Relgions commonly require contributions to charitable causes and helping other people. Developing free software without expecting a reward seems to fit that criteria.

If my primary religious belief (atheism) turns out to be incorrect then I am certain that whatever deity might exist would want me to do Free Software development.

It seems to me that denying people the ability to contribute to Free Software development or forcing them to use proprietary software is therefore an infringement of their rights to freely practice their religion.

Prisoners should be permitted to do Free Software development. Kevin Mitnik was prevented from using computers while incarcerated and after being released (which is wrong in so many ways). It has been recently announced that pagan prisoners in the UK are being given time off prison duties for haloween. I think that allowing free software development for people who believe that it is a religious requirement deserves at least the same protection.

Also government agencies should not require the use of MS file formats or IE for communication.

PS Day 24 of the beard is depicted above.

My daughter (13 month old) has started forming her first words. Of course there is the usual "Da!" which is also a german word ("There!") but she does not use it consistently and in a meaningfull way. The first word she DOES use consistently and in the context of food, and in only that context, is "More!" (or "Mehr!" in german). Usually she points on the table in front of her where she expects the food to show up, now!

I have no idea from where/whom she got that attitude.

I rebuilt all the packages in etch inside an i386 etch chroot on bi-Opteron systems with 2 Go of RAM. Here is some data about the build times for each package. They include the time needed to fetch the dependencies from a Debian mirror over NFS, so might have been overloaded during some builds, so it the build times might not be totally accurate, especially for the very short builds.
Two packages are excluded from the following stats because their didn’t complete their build: libmail-mboxparser-perl and camas. 17 packages took more than 1 hour to build. They are:

Package	Build time (seconds)
openoffice.org	21537
linux-2.6.16	17859
linux-2.6	14833
gcc-4.0	9142
gcj-4.1	9062
gcc-4.1	7111
gnat-4.1	6910
installation-guide	6337
gcc-3.4	6022
octaviz	5735
gcj-4.0	5300
k3d	5294
openscenegraph	4851
ghc6	4670
glibc	4504
vtk	3954
atlas3	3759

The full list is available. Most packages build very quickly:

Build time (s)	Number of packages	Total
30	5389	5389
30 - 59	2354	7743
60 - 119	1304	9047
120 - 499	873	9920
600 - 1799	92	10012
> 1800	40	10052

The total build time is 220.4 hours (that’s 9.2 days), the mean build time is 78.9s, the median build time is 27s.

Wouter Verhelst replies again:

"With all due respect, but I can't shake myself free of the feeling that you're being intentionally obnoxious here." "When I said "[...] these people never had to run a business", that wasn't intended to say that people who run a business "have" to do so, for lack of anything else. I mean, sure, there's choice, but that doesn't mean you can make this choice every day. Does the word "expression" mean anything to you?" "Additionally, the numbers I gave were meant to give people a general idea; while they're roughly accurate for my case, they certainly aren't completely correct in the general case, and were never meant to be." "Please stop putting whatever I say under the microscope like that, thank you very much."

I didn't need a microscope to spot the cracks in those numbers - our right-wing news media repeatedly points out that it's cheaper to do business in the US and casual web browsing finds figures. As I asked elsewhere, the general idea that net pay is less than the bill to the customer is widely known, so why use a detailed breakdown with higher figures to advocate US$6k? If the point is just "the 6k isn't net pay" then just write that. Personally, I think that point is mostly irrelevant, but the misleading breakdown looked like the sort of thing that dunc-tank should be publishing and isn't. As for "these people have never had to run a business" - yes, it's an expression, but it suggests a compulsion which doesn't exist - why use it? If the point is just "these people have never run a business" then just write that. It's shorter and more honest, although probably wrong: you don't need to have run a business to know that the bill to customer isn't the worker's net pay. I can think of many, many possible reasons for misdescribing something that some people choose to do as something they had to do, but I can't think of one I like. At worst, it's insulting to people who don't do their own business administration. "With all due respect" maybe I am being "intentionally obnoxious" about the breakdown and misleading phrasings: I want to discourage people who post comments without any obvious attempt to get their facts straight, or who exaggerate. Both of those take us away from discussing more basic points like: dunc-tank's execution has damaged debian; and dunc-tank is buying from neither an open market nor an openly regulated one.

I’ve long wondered what the point of the “Work Offline” option in Firefox is (it’s in the “File” menu). All it really seems to do is take you to a helpful (cough) error screen when you’re working offline that tells you you can’t view the page you’re trying to view till you’re online again. If the page is in the cache, it’ll display it, but that seems to happen only rarely. I jacked my cache up to 4GB, but much to my surprise, that doesn’t appear to result in a noticeably higher cache hit rate. IE has a similar option, but it actually does something. In fact, it’s quite slick. When you add a page as a favorite, you’re given a “Make available offline” option. Once that option is selected, you can click “Customize…”, which launches a wizard that allows you to mark other pages the favorite links to as available offline as well (useful for sites like Slashdot that primarily link to other sites). You can also specify when the page(s) should be synchronized (manually or on a predefined schedule, such as every day at 5am). The Blackberry browser has a similar option too, though I haven’t used it much (most of my offline time tends to be on airplanes, and I’d much rather view the web on my laptop). The Blackberry does have a neat feature IE doesn’t have though, which is if you try to load a page that isn’t available offline, it’ll offer to queue up the request and download it once you’re online again. As with everything on the Blackberry, the page will show up in the universal inbox along with email, SMS, missed calls, etc. No more trying to remember what pages you wanted to load when you were offline or resorting to tricks only a hacker could love. Imagining a feature like this integrated with a Gmail/Google Reader combo that supports offline operation makes my mouth water. As I said in the opening paragraph, I’ve been thinking about this for a long time, but I’ve never actually gotten around to writing about it. What inspired me to do that today? Scrybe, an amazing online productivity suite that has a variety of unique and killer features, including excellent use of AJAX to preserve context as you move around within the application, a novel approach to scheduling across timezones, full integration between the calendar and to-do lists (why don’t more calendar applications do this?), and more. Watch the video for yourself. The most interesting feature from my point of view, though, is the offline support: Simply select “Work Offline”, and everything works, well, offline, no browser extension required. It even appears that changes will be synchronized when you’re online again (i.e., it’s not just a read only copy). The beta isn’t publicly available yet, but I can’t wait to see how they did this. My prediction: If this works as well as it looks, all web applications will eventually work this way. And it’s good to see that some companies are thinking about the offline problem, rather than just assuming ubiquitous Internet connectivity makes the problem go away in the very near future.

I've written a little lately on the Dunc-Tank (a project to pay some key debian post-holders) and it's drawn some comments about running a business. I've owned businesses for years and there's a lot I don't know, but I've been frankly shocked by some of the comments. Here's two more. I wrote:

Double-taxation seems like something a good accountant should help to avoid - not heard of it being a significant problem often;

Today, I read a comment from Joe Buck:

"Self-employed people or contractors have to pay double Social Security taxes in the US. That's because, for salaried workers, the worker pays half and the employer pays half." "This is one factor contributing to why anyone considering leaving regular work and setting up shop as a contractor in the US needs to bill 2x their regularly hourly salary to wind up with the same standard of living. In addition to higher taxes, there's time between contracts, no paid time off, etc."

That's not double taxes. That's one tax split between two parties. Half plus half is one, not double. If the two parties (employer and employee) are the same (as in self-employment), you're still only paying the one tax. If the business is run half-decent, that tax will be figured into the cost of the worker, even if it's not in their posted gross salary. If the employer part is not widely known, that sounds like government slyness to me. Double-taxation is paying the same tax twice, not paying one tax split between employer and employee. By the way, I'm slightly surprised US contractors need to bill 2*gross. When taking on new contract staff at a UK university, I think the cost was estimated at 1.6*gross, and I think I've already mentioned that the cost for a UK SME seems to be about 1.5*gross. We're told that the US taxes less, so maybe work is much rarer there, or something. Which brings me to when I wrote:

I think running a business is a choice, not something anyone ever "had to" do.

to which Scott Robinson replied:

"That is certainly an odd perspective wrt. the choice of becoming an entrepreneur. Have you only lived in places where employment is guaranteed?"

As far as I know, I've never lived in a place with no jobs at all. Sometimes the jobs are crap and sometimes the terms for joining an existing business are crap (so in my opinion, they might as well not exist), but if you didn't want to run a business, you could avoid it. These are all things you weigh up when making your choice whether or not to run a business. Is there anywhere which forces workers to run businesses?

It looks like the condo purchase has actually gone through, subject to the usual final signing in front of the notary and handing over of a silly sum of money!

It also means that now we have to get rid of our place for December to avoid paying rent and mortgage at the same time. So hey, Montr alers, want to move to the plateau? We've got a lovely 5 1/2, front and back balcony, 3rd floor (2i me tage), washer and dryer hookups, clothes line, decent neighbours, 1 1/2 blocks from m tro Mont-Royal, and 1 1/2 blocks from m tro Laurier. The place has a decent cable hookup (my Vid otron connection just got the binutils source package in 14 seconds, 906k/sec), iron clawfoot bathtub with a skylight and a decent amount of storage.

Any takers? =)

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…

Dear old Mutt, ... My MUA of choice is Mutt. I've been using it for something like 8 years now and I like it: it's quick, powerful and well integrated with the Unix way of handling mail (e.g. procmail). But we all know that. My feeling today is that sooner or later I will be forced to abandon it. The main reason is that it seems to be a dead product, upstream development is not dead but I fail to see an overall plan for my beloved MUA. Other text based application have understood that they should be integrated in some way with the desktop and/or windowing environment in which they are run: Vim for example is able to deal with the mouse wheel event when run in an xterm or even has developed a GUI which is well integrated with the Gnome session mechanism. Why Mutt is not? Such feelings of today has been originated by Tomboy, a wonderful note taking tool with Wiki-like capabilities, integrated with Gnome. It has a plugin for drag and dropping Evolution mails on notes automatically providing links from the notes to your mailbox: that's ... wow, great! I'm already using Evolution as my organizer and I already have Gaim integrated with it for contacts. I fear the moment I will try it for mails because I'm pretty sure it also has an UI which can be easily used with keyboard without the need of the mouse. Since I'm using all this on my laptop which is always with me (and this means that the argument "Mutt can be used remotely using a 9600 GSM connection" is bogus), it seems I'm running out of arguments for sticking to Mutt. Oh, right, there is the procmail stuff, my last feeble chance of keep on using Mutt ...

715   + Oct 27 Debian Installe (0,5K) nbd_2.8.7-2_powerpc.changes REJECTED
[...]
717     Oct 28 Debian testing  (0,3K) nbd 1:2.8.7-1 MIGRATED to testing

Apparently I had done something wrong with the uploa of 2.8.7-2, so it didn't get in. And 2.8.7-1 migrated instead, which it shouldn't have. Oh well, fixed upload is on its way now; and it's not that important, either.

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.

It is currently rumored that, despite great efforts from the release managers and the dunc-tank board, the etch release will not make it on time. Some say this is because of Developers being upset by some random and obscure experiment. Some others think this is because there are too many RC bugs and that we won't be able to fix them on time. Some might say this is because of a surrealist conflict with the Mozilla corporation. Guys. You're all wrong. The main reason for the delay will be the same as that of the woody release. Developers will be too busy testing the brand new Frozen-bubble 2.0.0 release extensively. Instead of hacking, they will spend their nights fighting with each other in up to five players LAN and internet games, enjoying the shining new graphics. Debian unstable packages are available in incoming and tonight on your favorite mirror.

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.

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.

Today I reached another milestone in the development of upstart, the packages in universe can now replace the existing sysvinit package. Before trying this, make sure your installation is up to date as we’ve had to split out some parts of sysvinit into a new sysvutils package. If you’re up to date, and want to try it out, install the upstart and upstart-compat-sysv packages from universe. Note that the first reboot after you’ve installed the packages (from sysvinit to upstart) will be a little tricky … use reboot -f. If your system boots and shuts down normally, everything’s working just fine. Note that both will be somewhat more quiet than you’re used to, unless you have usplash running. Throughout the rest of this entry, I’ll try to answer some of the questions and comments that I’ve received since the last post. Events As I talked about previously, upstart is an event-based init daemon. Events are the primary force for having your services and tasks started and stopped at the appropriate time and in the appropriate order. So what are events and where do they come from? (Note that this part is under development, so may change in later releases). Events are just simple strings that may be sent by any process when something it is tracking the state of changes. They have no state or longevity, and if, when queued, they do not cause any job state changes, then they have no effect unless they are sent again. Jobs can list which events cause them to be started if they are not already running and which events cause them to be stopped if they are running. Multiple start and stop events may be listed, in which case the first to occur changes the job until the next one occurs. upstart itself generates the following system events:

• “startup”, on system boot.
• “shutdown”, when the system is about to be shut down.
• “stalled”, when there are no jobs running and no events in the queue.

The shutdown tool included in the package also causes one of the following events to be sent once the “shutdown” event has been handled:

• “reboot”,
• “halt”,
• “poweroff”,
• “maintenance” (aka. going into “single user” mode),
• any user-defined event with shutdown -e event.

Jobs also generate events whenever they change state, this is the primary source of events for ordering:

• “jobname/start”, when the job is first started.
• “jobname/started”, once the job is running.
• “jobname/stop”, when the job is first stopped.
• “jobname/stopped”, once the job has stopped.
• “jobname”, for services this is generated once it is running; for tasks this is generated once it has finished.

And as mentioned, any other process on the system may send events through the control socket or just by using initctl trigger EVENT. For now this is just the event string, however it’s intended that the event may include other details including environment variables and even file descriptors. Typical example To clarify how it all hangs together, here’s an example (using fictional names) of how the tasks and events can be arranged to provide race-free mounting of filesystems.

• “udev” service started on the “startup” event.
• udev daemon is configured to send a “new-block-device” event whenever a new block device is added to the system.
• “checkfs” task is started on the “new-block-device” event to check the filesystem.
• “mountfs” task is started when the “checkfs” task has finished and mounts the filesystem if listed in /etc/fstab
• “filesystem-mounted” event is generated whenever a filesystem is mounted.
• “fstab” task is started on the “filesystem-mounted” event, it checks the list of mounted filesystems against /etc/fstab and if all are mounted, generates the “writable-filesystem” event.
• other services and tasks would be started on the “writable-filesystem” event.

By breaking this job into these small tasks, we can see how the pieces fit together. Because everything is now done on events, there are no race conditions; we know that any filesystem listed in /etc/fstab will be checked and mounted. The only reason they wouldn’t be is if there’s an error of some kind, and that means you have larger problems anyway and the system administrator would have a shell to fix it. Of course, the moment they finish checking the filesystem and mount it, the boot process would carry on. There’s no reason that any of these events need to be generated by the upstart daemon itself, it can receive them from any other daemon on the system such as udev, acpid, etc. This keeps the focus of the init daemon narrow. A large part of the future development will be working out exactly what kinds of events we want init itself to generate, what kinds we want to come from elsewhere, and what the contents of an event can be. Getting Involved If you want to get involved with trying to nudge the direction of upstart development, you can join the upstart-devel mailing list at http://lists.netsplit.com/ Or if you just want to grab the source code, tarballs are published at http://people.ubuntu.com/\_{scott/software/upstart/ and the bzr archive is at http://bazaar.launchpad.net/\}keybuk/upstart/main

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.

Now that edgy has been frozen for the beta release in a week’s time, and the next developer summit, where the plans for the next release will be discussed, has been announced, I think it’s the perfect time to start thinking about the kinds of features we want to see in that release. At our recent sprint in Wiesbaden, Mark reminded us that when Ubuntu first released we were leading the field in many of the components we installed by default. Many users came to us because we provided Linux 2.6, hotplug/udev and Project Utopia by default; along with the latest GNOME release and development framework. Now everybody does that, butwe led the way. With the dapper release, we produced something that could be supported for a long time. With edgy we’ve scratched our itches and fixed things under the hood that have been causing us problems. edgy+1 seems a good time to integrate the hottest new technologies and lead the way again. So what do I think is exciting, and what do I want in edgy+1? telepathy, farsight and galago Anybody who has used the 2006 software release for the Nokia 770 Internet Tablet will have seen these in action already. They’re, in my opinion, some of the most exciting projects currently being worked on; and ripe for integration into Ubuntu. Telepathy is a communication framework built on DBus that allows any application to establish communication with users all around the world, using any protocol from IRC to MSN to VoIP. It uses Farsight to provide the codecs and protocol support on top of the (GStreamer)[http://gstreamer.freedesktop.org/] media framework. And Galago glues it all together; providing presence information about contacts and allowing users to specify their own status. This means that you’ll be able to contact your contacts. Your calendar alarm tells you that it’s a colleague’s birthday, you’d be able to click their name and see a selection of different ways that you can contact that person right now. From e-mail, opening an MSN or Jabber window or even establishing a VoIP or SIP call to them. The most exciting thing is that because every application on the desktop has easy access to this, people are coming up with fantastic ideas for using it! zeroconf By this, I mean zero configuration networking. Something the OLPC project appears to be going to do very well indeed. Where no existing network infrastructure exists, your computer should still be able to communicate with other nearby computers. It should use ad-hoc wireless networks, link-local IP addresses and server-free DNS resolution with libnss-mdns. Play games with your friends on the train without touching a button. Chat with other people in a lecture hall or at a conference where the existing network is unavailable. Hassle-free home and office networking without any complicated set up. Networking that “just works”. avahi Whether your computer is on an infrastructure or ad-hoc network, it should be able to locate resources on the network and share its own to other people. Avahi allows applications to, via DBus, do this by using a mulicast form of DNS; compatible with Apple’s Bonjour protocol. The immediately obvious benefits of this are that one can locate such things as file servers without any complicated directory; more fun things can be done too, such as sharing your music from RhythmBox with other users on the network. Combine it with telepathy, etc. and you can establish communication with anyone else, with a wide range of different protocols. The immediate problem here is that we currently have a “no open ports” policy, which if we’re going to give the users the opportunity to establish ad-hoc networks is almost certainly a very good thing. We already have exceptions for that policy for DNS and DHCP, it may be that Avahi (mDNS) joins that list. Another option is a “mobile-phone like” interface for enabling and disabling discovery and sharing. Bluetooth I don’t think we should stop discovery and sharing at 802.* networking either. Linux actually has a pretty decent bluetooth stack, it’s something that we should start taking advantage of. Your computer should be able to discover paired or known bluetooth devices when in range without intervention and communicate with them. If I attempt to establish a network connection, and my phone is nearby, that should be offered as a method for getting on the Internet. If possible, it should also be offered through telepathy as a method for contacting people in my address book! Synchronisation These technologies together give us a really big possibility, automatic synchronisation of user’s information. When I bring my laptop home, it should automatically update my desktop with any changes I’ve made to my address book or calendar, and any shared files, etc. Likewise it should be automatically be updated with any changes made on the network, to a company address book on a server, for example. And why stop there? Don’t use share your music, synchronise it so that your laptop, desktop and iPod have the same selection available at all times. Hassle-free backups is an obvious win here. But we’re stopping again. Why is my mobile phone, and PDA excluded from this? Via bluetooth, my address book and calendar should be automatically updated from these and these should be automatically updated themselves. If I add a new number to my phone’s memory, it should appear in my computer address book; and my computer should offer me the ability to contact that person (using VoIP, for example).

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 just wrapped up version 0.0.8 of r (pronounced littler), put it here and sent it to Debian's incoming queue. This version has a few small changes and fixes over 0.0.7. Most notably is that all of R's environment variables are now set for r as well (at compile time). This permits it to call JGR, for example. Other than that, we made the build process more robust, extended or clarified some of the documentation and added two more example scripts.