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.

I spent the past couple of days at LinuxWorld UK, mostly on the Debian stand. I'm not sure I'd go as a punter these days; I don't think a lot changes year on year. However I do think it's good for us to turn up and show our faces so people can come and talk to us and realise we're wonderful people. Plus it's always good to see people I haven't seen in ages. We sold a lot of T-Shirts (even the red one with yellow writing that looks like something Phil would come up with after too much vodka [I bought one of these myself]). We didn't sell a lot of DVDs, but that's been happening since broadband became more pervasive. There were a reasonable number of people who just stopped to chat (shouting "Use Debian, it's great!" at people as they walked by was surprisingly effective). Lots of questions about how we felt about Ubuntu. Not really many about why we hadn't released yet which is a change! I also found a new toy I think I want; the Nokia E70. Steve has one of these and it looks pretty sweet; 3G+WLAN, a keyboard and a screen that, while not that big, manages a pretty good PuTTY session in 80x43 or so. And all of this in something not that much larger than a normal phone. That's appealing. I'd been sort of lusting after an HTC TyTN, but reports of poor reliability have put me off. And Simon has put me off the 9300i by saying it's quite slow as a phone. Finally, courtesy of Trexy, I present a new, work safe, goat sex: And now I will spend the next week sleeping I think.

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.

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.

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

I've chosen Turbogears for a recent web project. Up to now, I was pretty happy with this choice, as it allowed me to made changes to the application rather easily, I happen to like KID templating, and it all was rather painless. However, I'm stuck at two place right now. One is a rather expensive database query I have not yet added - I know that it's going to be expensive, and I'd need some way of caching the results easily. I havn't found a "turbogearish" way of caching these interim results yet. Since that brought me onto the performance thing - when writing an app you don't really know yet how it will be implemented, you best postpone performance considerations a bit, so you don't optimize too early - I did some measurements. And was pretty disappointed by the results. The testing virtual machine (sorry, I don't have hardware specs for the actual machine) is rather slow. But still, static apache can serve some 450 requests per second. Turbogears will serve static files at ~22 r/s and the main page of the webapp at just 4.5 r/s (measured with siege, when it's not crashing). I tried switching from sqlite to mysql in Turbogears, but unfortunately that just makes the application crash altogether at some point (no SQL queries succeed anymore: 'Page handler: "Commands out of sync; you can't run this command now"') Notice that this was by no means a fair benchmark of Turbogears (I'm not a turbogears expert, and the little documentation I've found so far didn't help me at all in optimizing it's performance). I was just evaluating where I'm at, and now I'm about to decide where to go next. So can anyone point me to some docs on how to get turbogears up to an acceptable speed (where acceptable would probably be >20 r/s on this hardware)? Otherwise I guess I'll start a rewrite now, maybe using Java JSF and Facelets. They seem to be a good choice if you want XML-based templating. Don't even suggest PHP to me, it's crap. And I won't be trying Ruby on Rails next, either. I don't need rapid prototyping anymore, but can go for the high-performance implementation now, even if it will be harder to read, write and modify. I have now a better grasp for what I need and how the architecture of the app should be like.

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

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

Bring'em on.

For my new laptop, I decided to use harddrive encryption. The new Debian installer (to be released with etch) can handle this setup, and it works pretty well. The passphrase prompt isn't pretty, but who cares. But where I'm currently stuck is getting it to work with uswsusp. I used to be a Suspend 2 user, but I'm tired of compiling my own kernels; it takes a lot of diskspace and my new laptop has a much smaller harddisk (I bought a used laptop, so I didn't have a choice; the old laptop is PATA, the new is SATA, so I can't just move the HD over either). So I wanted to try new "userspace software suspend". s2ram works just fine on the laptop (with --force, but from some Google results I figured it's already reported to work, so it will probably be in the next versions whitelist), where it's becoming difficult is the suspend to disk with an encrypted swap device. From what I can tell, s2disk expects the resume device to be a swap device; so I'd need to pass it /dev/mapper/cswap. However this is encrypted using a random key, so it can't be decrypted after resume. Also it appears to be configured after the resume script at boot, which says it can't stat my resume device. Dear Lazyweb, anyone who could write some Howto for uswsusp and HD encryption? Do I need to encrypt swap with a static key (which would reside on an encrypted partition, after all)? And what about the boot sequence? [Update: one of the cryptomount maintainers told me he's working on fixing #394136 and #382280 this weekend, and that this will help me as well. (Basically it will allow the cryptomount initramfs things to setup more than one encrypted device, from what I figured).]

Well, this really is a controversal topic to say the least. While having the RMs get paid to get Etch out might be a good thing, the big problem I see with dunctank is that it is initiated by people very prominent inside Debian and moreover by people perceived as friends of th RMs in question. Though dunctank says that is distinct from Debian, due to the high profile the people involved have inside the Debian community, this distinction might not be recognized by less careful observers. The second problem is that the payment the RMs get is not connected to well specified tasks, but they are for “working on the release of Debian “Etch”. And finally, there is the problem that this is said to be an experiment. However, a good experiment has well defined objectives and well defined boundary conditions. In other words: Regarding Dunc-Tank, it is unclear to me what the experiment is trying to achieve. I admit I voted as much in favor of the experiment as the GR allowed, but in the meantime, I regret doing so. My vote was because my impression was that Dunc-Tank would pay just enough to pay rent, food and the other usual expenses (insurances, debts etc.). But now each of the two RMs is supposed to receive 6k$. This surely is less than they could earn working as IT freelancers, but it sure exceeds their pure living expenses. While just covering their living expenses would be OK for me (in the sense that I could live with it, not in the sense of being happy about it), paying substantially more isn’t, but that’s just me. A DPL collecting money to pay certain DDs is always going to ask for trouble. Or as Ben collins put it back in 2001:
… use Debian money to pay developers. It can never be done fairly, or in a way so as not to piss someone off. It will always be susceptible to political gains and/or favoritism. This subject caused a lot of hatred, and in my opinion, the experiment is a failure. Though it might help to get Etch out in time, it caused many DDs to cut down on the time they spend on Debian, among them people like the DWN editor, who used to invest a lot of time. And this effect will not go away when Etch is released and is thus hurting Debian in the long run. The whole thing might have been a lot different if some random, mostly unknown DD (or even better: non-DD) had started dunc-tank, collecting money and finally paying some DDs to work on some specific tasks. But the fact that the DPL started it makes it so controversial. But on the other hand, it would have been less likely that dunc-tank collected enough money to do so in that case. Honestly, if I were to decide, I would drop dunc-tank completely once Etch has been released (it’s too late to do it now, it would just deprive Debian of the benefits and still cause all the negative side effects). The people who thought (and think) dunc-tank was a good idea could then restart it later under some different name and without involvement of the DPL. There is only one position in Debian I could see reasons why the person occupying it should receive some sort of compensation: The DPL. The reason I see here is that this position requires a lot of time if taken seriously. This also means that many people can’t reasonably apply for it since they would need to resign from their “real world” job.

Uses of Debian in Venezuela I'm just back from the IV Foro Mundial de Conocimiento Libre that happened in Matur n, Venezuela from the 17th to the 21st of October. Besides it being a great event and a great opportunity to meet great people (here are photos taken by Ana), it gave me the chance of seeing a bunch more uses of Debian that I didn't know about. Jos Parrella kindly provided me with a list that should open a short series of blog posts:

• SAPI - Servicio Autonomo de la Propiedad Intelectual (the Patents Office which will hold all of the Cuban and Venezuelan patents) uses Debian in all of their servers, including the HP StorageWorks 9.5 TB. They are listed in Who's using Debian.
• MCT - Ministerio de Ciencia y Tecnolog a (the Ministry of Science and Technology), is on charge of the migration process to Free Software. All the decision-makers uses at least dual boot, but most of them use exclusively Debian. At the conference I had a pleasant conversation with one of their representatives, discussing various aspects to keep in mind when choosing a piece of Free Software to use.
• PNAT, the National Plan for IT Literacy, uses Debian (or Ubuntu) in all laboratories around the country.
• CONATEL (the local FCC) uses Debian in servers and Internet Access Points.
• PDVSA (the national oil company) uses Debian in some areas, most notably they've setup videoconferences using OpenH.323 or MBONE using Debian in the PDVSA side.
• FONDAFA (the government fund for agricoltural development), uses Debian in their servers.
• SECODENA, the local Pentagon, uses Debian in their servers.
• DGIM, the local CIA, also uses Debian. Which is kind of creepy. The website runs on ASP, but they have a complete PDC/BDC and Mail Servers using Debian Sarge.
• EDELCA, an energy company in the southern states of the country, is implementing Debian right now. They have several hundreds of desktops already running Debian, and they're migrating network services (LDAP, Mail servers, etc.). There are two huge hydroelectric dams they operate.

More to come as I get back to other people I've met there.

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.

There's a bit of commotion around the amount of 6000 US dollars that's being paid to the RMs for a month of work; some people seem to think that this is a lot of money for one month of work. My guess is that these people have never had to run a business. Steve does run one; I don't know about aba. But let's just make some calculations here, shall we? I'd make them with the US system in mind, but as I have a business in Belgium, that's kinda hard to do. So I'll make them with the Belgian system in mind instead.

• First, you have to pay VAT. On computer services, the amount of VAT in Belgium to be paid is 21%. That's roughly one-fifth, or 1200 US dollars. Had dunc-tank been a registered company (like, say, SPI) then they could get that money back. As it is, this is 1200 US dollars that goes to the government and stays there. So that's 4800 left.
• Steve has a company; I presume he rents an office somewhere. Rental prices for floorspace in office buildings is insanely expensive when compared to private apartments. 500US$ per person per month would seem to be approximately right. So, 4300 left.
• You'll be having to pay for utilities, such as phone, water, heating, electricity, Internet, and so on. In my experience, this is a few hundred each month. Say, 400? 3900 left.
• If you don't want to pay too much taxes and fines at the end of the year because you didn't fill out the right paperwork at the right time and in the right way, you'll want to pay an accountant. These people are not cheap; 300 each month (on average) would seem to be right. 3600.
• in Belgium, if you work as an "independent", you have to pay an amount of money to social security, which gives me basic health benefits. In addition to that, you pretty much have to pay an amount of money to a private institution for additional health benefits if you don't want to be left in the cold in case something happens that the basic health care doesn't cover. The amount you need to pay each quarter depends on your income; a guess could be somewhere around 500US$ each month. 3100.
• There's going to be insurance. This will involve both hardware insurance, and something to fall back on in case you make a terrible mistake and need to pay someone some compensation. The former depends on the amount of hardware your company has; the latter depends on the amount of invoices you get to write each year, i.e., the amount of money you make. I can't guess how much this is for Steve, but let's say 700? So we've got 2400 left.

And now if you want to pay yourself, you get to do the above dance all over again. You get to pay income taxes, insurance, rent or mortgage, Internet, phone, water, and whatnot. Plus food. In addition to all of the above, I don't know how much Steve has to drive around to talk to his customers, but if that's "quite a bit", then he may be leasing a car. I don't know whether he's got an ad running somewhere to attract more customers for the months after his paid Debian work, but if he is, he may have to pay a considerable amount of money to do so. And there can be any number of things that I've forgotten to include, but for which you still need to pay. In addition, if you want to run a business in a sane way, you need to ask a bit more than what your costs are, because there'll always be a few days that are not billable, and on which you need to live and pay expenses, too; but I could imagine that these were dropped for this particular month. Obviously the above numbers all involve some guesswork. I've been running a business for quite a while now, but it's only recently become profitable; many of these numbers will go up when your business is profitable for a long time. 6000 is nothing. I've had customers tell me you're cheap five seconds after I asked nearly twice as much. Trust me, that's no fun. It's one of the things I've had to learn while running a business: some amounts of money that seem hugely expensive in a private capacity are next to nothing in the business world. That's just the way it works... Finally, let me note that this is not meant to take any position one way or another in the matter. I did feel that experimenting with paying fellow developers was a good idea, but not at all costs; and certainly, I don't feel that going ahead with this by setting up something of the likes of dunc-tank is a very bright idea. I just thought it good to put some numbers into perspective. Update: Set the numbers straight. 6000 - 1200 is 4800, not 5800. Whoops. Yes, usually I do use a calculator :)

Packages of the Leafnode 2 alpha releases are now avaliable for use with unstable (and probably testing most of the time) in the experimental archive. To install them add lines for experimental to your apt sources:

deb http://ftp.debian.org/debian/ experimental main
deb-src http://ftp.debian.org/debian/ experimental main

(or use a mirror) and edit /etc/apt/preferences to tell apt to install Leafnode from experimental:

Package: leafnode
Pin: release a=experimental
Pin-Priority: 500

and install or upgrade Leafnode as normal. It should be possible to upgrade directly from Leafnode 1 (please file a bug if this is not the case) but please note that due to incompatible changes in the news spool format once Leafnode 2 has been installed you will have to purge Leafnode before downgrading to Leafnode 1.

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.

So since mricon already spilled the beans, I'm moving to New York City at the end of November. Having never really been to NYC (I drove through it once), this is more than a little crazy. But it's a great opportunity and I've never lived anywhere but Montr al, so it should be a bit of an adventure. Pretty scary too.

I'm hoping my new job won't completely kill my free time and my ability to work on Debian, but I'm guessing it will for a couple of months. Apologies to everyone for not having gotten Iceweasel packages together yet, but between wisdom teeth being pulled and "real life" and my co-maintainer taking a sabbatical, it's been tough to make progress.

I'm also looking for replacements for me here in Montr al, both at work and at home. If you're in the city and have some good Linux SysAdmin experience or want to share a nice apartment with a couple of LJers drop me a line.

Since I just started my blog and added it to planet.d.o, I thought I should introduce myself a little. I’m in my mid 30s (ouch), working as a sys/net admin (Linux based, mostly Debian these days) in a nice little company. I first encountered Linux back in the 1990s, before the 1.0 kernel got released. Back then, I used Slackware (which, surprisingly, seems to still be around), later switching to Mandrake. About 5 years ago, I got introduced to Debian and immediately liked it for the ease and clearness of administrating it (apt+dpkg+dselect was so much better than rpm used to be at that time). For about two years now, I’m contributing to Debian, including some involvement in the earliest pre-implementation phases of the volatile repository (mainly advocating a few ideas that actually led to it’s implementation, BTW thanks to those who did the work in the end), some small packages I maintain and involvement in some small teams. Mainly the cyrus-imapd packaging team, but also (to a much smaller degree) in the cyrus-sasl, initscripts-ng and (extremely little, since noone bothered to add me to the alioth group for it yet) the php packaging teams.
Letting computers aside, my interests are quite diverse, they range from wheelchair-basketball to books (SciFi and Fantasy mainly) and RC helicopters, among others.
More interesting posts will probably follow later.

I&aposve been dawdling and delaying writing about our trip to wt:Halifax (Nova Scotia) two weeks ago for some reason, but I&aposm bound and determined to get some info down on, uh, electrons about it right now.

Hella facts about Halifax We flew out of Trudeau airport eeeeearly on a Friday morning; I&aposd shopped a bit on the Air Canada site and got $99 each-way tickets from Montreal on their wp:Air Canada Tango program, but they required that we be on the 7:50AM flight. Air Canada used to be one of my favorite airlines, but they have been getting continuously disproportionately high prices and conversely worse amenities (pillows and blankets now cost extra, thank you very much). Discount flights in Canada are pretty sparse these days, with the collapse of Jetsgo in 2005 and the recent repositioning of CanJet for charters only. So, you just have to take what you can get. The flight to Halifax was quick and painless; Amita June slept most of the way there. The airport there is pretty small (yay small airports), so we buzzed through baggage claim. Cabs into town were a pricey flat-fee of $52, which got our hackles up, so instead we waited half an hour and took the Airporter shuttle ($16/person) into Halifax proper. We got to see a lot of the Nova Scotia countryside from the shuttle -- lots of leaves turning and conifer forests. We had reservations at the pretty and historic Lord Nelson Hotel, well away from the waterfront, but still in the downtown area, near Dalhousie University. The Lord Nelson is in the "Splurge" section of Halifax hotels on Wikitravel, but since this trip was for my birthday and our 2nd wedding anniversary I thought it&aposd be nice to stay there for one of the 4 nights we were in town. But when I called to make a reservation, I was able to get a very competitive rate, mostly due to a healthy 40% CAA discount, and I booked us for all 4 nights. I&aposd asked for early check-in, but our room wasn&apost ready at noon, so we tried the Lord Nelson Pub for lunch and a beer. The food was tasty and the atmosphere was, uh, pubby. We pawed through the stack of tourist-info documentation that we&aposd picked up at the info desk at the airport, then went up to our big and well-lit room for a mid-afternoon nap. Yes, all three of us. When we woke up, Maj and Amita June went for a walk across the street to the pretty wp:Halifax Public Gardens. It&aposs a very nice Victorian-era public park with disturbingly large geese roaming about. When they got back, the three of us headed down to the waterfront for an early dinner. Halifax&aposs streets are very steep -- they virtually plummet into the water. But we walked straight down to Water Street then meandered along looking at the sights. Our intention was to eat at the Privateer&aposs Warehouse, a building with a bar and two restaurants stacked on top of each other. It&aposs part of the Historic Properties on Upper Water Street, a collection of restored buildings with shopping and food. But the Warehouse turned out to be too rambunctious for us on a Friday night, so we instead went around the corner to Salty&aposs for a slightly more sedate meal on the water. We had good food; Maj had some very nice crab cakes and I took on a large seafood salad. Amita June chomped on really tasty fish and chips. The walk back up the hill was a bit tough, so we stopped in the Rogue&aposs Roost brewpub on the way home for a little strengthener. Unfortunately, as it was after 8:30PM, the baby wasn&apost allowed into the pub. So, we had to leave her tied to a parking meter while we had a... just kidding. We retired to bed after a long day, all three. tags: halifax travel amitajune nova scotia

California Dreamin&apos All the leaves are brown, red, orange, chartreuse and saffron here in Montreal, yet we&aposre off to wt:San Francisco tomorrow morning (early) to visit friends and family. I love going to see my parents and brothers and sister-in-law and nieces, but I also like going back to see the wt:Bay Area (California). It hasn&apost always been like this. It used to be that when I went back, it felt like I&aposd never left, and that the life that we&aposve made here in Quebec was just a story I told myself. San Francisco seemed real; Montreal seemed distant. San Francisco was where I was supposed to be; Montreal was where I stubbornly and irrationally insisted on staying. (The fact that I stayed in a room in my parents&apos house didn&apost help with the stepping-backwards feeling.) But it&aposs been a few years, and Maj and I have been married here, had a baby, and made a business for ourselves. Even though we don&apost own a house (yet), we&aposre putting down roots. Now when I return to California, it feels like a visit -- like traveling to just another destination. And you know what? California is a fabulous place to visit. Northern California even more so. San Francisco is a spectacular place on the edge of the ocean with music, art, redwood trees, organic food, and a sense of humor about itself that no other town quite has. It will be good to get back to SF for a while. It will be nice to take the baby around to see people and things that she hasn&apost ever seen before. We&aposll be in wt:Palo Alto to stay with my folks, visit my brothers in wt:San Francisco, up to wt:Petaluma and wt:Oakland to visit friends, and maybe even down to wt:Big Sur for a campout next weekend. I&aposve got the Web 2.0 Conference that I&aposm covering for LinuxWorld. And I&aposm sure there&aposll be more in there; we need ot dip the baby&aposs toes in the Pacific sometime soon. tags: california montreal home

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.

Say the word "infrastructure" and you conjure up the images of paved roads, hot water, and that series of tubes that makes up the Internet. In other words, infrastructure is that necessary stuff that lets you get your job done, but it doesn't seem sexy. Every open source project needs a high-quality infrastructure, though, and it turns out that building infrastructure is extremely fun, even though it's not as sexy as building "the next killer app". I've spent a lot of time building software infrastructure. The Debian project is (mostly) not about building new applications. It's about brining together projects with a solid infrastructure so that real people can use it. The Haskell Cabal is a piece of infrastructure that helps other people to compile and distribute applications. So what makes building software infrastructure seem less fun, even though it's really great? It's the idea of measuring the results of your work indirectly. It's easy to say that we wrote n lines of code this year, or that "my application" has n users. Depending on the size of n, that might make us feel good, or feel bad. But measuring results indirectly is much harder. You have to be content to say things like, "I helped 10 programmers build 15 applications for 5000 users, but I only helped each one a little bit." That's an indirect result. But if you are more interested in the result than in who creates it, then you're in a good position to let yourself have fun building infrastructure. If you are more interested in fun than in glory, then you're in a good position to get fulfillment in life :) In fact, infrastructure is really fun to build, at least in computing. You get to take a series of tubes and put them together in a new way. You get to lay the groundwork for many projects that come behind you. There's a bit of systems administration, a bit of hacking, and a lot of contact with the your peers in the community. People will help you figure out what to build since they're chasing right behind you using your stuff (at least in the open source world). People will respect and even occasionally thank you for helping them to do their job. Of course, some pieces of infrastructure become sexy. Debian's apt-get is considered pretty darn cool among those in the know. Writing awesome compilers that real people use (like GHC or Cryptol) is the dream of a lot of computing science academics. The Internet itself is actually cool these days, or so I hear. The Haskell language and community is badly in need of infrastructure right now. We need people to flesh out and improve the existing debuggers, code coverage tools, and IDE support. We need a robust package database, sysadmin support, and project repositories. We need folks to make Debian and Gentoo packages from Haskell packages. If you like people, and want people to get to know you and to appreciate your work, then go out there and discover an important piece of infrastructure that people need. Ask them what exactly they want, how they would build it, but be sure to bring your own vision to the project as well. Most of all, have fun building something with your friends.