And you wonder why people have a fear of flying.

The failure was ultimately down to a combination of human error and a design glitch in the Windows servers brought in over the past three years to replace the radio system’s original Unix servers, according to the FAA.

Full article

Really good article on Internet software patents and how “the old timers” already thought of most of the things we do today.

They couldn’t build our modern world for us back in the 1960s because the hardware hadn’t caught up. If you’d given them 50 million quad-core 2 GHz Pentium with 4 GB of RAM and 30 Mbps Verizon FiOS connections to every home, they would have built you all of the services of the modern Internet and probably many that would have been better.

What would happen if you gave present-day computer programmers those same powerful hardware gifts? We did that experiment. Our modern day best-and-brightest built Microsoft Windows Vista (TM).

About a month ago, a friend (John) mentioned that he was on a mission to try 20 different holiday/winter brews before the New Year. I happily accepted his challenge and so began our journey. Over the past month, we have hunted near and far for the worlds finest holiday beers. So far I’ve managed to try 15 different ones and all of them have been really good beers but the following five are special beers that you should definitely try this year.

First, the runner ups:

Jubilale

Brewery: Deschutes ABV: 6.7%

I’m a huge Deschutes fan. I really like their Hop Trip fresh hop ale, Mirror Pond and Black Butte Porter. Their winter brew, Jubilale, is a decent choice as well and would have made my top 5 last year (had I actually tried more beers last year).

Santa’s Little Helper

Brewery: Port Brewing ABV: 9.5%

I was recently introduced to Port Brewing (and the lovely Pizza Port chain of pizza “joints”). Let me tell you, this company creates some excellent beers. Santa’s Little Helper is a fair example of their talents. It’s an imperial stout with a lot of kick. It has a slight taste of alcohol at the end, but it’s a tasty little bugger. If you really want a good beer (and like extra hop), try their Hop 15!

5. Winterbraun

Brewer: Lost Coast ABV: 6.5%

Lost Coast’s label are always entertaining. The beer is usually always tasty and the Winterbraun is no exception. This is a nice brown ale with an excellent malty taste that’s easy to drink.

4. Celebration Ale

Brewery: Sierra Nevada AVB: 6.8%

From my alma mater hometown of Chico, CA. Their Pale Ale is one of the beers that brought the ale back into main stream in the early 90s. Every year Sierra Nevada makes the Celebration Ale to celebrate the holidays and it’s great every year.

3. Old Jubilation

Brewery: Avery ABV: 8%

Avery produces some very tasty ales. Old Jubilation is definitely one of them. Very crisp. This is the type of beer you want to have with you while sitting next to a fireplace on a cold winter’s night.

2. Yule Smith

Brewer: Ale Smith ABV: 9.5%

The first bottle I purchased of Yule Smith happened to be the summer version so be careful when looking for this beer. The summer version has fireworks on the label while the winter (holiday) version has a nice little wreath. Not that the summer version isn’t good (it was and I’ll look for that this summer for sure), but the holiday version was especially tasty. It slightly hoppy but not overly so.

1. Delirium Noël

Brewer: Brouwerij Huyghe ABV: 10%

This is an excellent beer! It’s a Belgium style ale with an extra kick. Despite its high ABV (Alcohol by Volume), it doesn’t have the alcohol taste. It’s smooth, flavorful and full bodied. It goes down easy and a pint full will definitely put you in the holiday spirit. Careful, this is a potent beer and will sneak up on you. Especially if you buy a 22oz bottle and enjoy the whole thing in one sitting.

In all fairness, all the beers I’ve had this year were excellent examples of what todays smaller breweries have to offer. Sure some where tastier than others, but overall, I was never dissatisfied. I’ll post a full list when the competition is over.

Unfortunately, the complexity of a feature is usually inversely proportional to its simplicity from a user’s perspective.

Dealing with this on a project at work. So true.

I just noticed that my MacBook Pro’s memory usage was rather high. I’m not working on anything memory intensive (Vmware, Photoshop, etc). So I opened up Activity Monitor to find this

Why the hell is Preview taking up nearly 350 MB of ram with NO windows open? I don’t remember opening any large files with it. I’ve been gone all day. I smell a leak!

I’ve been using Amazon’s S3 service for a couple months now. It was working OK using s3sync and a cron job, but it seemed like it wasn’t actually making incremental backups and I wasn’t 100% sure that it was backing up everything (i.e. it appeared to be crapping out once in a while). I searched around for various S3 backup solutions and found a handy utility called duplicity. Even more handy that it is available for most distributions (Archlinux, the debs, and Fedora anyway).

From the duplicity home page:

Duplicity backs directories by producing encrypted tar-format volumes and uploading them to a remote or local file server. Because duplicity uses librsync, the incremental archives are space efficient and only record the parts of files that have changed since the last backup. Because duplicity uses GnuPG to encrypt and/or sign these archives, they will be safe from spying and/or modification by the server.

What you’ll need

You’ll need to make sure you have a few things installed before you install duplicity. Namely librsync and GnuPG. Luckily, if the duplicity package is available for your distribution, you probably needn’t worry.

Here’s a rundown of the steps involved:

1. Generate a new GnuPG key
2. Create a simple shell script wrapper
3. Create a cron job

Generating a new Key

Start by generating a new gpg key for duplicity. Or if you have an existing one, you can use that.

N.B. I set this up on a Slice running Arch64 and had problems generating a new key (gpg --gen-key). Apparently, it could not generate enough entropy. Not a problem though: Just generate the keys else where and import them later if this happens to you.

#~ gpg --gen-key
gpg (GnuPG) 1.4.7; Copyright (C) 2006 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Please select what kind of key you want:
(1) DSA and Elgamal (default)
(2) DSA (sign only)
(5) RSA (sign only)
Your selection?

Default (DSA and Elgamal) is fine here.

DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)

The default (2048) is more than enough for this. Change it to whatever you want.

Requested keysize is 2048 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)

Unless you want the key to expire (I don’t see why one would want that), the default is what we want.

Key does not expire at all
Is this correct? (y/N)

Um, yes, this is correct.

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name: DuplicityBackup
Email address: duplicity@mydomain.com
Comment: Key for Duplicity
You selected this USER-ID:
    "DuplicityBackup (Key for Duplicity) <duplicity@mydomain.com>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?

Enter whatever information you want here and type ‘O’ for ‘Okay’

You need a Passphrase to protect your secret key.

Enter Passphrase:

Enter something. Anything. The more complex the better. This is your private data. Remember that it’s being transfered over http to a server you don’t own. I don’t care if it is Amazon. Remember what you type because you’ll need it later while creating the wrapper script.

gpg: key **9929DAB1** marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   2  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 2u
pub   1024D/9929DAB1 2007-11-15
      Key fingerprint = 3378 8E93 4349 0E7F 44F3  7C81 2460 5A11 9929 DAB1
uid                  DuplicityBackup (Key for Duplicity) <duplicity@mydomain.com>
sub   2048g/5385A6BB 2007-11-15

And you’re done. Make note of the key (in this case, 9929DAB1) as we’ll need that later too.

But I already have a key I want to use

OK, fine, but chances are, if you have a key already, you know how to get it. However, if you don’t know how to get your key, gpg --list-keys. You want the key in the ‘pub’ line… after the forward slash ‘/’

The Wrapper

This can be written in any language really. I chose shell because it’s easy and basic. You could run the duplicity now on the command line, but writing a wrapper is much more convenient and makes adding a cron job later a lot easier. Here’s what you’ll need:

• Your Amazon S3 Access Key ID and Secret Access Key. If you don’t have one, you’ll have to sign up for one.
• Your GPG key
• Your GPG key’s passphrase
• A list of directories you want to back up

Here’s a basic script that works for me:

#!/bin/bash
# Export some ENV variables so you don't have to type anything
export AWS_ACCESS_KEY_ID=<your-access-key-id>
export AWS_SECRET_ACCESS_KEY=<your-secret-access-key>
export PASSPHRASE=<your-gpg-passphrase>

GPG_KEY=<your-gpg-key>

# The source of your backup
SOURCE=/

# The destination
# Note that the bucket need not exist
# but does need to be unique amongst all
# Amazon S3 users. So, choose wisely.
DEST=s3+http://<your-bucket-name>

duplicity
    --encrypt-key=${GPG_KEY} \
    --sign-key=${GPG_KEY} \
    --include=/boot \
    --include=/etc \
    --include=/home \
    --include=/root \
    --include=/var/lib/mysql \
    --exclude=/** \
    ${SOURCE} ${DEST}

# Reset the ENV variables. Don't need them sitting around
export AWS_ACCESS_KEY_ID=
export AWS_SECRET_ACCESS_KEY=
export PASSPHRASE=

And, that’s pretty much it. Save the file as something creative, like, backup and make it executable (chmod 700 backup). If you want to test it first (and you have the disk space), change the destination to some /tmp directory or external HDD. Once you’ve got it working the way you want, set it up as a cron job. Daily, weekly, monthly… doesn’t matter.

Duplicity is a nice backup solution for any situation, not just Amazon’s S3. It can handle HTTP, SCP and local backups as well. I highly recommend reading the duplicity man page and checking out the various command line arguments and availble options.

A couple of Thanks goes out to Tim McCormack’s and Ben and Ron’s articles which got me started.

Tim points out that, adding your GPG PASSPHRASE to the shell script might not be the most secure method, especially in a shared environment. I agree, however, it kind of defeats the purpose of automated backups if you have to actually enter your passphrase (twice) on the command line when calling the wrapper script. One way I managed to go around this is to create a simple C++ application that prints the passphrase.

Here’s the C++ code:

#include <stdio.h>
int main()
{
    printf("your-gpg-passphrase");
    return 0;
}

Compile

#~ gcc gpg-passphrase.c -o gpg-passphrase

Make it executable by your user and set the sticky bit so no one else can execute it

#~ chmod 700 gpg-passphrase
#~ chmod +s gpg-passphrase

Modify the wrapper script to use the binary for the passphrase

export PASSPHRASE=$(gpg-passphrase)

You might go as far as to do the same thing for your AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as well. There are probably other ways around this, but this was a quick a dirty way to not have readable strings in shell scripts. I figure, if someone has rooted my server, I’ve got bigger problems to worry about than my data sitting on Amazon’s S3.

See here, Bullet point number one:

Logging in with an account originally created in Mac OS X 10.1 or earlier that has a password of 8 or more characters.

Mac OS X 10.1 came out just over six years ago in 2001. If you’ve been using the “upgrade” option every time you update your OS X version, I think it’s time you performed a fresh install. Especially on such an old system (what do you have, an original Quicksilver? No? Older?). If you’ve made it this long without having to do a clean install, congratulations. You’re one of very small number of people. Hell, I haven’t kept a computer for longer than two or three years.

I bought my first Apple in 1997 — PowerPC G3 300Mhz (of the Beige kind). I bought my second Apple in 2000 — Quicksilver 733Mhz (non-shiny doors). Sold the G3 in 2002 (or so). I bought my first Powerbook in 2003 (G4 1Ghz Titanium) slightly used from a nice girl (with buyer’s remorse) in San Francisco. It took a dump about two years ago and I succumbed to way of cheap x86 hardware and Linux. But I redeemed myself about a year and a half ago when I bought my second Apple laptop (Macbook Pro 2.16Ghz).

I digress. What I’m saying is that, even if you’re lucky enough to have the same computer for the last six years (or more), I doubt you’d be as lucky going through four separate system upgrades (assuming you upgraded every version). Even if you didn’t and you went from 10.1 directly to 10.5, I highly doubt Apple spent much time testing that upgrade path (if at all).

View from the Palace Hotel in San Francisco, CA

• 2560×1024

Radiohead is free from their EMI contract and free to do what they will with their latest release. Sell where they want, when they want and charge whatever they want for it as well. Which is why it makes sense to do what they are doing now: Sell it for how much YOU, the listener, thinks it (or the band itself) is worth. I imagine it’s akin to jumping down a rabbit hole; you never know where the idea of leaving it up to the consumer to pay for your products will end up. I’m not quite sure how it will pan out, but I’m fairly confident that Radiohead will make out O.K.

I’ll admit that when I first read of the It’s up to you pricing scheme of the new release, the first thing that popped into my head was, “Sweet! Free music without the guilt.” But then I stopped to think about what Radiohead was actually doing. They could charge whatever they wanted for the digital download of In Rainbows (even if it were only a few bucks for the album). They spent the better part of two and half years working on this album. Even if they didn’t work 40 hour work weeks writing/recording/mixing, it’s still a chunk of someone’s life. What’s that worth?

I know Radiohead could probably afford to just give the download away, but then the album would loose it’s worth. A friend of mine told me a story about this rather nice office chair he wanted gone. It was your average office chair and was in pretty good shape. He had put it out on the sidewalk in front of his house with a sign that read “FREE.” The chair sat in the same place for a week. No one wanted it. After a week, he put a different sign on it. This sign read “$5.” The chair was gone by the time he got home from work. It’s like the word “Free” has a neutral connotation (maybe even negative for some people) where it means, “Oooh, it’s FREE!” or “It’s free? Why?” I suppose it also depends on the “what” as well, but there are a LOT of people downloading free music everyday (just ask the record labels).

For me, I’m much more willing to shell out a ten-spot for an album when I know that most of that will end up directly in the pockets of the artists. In fact, I was “this” close to pulling the trigger this afternoon on the pre-sale, but I was either too lazy or too busy to pull the wallet out of my back pocket to get my credit card. I will buy this album. I won’t say for how much.

The only possible downside of this pricing scheme maybe the guilt factor of paying too little over paying nothing at all. It’s easier to just leave the field blank than to have to quantify the value of the album/artist. Even when you really like the artist and have complete faith that the album will nothing short of stellar. However, that said, I also believe most people are honest (maybe I’m naive). I predict more people will pay something than nothing. It will be interesting to see how this pans out.

Thom, if you’re reading this, drop me a line in 6 months and let me know how well this business model works out.

A snail I snapped in Kauai.

• 2560×1600
• 1920×1050
• 1440×900
• 1600×1200
• 1280×1024
• 480×320