History
For the sarge release official kernel-images from the newly formed Debian kernel team came together with initrd-tools. initrd-tools Maintainer was jbailey. It saw some care from tbm, vorlon and me before the actual release. Remembering the flow of bugs and installation-reports it accounted for a huge number of install failures plus lacked many features the Red Hat mkinitrd had. Ubuntu got hit more directly as hoary released with a newer kernel than 2.6.8 and due to the initrd-tools devfs requirement.
initramfs-tools originated out of the need of a direct replacement. Inspired by an initramfs OLS talk jbailey had the goals of boot-time hardware detection using the nice and neat features the Linux 2.5 branch incorporated: The sysfs support of the Linux drivers allows an neat userspace daemon aka udev to coldplug them. udev is the replacement of a maze of slow shell scripts called hotplug package. The second big feature is the new initramfs format (the curious may want to read Documentation/filesystems/ramfs-rootfs-initramfs.txt of any current linux-2.6 source). For a boot loader initramfs or initrd is the same fish. The smaller and more efficient in kernel code makes the difference. The initramfs gets loaded much earlier, due to being only an cpio archive and not an fs allowing it to completely rule the rootfs search and mount. One initial assigned spec had the name "easy NFS root". The LTSP guys joined in and showed interest in incorporating their work.
Technology
initramfs-tools got default in Debian together when the first common linux-2.6 (2.6.15) package reached etch, powered all the Ubuntu releases from Breezy on and is used by the grml live-cd. Since archive inclusion almost a year ago it got much better support of all the various linux boot parameters (see man initramfs-tools or the "official" Documentation/kernel-parameters.txt), keeps an backup initrd around and has better block-based bootloader support (lilo, ..). klibc has been ported to _all_ the Debian release archs where it is in use and compiles fine on m68k and sh.
The initramfs-tools early userspace is very flexible based on it's hooks for initramfs build and boot. Thanks to alphix for the help on shaping the building blocks. There are initramfs hooks in cryptsetup, evms, dmraid, firmware-qlogic, lvm2 multipath, mdadm, usplash, .. Reviewers, uploaders and sponsors included fs, jbailey and Sesse. Most of the time it is sufficient and easy to test changes in qemu images (See slides workshop early userspace). The best wish of an early userspace is not to be remarked - aka happy booting. Nevertheless thanks a lot for the public support: Achieving Xen Disk encryption support in Etch, Popping my initramfs cherry, ..
Future
The latest initramfs-tools release seems almost ready for the upcoming etch release. The bug reports coming over from installation-reports are happily rare. Although the uuid based fstab generation solution is not yet integrated in the debian-installer. There are one or two known nitpicks left-over in the bts plus one bugger: udevsettle may exit to early, when not all the discs are ready for use. For grub there is a fail-over net, but which does not account for a to early md or lvm2 boot hook. Future initramfs-tools development will focus on an optional small klibc based Modules=dep hand walking /sys initramfs generation allowing better embedded support. grub2 will present run-time assembly challenges for the initramfs.

The redoubtable Harald Welte recently blogged some thoughts about lack of value contributed back to linux from embedded system vendors:

How many times have you seen some code coming out of a "GPL code release" from one of the many (mostly embedded) vendors that was acutally useful to be contributed back to an existing Free Software project, or even that spawned a new Free Software project? I for my part am certain to say: Zero. The actual number might be close to zero, but very small anyways.

I was thinking about this in the context of my nslu2 box, which just a few days ago passed an important milestone -- full support in the Debian kernel, including a free, rewritten ethernet driver, a fixed RTC, a free boot loader, and hopefully soon, even working LED support. The perfect embedded system. This is an embedded linux box that started out running a typically awful special-purpose, dead-end linux distro, and which has been rescued to be a general-purpose linux box running a standard linux distro thanks to the work of a great many people. The road from the original firmware to the current system has been long, complex, and hard; you can see glimpses of parts of it here and here. Here's the thing: This box is a computer designed from the ground up to run linux. Working code was made available by Linksys. As Harald notes, this code was probably "throw-away software", but if the box hadn't been running hacked up Linux in the first place, I dare say we'd not be running stock Debian GNU/Linux on it now. So there is a value in a vendor deciding to use Linux on their embedded system, even if it's only as a proof of concept that it works, as a first step along the long road to doing it right.

Before anything else: Please excuse some grammatical mistakes I've made in this post. You should understand the topic is really upsetting, and typing while searching for links, listening to news, and gathering the basic information for a five month old conflict is not exactly compatible with me spewing out proper English ;-)
Just to re-state the obvious: Mexico is, once again, on fire. This posting is mainly written with the Debian people in mind - An important number of them, after Debconf 6, went to visit Oaxaca - In late May, during the first weeks of this incredible, stupid and scary conflict we are now facing.
I've written in my blog every now and then about our political situation. Many of us had high hopes on our current government. We thought that the authoritarian regimes were a thing of the past, we hoped for real democracy, we hoped for a government that would honor human rights and solve long-standing topics for our society - Yes, we all knew president Fox came from a right-wing party, and didn't expect much advance in the social agenda -which many of us perceive as the real problem in Mexico- but still, hoped for openness and reconciliation with the past.
I won't repeat what I've extensively said over and over - The thing is, Fox's government continues to amaze us with its stupidity, with its near-sightedness, with its hypocresy. Fox's term is really close to an end - In one more month, the govt. will change hands to the first de-facto president since Carlos Salinas (going over another story we hoped to forget).
As some of you wittnessed, there was a popular protest taking place mainly in Oaxaca - Basically, the State's public elementary school teachers demanding better payment for their work. Such a protest is already a common occurrence in Mexico, as public school teachers are among the worstly paid workers (no wonder, then, our country is still undeveloped - Make public education worse, and you have the warranty of an unprepared, ignorant population). The teachers went on strike in early May, briefly returned to classes on late June to properly close the 2005-2006 lective year, but went back on strike afterwards.
Of course, the local government (Mexico is a federative republic, each state is autonomous and makes decisions independently) took a very long time to act - and acted the worst way possible: By sending policemen to forcefully throw the teachers from their camps in the downtown streets, with no negotiation, no answer, not a drop of common sense.
That led to the formation of the (pleonasmicaly named) APPO: Popular Assembly of Oaxaca's People - A group of people, partly formed by the unhappy teachers, mainly demanding the Oaxaca state governor to step down, after he proved he is inept for his office. And yes, I'm oversimplifying here, but I don't want to dig too much - There is fortunately plenty of available information in this regard.
That happened over four months ago. APPO kept control of the city. Nobody denies that this has caused Oaxaca, a city that attracts national and international tourism like few others in the country, a great deal of economic damage - Oaxacan people are, however, still sympathetic to APPO's demands. Governor Ulises Ruiz (from PRI, the party that ruled the country for over 70 years) has not been able to be seen in public in his state for some months already. The legislative power has also been unable to work properly, and the judicial power is half-dead, doing only its most basic tasks. Renowned jurists, such as Miguel ngel Granados Chapa, have repeatedly stated that this is enough for the Federal Senate to declare the governing powers in Oaxaca have disappeared - This would put an end to the conflict, leading to immediate elections, but the Senate has denied taking this course of action. Not only that, but the Federal government took the command of the local security forces, tacitly recognizing the local government is unable to coherently excersise their authority. After almost five months, last week they issued an unanymous -but mild- exhort, asking Ulises Ruiz to consider stepping down.
So far, 15 people have been killed in the different represive actions taken, first by the local police under local command, later by the local police under federal command, and starting last week, by the federal police. Today, it seems the army is getting in the conflict as well, despite promises of not doing so by the federal authorities - Of course, they have become masters in the art of breaking promises.
Why is the federal government upholding Ulises Ruiz? Simple: After the undeniable electoral fraud we had some months ago, there are too many indicatives pointing out that our (supposedly) elected president Felipe Calder n (FeCal, as he is better known as) will have a hard time becoming the president, and many people doubt he will be able to hold the authority for the six years. So far, he has shown no better aptitude as a statesman than Vicente Fox: Instead of boldly facing the claims of fraud, he just chickened out and has spent many months hiding from the public, appearing only for selected, friendly audiences. For many months already we have heard "Ulises ya cay , le sigue Calder n" (Ulises has fallen, Calder n is next). This country has not been so badly shaken in decades - Of course, Great Statesman Vicente Fox insists the country is in peace and there are no red spots. Fox even was stupid/blind enough to state that the problems in Oaxaca would be dealt with easily and successfully, just as the problems in Chiapas and Atenco were doing his term. During Fox's campaign, he promised to solve the centuries-old Chiapas problem (that resulted in the EZLN uprising in 1994) in just 15 minutes - He just has not had time to do so. Atenco? Yes, in 2002 an angry people made him step back from the most important project of his term (a new airport for Mexico City). In May 2006, Atenco sprang again to the news because of a massive repression - I'm not going into details on Atenco right now, as it would be off-topic, but you can look at my article in FeCal.org.mx or watch a very strong video by Canal Seis de Julio (both in Spanish only) for further details.
Last Friday, however, something was different. In a repressive action, a USA citizen, the Indymedia reporter and cameraman Brad Will was killed by a paramilitary group. Even more, he was killed while doing his work, and we can clearly see this evidence on his last tape. Of course, the US ambassador issued a warning, asking the US citizens not to go to Oaxaca. And, as Lorenzo Mayer says, hay de muertos and muertos - There are different categories of dead people. A highly visible US citizen is more important than the other 14 dead Mexicans, and now the Federal Preventive Police is clashing in Oaxaca.
What should be shocking, but is not so much to those of us who know this beaten country, is the attitude of the authority when taking the city. After five months of occupation, the Oaxacan people have got used to living with APPO - be it for good or for bad. Tourism has diminished, but the people's living sources have not been attacked. Of course, as soon as the Federal Police took the downtown areas, all sorts of reports of looting have been reported. The policemen are robbing even sodas and chips, and up to TVs and microwaves. As many people state, this is a very Kafkian country.
Of course, we don't know what will come next. Most of the city has been "freed", and the APPO is holding at the University. The University is autonomous, and the PFP commands have promised not to break its autonomy - but we don't believe that. There are fights very close to the University. The Rector himself spoke a couple of hours ago at Radio Universidad, the main broadcasting point for real news on this subject (I am following on the news thanks to KeHuelga, 102.9MHz FM in Southern Mexico City, or at their webpage, from where they link to many other underground or Internet radio stations joining in the broadcast), and the reports are dramatic. Dramatic, as well, is the way all of the commercial news sources are ignoring the facts.
I want to keep you updated, as one of the very few reasons things are not worse is the public opinion and, even more, the international pressure. I'm sorry I'm not giving more links right now, but I will soon. I don't want, of course, to flood people that read my blog through the different syndications with a technical profile, so updates via my blog will be quite sparse. If you can read Spanish, we have posted many articles at FeCal, and many other individual sites are also joining in. A couple of links, and I'm off for now.

• APPO main site
• Spanish Wikipedia article on APPO
• La Hora del Pueblo
• Several videos in this regard in YouTube
• Centro de Medios Libres M xico
• Sendero del Peje

Technical note: I switched from the GIMP to krita for this picture. Overall I'm impressed, krita has a good selection of features and a much better interface thsn the GIMP. However some filters still cause it to crash.

It's funny, because it fits the name so well:

# dig myspace.com
myspace.com.            18112   IN      A       216.178.32.48
myspace.com.            18112   IN      A       216.178.32.49
myspace.com.            18112   IN      A       216.178.32.51
myspace.com.            18112   IN      A       216.178.32.50
myspace.com.            18112   IN      A       127.0.0.1

Yay. Myspace IS localhost! :-) At least until they fixed their DNS (the primary nameserver already publish a fixed record. too bad.)

Stolen gratuitously from David Ulevitch of OpenDNS:

$ host -vv myspace.com
Trying "myspace.com"
;; ->>HEADER - opcode: QUERY, status: NOERROR, id: 24145
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;myspace.com. IN A
;; ANSWER SECTION:
myspace.com. 68350 IN A 216.178.32.51
myspace.com. 68350 IN A 216.178.32.50
myspace.com. 68350 IN A 216.178.32.49
myspace.com. 68350 IN A 216.178.32.48
myspace.com. 68350 IN A 127.0.0.1
Received 109 bytes from 208.67.222.222#53 in 9 ms 

After visiting Google for the Summer of Code Summit the other week, I thought I might actually try out some of the web services they’ve come up with, rather than just sticking with search and maps, and see if they did anything for me. To my surprise – as a certified hater of webapps generally – a couple did. Writely, the web-based word processor, was kind-of interesting, but in the end didn’t work for me. The potential killer feature for me would’ve been SubEthaEdit or Gobby -like interactive collaboration, which seems like something Google ought to be able to do with their whacky AJAX techniques. Unfortunately, it seems to just be some sort of automated merge-on-commit, which does nothing for me. What I’d really like as far as online document editing goes, is actually to be able to do Gobby-like editing of (moinmoin) wikis, rather than having to deal with advisory locking. I poked a bit further at that, and I suspect it ought to be possible to hack something up by using a tool like editmoin to edit wikipages with an editor rather than a webbrowser, and using gobby to do the editing, via a sobby server hosted on the same site as the wiki. It ought to be possible to automate all that complexity using an application/gobbymoin mime type; but I didn’t get anywhere because sobby seems to require IPv6 support. Oh well, maybe some other time. I’ve played with GMail and Google Talk before, with minimal impact. GMail is kind-of nice, but I like to be able to read my mail offline, so whatever. It is useful as a backup email address if my regular one goes down though. Google Talk doesn’t seem to handle voice/video under Linux, so it’s just a Jabber server. Which is fine, since I hadn’t ever actually gotten any of these whizbang IM things setup. What’s less brilliant is that Gaim is a bit of a pain when it loses connectivity, which happens everytime I suspend my laptop, which is everytime I stop using it. But I need GMail in order to even try some of the interesting Google services these days, so whatever. Google Calendar isn’t really something I expected much of. Sure, it’s a calendar app, but I’ve never gotten much use out of appointment diaries or planners or whatever anyway. Having it be web-based actually changes that a bit though, since it makes it trivial to publish to other people, and that even makes a calendar a little bit useful for me too. Having it be able to send reminder SMSes is also neat, at least now I’ve worked out how to default that behaviour to off… Oddly, though, I’ve found I’m getting more value out of it in listing things I’ve done rather than things I’ve got coming up. I guess it’s nicer to have a list of things you’ve actually done, rather than a list of things you should have done (but often didn’t), or a list of things you’ve got to do… But the real winner is definitely Google Reader even if it’s still in Google Labs, rather than even being “beta”. While I’ve tried some aggregators in the past, none have remotely grabbed me, and I’ve been tending to just remember the URLs for the blogs and webcomics I like, and type them in when I’m feeling bored. That has the benefit that it limits the number of each I read, but the drawback that I waste time typing URLs and waiting for pages to load even when there haven’t been any updates. The keyboard interface to Reader is pretty pleasant, with the only drawback I’ve found a slight lag in loading entries at the start of the day. Having it be in my web browser is perfect, since I generally want to follow a few links from blog posts anyway. It’s also made it easy enough that I’ve added a few feeds from real newspapers (or news channels), which is probably a good thing as far as balancing my take on what’s going on in the world. There’s a couple of downsides. One is that a lot of webcomics don’t have RSS feeds, or, if they do, don’t seem to include the actual comic, just a link to it. I don’t think there’s much of a reason for that – there are a few blogs I read that include ads in their RSS, so that doesn’t seem difficult to handle, and I can’t see any other potential objections. Also annoying is that posts that get aggregated on multiple planets (such as Planet Debian and Planet Linux Australia) show up multiple times, though admittedly I pretty much expected that. Probably the major downside is that it’s so easy to read stuff that I keep adding feeds to it, though…

It's a beautiful day here in wt:Los Altos Hills, wt:California, where my parents live. It's been unseasonably warm this week, ever since we hit the ground on Thursday, and we've been enjoying the warm weather to the fullest. Amita June is storing up vitamin D (a precious commodity in the Canadian north) for use during the rest of the autumn and winter. We had an early flight into wt:San Francisco from Montreal on Thursday. There's only one direct flight from Trudeau airport to SFO on Air Canada per day, and it takes off at 8:30AM. Maj is pretty convinced that we need to take direct flights with no stops while we have the baby; I'm mixed on the issue. I think a break every 2-3 hours makes it easier on all of us -- everybody gets some exercise and a little change of scenery. But Maj wisely points out that the takeoff and landing is the hardest part of flying with a little one, so direct flights minimize those. I dunno. Anyways, the 6 hour flight was uneventful, except for people coming up to us to comment on how good our baby is. The movie was "Click", which as I've mentioned before is the worst movie of 2006 bar none. It was pretty disappointing to see it come on -- I like watching movies on the plane. It was bright and sunny at SFO when we landed, and my mom met us at the baggage claim. We had a bit of a struggle getting out to the short-term parking -- for some reason the elevator queue at SFO is out of control; probably all the people loading and unloading luggage from the elevator. In any event, they now have elevator attendants and structured lines to make sure things go in an orderly, if slow, fashion. Back at the house, we had a late lunch of tuna salad and then Maj, Amita June and I did a big group nap. My mom had set up a toddler bed for AJ, and she's been sleeping in it since we got her. I think she's just turning the corner where having a little more space in the bed for herself is more important than nursing all night. Which I think is better for all three of us. Thursday night my dad came home from work in wt:Morgan Hill and we had take-out burritos with my parents, my sister-in-law Pam and Amita's two cousins Elena (3) and Tessa (10 months). The three girls got along like gang-busters; Elena seems to like being the older sister showing the younger girls what to do. tags: california travel los altos hills amitajune elena tessa

Jagi's Birthday Party Friday night we went up to the City for my brother Nate's annual Halloween party. Nate lives on a precipitous incline in North Beach, the Italian-Beatnik section in the northeast of San Francisco with steep hills, great caf s and a significant dearth of parking. We managed to get Amita June down to bed for the night, gave her grandparents far more instructions than were actually needed, and then sped off into the night. We were running late, but we stopped on the way to pick up Maj's brother Brian, who lives in Noe Valley. It was the first time we'd seen his new apartment and we probably took longer than necessary there, but we finally got off towards North Beach around 7:30PM. And... we drove and drove. Every street I drove down was packed, and I kept doing U-turns and trying alternate routes to get where we were going. Finally, on Van Ness Avenue at California Street, we got stuck in a gridlock that wouldn't move at all. Friday nights are pretty bad for traffic in San Francisco, but at this point we sat through 5 red-and-green light cycles without any motion whatsoever. Unable to turn, unable to go forward, unable to go back. When traffic finally started moving again, we saw what the problem was: the last dregs of the Critical Mass rally were just passing through. Critical Mass is a bike rally that happens on the last Friday of each month in San Francisco and elsewhere; hundreds of bike riders take over streets and block traffic. It's really fun if you're riding; it's infuriating if you're driving. We drove down further on Van Ness to go through the Broadway Tunnel into North Beach, but it was blocked by... Critical Mass! They'd turned about and come to block our way again. This time, I was able to do a U-turn and get over to Nate's house through side streets. We had a good time at the party itself. Nate and his roommates have been having a Halloween party for years, but increased size and complaints from landlord and neighbors have made them move the party to a nearby bar, Woody Zip's. With two stories, two bars and a dance floor, it was just about the right size for their event. Nate was dressed up as Buzz Lightyear from "Toy Story"; Brian had a huge fat suit and a sumo-wrestler outfit. Maj and I were millionaires, with tiaras and top-hats. We all looked pretty good. Woody Zip's even let the guys bring their own Jagermeister machine, affectionately known as "Jagi". They got the machine for one of their Halloween parties a few years ago, and they've made special costumes for it each year (this year: Spongebob Squarepants). We had a shot of Jager and toasted the machine's maturity, then moved on to karaoke and dancing. But only for a while; by 10PM we had to start heading home. We worried quite a bit about Amita June, but when we got back she was asleep in the arms of her Pappou in the TV room. The "parent curfew" is a little hard to deal with, but on the bright side it makes sure you can find babysitters so you can go out in the future. tags: halloween nate north beach party jagermeister san francisco

Baby Circus Last night we went to visit our friends Zach and Wendy in wt:El Cerrito, in the East Bay. Zach and Wendy have been our friends for... oh, more than 10 years now, I guess. They had a handsome little cowboy son two years ago, on the same weekend as my bachelor party in wt:Las Vegas (making it easy to remember his birthday... better than I remember that weekend, is for sure). They have a nice house just near the BART station, with lots of room... although about 2/3 of it is taken up with Wyatt's toys. Wendy is a Web developer for Nolo Press, the do-it-yourself law book publisher. Zach is a hard-working computer genius, one of my favorite people to work with, but he's hung up his spurs to be a full-time stay-at-home dad and go back to school. We had dinner at the Kensington Circus Pub, just up the hill from Wendy and Zach's house. It was a great place; an English-style pub with Fuller's ESB on tap, and a kids' play area underneath the dartboard. Amita June and Wyatt ran around playing while we had fish-and-chips and burgers. It's a great recipe for getting young parents to come to your restaurant; I wish more places would use it. We spent the rest of the night talking about wikis and web sites and all the opportunities there are available to share information in creative ways. We dragged home after Wyatt's bedtime, and Amita fell asleep in the car on the way back home. Greatest thing in the world! tags: zach wendy wyatt el cerrito kensington circus pub

I learn fire I had drinks with Hugh McGuire, founder of Librivox, at La ka on St. Laurent last Wednesday. It was a real good time -- Hugh has had similar experiences "leading" that public domain audiobook project that Maj and I have had with Wikitravel. Another project he's working on Collectik.net, an interesting tool for sorting and organizing podcast streams. I have to admit that I've been skipping the podcast wave -- much like I skipped blogging before it -- and I don't listen to a lot of podcasts. But Hugh got me interested, and now I'm looking around at it. I find there are a lot of interesting tools for podcast catching for Linux; even Rhythmbox, the Gnome music player, can handle podcasts. I'm finding it interesting to listen to them; DestinyLand and Chris DiBona's FLOSS TV are both interesting, as well as the CBC podcasts. I haven't figured out how to listen to Vu d'ici, though -- m-c doesn't seem to have an RSS feed with just the podcasts in it. Or am I missing something? tags: podcast destinyland flosstv vudici rhythmbox librivox collectik laika hugh macguire

I'm working on an application that needs an idle callback (do something after the user has been idle for N seconds). It was pretty easy to hack up once I found some example javascript code (hopefully it works in IE too...):

def on_idle(timeout, options)
  timeout *= 1000
  remote = remote_function(options)
  javascript_tag("
var alarm =  
  remind: function()  
    # remote 
    delete this.timeoutID;
    this.setup(this.ms);
   ,
  setup: function(ms)  
    this.cancel();
    var self = this;
    self.ms = ms;
    this.timeoutID = window.setTimeout(function(msg)  self.remind(); , ms);
   ,
  cancel: function()  
    if(typeof this.timeoutID == \"number\")  
      window.clearTimeout(this.timeoutID);
      delete this.timeoutID;
     
   
 ;
alarm.setup(# timeout );
window.onblur = function()   alarm.setup(# timeout )  ;
window.onfocus = function()   alarm.setup(# timeout )  ;
window.onmousemove = function()   alarm.setup(# timeout )  ;
")
end

I use it like so, after putting it into my application_helper.rb file.

<%= on_idle 600, :url =>   :action => 'on_idle'   %>

It could probably improved by making it take some options to determine which events cause un-idleness and perhaps call a no-longer-idle hook. I'll update this page with those changes should I get around to them. I wonder if there's a good, centralized place to submit these kinds of little hacks to? The Rails trac system seems to be full of spam, indicating that people aren't triaging bugs at all.

Apparently (unless they already have some spam filters in place; I'm surprised they don't use rel="nofollow") you can turn YouTube into a huge link farm. You won't be able to inject links into non-youtube-sites, but maybe (I didn't test that) it's possible to inject at least a link from every single youtube video page to yours... And it's not even a new thing. I mean, referrer spam is old. Really old. Sure, they might have filters, I havn't tested, but I'm not sure you can reliably filter this unless the "attacker" seriously overdoes it. I'll try it with this blog entry. Maybe I can become a top result for "youtube chad steve" this way? Not that I'd have any benefits from that. (And no, it's not funny if you prove me correct by sabotaging my attemt using the same technique. Be more creative than that, please.)

Today I saw the movie God On My Side by Andrew Denton. It's an interesting movie about the televangelist industry in the US. I expected it to be about the shonky frauds who harm people, there was one scene in the start of a televangelist claiming to cure diabeties (a very dangerous claim that often results in serious injury to the victims of such frauds), but mostly it was about serious evangelists and not about the frauds.

What was scary was the level of advocacy of Armageddon. These people seemed very determined to have a great war between the US and Russia (haven't they realised that the USSR doesn't exist any more?). They advocated taking all possible measures to defend Israel (not ruling out the use of nuclear weapons) and didn't want any compromise with Palestine (no land for peace - after all peace gets in the way of Armageddon).

One insightful comment by an evangelist pointed out that many Christians have gone wrong in their advocacy in being based on what they are against rather than what they are for. It's a sad trend that most Christians are not able to express any positive things that they are for and only focus on things that they oppose. On most occasions when they say they are for something it is really a disguise for being against something else, EG supporting Family Values means oppressing homosexuals, preventing freedom of speech (bad language), and banning abortions (even for rape victims).

I am looking forward to the DVD release of this. I'm sure that the out-takes and some further footage post release will be interesting.

Above is the day 21 beard picture.

I don't often post about work, but it's always with some trepidation that I switch my main computers to the new distro.

While I moved from the Distro team to leading the Support team last October, I still retain my Ubuntu core-dev status, and keep current by looking at toolchain issues occasionally and hacking on our SCC ports, ia64 and hppa. This means that not only do I keep my programming sk1llz from getting rusty through disuse, but I also have reason to keep in touch with other members of the distro team who are both work colleagues and friends.

As one of the people who cares the most about glibc in Ubuntu, I try to make sure that I'm running it wherever possible and making sure that I'm likely to find at least the obvious bugs before others.

So last night I pointed my sources.list to feisty.

This morning there were already two updates: base-files, and debootstrap. linux-libc-dev (the kernel headers) will come along shortly after the new kernel doesn't FTBFS. At the beginning of next week, there will be binutils, libc*, and gcc-4.1. And after that, the merge.

This will be the fourth release in a row that I've ridden from the first files uploaded. At times it's been exciting (leaving for a management meeting in Spain with a non-working X or wireless, not to mention broken cell phone and airplane. All of which were solved by the time I got to Mallorca.)

Interestingly, Simon Richter write about rerunning maintainer scripts for changes in related packages just when I thought that it would really be nice to get SpamPD (a SMTP-proxy in Perl which scans mails for spam using the Mail::SpamAssassin Perl module) restarted when SpamAssassin gets updated. Or to get spamd (which is part of SpamAssassin) restarted when a plugin is updated, removed or installed. Of course the second one is easier since the plugin package “knows” that SpamAssassin is affected by the change and can thus reload/restart spamd.
One idea I had for this is to create a hierarchy to which an admin or maintainer could add scripts (effectively providing hooks), like this:
/var/lib/dpkg/hooks/<package>/(removal update install)/(pre post)/<hook-package>
Where <hook-package> would be the package installing the hook while <package> is the package for which the action is to be “monitored”.So that I as the SpamPD maintainer could make the spampd package install a script in
/var/lib/dpkg/hooks/spamassassin/update/post/spampd which would get called whenever spamassassin is updated, after the update, to be exact.
An alternative on per-package basis would of course be:
/var/lib/<package>/hooks/(pre post)inst/<hook-package> or /var/lib/spamassassin/hooks/postinst/spampd for the above example. I would be quite intested to hear what other devs think about this.

Tweaking my dspam setup I was recently disappointed with my dspam setup: while it was catching lots of spam and it would never misclassify ham, I would still get like 50 spams a day in my inbox. In a moment of enlightenment, I realised that it could be because I'm subscribed to loads of mailing lists many of which I read only every so often. This means that I don't feed dspam those spam messages that manage to go through those lists, and so dspam gets to figure out that they are innocent, and therefore ends up with too broad an idea of innocence. The solution was heroically simple: plug dspam only after sorting mailing lists in their own folders, and only on the remaining personal mail. Not so simple was the implementation, since I had dspam integrated with postfix and it would necessarily process all the mail I get. This is what I did:

1. I removed dspam hooks from postfix
2. I hooked dspam into procmail:

   :0fw
     /usr/bin/dspam --user=enrico --stdout --deliver=innocent,spam
   :0
   * ^X-DSPAM-Result: spam
   .spam/
   

3. I figured out that dspam run from postfix in that way would not make use of the server, not even if I use --client. I thus disabled the dspam server in /etc/default/dspam. This is a shame, but luckily I don't have many users and the server load won't suffer much.
4. I fixed the privileges under /var/spool/dspam so that the users can read their dspam data but not the data of other users. Here's what I conjured:

   drwxrwxr-x dspam  dspam /var/spool/dspam/
   drwxrwxr-x dspam  dspam /var/spool/dspam/data
   drwxrwxr-x dspam  dspam /var/spool/dspam/data/local
   drwxrwx--- enrico dspam /var/spool/dspam/data/local/enrico
   drwxrwx--- enrico dspam /var/spool/dspam/data/local/enrico/enrico.sig
   -rw-rw---- enrico dspam /var/spool/dspam/data/local/enrico/enrico.*
   drwxrwx--- pippo  dspam /var/spool/dspam/data/local/pippo [...]
   drwxrwx--- pluto  dspam /var/spool/dspam/data/local/pluto [...]
   drwxrwxr-x dspam  dspam /var/spool/dspam/opt-in
   drwxrwxr-x dspam  dspam /var/spool/dspam/opt-in/local
   -rw-rw-r-- dspam  dspam /var/spool/dspam/opt-in/local/enrico.dspam
   -rw-rw-r-- dspam  dspam /var/spool/dspam/opt-in/local/pippo.dspam
   -rw-rw-r-- dspam  dspam /var/spool/dspam/opt-in/local/pluto.dspam
   -rw-rw---- dspam  dspam /var/spool/dspam/system.log
   

   the opt-in files are actually empty files and dspam seems to only stat() them, so they are probably ok even if they're not readable by users. This setup of permissions should allow dspam to run as the various users while fully preserving their privacy towards each others.
5. In /etc/dspam/dspam.conf I commented out the Delivery options, since I let procmail take care of the delivery. I'm also not using ParseToHeaders anymore. The rest of the dspam configuration did not change.
6. Instead of ParseToHeaders, I set up postfix aliases properly running dspam as the dspam user. The trick is to create an alias file owned by the dspam user and the dspam group, and tell postfix to use it:

   alias_maps = hash:/etc/aliases, hash:/etc/postfix/aliases-dspam
   alias_database = hash:/etc/aliases, hash:/etc/postfix/aliases-dspam
   

   /etc/postfix/aliases-dspam in turn contains:

   spam-enrico:" /usr/bin/dspam --user enrico --class=spam --source=error"
   notspam-enrico:" /usr/bin/dspam --user enrico --class=innocent --source=error"
   spam-pippo:" /usr/bin/dspam --user pippo --class=spam --source=error"
   notspam-pippo:" /usr/bin/dspam --user pippo --class=innocent --source=error"
   spam-pluto:" /usr/bin/dspam --user pluto --class=spam --source=error"
   notspam-pluto:" /usr/bin/dspam --user pluto --class=innocent --source=error"
   

   since I took care of leaving everything in /var/spool/dspam writable by the dspam group, this works perfectly. It also allows me to bounce a mail to the report address instead of forwarding it. With ParseToHeaders I had to forward because the bounced messages would not have the report address in their headers, and so dspam could not identify them. By the way, here's the mutt macro I use to report spam:

   macro index,pager <F12> "bspam-enrico@xxx.xx\n\ns=.spam\n" 'Report as spam'
   

This is it. It took a while as dspam isn't always straightforward to set up, but now I've finally stopped having to remove 20 spam messages from my inbox for every 1 legitimate mail I receive.

First, my position: I'm in favour of paying people to work on debian, but I think the one-person job markets, lack of openness and trading on debian's goodwill makes the current configuration of Dunc-Tank unacceptable. This should not be a surprise: I questioned the one-person-time contracts right near the start, but - like so many questions - it went unanswered. Secondly, I think this is wrong for the project. Damage was forseeable and maybe could have been mitigated, but Debian Project Leader Anthony Towns chose to raise the stakes, taking the funding outside the project, leaving no control for the developers except a recall vote, as far as I can see. The DPL wasn't recalled, but is still partly to blame for the damage, no matter whether more than half of DDs support him or not. Finally, I'm unconvinced by Wouter Verhelst's arguments that USD 6000 is a fair price. The one-person market is nothing like a free market and that particular rationale seems wrong because:

1. VAT is a Tax on Value Added, so the payment of 21% or whatever would be reduced by the VAT paid on any supplies, which reduces the effective total rate. Also, small businesses are VAT-exempt in some states. Finally, Stephen R. Langasek seems to be in Oregon and Oregon has no state sales tax [Oregon Department of Revenue] - does that mean no VAT either? So, still 6000 left;
2. Suburban office space in Oregon looks like it costs USD 13.50/sf/yr fully-serviced (source), so a month for one person (175sf) would be about USD 200. Even downtown Portland is only about USD 300. (Where did 500 come from?) So, 5700 left;
3. Utilities: it's GBP 40 for phone+internet here and the rest are included in fully-serviced, as far as I know, so let's say USD 100, even though USA is reputedly cheaper? 5600 left;
4. Accountant fees are pretty much constant if you have a working business, but USD 3600 for a year? I'd expect closer to USD2000 (so about 200 per month) for a one-person business. SPI seems to pay USD1000 for bookkeeping, but I can't find a direct comparable - anyone know? 5400 left;
5. Social and other insurances tend to be related to income, working out around to a third or so in the UK IIRC, so USD2000? What's the current US rate? 3400 left;
6. Double-taxation seems like something a good accountant should help to avoid - not heard of it being a significant problem often; 3400 left.

So, that leaves USD 3400, less some % for VAT maybe. Not well-paid IMO, but much more than living cost for many DDs. If any of the above figures are too high or low, please tell me and I'll update this. Of course, the actual payment rate is minor to me, compared to the problem of dunc-tank being designed as a market for lemons and being driven through by brinkmanship.

upstart is a replacement for the init daemon, the process spawned by the kernel that is responsible for starting, supervising and stopping all other processes on the system. The existing daemon is based on the one found in UNIX System V, and is thus known as sysvinit. It separates jobs into different “run levels” and can either run a job when particular run levels are entered (e.g. /etc/init.d/rc 2) or continually during a particular run level (e.g. /sbin/getty). The /etc/init.d/rc script is also based on the System V one (and is in the sysv-rc package), it simply executes the stop then start scripts found in /etc/rcN.d (where N is the run level) in numerical order. Why change it? Running a fixed set of scripts, one after the other, in a particular order has served us reasonably well until now. However as Linux has got better and better at dealing with modern computing (arguably Linux’s removable device support is better than Windows’ now) this approach has begun to have problems. The old approach works as long as you can guarantee when in the boot sequence things are available, so you can place your init script after that point and know that it will work. Typical ordering requirements are:

• Hard drive devices must have been discovered, initialised and partitions detected before we try and mount from /etc/fstab.

• Network devices must have been discovered and initialised before we try and start networking.

This worked ten years ago, why doesn’t it work now? The simple answer is that our computer has become far more flexible:

• Drives can be plugged in and removed at any point, e.g. USB drives.

• Storage buses allow more than a fixed number of drives, so they must be scanned for; this operation frequently does not block.

• To reduce power consumption, the drive may not actually be spun up until the bus scan so will not appear for an even longer time.

• Network devices can be plugged in and removed at any point.

• Firmware may need to be loaded after the device has been detected, but before it is usable by the system.

• Mounting a partition in /etc/fstab may require tools in /usr which is a network filesystem that cannot be mounted until after networking has been brought up.

We’ve been able to hack the existing system to make much of this possible, however the result is chock-full of race conditions and bugs. It was time to design a new system that can cope with all of these things without any problems. What we needed was an init system that could dynamically order the start up sequence based on the configuration and hardware found as it went along. Design of upstart upstart is an event-based init daemon; events generated by the system cause jobs to be started and running jobs to be stopped. Events can include things such as:

• the system has started,

• the root filesystem is now writable,

• a block device has been added to the system,

• a filesystem has been mounted,

• at a certain time or repeated time period,

• another job has begun running or has finished,

• a file on the disk has been modified,

• there are files in a queue directory,

• a network device has been detected,

• the default route has been added or removed.

In fact, any process on the system may send events to the init daemon over its control socket (subject to security restrictions, of course) so there is no limit. Each job has a life-cycle which is shown in the graph below: The two states shown in red (“waiting” and “running”) are rest states, normally we expect the job to remain in these states until an event comes in, at which point we need to take actual to get the job into the next state. The other states are temporary states; these allow a job to run shell script to prepare for the job itself to be run (“starting”) and clean up afterwards (“stopping”). For services that should be respawned if they terminate before an event that stops them is received, they may run shell script before the process is started again (“respawning”). Jobs leave a state because the process associated with them terminates (or gets killed) and move to the next appropriate state, following the green arrow if the job is to be started or the red arrow if it is to be stopped. When a script returns a non-zero exit status, or is killed, the job will always be stoped. When the main process terminates and the job should not be respawned, the job will also always be stopped. As already covered, events generated by the init daemon or received from other processes cause jobs to be started or stopped; also manual requests to start or stop a job may be received. The communication between the init daemon and other processes is bi-directional, so the status of jobs may be queries and even changes of state to all jobs be received. How does it differ from launchd? launchd is the replacement init system used in MacOS X developed as an “Open Source” project by Apple. For much of its life so far, the licence has actually been entirely non-free and thus it has only become recently interesting with the licence change. Much of the goal of both systems appears initially to be the same; they both start jobs based on system events, however the launchd system severly limits the events to only the following:

• system startup,

• file modified or placed in queue directory,

• particular time (cron replacement),

• connection on a particular port (inetd replacement).

Therefore it does not actually allow us to directly solve the problems we currently have; we couldn’t mount filesystems once the “filesystem checked” event has been recived, we couldn’t check filesystems when the block device is added and we certainly couldn’t start daemons once the complete filesystem (as described by /etc/fstab) is available and writable. The launchd model expects the job to “sit and wait” if it is unable to start, rather than provide a mechanism for the job to only be started when it doesn’t need to wait. Jobs that need /usr to be mounted would need to spin in a loop waiting for /usr to be available before continuing (or use a file in a tmpfs to indicate it’s available, and use that modification as the event). This is not especially surprising given that Apple have a high degree of control over both their hardware and the actual underlying operating system; they don’t need to deal with the wide array of different configurations that we have in the Linux world. Had the licence been sufficiently free at the point we began development of our own system, we would probably have extended launchd rather than implement our own. At the point Apple changed the licence, our own system was already more suitable for our purposes. How does it differ from initng? Initng by Jimmy Wennlund is another replacement init daemon intended to replace the sysvinit system used by Linux. It is a dependency-based system, where upstart is an event-based system. The notion of a dependency-based system is interesting to talk about at this point. Jobs declare dependencies on other jobs that need to happen before the job itself can be started. Starting the job causes its dependencies to be started first, and their dependencies, and so on. When jobs are stopped, if running jobs have no dependencies, they themselves can be stopped. It’s a neat solution to the problem of ordering a fixed boot sequence and the problem of keeping the number of running processes to a minimum needed. However this means that you need to have goals in mind when you boot the system, you need to have decided that you want gdm to be started in order for it, and its dependencies, to be started. Initng uses run levels to ensure this happens, where a run level is a list of goal jobs that should be running in that run level. It’s also not clear how the dependencies interact with the different types of job, a dependency on Apache would need the daemon to be running where a dependency on “checkroot” would need the script to have finished running. Upstart handles this by using different events (“apache running” vs. “checkroot stopping”). Again while interesting, Initng does not solve the problems that we wanted to solve. It can reorder a fixed set of jobs, but cannot dynamically determine the set of jobs needed for that particular boot. A typical example would be that if the only dependency on the job that configures networking is the mount network filesystems job, then should that job fail or notbe a goal (e.g. because there are no network filesystems to be mounted) the result is that network devices themselves will not be configured. You could make everything a goal, and just use the dependencies to determine the order, however this is less efficient than just ordering the existing sysv-rc scripts (which can be done at install time). Another example is that often you simply don’t know whether something is a dependency or not without reading other configuration, for example the mount network filesystems may be a dependency of everything under /usr or may just be a dependency of anything allowing the user to login if it just mounts /home. The difference in model can be summed up as “initng starts with a list of goals and works out how to get there, upstart starts with nothing and finds out where it gets to.” How does it differ from Solaris SMF? SMF is another approach to replacing init developed by Sun for the Solaris operating system. Like initng it’s a dependency-based system, so see above for the differences between those systems and upstart. SMF’s main focus is serive management; making sure that once services are running, they stay running, and allowing the system administrator to query and modify the states of jobs on the system. Upstart provides the same set of functionality in this regard, services are respawned when they fail and system administrators can at any time query the state of running services and adjust the state to their liking. Will it replace cron, inetd, etc? The goal of upstart is to replace those daemons, so that there is only one place (/etc/event.d) where system administrators need to configure when and how jobs should be run. In fact, the goal is that upstart should also replace the “run event scripts” functionality of any daemon on the system. Daemons such as acpid, apmd and Network Manager would send events to init instead of running scripts themselves with their own perculiar configuration and semantics. A system administrator who only wanted a particular daemon to be run while the computer was on AC power would simply need to edit /etc/event.d/daemon and change “on startup” to “on ac power”. What about compatibility? There’s a lot of systems administrators out there who have learned how Linux works already and will not want to learn again immediately, there’s also a large number of books that cover the existing software and won’t cover upstart for at least a couple of years. For this reason, compatibility is very important. upstart will continue to run the existing scripts for the forseeable future so that packages will not need to be updated until the author wants. Compatibility command-line tools that behave like their existing equivalents will also be implemented, a system administrator would never need to know that crontab -e is actually changing upstart jobs. Does it use D-BUS?

“To D-BUS people, every problem seems like a D-BUS problem.” —Erik Troan

The UNIX philosophy is that something should do just one job, and do it very well. upstart’s one job is starting, supervising and stopping other jobs; D-BUS’s one job is passing messages between other jobs. D-BUS does provide a mechanism for services to be activated when the first message is sent to them, thereby starting other jobs. Some people have taken this idea and extended it to suggest that all a replacement init system need do is register jobs with D-BUS and turn booting into a simple matter of message parsing. This seems wrong to me, D-BUS would need to be extended to supervise these services, provide means for them to be restarted and stopped; as well as deal with being process #1 which means cleaning up after children whose parent’s have died, etc. It seems far simpler to arrange for D-BUS to send an event to init when it needs a service to be started, and focus on being a very good message passing system. The IPC mechanism used by upstart is not currently D-BUS because of various problems, however it’s always been expected that even if init itself doesn’t communicate with D-BUS directly, there would be a D-BUS proxy that would ensure messages about all init jobs and events would be given to D-BUS and D-BUS clients could send messages to init to query and change the state of jobs. What is the implementation plan? Because this is process #1 we are changing, we want to make sure that we get it right. Therefore instead of releasing a fully-featured daemon and configuration to the world, we’re developing it in the following stages:

1. Principal development; at the end of this stage the daemon has been implemented and can manage jobs as described.
2. Replacement of /sbin/init while running the existing sysv-rc scripts. This is the shake-down test of the daemon, can it perform the same job as the existing sysvinit daemon without any regressions?
3. /etc/rcS.d scripts replaced by upstart jobs. These consitute the majority of tasks for booting the system into at least single-user mode, and contain many of the current ordering problems and race conditions. If the daemon solves the problems here, it will be a success.
4. Other daemon’s scripts replaced by upstart jobs on a package-by-package basis; this will be an ongoing effort during which upstart will continue running the existing sysv-rc scripts as well as its own jobs. During this time the event system may be tweaked to ensure it truly solves the problems we need.
5. Replcement of cron, atd, anacron and inetd. This will happen alongside the above and result in a single place to configure system jobs.
6. Modification of other daemons and processes to send events to init instead of trying to run things themselves.

The current plan is that we will be at least part of the way into stage #3 by the time edgy is released, with that release shipping with upstart as the init daemon and the most critical rcS scripts being run by it to correct the major problems For edgy+1 we hope to have completed stage #5 and be at least part of the way into the implementation of stage #6. From the start of development of edgy+2, no new packages will be accepted unless they provide upstart jobs instead of init scripts and init scripts will be considered deprecated. What state is it in now? The init daemon has been written and is able to manage jobs as described above, receiving events on the control socket to start and stop them. This has now been uploaded to the Ubuntu universe component in the upstart package for testing before it becomes the init daemon. We welcome any experienced users who want to help test this; install the package and follow the instructions in /usr/share/doc/upstart/README.Debian to add a boot option that will use upstart instead of init. If your system boots and shut downs normally (other than a slightly more verbose boot without usplash running) then it is working correctly. Other types of events will be added as required during development and testing. Currently only a basic client tool (initctl) has been written, compatibility tools such as shutdown will be written over the next week or two before it replaces our sysvinit package.

Here at Canonical Towers we have several staff who worship at the altar of Extreme Programming, and as such many of the methodologies and rituals prescribed by that religion find their way into our day-to-day working practices. A few of these came together in an interesting way a few weeks ago, and it was suggested by a cow-orker that I blog about it so he could give the URL to people. The first ritual is that of the sprint, I don’t think this is orthodox XP but rather something inspired from it that we picked up from the Python community. With all of the Canonical developers scattered across the globe mostly working from their own homes, it’s become a useful tool; particularly for the Launchpad team. The basic idea for those that haven’t heard of it is simple, and perhaps obvious; you get a selection of the team together in one place, sit them around the same table with particular goals to complete. In effect it’s highly compressed facetime and high bandwidth interaction to nail those tasks that need it, before you head off again and work at a more sedate pace. The second is directly from XP doctrine and is that peculiar observance known as pair programming, something that is often coupled with sprints. For anybody who hasn’t encountered this before, it’s something I’ve always found rather odd. You get two programmers together, both itching to code, and you take one of them’s laptop away; and you don’t just force them to fight over the keyboard either, the laptop-less soul isn’t allowed to touch it. The theory here is that it frees the deprived individual of the hassle of coding and allows them to direct the programmer in ways that may not be immediately obbious, or alternately think about the next bit of work that needs doing. Another interesting side-effect is it can be an interesting way to learn code you’ve not worked with before, if you’re the one doing the coding and you’re being guided what to do by a sage who already knows it. I have a funny story here, so I’m going to digress from the main stream for a moment to tell it. A few months ago I was working in the London office, Mark had been up all night coding and had then given me responsibility to get his changes landed onto the Launchpad mainline. I’m not that hot on quite a bit of Launchpad, and fade to utterly clueless the nearer the code gets to the web application itself; and when trying to merge the two there were conflicts which I needed Mark’s help to resolve. Now as anybody who’s met Mark knows, he’s a pretty good example of a Type-A personality, yet he suggested that we do a spot of pair programming to get the code in and I’d be the one with the laptop as it’d help me get to grips with the affected parts. This hilighted something I’ve always seen as a problem with pair programming, dealing with it when the a person with the keyboard has a totally different way of working to you. In particular, I’m an emacs user, whereas Mark is a die-hard vim user; but also right down to the working directory I would work from, how I test results, etc. When you’re the one without the laptop, this can be quite infuriating, as you know exactly how to solve a problem and the idiot with the keyboard is dithering about doing things you don’t understand just to get there. If you’re a Type-A personality, you generally snatch the laptop away at this point and do it yourself; or at least you would, if you could drive the strange editor the other person uses. I swear Mark was sulking as he gave the laptop back and let me do it. Anyway, there is some relevance to that and we’ll come to it in a moment. The third and final methodology is the concept of unit tests and more specifically test driven development. For anyone who hasn’t come across this before, I highly recommend it; I was suspicious too when Robert Collins took it upon himself to teach me the true way, but now I’m sold. Simply the idea is that if you have any code that doesn’t have another piece of code in a test suite that checks that it’s working correctly, that code is broken. More particularly unit testing involves checking just one feature or requirement at a time, and stacking them together to test all of the code paths. I’ve actually found that this improves the APIs I design, as I write the code in small blocks and functions to make them easier to test. Test driven development takes it even further, you write the unit tests first, before you write the code they’re supposed to test; usually one or two at a time. Obviously these tests will fail at first, it’s then your job to write as little code as possible to make them pass. If your code isn’t right, you add a unit test that will fail, and modify the code to make it pass. This really comes into its own when you’re fixing bugs later, once you’ve identified the bug you write a test case or two that cause the problem; these will of course fail. You can then modify the code to make them pass, and at the same time be sure you’ve not broken other functionality because of the existing test suite. I’ve also found it really useful for particularly complicated or tricky pieces of code, especially those intricate algorithms that do particularly heavy lifting. So onto the event itself, this was a sprint in our London office to indoctrinate Gustavo Niemeyer with the various projects he’d be working on. The goal for this sprint was decided to start the conversion of HCT to Bazaar-NG, and to do this Gustavo and I would pair program. Now my last experience of pair programming had been that story with Mark (see, it had some relevance) and I knew I’d be just as bad if I wasn’t allowed to have the keyboard. I was also acutely aware that if Gustavo was just sitting by and watching, he wouldn’t get much benefit from it either, so he needed to be actively involved in the coding so he could learn the things he’d be working on. I came to what I thought was a pretty neat, and obvious, solution to these problems. We set up my laptop with the code we’d be working on, and on my display were two side-by-side terminals both running screen sessions. Gustavo then set up two same-sized terminals on his, ssh’d into my laptop from both of them and joined the screen sessions. In the left-hand one he ran vi, and in the right-hand one I ran emacs. Thus we both had keyboards, and both had editors, yet could see each other working and even steal the keyboard without danger of violence. We didn’t just sit side-by-side and code on different things though, that’s not pair programming and is just ordinary programming with a bit of a voyeuristic twist. What we did was: in my terminal I started writing the test cases for the code we needed, it was Gustavo’s job to write the code that would make them pass. We actually added a third terminal in which we could run the test cases themselves; so I could run them when I’d added something that would fail, and Gustavo could run them when he thought he’d made them pass again. This turned out to be a rather fun way to work, and at one point I was almost able to try and convince myself that the code was writing itself to pass the test cases I was writing. It also got me thinking that it’d be really neat to use genetic algorithms to breed code to pass test cases.

For a project, I've been working a bit with "web 2.0 video services". That is, YouTube, Gogle Video, MySpace videos and similar. So far, the only one I can actually use for my cause is YouTube; Google Video should be possible, whereas MySpace and e.g. MyVideo.de apparently lack the functionality I need. But the functionality I need is pretty simple: thumbnails. For YouTube, I can use their API to query metadata on videos such as viewing counts, title, description, tags - and a thumbnail URL (all I'm lacking is some information on whether the thumbnail URL is permanent, i.e. if I can cache it, or bound to change). For Google Video, there apparently is some way to do the same - digg is reported to have Thumbnails for YouTube and Google Video. Dear Lazyweb, if you have some information on how to get thumbnails (and other metadata such as title, description, tags) for other video services, please send me an email to Erich@debian.org. Thanks! [Update: revver.com has Thumbnails and some API. It works with the beta flash plugin and epiphany.]

Robert Cringely opens his new-look digs (now in blog format which is funny given how his columns predate the term by a good while, even though they always were web logs') with a stunning column about a new disk technology coming to market next year:

[...] disk drives that held up to three times as much data in the same space, were more reliable, actually cheaper to build, and used 70-95 percent less energy to run.
[...]
Our metal foil drive costs less, not more, and spins up so quickly that data can be read from disk as fast or faster than it can be read from flash. Who needs a hybrid disk drive?
[...]
The market potential is one billion computer disk drives and one billion mobile phone drives per year. And it all starts around this time next year when metal foil drives will begin to appear under well-known brand names.

Bring'em on.