The BarCamp Zurich 2006 is over. On the way there I thought about what I would do during time slots with no interesting talks. But when I tried to make up my personal schedule, I noticed that I rather would have the opposite problem: Too many interesting talks at the same time… Well, to many interesting talks at all, although I only went to tech talks and left out the biz talks. I first went to the Podcasting & Co. talk by Timo Hetzel, since I never heard or made a podcast, but was curious about podcasts in general. Besides statistics and rankings he spoke about where people listen to podcast (most listeners seem to do that during commuting), what people like in podcasts, why companies podcast, etc. And that a very big share of all podcast listeners use iTunes as podcast client and except juice (never heard of it before) all other podcast clients seem to be irrelevant. My conclusion: I haven’t missed anything not having listened to or made podcasts neither do I need to listen or make podcasts in the future. They’re irrelevant. To me. :-) Then I had to choose between the talks AJAX@localhost (PDF) by Harry Fuecks and Realtime Collaborative Text Editing and SubEthaEdit by the Coding Monkeys. I heard about realtime collaborative editing once know that it’s a challenging task for the developer. I also know what AJAX is (and that I would only use or recommend it for bells and whistles, but not for content in general), but “AJAX@localhost” sounded like writing normal applications using AJAX. It sounded interesting and evil at the same time. I had to go there! ;-) Others had similar expectations after reading the talk’s title, so I was quite surprised that it was about something completely different, namely about debugging AJAX on the localhost but under conditions usually only appearing if you’re running AJAX application not from localhost but from somewhere on the net: You may have different lags with every request, so some requests may reach the server before others, which may screw up the whole AJAX application, if the developers didn’t think about it and only tested it on localhost. (Hence the talk’s title…) My conlusion: I will use and recommend AJAX even more seldom, since there seem to be even more design misconceptions than I thought before. But I’ll once have a look at the Webtuesday meeting, he mentioned. For the third time-slot, I didn’t need long to decide where to go: I already knew a little bit about Microformats and I wanted to know more. Tag Trade also sounded interesting, but the second part of the talk’s title, Paid Learning sounded like business and so I had no scruples to cold-shoulder that talk. I probably didn’t learn anything really new in the microformats talk, but my knowledge about microformats is now more concrete, and after talking with Cédric Hüsler later during a break, I would even trust myself to start and define a new microformat. Then I went to the HG Caféteria together with Gürkan and two German guys. While waiting in the queue, we were talking about our jobs and our favourite Linux distributions. I got some rhubarb pie and a rum truffles, assuming that the Caféteria uses no alcohol in their products like all other SV restaurant I know. But this one seemed to have quite a lot of alcohol, since it felt like my breath was burning… Well, this resulted in my second SV feedback form submission… Next I went to Alex Schröder’s talk about multilingual websites, Oddmuse and the Emacs Wiki, although also the talk A-Life about simulating evolution sounded promising. Alex asked the listeners about their experiences with multilingual websites and showed what Oddmuse offers as partial solution to the general multilingualism problems. But regarding the comments from the auditorium, there probably won’t be a perfect solution until computers can translate perfectly… The next talk I visited was Gabor’s talk about his master thesis Organizing E-Mail which resulted in a soon to be released Mozilla Thunderbird extension called BuzzTrack. From the other concepts he showed, I found Microsoft’s SNARF (Social Network and Relationship Finder) and IBM’s Thread Arcs most interesting as well as the fact that there is no e-mail client seems to have a majority at all. Directly after Gabor I had my own talk about Understanding Shell Quoting, so I also couldn’t go to Adrian Heydecker’s talk about Learning with Hypertext and Search Engines. I had only about three and a half listeners of whom several to my surprise where here because they didn’t know what “shell quoting” is. I really didn’t expect that. But that seems to be one of the differences between a BarCamp and a Linux Conferences: People come here to see something new, something they haven’t heard about before. On Linux events most people come, because they already heard about some special topic and want to know more or learn something about it. On Linux event my shell talks usually were attracting many visitors while at a BarCamp, talks presenting an idea, a concept or a tool seem to much more interesting for the attendees. So for the next BarCamp I perhaps exhume my Website Meta Language talk which never seemed to hit the nerve of Linux event attendees, since it tried to “sell” a different concept of generating website than most were used to. At least one listener excepted the talk to be named “shell escaping”, but IMHO escaping is only one quoting technic and it’s not only used for quoting. But perhaps I should take the word “escaping” in the title though for the next time. Happily most of the listeners seem to have learned something new from the talk and Silvan Gebhardt was really happy about his new knowledge about ssh ~ escapes, although I mainly talked about how to quote them than how to use them. :-) During the last slot I visited the session about the upcoming BarCamp Alsace 2 and the yet to be planned BarCamp Rhine, a BarCamp to be held on a ship traveling from Basel in Switzerland down the Rhine, stopping in Strasbourg, Karlsruhe, Rhein-Main-Area and perhaps even Cologne and Amsterdam. Contrary to my initial thoughts, the day was over very fast and I had no single boring minute during the BarCamp. Wow! After we’ve been kicked out of the building by ETH janitors, we joined again at the Bar N-68. On the way there I met Urban M ller who attended BarCamp Zurich, too. We talked quite a lot and it was very interesting to see behind the scenes of e.g. map.search.ch. Later I joined the French speaking table, talking with Gregoire Japiot from WineCamp France and Alex Schröder. Around 9pm I left the N-68 as one of the last BarCampers, tired but with new knowledge, new ideas, new acquaintances and a new hobby: BarCamping. What a luck that BarCamps aren’t that often, otherwise I couldn’t afford this new hobby. ;-) As a relaxing end I met with Alex Schröder and Christophe Ducamp on Sunday morning for brunch in the restaurant Gloria in the Industriequartier. When we were leaving the Gloria I noticed their book board with a lots of BookCrossing books and I took “The Da Vinci Code” with me, since I saw the movie and people were telling me that the book is much better. I’ll see…

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

Since everyone is doing it these days, I'm writing a wiki. It's a compiler for simple documents, with strictly semantic markup, but with a query language that allows database accesses.

Things come and go. In batches, it seems. Tonight, at exactly the very same time I was filling out my NM application, I received the final, definitive, no self-denial-possible message that my previous life is over. With prejudice. Kind of ruined the moment. Or, maybe it was the other way around and having mustered the courage to apply damped the sorrow. Up and onwards, I guess.

Dude, I could not agree with you more.

However, you seem unwilling to take Ubuntu to task over it's decision to use the trademarks. It's not clear to me under what circumstances you can even use the icon, since the copyright file doesn't list what the copying conditions are, in fact it doesn't mention the logo graphic copyrights at all. I think this is a big loss for distributions everywhere. While this would appear to be expedient and make users happy, but it creates more work for the derivers of Ubuntu and it also makes it harder for Ubuntu to derive from Debian. It also sends the message that this sort of thing is alright, that we should just accept upstreams doing 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.

With my Ubuntu hat, I strongly regret that no Ubuntu developer (to my knowledge) stepped forward to point out the inaccuracies in Chris Beard’s (Mozilla Vice President of Products) Q&A on Mozilla Firefox in Ubuntu. Letting people bash Debian when Ubuntu gets so much stuff from Debian isn’t nice at all. With my Debian hat, I really like how Mike Hommey chose to discuss facts, with references, in his reply to Chris Beard’s post. When it is possible, going back to the facts is really the best thing to do to avoid the usual FUD. It’s not really a surprise that this intelligent behaviour came from the Debian side. I have been a very happy user of Epiphany since I made the switch from Firefox 3 months ago. I would recommend it to anyone still using Firefox who is tired of its slow startup times, and its lack of integration in the Gnome desktop.

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

or How Mozilla Corporation is FUDing on Debian. Again. This time, Christopher Beard, Mr Mozilla Marketing is talking about Firefox in Ubuntu, that it’s great, Ubuntu is a good boy, that it cooperates with Mozilla , and that by cooperating, it can use the great Firefox name and logo. To be honest, I don’t care that Ubuntu calls Firefox Firefox instead of Iceweasel or whatever. I don’t care that Ubuntu doesn’t care about freedom as much as Debian does. I could not care less. But, indeed, I do care about (yet other) false claims about Firefox in Debian. Let’s see what Christopher has to say about it:

I understand that Ubuntu is based upon Debian. Is that the same or different than the IceWeasel browser that Debian is shipping with their latest release?
It’s different. The patches that Debian applied to the Mozilla source code (which then resulted in their IceWeasel product) are more significant in scope than those in what Ubuntu is shipping (and branding as an official Mozilla Firefox release). Firefox in Ubuntu represents a somewhat more modest set of divergences from original Mozilla source code.

Let’s check out what it is about. And as I don’t want people to doubt my words, I’ll give you, readers, the ability to check for yourself what it is all about. First, please download the latest currently available patch for Firefox 2.0 beta 2 in Debian. It has been in experimental for some weeks now. It is a bit different from the patch I described earlier, so I’ll also tell you what has been changed since this 2.0b2 patch:

• security/coreconf/rules.mk is not patched for the perl dependencies thing any more because the patch (taken from bugzilla #325148) has been applied in Firefox 2.0rc1
• The patch from bugzilla #336056 has been applied because the directory in which we would build the 2.0rc1 version contained a ~ character, which would make the build fail because of this bug.
• The patch from bugzilla #294879 has been applied for obvious reasons. It has been applied later in the Firefox 2.0 release process.

(Also note that another change has been done since then, which is actually reverting a previous patch on gfx/src/gtk/mozilla-decoder.cpp, that was adding code that became dead code when we changed the way to fix the bug.) Next, please download the official and supported Firefox diff from Ubuntu. Uncompress both these diff files, and create two directories (let’s call them ubuntudiff and debdiff) which will contain the individual patches for each file. To fill these directories, please use the following commands:

$ filterdiff --strip=1 firefox_2.0+0dfsg-0ubuntu3.diff > ubuntu.diff
$ filterdiff --strip=1 firefox_1.99+2.0b2+dfsg-1.diff > deb.diff
$ cd ubuntudiff
$ splitdiff -d -a ../ubuntu.diff
$ cd ../debdiff
$ splitdiff -d -a ../deb.diff
If you don’t have the splitdiff and filterdiff utilities, you can get them from the patchutils tools (you will also need another of these tools later). Now, let’s have fun with these split patches… Files that are only patched in Debian: (excluding any file that would be in the debian subdirectory, that contains maintainer scripts for build and installation)

$ LANG=C diff -ru debdiff/ ubuntudiff/ grep "^Only in deb" grep -v debian wc -l
6
So, that’s 6 files that Debian patches that Ubuntu doesn’t. Let’s check what they are:

$ LANG=C diff -ru debdiff/ ubuntudiff/ grep "^Only in deb" grep -v debian

(reordering result for convenience)

Only in debdiff/: browser_base_content_aboutDialog.xul

Adds rows=5 to the user agent textbox so as to display the user agent string uncut by default

Only in debdiff/: content_html_content_src_nsGenericHTMLElement.cpp
Only in debdiff/: content_html_content_src_nsHTMLInputElement.cpp
Only in debdiff/: dom_src_base_nsGlobalWindow.cpp

It’s a patch I submitted in bugzilla #343953 and that got applied in Firefox 2.0. No surprise the patch is not applied on Ubuntu.

Only in debdiff/: extensions_reporter_Makefile.in

Patch I submitted in bugzilla #354413 and that got applied in Firefox 2.0.

Only in debdiff/: security_coreconf_rules.mk

Patch from bugzilla #325148 that got applied in Firefox 2.0 (see above), and a small patch to build the NSS library with debugging symbols (put -g in CFLAGS). That leaves only 2 small patches : CFLAGS = -g added to security/coreconf/rules.mk and rows=5 to browser/base/content/aboutDialog.xul Files that are only patched in Ubuntu: (same exceptions as for Debian)

$ LANG=C diff -ru debdiff/ ubuntudiff/ grep "^Only in ubuntu" grep -v debian wc -l
45
Yes, that’s right, that’s 45 files that Ubuntu patches that Debian doesn’t. Most are windows sizes and similar things that upstream can’t get right because they are values adapted to Windows, but that also includes some changes to the code and some other things. Let’s now check differences in files that are patched in both. It’s a bit of shell black magic, but you can check by hand that it does nothing wrong :

$ LANG=C diff -ru debdiff/ ubuntudiff/ filterdiff -p1 -x configure -x debian"*" lsdiff --strip=1 while read f; do diff -u debdiff/$f ubuntudiff/ awk "! /^--- ^\+\+\+ ^ ^[-+]*\@\@/ print \"$f\"; exit "; done

That gives a list of patch files that have more differences than line numbers changes, and that do not apply to the debian directory or the configure script (which is generated from configure.in), which is what we really want to compare here. You can take this list and run interdiff between these files from the ubuntudiff and debdiff directories. I’ll explain for you what these differences are:

• Makefile.in: Ubuntu adds a line in order to install the NSS include files,
• browser_app_Makefile.in: Patch from bugzilla #314927 applied by Debian
• browser_app_profile_firefox.js: (interdiff fails because the changes apply to different versions of the file) Ubuntu changes the homepage, and sets profile.allow_automigration to false,
• config_autoconf.mk.in: Ubuntu changes includedir and idldir,
• configure.in: Ubuntu changes MOZ_APP_DISPLAYNAME, and adds some echos,
• gfx_src_gtk_nsFontMetricsXft.cpp: Ubuntu sets FC_ANY_METRICS to some patterns,
• intl_lwbrk_src_nsJISx4501LineBreaker.cpp: Patch from bugzilla #161826 applied by Debian for sparc64, which is not an architecture supported by Ubuntu,
• modules_libpref_src_init_all.js: Ubuntu changes some default fonts from serif to sans-serif, while Debian changes fonts for serif, sans-serif and monospace (setting to generic names instead of Times, Helvetica and Courier) ; I think both should be applied in Debian, actually. Ubuntu also sets dom.event.contextmenu.enabled to false,
• security_nss_lib_freebl_unix_rand.c: (interdiff fails because the changes apply to different versions of the file): both patches have the exact same effect, but are different due to changes to original file between 2.0rc1 and 2.0 final.

Overall, Ubuntu applies the same set of patches as Debian, plus some more. A somewhat more modest set of divergences, huh ?!? For what it’s worth, Ubuntu, like Debian, builds its Firefox with flat chrome and pango enabled.

What’s different in the shipping Ubuntu version of Firefox than the proposed Debian version of Firefox (that didn’t ultimately ship)?
Technically, changes include fixes to the User Agent string and the feed preview, a well as addressing issues of coherent branding. More significant than any specific difference in code, however, is Ubuntu’s commitment to work together with Mozilla and our community on releases going forward to insure product quality and integrity.
Why are you working with Ubuntu when you wouldn’t work with Debian?
We did try to work with Debian and would prefer a situation in which we work together. Ultimately, Debian took a position that was consistent with their own policies, and not compatible with some of the exceptions to Mozilla trademark policies that we offered. While we understand and respect their decision not to work with us under our branding guidelines, Mozilla believes that brands like Firefox are important for consumer protection. In any event, Ubuntu developers are working closely with Mozilla developers to insure product quality and features that are what users expect when they use Mozilla Firefox, which means that they’ll ship (and will continue to ship) a fully branded version.

Reading between the lines, that means Debian is not working with Mozilla. It’s not like we’re submitting patches. No. Never. Ever. I’m also glad to hear from Asa Dotzler, in comments to Mr Beard’s article, that this great collaboration with Ubuntu will lead to patches applied to Firefox (I guess the paid Canonical employees having more time to deal with Mozilla than the volunteer Debian maintainers may have helped, especially considering they didn’t have to do all what we already prepared). Anyways, it’s not like some of the patches we sent got applied. So, while I’m at it, here is an exhaustive list of the bugs where we took or sent the patches that are applied to Iceweasel: #51429, #161826, #252033, #258429, #273524, #287150, #289394, #294879, #307168, #307418, #314927, #319012, #322806, #323114, #325148, #326245, #330628, #331781, #331785, #331818, #333289, #333308, #343953, #345077, #345079, #345080, #345413. These don’t cover the following patches (see the rationale for these in my previous article):

• security/manager/Makefile.in, security/nss/cmd/shlibsign/Makefile: Don’t build the shlib signatures, see the rationale in my previous article,
• security/nss/cmd/shlibsign/manifest.mn: Don’t build the mangle utility,
• browser/app/Makefile.in: Force linking against libxpcom.so despite -Wl,–as-needed,
• browser/app/profile/firefox.js, gfx/src/gtk/fontEncoding.properties, modules/libpref/src/init/all.js: Preferences changes,
• browser/base/content/aboutDialog.xul: That’s one of the patches that Debian applies that Ubuntu doesn’t. See above,
• config/autoconf.mk.in: Remainings of an old patch for pangocairo, which is now useless, and setting of mozappdir,
• config/rules.mk, configure.in: Patch from Thiemo Seufer to increase stability and performance on mips, useless upstream until bugzilla #258429 is fixed, but on my to_send list,
• extensions/inspector/Makefile.in: Something that should be added to #331785, but well, it’s WONTFIX, anyway,
• layout/build/Makefile.in, layout/build/nsLayoutModule.cpp: Change to the Gecko string,
• modules/libpref/src/nsPrefService.cpp: Add a preferences directory for /etc/firefox/pref,
• widget/src/gtk2/nsWindow.cpp: Extended mouse buttons support, on my to_send list,
• configure.in, xpcom/reflect/xptcall/src/md/unix/Makefile.in: Basic patch for bugzilla #343975,
• configure.in: Check for pangoxft.

It’s so great to spend a great amount of time on a package, send patches, try to understand how things work to get patches applied, and yet, see such denial and false claims about our work. So please, Christopher, Asa, and the others, just stop talking about Debian, it will be better for everyone. PS for Rob in comments out there: No, ColorZilla won’t work on Ubuntu, because of the ABI incompatibility I explained in my previous entry, that Mozilla doesn’t seem to care much about.

I notice that Planet Linux Australia has been changed to not list the feeds URLs, instead it displays the HTML pages for the blogs.

I believe this is a bad idea as some people want to get a list of feeds for the blogs that are aggregated without having to visit all the blog sites and do it manually. One of the many reasons for doing this is for a blog server that has intermittent net access, it might be down at the moment which prevents me from adding it to my feed list. Another reason is that some people (such as me) want to automatically get a list of all feeds from the planet to add to their own personal planet configuration.

I am blogging this not to criticise the administrators of Planet Linux Australia or even to inform them (I have already send them an email). My point is to prevent other people from doing the same thing. At this time I am not sure whether this change in Planet Linux Australia was deliberate, a result of a bug in Planet, or a mistake in configuration (maybe a default changed unexpectedly).

Another planet related surprise that I received today was to notice that my blog appears to have been removed from Planet Fedora. I'm not sure why this happened, one possibility is that removing my blog was regarded as the solution to the problem of it displaying incorrectly (the better solution being to upgrade the Planet software as was done on Planet Debian). Another possibility is that my post about Gratis vs Libre was regarded as criteria for removal. If my blog was removed from Planet Debian or Planet Linux Australia then I would be able to ask the administrators about this (they have email address links conveniently located). Planet Fedora has no such link, so I guess I'll have to wait for a blog comment to find out.

I've included a day 19 beard picture, I was planning to do one yesterday but a design meeting for a VOIP project ran late and I ran out of time. I'll write a post about VOIP in the near future.

If you have to name a single thing that singles out Debian over all the other distributions in practical quality, then you cannot come up with anything but Debian having a policy, packages have to follow.

The little things make something feel raw or polished. Those things that one by itself look to unimportant by itself have real importance in their magnitude.

As with all rules, rulesets can become too large and become a obstacle. This can be avoided by being conservative and minimal in those rules, which Debian always already practised to the extreme.

Limiting this further down to things people deem as "important" will only futher reduce the overall quality. Instead of removing those few things that are in the policy, we should rather extend to make everything in current policy not met to be a bug (which can still be tagged wontfix or help) instead of reducing the rules found in policy or making more things non-binding.

I’m amused that the spellchecker supplied with Firefox 2.0 recognises “Firefox”, but not “firefox”. Must be a trademark issue .. In other news I’ve lost weight and need to buy some new clothes. Or spend the same money on lots of pies. I can’t decide which makes the most sense. Lots of new article submissions on the Debian Administration website which is gratifying to see. That should give me a chance to actually read the books I’m supposed to be reviewing at the moment. Right now I’m working my way through a box-set of thirteen twelve Inspector Morse books which is a lot of fun. In more technical news I’ve made a new release of xen-tools and am still fighting POST handing with Apache2.x.

Tuxpaint could be a poster child for l10n. It has translations now for 68 different locales. The large number of locales poses somewhat of a problem for testing¹. Tuxpaint 0.9.16 just released. During the release preparation, the manual testing of all of these locales drove me nearly insane. So to help out next time, I created the following bash script using xautomation², imagemagick and xprop (from xbase-clients):

#!/bin/bash
testname="tuxpaint" 
root_geometry= xprop -root _NET_DESKTOP_GEOMETRY  cut -d= -f2 
root_x= echo $root_geometry  cut -d, -f1 
root_y= echo $root_geometry  cut -d, -f2 
xc=$((root_x/2-1))
yc=$((root_y/2-1))
capture_tuxpaint ()  
   tuxpaint --startblank --nolockfile --lang $1 --640x480 --windowed --nosound &
   sleep 1
   xte "mousemove $xc $yc" 
   xte "mouseclick 1" 
   sleep 1
   xte "key Escape" 
   sleep 2
   import -silent -window "Tux Paint" $testname-$1.png
   xte "mousermove -120 -40" 
   xte "mouseclick 1" 
 
for lang in  tuxpaint --lang help  awk '$1~/^[[:lower:]]/  print $1 ' ; do
   capture_tuxpaint $lang
done

I’m not entirely happy with it, but it’s at least a starting point. Ideally, I’d make .pat files to use with visgrep to find coordinates for the button images instead of hardwiring the approximate button positions. Also, the script needs a companion script to configure the system for testing (i.e. perform the locales configuration and install all fonts). Here are the resulting screenshots which show up a few problems with the translations. It looks like the quit dialog strings have been updated since they were first translated, so now we need retranslation for several languages. Also, there are some languages, like Swahili and Klingon, for which there are no locales in glibc in Debian. I’ll have to talk to the glibc maintainers about that. And for that matter, I don’t even know if a DFSG-free Klingon font exists. In any event, I’m delighted with the results, and look forward to using xautomation more for GUI testing.

¹ For one thing, several languages require special fonts. For another, there is no way to get tuxpaint to tell you what locales it supports. Granted, there is --lang help, but this is a crude approximation, as the mapping between language and locale is arbitrarily hardwired (which hmh on #debian-devel irc pointed out to me is just plain wrong). It doesn’t help me at all in the arduous task of configuring glibc locales so I can test them. For that, I need to look at i18n.c.

² I tried using xmacro at first, but xmacrorec just made my pointer jiggle back and forth. It seemed like it was updating the position for a short distance, and then X was resetting it back to the former position of the pointer. Some strange interaction with my window manager, perhaps? But ultimately I am happier with the xautomation approach anyway.

This Wired story about 6-word stories is absolutely great.

Here's my attempt:

Sleeping Debian money. Waste?
Impending doom.

(via kottke.org)

Some of you might have followed my volounteer work at the SOS Hermann Gmeiner International College in Tema, Ghana, where I was invited to introduce Linux at the school. Being a free software advocate, I thought this a great opportunity to spread Free Software where it can make the most difference and helps bridging the Digital Divide: In a developing country.Judging from the offer (which was very nice, it included housing, flights, freight, money), I expected the school to be very eager to learn about Linux. I was expecting that I only had to guide existing momentum. What I found instead was that there was zero interest from the people who matter in this case. I got all freedoms to implement what I want (as long as I didn t break anything), and I created some things I think are quite nice: Automatic installations that keep the installed windows intact, neat integration in the Active Directory setup, network monitoring with nagios, a transparent firewall that let s the teachers turn the internet for the class room off and on. But it felt like working for nothing, and I can t push people to use Free Software who are unwilling.So today I drew the concequences and quit with effect to the end of December. The principal, who s project it was in the first place, was sorry, but understanding of my issues, and accepted my resignation. I will be on a trip to the Volta lake and other parts of Ghana with friends from Accra for the next 10 days anywasy, so she will take the time to think and discuss how the school can make the best out of the remaining two months.I have not giving up on spreading Free Software here completely. If I find another project where I can be of more use afterwards, I will consider that. But this time I m going to be very picky where I go, and only take a shorter, better defined project. If I can t find something, then that s it and I ll go back to Germany to continue my studies.

Thanks to Don Armstrong's improvements to the performance of version-tracking in the BTS and Anthony Towns's tweaks to dak, as of the middle of last week, all NMUs uploaded to Debian unstable will cause the bugs mentioned in their changelogs to be marked as closed in that version, instead of just being marked as fixed. This is a great benefit to the release process, since previously, bugfixes in NMUs were still falling off the radar as soon as they were uploaded, with no automatable way to check whether a given update stuck in unstable fixed release-critical bugs that we needed to have in testing for the release. So these guys get a big thank you from me for helping to ensure etch only ships with the bugs we want it to ship with. ;) The new setup also has the advantage that bug submitters finally get the same, real email for bugs closed in NMU as they do for bugs closed in MU, instead of being left in the dark as they were before. But that only takes care of bugs closed in NMUs that happen between now and the release -- it does nothing for the roughly 1200 RC bugs that were already fixed in prior NMUs that haven't been acknowledged by the maintainer. Who knows if any (or how many) of those are still open in etch right now? Rather hard to tell when we don't know what version closed them, isn't it? So with a lot of help from Adam Barratt this weekend, we've marked about 800 (egads) of these RC bugs as closed in the corresponding NMU versions, with a brief note to the submitters. In the next couple of days, we should find our way to the end of the list, at which point we can think about ignoring the 'fixed' tag over on turmzimmer.net. Also fixed now is bug #388431, so people should be able to stop worrying now about their users chewing up the CPU with real-time scheduling. Nothing like a maintainer upload of a base package one year in the making, being uploaded after it's been frozen. So make that... 801 bugs closed?

A while ago I read Steve Yegge’s rant about Agile development, though I’ve forgotten who linked to it. The thing that struck me as interesting was the bit about “work queues”:

With a priority queue, you have a dumping-ground for any and all ideas (and bugs) that people suggest as the project unfolds. No engineer is ever idle, unless the queue is empty, which by definition means the project has launched. Tasks can be suspended and resumed simply by putting them back in the queue with appropriate notes or documentation. You always know how much work is left, and if you like, you can make time estimates based on the remaining tasks. You can examine closed work items to infer anything from bug regression rates to (if you like) individual productivity. You can see which tasks are often passed over, which can help you discover root causes of pain in the organization. A work queue is completely transparent, so there is minimal risk of accidental duplication of work.

Sadly, googling for “work queue” doesn’t come up with any sort of todo list stuff, but rather a multiprocessing scheduling tool which is cool, but not immediately relevant for me. As far as I can see, whatever was actually being talked about either isn’t public, or is more of a concept than an actual tool. The only Google Todo thing I could find was an applet thing for the personalised google homepage, which just lets you make todo items and set them as high/medium/low priority. And while that might be all that Steve Yegge was talking about, it doesn’t really feel terribly inspiring to me. I guess what I’d really like is to have todo items get assigned to a project (so that I can ignore all the todos for projects I don’t want to worry about atm), and also to be able to give them a deadline (so I can treat them with a bit more urgency when necessary) and a priority (so that I can easily spot things I’m willing to defer or ignore completely when I find I don’t have time to do everything I’d like). I suspect I’ll probably just stick with writing notes in vi to keep track of things, though, same as I have been for years.