Finally back home post DebConf9; felt reasonably productive and I have a lengthy todo list which I've even written down and started work on. More on that when any of them come to fruition.

Very much enjoying the return to easily accessible decent tea and salad/other vegetables. I haven't eaten any fish since my return and hopefully won't for at least a few days. Also I feel the need for an alcohol free week so my liver can recover. Back to work tomorrow - what is it I do again? Also, bets on how my cow orkers will react to my purple hair?

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.