I'm off to DebConf next Thursday. I'm looking forward to it; I could do with a change of scenery and some time with friends. I'm having my usual "What do I need to bring?" worries and I got to wondering about which laptop to bring - since last year I've gained an EEE 901, but I still have my Toshiba R200.

In general I'm using the EEE these days when I'm not using my desktop - it's much more convenient to throw in an overnight bag. However the keyboard and screen are too small for hard core use. Which suggests I should take the R200. Except the EEE battery life is great and a small laptop is handy for use in talks. So I think I'll bring both. Which led me to think about the fact I don't use the R200 that much these days and why that is. And it's partly about all the various bits that live in my home directory that mean switching machine is a sort of context shift. That applies to my desktops too.

And then I had a thought. Both laptops have built in SD readers. So do both of the desktops I regularly use. Why not just put my home directory on an SD card? These are machines that I don't log into remotely, so the card being removed when I'm not in front of the machine isn't a problem (it means I have to log out, but I think that's acceptable). I'm not totally sure of the speed of the readers in the various machines, but I guess the best way to find out if it's doable is to try it.

So, various things to ponder:

• Card size. Do all my readers support SDHC? In which case I should get an 8G or 16G card. Otherwise 1G is probably the safest maximum size? I suppose I can order one of each; they'll get used somewhere even if it's not for this.
• Card make. I don't want something that's going to die after a week of use; I'll try to ensure cache directories and similar are symlinks to a local piece of storage but I don't have a feel for the number of writes my home directory normally sees. I like Crucial for RAM. How's their flash? Integral? Or just bite the bullet and accept Sandisk are going to be best, if pricey?
• Filesystem. ext3? Or will the journal kill the card faster - I understood this was less of a concern these days. Are ext4 or btrfs ready for this sort of use? Perhaps this is the right time to try; I can keep backups on every machine that uses the card easily enough.
• Crypto. I may as well encrypt the card for security as I doubt that'll end up being the bottleneck for access. Is dm-crypt the right thing? libpam-mount looks like it might let me tie things together in a simplish fashion.
• Union mount? It might be nice to have a basic home directory on every machine so I can login even if I don't have my card with me. Or have local configuration bits specific to each machine. Perhaps something for a bit further down the line - I'm not sure any of the unionfs options are in mainline kernels yet?

I suppose I'll do some card manufacturer investigation and try and get a couple of cards ordered in time to play with over DebConf.

I've known I was going for a while, but only finally booked the holiday off work and had it approved last week (unfortunately they're not giving me the time for free like last year. :( ). I'll be there for DebConf proper (ie 23rd until 31st). In the unlikely event anyone else is flying DUB<>MAD my flights are:

2009-07-23 06:00 (DUB) -> 09:30 (MAD) FR 7158
2009-07-31 20:15 (MAD) -> 21:50 (DUB) EI 595

I'm on the 16:25 Talgo from Madrid and then the 09:25 back on the 31st. Looks like I'll have company from the train booking page.

Also I've been doing the first draft of the room allocation. If you're expecting to stay at DebConf organised accommodation you should check your name is on this list with the expected dates, and email rooms@debconf.org if it's not.

With all the discussion about SHA-1 weaknesses and generation of new OpenPGP keys going on there's some concern about how the web of trust will be affected. I'm particularly interested in the impact on Debian; while it's possible to add new keys and keep the old ones around that hasn't worked so well for us with the migration away from PGPv3 keys. We still have 125 v3 keys left, many of them for users who also have a v4 key but haven't asked for the v3 key to be removed or responded to my email prodding them about it. I don't want to repeat that.

So if we're looking at key replacement we need to have some idea about where our Web of Trust currently stands, and what effect various changes might have on it. I managed to find the keyrings Debian shipped all the way back to slink and ran the keyanalyze and cwot stats against them. I then took the current keyring, pull in all the updates for the keys in it (so that any signatures from newly generated keys would be included) and ran the stats again. Finally I took details of 12 key migrations (mostly from Debian Planet but also a couple of others I knew about) and calculated what the effect of removing each key would be. These stats are cumulative and I replaced the most well connected (by centrality) keys first.

The results are below.

• Total is the total number of keys in the keyring
• SCS is the largest Strongly Connected Subset
• Reachable is the largest reachable subset
• MSD is the Mean Shortest Distance
• Centrality is the average centrality for the reachable subset
• update-foo indicates that foo's key was replaced with a newer one

This is actually more hopeful than I thought. There's an obvious weakening as a result of the migrations, but the MSD stays under 3 and the centrality stays fairly constant too. The reachable/SCS counts do decrease, but at this point it looks fairly linear rather than an instant partition. Of course the more keys that are removed the more likely this is to drop off suddenly. Counteracting that DebConf9 is coming up which will provide a good opportunity for normally geographically disperse groups to cross sign, reinforcing the WoT for these new keys.

Either way I at least have a better handle on the current state of play, which gives me something to work with when thinking about how to proceed. For now, bed.

I bought a new machine recently; for the flat at present with the aim of it becoming an upgrade for the media box once my lease is up. Nothing spectacular; E5200 Dual Core Pentium at 2.5Ghz, MSI G41M-FIDP mobo and 4G of OCZ DDR2 800. I don't need that much, but for £30 how could I resist? Total price, including the extra postage tax to NI and a small case, £200 from eBuyer. I had an existing HD I could use and also managed to find a spare DVD writer too.

I did a 64 bit lenny install from the multiarch netinst CD. There was a slight issue with partman getting confused at one point but I couldn't reproduce it so it might well have been user error. Network, graphics, sound all detected fine out of the box.

Anyway. Part of the reason for a G41 based board is that it's a fairly recent Intel chipset but slightly cheaper than the cutting edge G45. And Intel have been pretty good about getting decent support for their chipsets, both in X for 2D and Mesa for 3D. Unfortunately the X support in lenny isn't great; the driver (2.3.2) works, but I found I needed to disable acceleration for it to be reliable. And I wanted to take advantage of what the chipset could offer.

Helpfully there was a push of various shiny new bits of X into unstable last week, including libdrm 2.4.5 and xserver-xorg-video-intel 2.6.3. So I thought I'd give that a try. I don't want to track unstable on this box as it'll have pretty dire connectivity (Orange 3G at best). Testing may be a possibility but I'd need to sort out a way of pulling the updates via a USB stick on a better connected box - pretty sure I've seen things about doing this in the past so will have to investigate. For the moment I added an entry for unstable, set pinning to prefer lenny and told aptitude to install xserver-xorg-video-intel and mesa from unstable. While I can't possibly recommend this unless you're confident about being able to repair any resulting mess yourself I found it went quite smoothly and didn't pull in nearly as much new stuff as I feared.

The newer X/Mesa packages alone weren't enough. The PCI IDs for the G41 aren't yet in mainline kernels, let alone the 2.6.26 variant in stable. So I compiled up 2.6.29.1 with this patch and figured I'd enable Kernel Mode Setting at the same time. 2 reboots later (when setting KMS you don't want to enable the intelfb driver, but you do still need to enable the "Console on Framebuffer" option. Ooops.) and I had a shiny X install proclaiming OpenGL 2 hardware acceleration support and Xv. Plus switching between X and a text console was pretty damn smooth. Rockin'

On the whole I'm quite impressed, though I am seeing occasional freezes with Xine and Xv output - not sure what it's tickling as mplayer seems to be ok and I can't actually get any error output when it happens. Will try and hook it up to the network and see if I can still login that way at some point. For the moment it's still perfectly usable aside from that.

Nearly a month has elapsed since Debian released Lenny. The interesting thing for me about this release was that I failed to get to the point where running etch was causing me pain. This became even more evident when Katherine commented on my Lenny T-Shirt - I'd forgotten to mention our release to her! Previously there have been a bunch of features coming that I really wanted, sometimes to the point of using backports. It's probably something to do with the way I run Debian; I use stable for remote machines and while in the past this would have meant quite a few work boxes these days it's just a box at my parents' and my colo.

Where I felt the pain during this release cycle was on the boxes where I run unstable (my home desktop) or testing (my work box and my laptops). Development on new shininess slows down significantly while we're preparing for release (not unsurprisingly). And there are things coming up I quite like the look of, largely aimed at the desktop arena. I've been running Network Manager 0.7 from experimental on my EEE, for example - I need the HSO 3G support to avoid unnecessary faff on a daily basis. I've got ATI cards in my work and home desktops, so I'm watching the Mesa developments with interest - roll on OpenGL 2.0 support hopefully. The Intel KMS support that doesn't seem to be quite there yet but RSN, no, really, will be nice for my laptops. Experimental VDRs are looking interesting and perhaps worth upgrading my PVR to.

For a long time I haven't really understood the point of view that Debian shouldn't release. Or rather, I haven't understood why people would think that was a serious option. The first Debian box I installed went into a colo facility shortly afterwards. This is the first release I've not been running Debian on a commercial colo box and while I treat my personal colo in a similar fashion it's not quite the same in terms of priorities. However I still think regular releases are hugely important to the project. Some pain for those of us more interested in new shiny is a small price to pay for producing a flexible, reliable distribution, be they server administrators (though I see a worrying number of people decide to install testing on their production servers and then rarely/never update it), derivers or appliance vendors.

Mind you, now we've released I'm going to have to do all those things I've been putting off. I should probably start with moving my Perl bits into pkg-perl. And maybe I should switch over some sources.list files to point at squeeze instead of lenny...