Daemonic Dispatches

Thoughts on the Tarsnap logo contest

Coming as I do from the worlds of academia and open source software, it was only natural that when I decided that my online backup service needed a logo, I turned to the "crowd" with a $500 contest. While I considered using one of the many logo-design-competition sites, I decided to run the contest myself for a simple reason: Tarsnap isn't exactly like most commercial products, but it has an enthusiastic user community who understand the mindset behind it. Tarsnap is not just "online backups for the truly paranoid"; it's also very much unix software, in the sense of "do one thing well", "keep it simple (stupid)", and "tools, not policy". Running the contest myself and announcing it via the tarsnap-users mailing list might have decreased the number of graphic designers participating, but I'm sure it increased the number of people who knew something about Tarsnap. (I did, however, keep one such site in mind as a backup plan in case I didn't like any of the submitted logos.)

I announced the contest on September 28th, and set a deadline of October 31st for submissions. During this time, 83 people submitted over 100 designs — with over half of them arriving in the first three days. Based on the numbers alone, it sounds as though a shorter contest period would have worked well; but there was a general tendency that the logos submitted later looked like they had received more thought, so I'm glad I resisted the temptation to set an earlier deadline.

Getting people to submit logos was easy; selecting one was much harder. I started by performing a rough pass, throwing out the logos which seemed (to my eye) to be ugly, too generic, or simply not conveying the right message (that Tarsnap is secure, serious, and reliable, as opposed to colourful and fun); this left me with 16 logos. I took these to an informal "focus group" consisting of friends, family, long-time Tarsnap users, and other startup founders (there was considerable overlap between those categories), and came away with two logos which were clearly superior to the others — but for a variety of reasons didn't quite work as they were.

The following few weeks convinced me that Rorschach should have skipped the ink blots and used corporate logos instead. One of the two remaining designs — a reel of tape with a keyhole — was immediately identified by younger members of my focus group as being a Poké ball; upon revisions, it morphed in the eyes of other people into a radiation warning symbol, a peace sign, and a car steering wheel. The other leading logo, after being changed from a stack of documents with a keyhole to a stack of disks (the original was too similar to Buffer's logo) was immediately identified instead as a cylinder lock, a stack of pancakes, and a stack of cookies. After many round trips with the designers of the two logos, I eventually decided that anything I picked was going to end up giving someone the wrong idea — but if people were going to look at the logo the wrong way, a stack of pancakes was at least better than a radiation warning symbol. The winner, as promised, received $500; I decided to create a second prize of $100 for the designer of the other logo, in part as an apology for the time I took up asking him for revisions.

Once I was satisfied with the image — and had redrawn it in MetaPost, for my ease of manipulation — I created three variants for different sizes of usage: The image next to the name "Tarsnap", underlined by the tagline "Online backups for the truly paranoid" (for use at the top of the Tarsnap website); the image above the name "Tarsnap", creating a square logo (for use on the FreeBSD Foundation's sponsors list); and the image alone (for use as a website favicon and on the @tarsnap twitter account).

Overall, I'm quite happy with how this went, and I'm very happy with the final logo. I did however learn some lessons, which I'll list here for the benefit of anyone else considering such a process:

1. Everything takes longer than you expect.
2. It's essential to have a way to make people aware of the contest — enthusiastic users, twitter followers, name recognition within an online community, or ideally all three.
3. Find a group of people to help you narrow down your list, and when they (mostly) agree, listen to them. The submission the final logo was derived from was 8th on my personal preference list.
4. Don't expect to find a logo which everybody likes — it won't happen. But if someone has a seriously bad reaction to a logo (e.g., "it looks like a radiation warning sign") rather than merely a lack of enthusiasm, move on to another design.
5. If you're going to have a combination of image and text, you can decide how the two should fit together long before knowing what the image will be.
6. If you show someone a logo and ask "what does this look like?", be prepared to be astonished.
7. Everything takes longer than you expect.

Should all companies get their logos this way? Absolutely not: A large company will probably be better off hiring artists, while at the opposite end of the spectrum, a company without any public presence would need to use an existing design-contest site in order for anyone to even notice that the contest existed. But was this the right way to get a logo for Tarsnap? Yes, I think it was.

Introducing configinit

I have been working on bringing FreeBSD to the Amazon EC2 platform since 2006, and for the past three years I've been blogging about my progress: First FreeBSD on t1.micro instances, then cluster compute instances, then "m1" and "m2" family large and xlarge instances, and finally in early 2012, FreeBSD could finally run on all EC2 instance types. Once I had a hacked-up version of FreeBSD which ran smoothly, I turned my attention towards polishing it: First moving my EC2 scripts into the ports tree, then using binaries from the release ISOs for the FreeBSD world, and finally in early October (with FreeBSD 10.0-ALPHA4) all the necessary bits had been merged to make it possible for me to build EC2 images completely (including the kernel) with "straight off the ISO" binaries. Next on my agenda was taking my images from "pure FreeBSD" to "FreeBSD set up to be used in the cloud", and for that I'm happy to now announce that starting from 10.0-RC1, my FreeBSD AMIs have a new feature: configinit.

Anyone who has been around the world of cloud computing for long is likely to have heard of CloudInit. It is a system originally written for Ubuntu which performs configuration of a system at boot-time based on "user-data" provided via EC2 or from a similar environment (e.g., OpenStack). CloudInit works well for its original purpose, but is less than ideal for FreeBSD systems, for two reasons: First, it relies on Python, which is not part of the FreeBSD base system; and second, it is designed around a concept of configuring a system by running commands rather than editing configuration files.

Now, there are merits to both approaches — most notably, configuring a system by running commands is easier to script, while configuring a system by editing text files has the advantage that given a working configuration there's no doubt about how to reproduce it — but the fact that BSD systems are far more edit-configuration-files oriented (to the point that /etc/rc.conf might be the only configuration file which needs to be edited on some systems), and thus CloudInit is less than optimal for configuring FreeBSD systems.

Enter configinit. Rather than providing instructions such as "tell apt to use this mirror" or "run this python code", configinit handles four types of input:

1. If the configuration data starts ">/path/to/file" then the data, minus the first line, will be written to the specified location.
2. If the configuration data starts ">>/path/to/file". then the data, minus the first line, will be appended to the specified location.
3. If the configuration data starts "#!", it will be executed (in most cases this would be a shell script).
4. For any other inputs, configinit attempts to extract the file as an archive, and (if extraction was successful) runs on each part in turn. The extraction is performed using bsdtar, so archives in tar, pax, cpio, zip, jar, ar, xar, rpm and ISO 9660 formats, optionally compressed using gzip, bzip2, xz, or compress can all be used.

This is much simpler than CloudInit, but — in combination with other tools which are already available on FreeBSD, such as my firstboot-pkgs port, it provides very powerful yet easy-to-use functionality. For example, launching a FreeBSD 10.0-RC1 EC2 instance with the following user-data:

>>/etc/rc.conf
firstboot_pkgs_list="apache22"
apache22_enable="YES"

will provide a system with Apache 2.2 installed and running (in my test, within 150 seconds of when I clicked "launch" in the EC2 Management Console) — in addition to performing the other default system initialization behaviours of my EC2 images: checking for updates to the FreeBSD base system, downloading an SSH public key to allow SSH logins as ec2-user, logging SSH host keys to the EC2 console, and autoconfiguring swap space using EC2 ephemeral disks.

I know for my purposes this will be very useful — for example, while I have the process of configuring a new Portsnap mirror mostly scripted now, using configinit I could have it entirely scripted and avoid the need to ever SSH into the mirrors — and from what other FreeBSD users have told me, I don't think I will be alone. Is there anything else I could do to make FreeBSD even more usable in EC2? Quite likely — but I don't know what. If I'm missing something important, please let me know!