This is the point where I should be writing something witty and intelligent about the election going on across the pond, but I can't think of anything worth saying. If you can, go and vote. Even if you think your side is going to win, go and bloody do it anyway.

Anyway. Today I achieved FDMI success; my code successfully registered my test cluster against the fabric switch it's connected to and reported various bits of information about itself. Hardly earth shattering but does at least indicate that I'm beginning to understand some details of Fibre Channel at the packet level and how to make our code send/receive them. Go 'bama me.

(FDMI is the Fabric Device Management Interface and a way for Fibre Channel devices to report things like their manufacturer, serial number, OS, HBA model and driver/firmware versions to a management controller on the switch fabric. It's not a complex protocol in any manner, but there's a distinct lack of clear Fibre Channel documentation around that's at a lower level than "So you want to hook up a SAN?")

If you ask the old timers about how they got started in Debian they'll tell you about sending off an email saying they wanted to get involved and having an account setup the same day. By the time I got round to joining it was during tbm's blitz when NM opened up again and it took only a few days to get through the process. When I first AMed, back in 2002, it took anywhere from a few days to a few months to process an applicant. I've recently started AMing again and so far my NM and I have exchanged 9 mails over the course of 2 weeks and still aren't through Philosophy and Procedures.

This isn't due to any failing on the part of my NM. It's just that there's a lot more "paperwork" to get through these days. There's currently a lot of discussion going on about the idea of introducing new classes of Debian involvement. I think that's something that's definitely worth looking at; it's already in existence for Debian Maintainers vs Debian Developers. However anything new that's introduced really needs to make some effort to be lighter than NM; someone who just wants to handle a few packages is going to get put off by too many hoops and the current NM process is already largely constrained by available AM time rather than anything else. I don't pretend to know what the right solution is, but I think anyone attempting to produce one should be praised for that rather than attacked.

Apparently I'm supposed to be blogging once a day, every day, for November. I missed yesterday and doubt I'll have something to say every day, but let's try...

Today I have been playing with the export-clean and import-clean options to gnupg, in particular in conjunction with the debian-keyring. The options result in only signatures that can be verified (ie that are from keys that exist in your keyring) being allowed, and remove signatures other than the revocation from revoked keys/uids.

Why is this interesting to me? Well, a number of reasons:

• It makes key updates a hell of a lot easier. It cuts down on the number of new signatures to check, for example.
• It cuts down on the keyring size, meaning smaller uploads for me and smaller downloads for everyone else. The .deb goes from 20M to 6.6M and the installed debian-keyring.gpg from 24M to 7.6M. That's a signficant saving.
• It makes for "cleaner" keys; only signatures that we know are valid end up remaining on the keys, anything invalid is removed.

(Note I haven't actually rolled any of this out, it's just something I've been playing with locally at present to get a feel for the savings/benefits to be had.)

As mentioned I bought an EEE 901. The battery life was the clincher. I've had it for about 3 weeks now, but have only really been using it for a week - since I finished doing my mobile broadband survey and got an Orange contract.

I can't really comment on the supplied Xandros install. I used it for a week or so, with Firefox + a shell for ssh (Ctrl-Alt-T IYF) but once I found time I installed Debian. I used the EEE installer which I think mainly does the appropriate ethernet driver magic without faff. Certainly went smoothly and all up and running minus wifi, which was soon sorted out with the rt2860-source package. Ethernet, bluetooth and camera all seem fine. SD reader is a USB device that appears when a card is inserted.

Battery life rocks. I can use it on the morning on the train (1hr30 or so), suspend to ram all day, use it on the train on the way home and then around the house in the evening without needing to charge it up. And that's while powering the USB 3G dongle and without any real tuning in terms of trying to save power by dimming the screen etc.

The keyboard *is* small. I wouldn't want this to be my main machine. However it is just about touch typable and the overall machine size is superb - even if I get a bad seat on the train I can still unfold the screen fully and it's my arms/elbows that end up being the issue rather than the laptop itself. I also notice the decrease in screen resolution down to 1024x600 (my old laptop is 1024x768); I can't fit enough xterms. :)

Speed seems fine too. I've not really pushed it hard (I've been resisting installing build-essential) but for a handful of xterms and Iceweasel it's doing a fine job. Equally firing up mplayer resulted in perfectly smooth playback of some mpeg4 over the network. Must actually remember to put something on it to watch on train journeys...

Speaking of train journeys the Orange dongle has integrated without too much hassle. 2.6.27-rc kernels have the appropriate hso driver but I found it caused crashes in areas of low/no signal. Patching up to the latest 1.6 driver solved the problem and adding PPTP to my work VPN into the mix means I can use offlineimap to pull mail locally and then read it with mutt on my journey even when the signal is fluctuating. Hopefully ridiculous starts can be mostly a thing of the past if I can get work done on the train.

What else to say? I'm quite liking the trackpad. The buttons are a bit stiff, but I'm getting used to the double tap, or tap and drag gestures in a way I never seemed to on the R200. Wifi reception seems fine. All in all I'm happy with my choice; the small keyboard is the main drawback and that's the (acceptable) price I pay for a small laptop.

For the past few weeks I've been trying to work out which "mobile broadband" provider to go with for my daily commute. It's a train journey from the north coast of Northern Ireland to Belfast and goes through some sparsely populated areas, so I wasn't expecting to get anything that would provide 3G all the way. However I do want a provider that can do their best to keep a session up for the journey, handing over between 2G + 3G as necessary. Coverage maps/checkers aren't too bad if you just want to check a static point, but really even then it's better to actually try the provider in the location yourself. So, armed with a bluetooth GPS (BlueNEXT BN-909GR), an Option GT 3G Quad PCMCIA card and my laptop I set about measuring signal strength along my train journey for each of the 5 providers available. I also made sure to actually try a session with them for at least one journey, because signal strength is not everything.

I wrote some Perl using Net::GPSD and Device::Gsm to query my current location, signal strength, 2G/3G status and network every 10 seconds. I did this for 3 train journeys (except for O2) and then also produced an "optimistic" file of all the data points combined for that provider.

A second piece of Perl took this data and drew the maps you see below. The graph on the right for each provider is all data points. Red means 2G, blue means 3G, green means "Limited Service" (i.e. it could see a signal, but not one it was allowed to connect to). White means that we had a GPS location and no signal at all. Click on the maps for bigger versions. You can see the route on OpenStreetMap - my graphs are a little squished horizontally, but the journey is from Castlerock (top left on the coast near Coleraine) to Belfast (bottom right).

At first glance 3 look to be the best bet. Lots of blue, a reasonably priced data plan. Except they can't hold up a session to save themselves. Not only does a 2G/3G handover almost always seem to result in a drop, but I had periods of failing to get a 2G session up at all and had some random drops while in 3G coverage as well. So strike them off.

O2 and T-Mobile don't manage any 3G outside Belfast (that's the bottom right corner btw). I found that a few periods of 3G along the journey helped a lot; it meant I could do a quick mail sync rather than the long drawn out affair it was on a 2G connection. They can both handle handover between 2G/3G and keep a session up for most of the journey, but the lack of speed counts them out.

Vodafone managed the worst reception, which is disappointing. I found them quite good when I lived in England (my datacard is from a Vodafone Pay as You Use data contract). I did find sessions being dropped during the no signal regions, so they just don't seem to be a good bet.

Which leaves Orange. I've had issues with Orange and data in the past (pre 2004 IIRC) but in testing they were able to keep a session up between Belfast and Castlerock, handling 2G/3G handover fine. Coverage was reasonably good and they manage 3G at several points along the journey (the blue points roughly correspond to Coleraine, Ballymena, Antrim and Belfast). I understand Orange have some EDGE capability, but my card doesn't do EDGE so I've no idea if that'll be an extra gain or not. I had a few issues with getting dud DNS servers but this happened with the other providers too so I was beginning to suspect the datacard of playing up. Manually setting known good servers in resolv.conf worked fine.

So, before I go and sign up to an 18 month Orange contract, what have I forgotten?