Not that I ever thought I wasn't going, but due to some uncertainty about where I needed flights from I've only got round to booking things today - wish I'd gone ahead and done it last week!

Outbound:

2010-07-31 10:55 BHD -> 12:15 LHR BD85
2010-07-31 16:20 LHR -> 19:00 EWR VS001

Inbound:

2010-08-08 18:15 JFK -> 06:35 LHR VS004
2010-08-09 10:55 LHR -> 12:20 BHD BD84

See you all there!

Nearly a year ago people starting worrying about the complexity of SHA-1 being reduced and the potential availability of viable attacks against things such as PGP keys that used SHA-1. Many people (myself included) generated a new key, or updated preferences on keys that were otherwise strong enough. There were worries about what this might mean for Debian. We were getting ahead of ourselves a bit though. Firstly there haven't been any public viable attacks that I'm aware of (though of course this doesn't mean we shouldn't continue to migrate away), but secondly there's a much easier method of attack. PGP v3 keys. To quote RFC4880:

V3 keys are deprecated. They contain three weaknesses. First, it is relatively easy to construct a V3 key that has the same Key ID as any other key because the Key ID is simply the low 64 bits of the public modulus. Secondly, because the fingerprint of a V3 key hashes the key material, but not its length, there is an increased opportunity for fingerprint collisions. Third, there are weaknesses in the MD5 hash algorithm that make developers prefer other algorithms. See below for a fuller discussion of Key IDs and fingerprints.

At the time of writing Debian has 21 remaining v3 keys. This is a significant improvement over a year ago, when we had 200, but it's still 21 more than I'd like. I've been chasing people since last May (starting with those who had v3 + v4 keys, all of whom now only have a v4 key) and we're down to the stragglers. So it's time to name and shame, in the hope of kicking them into action. The following keys are what's left (doesn't match the currently active keyring because we've had a few replacements since the last promote):

0x0D2156BD3D97C149 Michael Stone <mstone>
0x225FD911CD269B31 Carlos Barros <cbf>
0x31E73F14E298966D James R. Van Zandt <jrv>
0x366CD3FEEBC11B01 Chris Waters <xtifr>
0x37A73FE355E8BC4D Frederic Lepied <lepied>
0x3E973117DCC528E9 Ardo van Rangelrooij <ardo>
0x5C7A46637953F711 Rich Sahlender <rsahlen>
0x5D6560F85F30F005 Craig Brozefsky <craig>
0x6B0E322836129171 Jim Westveer <jwest>
0x723724B4A5B6DD31 Christian Meder <meder>
0x7629B22ED71DAABD Adrian Bridgett <bridgett>
0x8FFC405EFD5A67CD Adam Di Carlo <aph>
0xB0D269DE17F3D4D1 Matthew Vernon <matthew>
0xBC151FC8D2A913A1 Peter S Galbraith <psg>
0xC1A0A171C2DCD3B1 Jim Mintha <jmintha>
0xC3168EBA23F5ADDB Ian Jackson <iwj>
0xCE951B1160D74C7D Patrick Cole <ltd>
0xE82A8B0D57137FE5 Paul Seelig <pseelig>
0xF20E242CE77AC835 Brian White <bcwhite>
0xFBAA570C3087194D Alan Bain <afrb2>
0xFFD1B4AC7C19FD19 David Engel <david>

Of these keys only 2 voted in the recent DPL election. 8 have failed to make any response to my mails (3 since last August). Only 9 have uploaded a package since August 2008. And 10 were already known to the MIA database. Some of them have stated they'll sort out a new key, but not yet done so.

If you are one of these people, please either get a new key sorted and signed and reply to the mails I've sent you, or reply and say you no longer wish to be involved in Debian. And if you know any of these people, encourage them to get a new key sorted and offer to sign it for them.

Inspired by a conversation about interview coding tasks from a list I'm on, I present the following - I considered it too long to email there. It took me longer than I expected to write; my x86 assembly is quite rusty. I'm not claiming it's pretty, but it fits in a single sector and most of the overhead is actually ELF structures.

; nasm -f elf fizzbuzz.asm
; ld -melf_i386 -s -o fizzbuzz fizzbuzz.o
; ./fizzbuzz
section .data
fizz	db	" fizz"
fizzlen	equ	$ - fizz
buzz	db	" buzz"
buzzlen	equ	$ - buzz
num	db	"   "
numend	equ	$ - 1
numlen	equ	$ - num
nl	db	0xa
nllen	equ	$ - nl
curnum	db 1
section .text
	global _start
_start:
	mov ax, [curnum]
	call printnum
	mov ax, [curnum]
	mov cx, 3
	xor dx, dx
	div cx
	cmp dx, 0
	jnz notfizz
	mov edx, fizzlen
	mov ecx, fizz
	call printstr
notfizz:
	mov ax, [curnum]
	mov cx, 5
	xor dx, dx
	div cx
	cmp dx, 0
	jnz notbuzz
	mov edx, buzzlen
	mov ecx, buzz
	call printstr
notbuzz:
	mov edx, nllen
	mov ecx, nl
	call printstr
	inc BYTE [curnum]
	cmp BYTE [curnum], 100
	jle _start
	xor ebx, ebx
	mov eax, 1
	int 0x80
printnum:
	mov edi, numend
	mov cx, 10
p1:
	xor edx, edx
	div cx
	add dx, '0'
	mov [edi], dl
	dec edi
	cmp ax, 0
	jne p1
	mov ecx, num
	mov edx, numlen
printstr:
	mov ebx, 1
	mov eax, 4
	int 0x80
	ret

(This has ended up longer than I intended, largely because I felt I should then get into why. I'm aware I haven't got into all the nuances, so I hope readers familiar with the area will appreciate this is the compact version.)

Thorsten had a rant last week about PGP keysigning problems. He apologises for his tone, but that's not the issue I take with his rant.

It starts "Keysigning is useless". And yet his complaints seem to be:

• Dealing with the private half of your GPG key securely involves some faff (in this case booting with a live CD and having to set things up ready to keysign).
• He doesn't get on with caff.
• People reject email from machines with invalid HELOs and perform other anti spam measures on ISP access ranges (I'm not clear if it's just greylisting or outright rejects as that's not made clear).
• PGP/MIME is a protocol violation (yes, but it's much better than inline OpenPGP. Unless you have to deal with RT, which mangles it. *sigh*)

None of these seem to actually be about keysigning being useless. The process of doing it, maybe, though he misses the main valid rant about this I'd have, which is that most mass keysignings don't actually allow you to accurately verify the identity of other participants unless you already know them reasonably well. (The LCA2010 keysigning and DebConf5 in Helsinki spring to mind as 2 good examples of bad keysignings I've attended, but speaking to others suggests it's far from an isolated thing.)

Torsten does say that he'll continue to do keysigning on a per-person basis, so it doesn't sound like he's completely given up. I'm posting this largely so other Debian related people don't get the idea that it's not important to think about keysigning.

Why should we care?

Firstly, let's clarify what I mean when I sign someone else's key. If I sign your key then I think that I believe you hold the private part of a key that has your name and an email address I believe I can use to contact you on it. It means I have seen government issued ID that matches that name. It also means that I have interacted with you (and watched others interact with you) under that persona. In short I am happy that the key is a reasonable digital representation of your identity - something signed by it either comes from you or has involved the key being compromised or you coerced into using it against your will.

Why is this useful?

It gets useful thanks to the web of trust; ie the idea that there are a bunch of people I trust partially to sign other keys, and if enough of them have signed a key then I can have a reasonable expectation that the key belongs to the person I want to talk to. Which means I might be prepared to send private data to them. Or Debian might be prepared to accept an upload from them. Which, when you're dealing with a community that spans the planet and where most of the contributors haven't met each other, is pretty freakin' useful - I, as part of Debian's keyring team, don't need to personally be able to identify every Debian developer. All I need to do is be able to trust other DDs to be able to do so. (Though maybe I'm missing out on something here - perhaps Debian should be paying for Gunnar and me to travel the world verifying fingerprints. \o/)

(I still do mass keysignings btw. I'm picky about which keys I actually sign - this is in no way intended as a slight against those I don't, but a mass keysigning at least lets me know that the people involved are happy to exchange fingerprints. Though, FWIW, I normally have ID on me and frequently have fingerprint slips, so if you know me and want me to sign your key/want to sign mine then by all means ask me when you see me!)

Knowing full well that it will cause many of my readers to tut and roll their eyes at me I derive slight pleasure from confessing that I have now eaten at McDonalds on 6 continents. To make it worse I only did so in Asia and Australia so I could say I had.

It does lead me into a slightly more valid ramble. I'm not particularly bothered about eating on my own. I like food (even if I'm picky about what I like), but I prefer it with company. This means I'm not particularly great about being organised to cook complicated things when I'm on my own; largely the whole thing just turns into dealing with hunger. It also mean I'm bad at finding nice places to eat out while travelling. Which, when you're travelling for a month to some interesting places, is a bit of a bugger. I've got a bit better at actually going to nice places, and trying not to bolt my food into me so I can get out ASAP but instead enjoy it. A book helps. Also places that aren't quite as busy (which if you have no agenda is nicely achieved by letting your body clock desync from the world around you). Unfortunately I didn't really do so until after Hong Kong. Guess I'll just have to go back at some point...

(More on my travels at some point, maybe. I've started the tortuous journey home now.)

Being a bit of a freak I actually tend to read my boot output. Well, when I'm not using that time to go grab a cup of coffee first thing on a Monday morning. However I don't always find Debian's default output as clear as I'd like (especially when I haven't had that coffee yet, or when I'm half watching a remote machine boot over its serial console). ISTR that RedHat had much nicer boot output (I'm talking about text based here, not the fancy Plymouth stuff) with a row of OK/FAILED etc down the right hand side that made it nice and obvious what was happening. Of course we can do that with Debian, at least for packages that use the lsb-base logging functions. Drop the following into /etc/lsb-base-logging.sh and enjoy a slightly prettier boot. I'm slowly filing wishlist bugs with patches for those bits and pieces I use that don't use lsb-base for their init script logging.

# Colour our init scripts output
# int log_end_message (int exitstatus)
log_end_msg ()  
    # If no arguments were passed, return
    if [ -z "$ 1:- " ]; then
        return 1
    fi
    retval=$1
    log_end_msg_pre "$@"
    # Only do the fancy stuff if we have an appropriate terminal
    # and if /usr is already mounted
    if log_use_fancy_output; then
        RED= $TPUT setaf 1 
        GREEN= $TPUT setaf 2 
        YELLOW= $TPUT setaf 3 
        NORMAL= $TPUT sgr0 
        $TPUT hpa $(( $TPUT cols  - 12))
    else
        RED=''
        GREEN=''
        YELLOW=''
        NORMAL=''
    fi
    if [ $1 -eq 0 ]; then
        /bin/echo -e " [   $ GREEN OK$ NORMAL    ]"
    elif [ $1 -eq 255 ]; then
        /bin/echo -e " [$ YELLOW WARNING!$ NORMAL ]"
    else
        /bin/echo -e " [ $ RED FAILED$ NORMAL  ]"
    fi
    log_end_msg_post "$@"
    return $retval
 
log_action_end_msg ()  
    log_action_end_msg_pre "$@"
    if [ -z "$ 2:- " ]; then
        end=""
    else
        end=" ($2)"
    fi
    /bin/echo -n "$ end "
    # Only do the fancy stuff if we have an appropriate terminal
    # and if /usr is already mounted
    if log_use_fancy_output; then
        RED= $TPUT setaf 1 
        BLUE= $TPUT setaf 4 
        NORMAL= $TPUT sgr0 
        $TPUT hpa $(( $TPUT cols  - 12))
    else
        RED=''
        BLUE=''
        NORMAL=''
    fi
    if [ $1 -eq 0 ]; then
        /bin/echo -e " [  $ BLUE DONE$ NORMAL   ]"
    else
        /bin/echo -e " [ $ RED FAILED$ NORMAL  ]"
    fi
    log_action_end_msg_post "$@"
 

(This is mostly for my own future reference, because I keep trying to search for details on it and not finding exactly what I want. I forget where I even found the basis for this, though there are lots of similar snippets out there. I've not tried it with a concurrency based boot so it may well look horrible under that.)

I've recently been fixing up my VDR setup to work with FreeSat and make it brother/parent friendly. I've applied the EPG patches to get the 7 day guide, setup an autologging in user under gdm with vdr-sxfe running and that left getting the remote working. For some reason my old serial dongle wasn't happy with lirc - it got detected ok, and would show some signal when buttons were pressed but didn't work with the old config. The entire hardware of the box has changed, so it seems likely something isn't quite right (in particular the lirc drivers spew out warnings about SMP bits so I should probably try the dongle under a single core setup to rule that out, but there's also a move to 64 bit involved).

The easy solution to have something sorted for Christmas was to pickup a cheap remote from eBay. This ended up being a Cyberlink remote + USB dongle combo. Worked just fine when plugged in, turning up as a normal input device and the obvious keys doing the obvious things. I wanted all the keys to work though, as I'd got used to having a lot of the VDR functions instantly accessible rather than having to work my way through the menus. Various searches suggested I'd need to use LIRC to access the odder keys. That seemed a lot of hassle for something that was doing the decoding itself. Some playing with xev turned up keycodes for a number of the keys, but there were still a few missing (and important ones at that, such as Red/Green/Yellow/Blue). Further digging found me a suggestion of an Xorg keyboard map that would map the KEY_RED etc from the evdev device into something workable under X. And then I found inputlirc via the Debian package. This is really bloody neat - point it at an evdev device and it will present all of the KEY_* codes out as lirc keys. If you pass the -g parameter it makes sure the key presses only go to lirc as well. Exactly what I want and a doddle to setup - no messing with a big configuration file, just edit /etc/defaults/inputlirc to point to the correct /dev/input/by-id/ file, add the -g to the options in that file and restart.

Now the main remaining task is to get it working with BBC/ITV HD.

I'm due a new laptop; my Portege R200 is over 4 years old now, I find it much slower than my desktop (no surprise; P-M 1.2GHz/1.2GB vs Core 2 2GHz/4GB), it's had a new battery and it has an annoying whine on the screen unless you press the side in just the right way. It's still better for long periods of use than my EEE 901, which is why I keep it. In particular I'm off to LCA2010 in January, along with some associated travel beforehand, and I'll want more than the EEE for that, but probably not a brand new laptop. Which meant that when the R200 started throwing disk errors recently I wasn't particularly happy.

Having decided it wasn't worth buying a new 1.8" drive I looked for alternatives. eBay offered plenty of options for 1.8" IDE to CF adaptors and I picked up a Kingston 32GB CF card from eBuyer. I copied across the data from the old drive using a USB adaptor, frobbed grub sufficiently that I got it installed on the CF, then swapped out the drive for the adaptor + CF. I had to do the swap a few times; the first I forgot to have a kernel with ext2 support (the HDD was ext3, but I went back to ext2 for the CF). The second I'd done my usual trick of forgetting to populate /dev with things like console and sda* (ie enough to get to the point where udev will run). And then grub needed some prodding to boot without intervention. I got there in the end and I'm currently writing this from said laptop.

I've made a few changes to the Debian install in an attempt to make things smoother; basically the same tricks people have been using on EEEs or other slow SSD devices. No swap, Iceweasel synchronous toolkit writes disabled, filesystems mounted with noatime, /tmp on tmpfs, various daemons that I don't really use disabled. It's still noticably slower than with the HDD, particularly on writes. However it's quieter and as long as it lasts for the next 3 months I'm happy (plus after that I can reuse the 32G CF card somewhere else, which I couldn't have done with a 1.8" HDD as easily).

Now, back to eying the Lenovo X200s (ugly, trackpoint but 1440x900 display, good battery life) and Toshiba R600 (slower, lower res but pretty and trackpad).as potential replacements. Maybe there'll be something even shinier in 12" by next year...

I've always preferred dead tree to reading things on screen; I just find it easier. I've tried reading fiction in the past off a laptop and just didn't find it as enjoyable an experience; whether it was the form factor (hard to curl up with a laptop, even a netbook), the quality of the screen or the interface I don't know. Equally with technical documentation if it's something I'm using a lot I prefer a printed copy to flick through. However e-ink based e-readers are becoming much more common and affordable and I figured I should give the whole ebook experience another try.

I spent 3 weeks in October in the Bay Area on work, so I borrowed my Dad's Sony PR505 for the trip. First problem is that it's picky about USB charging - works fine if attached to a computer, but using a Blackberry charger looks like it's fine but then results in what looks like a hanging reader. However once charged it lasts for ages - I charged it before I went and only hooked it up to my laptop once during the trip to transfer some new content onto it. The form factor is also quite good; a bit heavier than a book, but not excessively so. Holdable in one hand, big enough screen that I wasn't squinting at it. Slightly too big physically to easily go in a coat pocket the way a paperback would unfortunately, but perfectly fine for taking to read at breakfast every morning in the hotel.

The screen was also much better than I'd expected. I knew the technology was different and supposed to be easier to read than traditional LCDs, but I was sceptical. Overall I had no problems with it. I was even quite impressed with the Sony's zoom function - one of the PDFs I was reading was too small when view full screen, so I zoomed in so it was readable. The nice feature was that then the "next page" button gave me the next bit of text to read, rather than the actual next page, so it remained very easy to navigate through as I read. A small touch, but very welcome.

This isn't intended to be a review of the Sony reader; that just happened to be the model I was easily able to borrow. I happened to see a Kindle in use on the plane and I was struck by how much bulkier it seemed, though having looked at the relative specs it seems this is entirely due to the keyboard rather than any difference in screen size. The Nook was also announced during my trip and I'd quite like a play with that as it looks quite nice.

Despite my positive experience with the Sony I'm not planning to go out and get one just yet. And that's the lack of sensibly priced content. When I bought my first mp3 player I could take my exising CD collection, rip it and be able to play it on my new device. This meant I got an immediate benefit of having my entire music collection with me all the time, just by buying the player. If I buy an e-reader then in order to get all my existing books on it I have to go and buy them again. What's worse is they'll cost me the same or more than I paid for the paperbacks. I can't go and exchange my Pratchett collection for the electronic versions for a nominal fee. I can't easily scan them in myself and produce some decent ebooks. I can't even go and buy the entire set for 20; I'd have to spend something like ten times that. With mp3s I can continue to buy the real item and also have it on my portable player. Or, while albums still don't seem to be much cheaper electronically than on CD, there is at least the ability to buy a single track if that's all I want. Books don't have a comparison. I'm not going to want to buy a single chapter, am I?

There are some sites out there that can provide cheaper ebooks - Rachel Willmer runs ebookprice.info which lets you compare pricing from different vendors. There's also Project Gutenberg if you're looking for out of copyright books. Finally Peter Corlett pointed me at the Baen Free Library, which I haven't downloaded anything from but will definitely investigate at some point. I still maintain that none of these are enough and that content provision will continue to be a hinderance for e-reader mass adoption until there is some fundemental change in the way its provision is handled.

I tend to dress quite casually - unless there's a good reason to do otherwise I'll be in jeans and a t-shirt, or something similar. I'm comfortable in it and I take the view point that in general people shouldn't be making assumptions based on what I'm wearing. Of course they do, and while this can be infuriating at times it can also be amusing. The man at the RBoS who witnessed me signing the personal DD guarantee form for Black Cat obviously couldn't reconcile my appearance with what I was there to do, for example.

I'd never thought about this from the other side until a few weeks ago. I spoke to someone who explained how difficult it had become to conduct business meetings with other companies with the increased level of business casual. In fact on occasion different branches of the same company that he'd be meeting with would have different dress codes, so he'd go to something involving casual dress in the morning and something with full business suit attire in the afternoon and end up feeling over or under dressed.

This isn't likely to make me change my own behaviour in the immediate future (I don't have to interact with external parties as part of my current job). It did help me realise that there was another explanation for awkward behaviour when I'm my usual scruffy self that wasn't just about judging on appearances though.

(All of the above blatantly obvious once you think about it, but it took that conversation for me to do so.)

Debian maintainer: Some days ago I had the great announcement that my Debian Maintainer s application was accepted and thanks to Jonathan McDowell my key is finally into the debian-maintainers keyring. (which is now part of the debian-keyring itself thanks to the ftp-masters / keyring maintainer work that made the changes on both DAK and keyring) I applied on the 22th of August, and thanks to Reinhard s advocation, everything went on the right side. Many thanks to all the people who made this possible. Pkg-mozext: Around 3 weeks ago I started being involved with the pkg-mozext team working on the new policy and to mozilla-devscripts transition for all iceweasel / icedove extensions. The work is going great so far and we managed to update several extensions that are now part of the team itself. For a fast look at our package list, feel free to browse pkg-mozext s QA page. A lot of work needs to be done, so if anyone wanna jump in, I would suggest to read our guidelines / policy into the team s Wiki Page. Pkg-gnome: GNOME 2.28 is now released, and the pkg-gnome team is now working hard to provide all the needed updates into unstable and experimental. Everything is going great and we are cleaning up everything listed on our schedule. Ephipany is under transition (gecko > webkit) so there are still some open issues / bugs, but now it looks fine so far and it can be used without any particular problem.

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

	Total	SCS		Reachable		MSD	Centrality
1999-02-06 (slink)	228	36	(15.78%)	50	(21.92%)	2.9022
2000-01-03 (potato)	375	104	(27.73%)	180	(48.00%)	4.3382
2001-09-22 (woody)	948	538	(56.75%)	704	(74.26%)	4.7320	2008.6249
2005-05-28 (sarge/etch)	1106	883	(79.83%)	969	(87.61%)	3.3485	2074.6604
2007-12-04	1191	1001	(84.04%)	1062	(89.16%)	3.1103	2113.3747
2009-01-18 (lenny)	1126	947	(84.10%)	1010	(89.69%)	3.0489	1941.2594
2009-04-04 (squeeze/sid)	1121	946	(84.38%)	1008	(89.91%)	3.0466	1936.9761
2009-05-06 (current)	1067	894	(83.78%)	958	(89.78%)	2.9670	1759.4363
	Total	SCS		Reachable		MSD	Centrality
base	1067	904	(84.72%)	959	(89.87%)	2.9640	1776.4389
update-93sam	1067	902	(84.53%)	958	(89.78%)	2.9734	1780.9874
update-joerg	1067	900	(84.34%)	958	(89.78%)	2.9776	1780.7578
update-aurel32	1067	898	(84.16%)	957	(89.69%)	2.9803	1779.2497
update-noodles	1067	896	(83.97%)	956	(89.59%)	2.9831	1777.8326
update-jaldhar	1067	896	(83.97%)	955	(89.50%)	2.9855	1779.9193
update-srivasta	1067	896	(83.97%)	955	(89.50%)	2.9904	1784.3382
update-ana	1067	895	(83.88%)	954	(89.40%)	2.9926	1784.3102
update-nobse	1067	893	(83.69%)	953	(89.31%)	2.9947	1782.2392
update-neilm	1067	892	(83.59%)	951	(89.12%)	2.9974	1782.6098
update-reg	1067	891	(83.50%)	950	(89.03%)	2.9977	1780.8515
update-rmayorga	1067	890	(83.41%)	949	(88.94%)	2.9984	1779.4910
update-evgeni	1067	889	(83.31%)	948	(88.84%)	2.9974	1776.6445

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...

Translink are breaking the trains for 3 months at the end of March. This is manifesting as the line between Ballymena and Coleraine being entirely shut (it's only single track, so it's not like they can do one side at a time), but will hopefully result in a smoother, faster journey. Not much good for the 3 months when my journey goes from a single train ride to a train, bus, then another train ride. And gets longer by 20-30 minutes (so potentially 5 hours a day commuting. Yay!). I think not.

So I have rented a flat in Belfast, conveniently only 3 minutes walk from work. 3 month leases are hard to find so I have it for 6 months. I'm a bit freaked. I shouldn't be really; I lived alone when Katherine first moved back to NI. But that was in a house I'd been in for ages rather than somewhere entirely new to me. It proved its worth last night when we were able to walk to Do You Remember the First Time? in a couple of minutes though. Being in the city centre is damn handy, though I'm having to get used to the regular noise of traffic again. :)

(This post primarily a test of Drivel; it's not worth the hassle of dealing with Virgin or BT to get a broadband connection, so I'm going to end up continuing to use my Orange 3G dongle and trying to do things in local clients where possible.)

I wanted to record a conference call for a colleague who couldn't make it. Normally I'd cheat and run Wireshark to capture and dump an unencrypted VOIP stream, but for various reasons that wasn't an easy option and Skype was going to work better for the call. But how to record it? IRC suggested various ALSA magic options, which looked like they'd do the trick if I could only understand the fine manual. It actually turned out to be much easier than it looked. I dropped:

pcm.fileout  
	type file;
	slave  
		pcm "hw:0"
	 
	file "/home/noodles/pcmout";
	format "raw";
 

into .asoundrc, restarted Skype and told it to use the fileout device for audio out. That led to a pcmout file being created, as well as the sound going to the sound card.

sox -r 44100 -s -2 -c 2 -t raw pcmout -t wav foo.wav then converted that file into a WAV that could be played back. For some reason setting format to wav in the ALSA config resulted in an error - throwing sox at the problem was the easy answer but I suspect that step could be eliminated with some more doc reading.

I managed to go to FOSDEM in 2005. I enjoyed myself. I'd like to go again. No, really, I would.

In 2006 I drew the short straw while working for Black Cat; Simon and Dom went, I remained the person on the same landmass as the servers.

In 2007 I had a wedding to go to.

Last year I was too disorganised to sort out suitable transport from Northern Ireland.

I'd resigned myself to having to take off the Friday and Monday this year and fly. Except it's been moved to near the start of February, which thus conflicts with an annual dinner that gets to have higher priority. Bah.

Maybe I'll manage 2010, but I'll not be holding my breath.

I've previously mentioned my desire for a new smartphone. I'd been eyeing the G1 since its release, with the main factor stopping me from going ahead the need for a T-Mobile contract. They don't have any 3G coverage north of Belfast that I've seen and I'm very happy with my 20/month O2 Simplicity contract and don't have any need to pay twice that. Luckily Katherine decided to get me one for my birthday, and after some confusion involving it going to Norwich (always remember to update your Paypal delivery address as well as the card address when you move home, folks. Oh, and your Amazon wishlist address too; it's different than your primary address and I've been bitten by that myself in the past) it turned up the weekend before Christmas.

I have a UK spec T-Mobile G1. First step was to get it unlocked for use on O2. I used Unlock G1 - they weren't the cheapest, but I'd seen them recommended on a few G1 news sites and they had a helpful guide on their site about activating without a T-Mobile SIM. They claim a code within 2 business days. I ordered at 19:30 UTC on a Saturday night and had a code by 21:00 that worked first time.

Once the O2 SIM was working I needed to check if the phone was easily rootable. I typed reboot and was rewarded with a rebooting phone. I had the RC7 UK firmware release, which still had the bug. I followed the android-dls.com guide to keeping root and upgraded to the RC8 release. With that out of the way I could start to actually have a play.

The screen is lovely. I'm used to the high res E70 screen and have been disappointed at the number of phones that only do 320x240. 480x320 is probably the minimum I'd want (if I can't manage an 80 character wide SSH session I'm not really interested) though obviously if HTC ever get round to a Touch Pro with Android I might be tempted... Touch aspect is perfectly responsive, as is the interface in general - while I don't use a phone that much day to day my mobile is the only number I give out so it tends to be the only phone I use. This means that the ability to make/receive calls/sms is the most important feature for me (it's odd having to say this, but I know people who've claimed to love phones but on further probing reveal it's a great PDA but dire for calls and they have to carry something else for that). The G1 performs admirably for my needs.

The built in apps are good too. The browser is much better than the E70. I don't know if that's the bigger screen (though the resolution isn't much different) or a faster processor, but browsing on my mobile is a much more realistic proposition now. I've only played briefly with the iPhone browser and I wouldn't say the G1 was any better, but it's certainly good. Calendaring is functional too and copes with multiple Google Calendars as you'd hope. Shame it doesn't deal with anything else, but for the moment this suits my needs. I haven't used it for email; I prefer to ssh to my colo box and run mutt. Contacts are mostly ok, though I have a few gripes I'll mention later.

I haven't felt the need to install many apps. The connectbot ssh client was an obvious one and is pretty nice (main missing feature is UTF-8 and there's a feature request for it raised already). I've installed a few games off the Android Market, as well as Barcode Scanner (does what you'd think) and CellFinder (displays your location and which mobile cell you're using; it's a bit scary how few O2 masts there seem to be near my house). Installation from the market has been a breeze and it's nice to be able to flick through what's available. With my E70 it was always a real pain to go and hunt down Symbian apps (especially when S60 3rd Edition was new) and install them.

Before I start on my gripes, let me clarify that I am very happy with this phone. I wanted something with a keyboard that was functional and this fits the bill. It's a definite improvement over my E70 and I feel it's much more responsive than any of the recent Windows Mobile devices I've encountered. Also the battery life hasn't proved to be an issue - from articles I'd read I'd expected to have difficulty getting a day out of it, but in general I can easily get 2 and have had 3. Maybe my usage patterns aren't as heavy as everyone else, but that's fine for me (I remember my 9000i Communicator which really was a case of having to charge it every night).

The first issue I hit was the contacts system. Google have tied this into GMail and it really seems to have been a last minute thought process, perhaps along the lines of "Where can we stick this? Oh, hang on, people have email contacts, how about there?". Trying to move my contacts over from my E70 I was surprised to find that there's no way to import a vCard. The only option is CSV. WTF? I'm not saying vCard is perfect, but it's pretty much what we have as a standard method of contact interchange. I ended up writing some Perl to crudely parse the vCards and output CSV. I shouldn't have had to.

Then again, maybe the issue is that Google know their contacts system is a bit lacking. You'd think a company with online calendaring and contacts would be able to cope with things like birthdays, tying them together between contacts and displaying them in your calendar, wouldn't you? They can't. I can't see any way to store a birthday or anniversary with a contact. Nor a home page. The contacts system is the one area that the E70 outshines the G1.

I miss an onscreen keyboard more than I thought I would (ie at all). I understand this should be coming in the next release, which will make things like quick replies to SMSes much easier (there's no point opening the keyboard for a "Nearly there" response).

The use of only a single APN for internet access and MMS is a bit troublesome; I haven't managed to get this to work properly with O2 - either I have fully working 'net or fully working MMS with only web seeming to work. I haven't played with the settings very much though and I spent 7 months without MMS even enabled on my O2 account, so it's not high priority. Also something I understand is being fixed upstream.

I'd like a way to see the next calendar event on my home screen. I may just be missing how to do this, but it was a nice feature on the E70.

I haven't played much with the camera, but I get the impression it's pretty typical of the average mobile phone; ie not great. Not a problem for me, but don't expect this to replace a compact digital camera.

While I accept this phone isn't for everyone I think it's pretty much what I'm looking for in terms of what's on the market today. There's nicer hardware out there, but a large part of what makes this phone is the Android software. I look forward to seeing new phones in the coming year making use of it, hopefully leading to a decent selection by the time I need a new phone again. :)

When I ran Black Cat we preferred customers to use role addresses (eg support@, sales@) rather than contact us directly. This had the advantage that more people got the mail, increasing the likelihood of it getting answered swiftly. However some people preferred to email one of us directly, even for trivial matters. Having a preference for using role addresses myself I can sort of understand why people did this; often there is a poor or non existant response from a company's generic email addresses, leaving no choice but to try and email a known contact. However in our case it would have led to a poorer chance of timely response.

These days I don't have to worry about these things in quite the same way, but there are a few things I'm on what could be considered a "role" address for. And still I get emailed directly about things. Which is still annoying. So please, if you are considering emailing me about something that isn't personal, consider whether you should be using a role address rather than emailing me directly.

(This semi rant brought to you as a way of testing if my MovableType upgrade worked)

Once again Debian is close to release. And once again we're trying to find ways to avoid doing so. Using a technique we've employed before; firmware.
Social Contract #4 states that "Our priorities are our users and free software". The hard liners believe that it's in our users' best interests that we ensure Debian is 100% Free, whether that be regarding software, documentation or firmware. In the long run I think they're right. Access to firmware source (assuming that there's also access to
suitable tools for building it and producing an image the hardware will accept, which is a fairly big assumption) enables us to continue supporting and improving hardware support long after a manufacturer has discontinued a device. It enables us to understand the behaviour of a new device better (allowing better support which makes it a more attractive purchase). It potentially lets us appropriate a device for new and exciting purposes the manufacturer never imagined (which may again increase the sales of the device). Access to firmware source is a good thing in the long term, for the consumer, the driver author and the manufacturer.
In the short term we I think we need to be pragmatic. We can say that we won't release until all non-free firmware is purged, but who knows how long that will take, and once we've done so how much hardware will we actually be able to support out of the box? What benefit is it to our users if we ship them a distribution that doesn't support their hardware and is already out of date because we spent so long removing that support? Wouldn't we be better to say "We're aware of some firmware issues. We're going to keep working on spliting such blobs out to their own easily installable packages that live outside main. We promise to continue improving the situation for each release (as we have already done since etch), but in the interests of our users we will not hold up a release at this stage of the process." Obviously plenty of people disagree with that, but I don't believe that pragmatism is against the Social Contract and I'd like to think that even our users who are fervently against firmware blobs would accept that there's a tradeoff to be had against release dates.
Anyway. I doubt I've changed anyones mind with the above, so I'm going to go and destack the dishwasher and reply to the latest mail from my NM.