Ian Wienand: Durable photo workflow
Ever since my kids were born I have accumulated thousands of digital
happy-snaps and I have finally gotten to a point where I'm quite happy
with my work-flow. I have always been extremely dubious of using any
sort of external all-in-one solution to managing my photos; so many
things seem to shut-down, cease development or disappear, all leaving
you to have to figure out how to migrate to the next latest thing
(e.g. Picasa shutting down).
So while there is nothing complicated or even generic about them,
there are a few things in my photo-scripts repo that might help others
who like to keep a self-contained archive.
Firstly I have a simple script
to copy the latest photos from the SD card (i.e. those new since the
last copy -- this is obviously very camera specific). I then split
by date
so I have a simple flat directory layout with each week's photos in
it. With the price of SD cards and my rate of filling them up, I
don't even bother wiping them at this point, but just keep them in the
safe as a backup.
For some reason I have a bit of a thing about geotagging all the
photos so I know where I took them. Certainly some cameras do this
today, but mine does not. I have a two-progned approach; I have a
geotag script and
then a small website easygeotag.info
which quickly lets met translate a point on Google maps to exiv2
command-line syntax. Since I take a lot of photos in the same place,
the script can store points by name in a small file sourced by the
script.
Adding comments to the photos is done with perhaps the lesser-known
cousin of EXIF -- IPTC. Some time ago I wrote python bindings for
libiptcdata and it has been
working just fine ever since. Debian's python-iptcdata comes
with a inbuilt script to set title and caption, which is easily
wrapped.
What I like about this is that my photos are in a simple directory
layout, with all metadata embedded within the actual image files in
very standarised formats that should be readable by anywhere I choose
to host them.
For sharing, I then upload to Flickr. I used to have a command-line
script for this, but have found the web uploader works even better
these days. It reads the IPTC data for titles and comments, and gets
the geotag info for nice map displays. I manually coralle them into
albums, and the Flickr "guest pass" is perfect for then sharing albums
to friends and family without making them jump through hoops to
register on a site to get access to the photos, or worse, host them
myself. I consider Flickr a cache, because (even though I pay) I
expect it to shut-down or turn evil at any time. Interestingly, their
AI tagging is often quite accurate, and I imagine will only get
better. This is nice extra metadata that you don't have to spend time
on yourself.
The last piece has always been the "hit by a bus" component of all
this. Can anyone figure out access to all these photos if I suddenly
disappear? I've tried many things here -- at one point I was using
rdiff-backup to sync encrypted bundles up to AWS for example; but
I very clearly found the problem in that when I forgot the keep the
key safe and couldn't unencrypt any of my backups (let alone anyone
else figuring all this out).
Finally Google Nearline seems to be just
what I want. It's off-site, redundant and the price is right; but
more importantly I can very easily give access to the backup bucket to
anyone with a Google address, who can then just hit a website to
download the originals from the bucket (I left the link with my other
"hit by a bus" bits and pieces). Of course what they then do with
this data is their problem, but at least I feel like they have a
chance. This even has an rsync like interface in the client, so I
can quickly upload the new stuff from my home NAS (where I keep the
photos in a RAID0).
I've been doing this now for 350 weeks and have worked through some
25,000 photos. I used to get an album up every week, but as the kids
get older and we're closer to family I now do it in batches about once
a month. I do wonder if my kids will ever be interested in tagged and
commented photos with pretty much their exact location from their
childhood ... I doubt it, but it's nice to feel like I have a good
chance of still having them if they do.
DebConf16 will take place in Cape Town, South Africa in July 2016. We strive to
provide an intense working environment and enable good progress for Debian and
for Free Software in general. We extend an invitation to everyone to join us
and to support this event. As a volunteer-run non-profit conference, we depend
on our sponsors.
Nine companies have already committed to sponsor DebConf16! Let's introduce
them:
Our first Platinum sponsor is 
When I started contributing to 
Julian has
Last week we've finally released 
In the interest of being as brief as possible (just ask for details if you
want to know more or if you think that it would help), I have started,
against my preferences, to start using chromium from Debian instead of
Firefox (aka, Iceweasel).
The reason? I have a slow computer (a Core 2 Duo T7250). My main computer.
My workhorse.
There are some sites that even with an empty profile and a vanilla Firefox
build right from Mozilla Foundation cause Firefox to generate a very heavy
CPU load. I 
As my readers probably are well aware, I wrote my 
In January and February of 2016 I ran an Obnam user survey. I'm not a
statistician, but here is my analysis of the results.
Executive summary: Obnam is slow, buggy, and the name is bad. But
they'd like to buy stickers and t-shirts.
Method
I wrote up a long list of questions about things I felt were of
interest to me. I used Google Forms to collect responses, and exported
them as a CSV file, and analysed based on that.
I used Google Forms, even though it is not free software, as it was
the easiest service I got to work that also seemed it'd be nice for
people to use. I could have run the survey using 
Propellor was recently ported to FreeBSD, by Evan Cofsky. This new feature
led me down a two week long rabbit hole to make it type safe. In particular,
Propellor needed to be taught that some properties work on Debian, others on
FreeBSD, and others on both.
The user shouldn't need to worry about making a mistake like this;
the type checker should tell them they're asking for something that can't
fly.
What happened in the 
One common testing anti-pattern is a single testcase that loops over multiple yet independent inputs:
The fourth update in the 0.12.* series of 
[I wrote this as part of