Quick update on the ginger wine front, I'm having real trouble getting the yeast to do its thing on the wine.

I'm using EC1118 at the recommendation of the fine people over at Brewcraft, but it's been difficult to get it to do anything much past pitching it.

At first I thought it was temperature related, but keeping it insulated and actively heating it during the night hasn't helped any.

Now I'm beginning to think that either the pH of the ginger wine solution is too low, or that the solution is anaerobic because it's so dense... something like that, yeah.

Will have to call the good people at Brewcraft unless anyone has some advice for me?

For about a year or so now I've been hosting my Email, Website and other related services off Slicehost. As I don't host people's websites en masse any more, this makes sense financially - which frees up money for other projects.

When I evaluated where to put my slice originally, I looked at a few VPS providers:

• Slicehost
• RedWood Virtual
• Linode
• GANDI

Based on price and feature sets, I ended up trialling Redwood, GANDI and Slicehost to see what their service was like. From a technology point of view, I was looking for a Xen or VMWare based provider, no KVM or Virtualbox providers for me, kthx.

GANDI, being relatively new at the game - managed to irrecoverably lose my slice image in the first week. Bad luck on their part, but ruled it out for me.

Redwood's management tools weren't great, and dealing with support was a bit average, but otherwise things were okay. Not so okay was having storage not showing up as a block device. I'm not actually sure these guys were running Xen, but I'd been curious to go with them after hearing good things.

Slicehost, as well as boasting a recommendation from one of my colleagues - had some good management tools and just worked(tm). Also appreciated is that their kernel management seems to play nicely with Debian/Ubuntu package management (ie: they didn't piss over each other).

So in the last year I've had a pretty good experience, and only a few hiccups - most notably a bug in the management tool which caused my host to run a newer kernel without installing any of the loadable modules outside of the initrd. That and some really big process queues from IO wait lately.

Now I'm in the situation where I'd like to upgrade to Ubuntu/Lucid, the latest Long-Term-Support edition - so I can continue to receive security updates into the future.

Let's start by saying I'm not normal. I don't like to dist-upgrade boxes between major releases. There's something not quite right about doing an in-place upgrade on your init, really. As such, my boxes are built to be blown away and reinstalled easily.

Unfortunately, with the Slicehost management tools there just doesn't seem any easy way to create a new slice, mount the old image and copy files across whilst keeping the same IP. The only solutions are to create a new slice, and use the private interface IPs to copy between them, and set up for a new IP.

Which sucks, so I don't know what to do. I've just shot a support ticket to Slicehost to find out, but it would be nice to be able to just mount the old image on a new box.

As it turns out, this is not only possible on Linode - but downright easy. Whilst fixing someones Linode (funnily enough, from a broken dist-upgrade to Ubuntu/Lucid), I got a good chance to play with their management tools: they're awesome.

Want to create your own customised partition layout (instead of using an all-in-one layout)? No problems. Want to create multiple block devices? No worries. Want to boot into a new image with the old one available? No problems.

Oh, and it turns out that Linode have updated their plans to be more competitive for RAM and Storage. Going from a 512 slice to a 1024 slice will cost the same - and you'll get the benefits of better management tools.

Theres a lot more info on their management tools available on their site than there used to be also, so worth checking out: http://www.linode.com/features.cfm

So I've had a quick look at the bandwidth and latency from the various Linode datacentres, overall not bad at all.


11:10:07 (740.23 KB/s) - `100MB-london.bin' saved [104857600/104857600]
11:12:56 (696.35 KB/s) - `100MB-newark.bin' saved [104857600/104857600]
12:18:09 (844.26 KB/s) - `100MB-atlanta.bin' saved [104857600/104857600]
12:23:42 (987.36 KB/s) - `100MB-dallas.bin' saved [104857600/104857600]
12:27:51 (840.12 KB/s) - `100MB-fremont.bin' saved [104857600/104857600]


The Fremont DC was flapping between 750KB/s 1.2MB/s, whilst most others stayed reasonably constant.

And the round trip times are also quite good:

london: rtt min/avg/max/mdev = 348.397/349.640/363.074/1.498 ms
newark: rtt min/avg/max/mdev = 284.731/285.829/303.533/1.992 ms
atlanta: rtt min/avg/max/mdev = 268.222/269.473/296.800/2.947 ms
dallas: rtt min/avg/max/mdev = 249.007/250.088/261.556/1.603 ms
fremont: rtt min/avg/max/mdev = 211.310/212.034/213.691/0.578 ms


Packet loss was 0 or negligible on all tests, so I'll leave it out for the purposes of simplicity. Also, for a baseline, here's a test from the same network to my existing slice:


13:29:59 (808.72 KB/s) - `100MB-autodeist.bin' saved [104857600/104857600]

rtt min/avg/max/mdev = 255.246/255.970/257.267/0.723 ms

Transfer speeds from my slice also flap fairly heavily between 450KB/s and 1.3MB/s.

Whilst these tests are only useful for an indication only, the RTT times gave me pause on what DC I would choose. Originally it was a toss up between Atlanta/Dallas - but with the fairly consistent low response times from Fremont, that might just be the contender. Obviously this benefit is from being geographically closer to the cable landings in the US.

So what happens now? I'm pretty tempted about the move, so I might sign up an account on Linode to test with, and if it runs smoothly and as expected - I could be moving host soon, hopefully for the last time in a while.

I'll update soon :)

Whilst carefully evaluating a number of the proprieters of fermented goods at the local Good Food & Wine expo, or rather - trolling for tastings, I came across the booth for Stone's, a popular european brand of ginger based goosd - most notably their ginger wine.

If you haven't sampled their mouth candy, you must. Their alcoholic ginger beer and ginger wine is worth it - and I'm sure I'll be a regular buyer - once I find a bottle shop that stocks it nearby.

In the meantime though, I thought I'd give it a go for myself. Of course I did.

Well, it turns out there aren't that many recipes to be found. Of the several recipes I looked at, exactly zero of them used all the ingredients they specify - and don't inspire confidence. So in my usual tradition - I decided to wing it.

So, here's my recipe for ginger wine, complete with exact measurements:

• 1 big-ass bit of ginger, thinly sliced
• 1.5ish kg of white sugar
• 2 lemons, zested and juiced
• 2 oranges, juiced

1. Boil up about 2.5L of water in a saucepan, add ginger and lemon zest.
2. Simmer for 15 minutes.
3. Drain off juice into a second saucepan.
4. Bring ginger and another 2.5L of water to the boil in the saucepan.
5. Whilst the first saucepan is coming to the boil, heat the second and stir in all the sugar until it dissolved, then remove from heat.
6. Drain off the ginger and put the liquid into the first saucepan, stir.
7. Cover with a teatowel and stand for 12 hours.
8. Warm the juice up a little bit and add some activated wine yeast
9. Covering with a teatowel, stir twice a day for 3-5 days
10. Strain the liquid into a demijon with an airlock.
11. After twelve weeks of fermentation, rack every 3-4 months until it is has been going for 12 months.
12. Bottle and enjoy.

As I write, I'm only up to stage 7, so pretend I've got a bottle of Stone's, with a fresh linen covering the label - some I prepared earlier.

Updates as they come - I can't wait :)

For a while now I've been wanting to put together a system-on-disk, a USB stick I can use on the road which gives me a comfortable linux desktop with all the apps I might need.

It turns out that the Ubuntu Desktop LiveCDs already have a nifty persistent mode, where it will save any filesystem changes to a seperate partition with the label 'casper-rw'. That's great, and a lot of the work out of the way towards getting the project done.

There are a few guides out there for getting this going on a USB key, most notably on the PenDriveLinux website. Following this guide is pretty straightforward, and can get you up and running in no time.

Unless of course, you run certain Phoenix-based BIOS firmwares on your computer. My work Dell (the primary use for this project) runs such a BIOS, and misreports the device IDs for bootable USB keys. The good fellows who put together Syslinux have a patch in place, so if you use the latest Syslinux (newer than that which is available in Ubuntu 10.04) this is supposed to fix it.

Sadly this wasn't the case, and after a long time I ended up switching from FAT16+Syslinux to EXT2+Extlinux, which worked straight off the bat.

Now to forge ahead with the encryption side of things.