There's a protest/rally outside Apple Store in Regent Street, London, England from 2pm on Saturday 2006-09-30, just ahead of 2009-10-03's Day Against DRM.

Note to self: 11:30 PM is not a good time to go home if you need to pass the Oktoberfest on the way. (Obviously, the "after" image was not suitable for this medium.)

Note to self: 11:30 PM is not a good time to go home if you need to pass the Oktoberfest on the way.

You want a cheap ARM development machine to test your packages? You can actually have one for free (both as in beer and as in speach ) provided that you have a not to slow i386, AMD64 or PowerPC computer. The solution is called QEMU, a generic and open source processor emulator which can emulate i386, x86_64, ARM, MIPS, PowerPC and Sparc systems. Running an Athlon 64 3800+ the emulated system is around 20% faster than the popular NSLU2 and possibly with much more RAM (my emulated system has 256 MB of RAM). I have written a small howto explaining how to install Debian Etch on such an emulated ARM machine. Note: I have written this howto very quickly, so there are probably some mistakes. Comments are welcome.

The Philadelphia Orchestra just announced the launch of an online store, where they are selling tracks directly from their own website. Following in the tentative steps of MySpace, eMusic, and Yahoo!, the Orchestra is selling unencumbered (i.e., DRM-free) MP3’s. Even better, for a slightly higher price, you can download content in the higher quality (lossless) FLAC format. Performances currently seemed to be priced at approximately $5 for the MP3 version and $6 for the FLAC version. This seems just about right to me. As an added bonus, they’re offering Beethoven’s Fifth in C minor for free. I’d love to see more of the industry move in this direction, particularly for longer-tail type cultural content like classical and world music. These recent developments are certainly a good start. It will be interesting to see if the iTunes Store eventually is forced to respond to these pressures.

Well, I've been added to the python-modules project on alioth and am looking at getting the django development in there over the next week, just need to get my head round how this works first and checkout Raphael Hertzog's repackaging of the 0.95 debs that I did in to the new python policy style. Will also need to work out what to do about different python versions, django-admin.py would need to call the right python depending on some setting - not sure how to do that yet - with the previous format there where just 2 different python-django packages for the 2 different versions of python, and then an alternative to point to the "right" django-admin.py within site-packages of the correct python directory - with the central install this is going to be more interesting. Any thoughts on this gratefully recieved to my email address (linked from the bottom of my website.

I've been looking at getting eclim working on my laptop... haven't yet worked it out, can't get the eclimd to run as expected - it's looking very much like I might need to actually do a central install which means creating a package (stuff does not get installed on this machine in central locations unless it's packaged, hopefully for obvious reasons) so I may take some time out to package it over the next week or so. As far as Java IDEs go, eclipse is where it's at, but I don't like the UI and so, being able to use the useful bits of eclim from a text editor that I use for everything seems to me like a fantastic idea... especially now that I'm editing more Java than previously - my current dev environment it purely vim with a reasonable vimrc that sets expandtab, sw=4, ts=4 to fit with the company policy on java development - would occasionaly be useful to use eclipse to manage various things for me though - so that's why I'm looking at it (thanks for pointing me at it Joe!).

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.

It’s been a while since I’ve written about the LSB here, so I figured I was overdue to give an update. In short, it’s been a great year. Highlights include: » All major distributions, including Asianux, Debian, Mandriva, Red Hat, SUSE, and Ubuntu, are either already certified to LSB 3, in the process of certifying, or planning to certify their next version (see our list of expected distribution coverage for LSB 3). » A number of ISVs (independent software vendors), including MySQL and RealNetworks, are in the process of certifying applications to LSB 3. For ISVs, LSB certification means fewer distribution specific packages without sacrificing distribution coverage (take a look at the MySQL download page for an example of how crazy it can get). For users, LSB certification means greater application availability with a minimum of hoops to jump through. Expect a lot more announcements about LSB certified applications in the coming months. » We’ve put together a solid roadmap for the LSB going forward. The LSB aims to provide a “highest common denominator” across the various Linux distributions—in other words, to provide a single target for ISVs writing or porting to the Linux platform, where “the Linux platform” is defined by a short (and potentially different from ISV to ISV) list of distributions on which their applications must run. To serve as an effective highest common denominator, it needs to be easy to map from LSB versions to distributions and vice versa; and it needs to be possible to target a version of the LSB with assurance that the application will work not only on that version but on future versions as well (i.e., an LSB 3.0 application will run on LSB 3.0, 3.1, 3.2, 4.0, … compliant distributions). We’ve made great strides toward these goals in the past few months. To satisfy the “easy mapping” requirement, each major version of the LSB now corresponds to a major version, or “generation”, of the enterprise distributions. So, for example, LSB 3.x corresponds to the current generation (Red Hat Enterprise Linux 5, SUSE Linux Enterprise 10, etc.), LSB 4.x corresponds to the next generation (RHEL 6, SLE 11, etc.), etc. To satisfy the application compatibility requirement, LSB versions both major and minor beginning with 3.0 are strictly backward compatible with previous versions. At a high level, then, the LSB roadmap looks something like this:

LSB 3.x (2006-2008)	LSB 4.x (2008-2010)
Asianux 2.0 Debian 4.0 (”etch”) Mandriva Corporate 4.0 Red Hat Enterprise Linux 4 & 5 SUSE Linux Enterprise 9 & 10 Ubuntu 6.06 LTS (”dapper”) […]	Asianux 3.0 Debian “etch” + 1 Mandriva Corporate 5.0 Red Hat Enterprise Linux 6 SUSE Linux Enterprise 11 Ubuntu LTS “dapper” + 1 […]

» Speaking of the LSB roadmap, we’re hard at work on LSB 3.2, to be released Q2 2007. The short list of new features include the addition of Perl, Python, several freedesktop.org specifications for desktop interoperability, CUPS, HPIJS, ALSA, and more. For LSB 4.0, we’ll be uplifting LSB Core to GCC 4.1 and glibc 2.4 and looking at two longstanding issues, the addition of Java and a packaging facility for ISVs, among many other things. The roadmap will be posted for public comment shortly. » We’re making it easier than ever to build portable applications using the LSB. We released the LSB SDK (Software Development Kit), which bundles everything a developer needs to write or port to the LSB, with LSB 3.1. We’re building something called the LSB Application Testkit, which aims to be the LSB’s validator.w3.org, an easy to use tool that developers can use to test for application portability. And we quietly launched a beta version of the LSB Developer Network last month. » In July, we hired Till Kamppeter, making linuxprinting.org, the de facto standard repository of Linux printer drivers, an FSG project. We’re adding both distribution neutral printer drivers (delivered, naturally, as LSB packages) to the linuxprinting.org foomatic database as well as an API that third party printer management tools can use to install and update printer drivers. We also plan to extend the LSB certification program to cover printers in addition to distributions and applications. If all goes well, you’ll be able to look for the LSB Certified mark on a printer at the store and know that it will work on your distribution of choice in the not too distant future. » Last, but certainly not least, we’re embarking on an exciting new project in partnership with the Institute for Systems Programming at the Russian Academy of Sciences to build the next generation LSB database and test suite infrastructure. The new system will interlink the various moving parts that make up the Linux platform to an unprecedented degree, providing upstream developers and distribution vendors a powerful set of tools for coordinating their work and improving the quality of the platform, as well as giving ISVs a more efficient way to provide feedback to both parties. This is a key tool for enabling the backward compatibility guarantee mentioned earlier, and it will also vastly improve the coverage and quality of the LSB tests, an area where we’ve been criticized in the past (our goal is 75% interface coverage by LSB 4.0). More details here. I’ll drill down on all of these topics and more in the coming months. In the meantime, you can keep up with the latest at the FSG and LSB by visiting the FSG web site or by signing up for the FSG newsletter (sorry, no RSS feed yet, though I’m told we’re working on it). Finally, if you’re interested in participating in the LSB project, join the lsb-discuss mailing list or the IRC channel #lsb on irc.freestandards.org, where the bulk of LSB development happens.

The other day I had an incident involving my vision. It has nothing to do with the vision problems many people had the other day, when someone posted some pr0n on various Planets. For some time already, maybe two or three years, I've had this weird vision problem at times, when I'd start seeing some black stains with some flashing lights , even with my eyes closed. These symptoms would go away after a few minutes, and washing my eyes with a good amount of water also helped. It happened a lot during mornings, and I somehow connected it to showering with too hot water, using a certain brand of shampoo (Say no to Revlon!) and shower vapour. When I described the symptoms to my mother, the reaction was the expected in a house of doctors and nurses: indiference. En casa del herrero, cuchillo de palo, for those who understand it. On Sunday I stayed up helping Bel n with her DEA paper until 5AM. I woke up at 7:30AM, and stayed at work like a zombie, until I had a chance to have a needed nap at 6PM. The problem was my nap was a bit longer than I wanted, and woke up at 9:15PM, still tired but no longer sleepy. I wasn't sleepy until 4AM, and next morning I accidentally overslept, and rushed out of the bed to get to work as soon as possible. While preparing, I suddenly noticed my vision went a bit blurry and strange. I thought it just was one of those stains , until I closed my right eye to rub it and all I saw was darkness. I totally freaked out. OMFG, I'm fucking BLIND . I wanted to phone someone, but wireless had broken down and I didn't have my mobile phone with me, so I tried looking at a text file I have in the laptop with some numbers on, when it ran out of battery. I grabbed my old mobile and failed to introduce the correct PIN three times. I went to the bathroom, covered my right eye, and yeah, there was darkness. If I waved my hand over my blind eye, I would barely notice some movement on the left side, but that was all. Still very frightened, I washed my eye thoroughly and to my relief, I was able to see the upper part of my field of vision. After some more, I had recovered all my sight. Whew. I managed to speak to Ra l on the phone, who told me this probably wasn't too bad, just the optic nerve being tired due to stress and so on. My mother also asked an opthalmologist at her hospital the day after, who confirmed this. It's probably caused by my recent whacky sleeping habits (basically non-existing), general stress, and long exposures to computer monitors. The doctor asked her if I had a headache, which I didn't the day before, but I had one the day after, when she asked. How do you know? , I replied. Last night I went to bed at 00:05 and managed to sleep eight hours for the first time in many months. I'm really going to make an effort to fix my sleeping habits, because they were quite fucked up lately, not catching up sleep even during weekends. On Monday I'll visit the doctor anyway, just to confirm all of this. Coincidentally, Russel Coker also had similar symptoms this week, and also blogged about it.

With the ever increasing number of trolls, the average developer has no more time to maintain his packages. Motivating him to work on his packages instead of reading debian-vote is a hard challenge.

Here comes BAD-tank, which is the way to:

• motivate developers to work on their packages in the best interest of users;


• motivate users to get interest in what developers do;


• find a way for possible sponsors to spend their money in a useful manner.

BAD stands for Bribe Assisted Development. The idea is to add a new field, named XC-Bribe, to the control file. The field must contain the amount of money the maintainer requires for an upload, with a ISO-4217 currency code. For example, the maintainer might add:

XC-Bribe: EUR 50.00

to require 50 to get the package uploaded.

Then, the package shall be uploaded to the BAD-tank FTP queue. The related sources and binaries will be automatically put into a private area, while the .changes remains public. Users can then read the .changes and decide whether they want to contribute to this upload. BAD-tank accepts Visa, Mastercard, AmEx and PayPal. When the amount of the bribe is reached, the package is automatically uploaded to the Debian ftp-master queue, and the developer is credited with the bribe.

Des Traynor made a very nice roundup of various IDEs and development environments. These were collected from friends of his and it was quite a shock to find Notepad in there!

Since I currently have Debian Sarge and a quite actual kernel (2.6.17.13) successfully running on my 10 years old Pentium-1-ThinkPad bijou, I today thought I could see, if I get the builtin infrared port working. Since lspci and lshw didn’t help much to find out the details about the IR port, I looked at Werner Heuser’s tuxmobil for such information. And I was right: tuxmobil listed all the necessary informations: It’s an internal serial port infrared device on /dev/ttyS0 working without any special driver. It seems to only need the kernel modules irda, sir_dev and irtty_sir as well as probably also the Debian package irda-utils. I could immediately play around with gnokii after configuring it ot use the right serial port and the right drivers for my Nokia 6310i. Also sending SMS via xgnokii worked. It was funny to be able to play ringtones on the phone by clicking around on a virtual piano keyboard. Inebriated by the success with IrDA, I decided to go on and try myself with the notorious Mwave DSP sound and modem card, which came with some of the ThinkPad 760 versions including my ED version. This didn’t start as easy as IrDA since tuxmobil this time writes: But MWave and some other sound technologies won’t work or are very hard to get working, e.g. booting to DOS, loading a driver, then using the soundcard as a standard SB-PRO. So you might need a commercial sound driver. Well, I too often noticed that negative information about hardware support in Linux found on the net with a search engine often is outdated and the formerly badly missed hardware support is available nowadays. So even not giving up on a 404 for a promising site, I found the no more existing webpage of the Mwave Project for Linux in the WayBack Archive. There I found a still working link to Thomas Hood’s Debian GNU/Linux on IBM ThinkPad 600X page which mentions tpctl, the ThinkPad configuration tools for Linux. And happily, they’re included in Sarge as package tpctl. Another link still worked, too: The one to Dale Wick’s Thinkpad under Linux page, which tell’s what I’ve expected: Some of the information on tuxmobil seems to be outdated, although Dave’s page mainly concerns the modem functionality of the Mwave DSP. So I first installed tpctl on bijou, then tried to compile the ThinkPad kernel modules from package thinkpad-source with my both current kernels, 2.4.33.3 and 2.6.17.13 using make-kpkg. The modules built fine for the 2.4 series kernel, but failed on the two latest 2.6 kernels (2.6.17.13 and 2.6.18), I’m mainly running. So I switched over to playing around with the 2.4.33.3 kernel. The thinkpad modules loaded fine and I get access to a lot of the ThinkPad’s special hardware. But tpctl at least doesn’t work as expected regarding Standby and Suspend: It has no effect while requesting Suspend or Standby using apm still works fine. But nothing to see in direction sound, modem or mwave. So I had a closer look at documentation around the mwave module. Tried to find out appropriate I/O and IRQ settings for the module, but what I found in the Linux ACP Modem (Mwave) mini-HOWTO didn’t help. The module just didn’t load. Then I noticed that module seems to need an mwave daemon. A search in the Debian package repository found the package mwavem. No long thinking – installed it. But the installation script gave the same errors when trying to load the module. man mwavem(8) gave the reason: Only the 3780i chip is supported. Earlier Mwave DSPs, which were used for sound generation as well as modem functionality, are not supported. Also according to the kernel documentation for the mwave sound module, the only way to get it making some sounds seems to be to boot to DOS, load the Windows 95 drivers, then call loadlin and warm-boot Linux from DOS. So native Mwave sound on IBM 760 ThinkPads under Linux is really still a dream while the Mwave modem is said to work nowadays. I will continue my ThinkPad 760 journey with a closer look at the pcspkr driver and at eBay, where I’ll look for another 760 series ThinkPad, but with ESS1688 soundcard and no modem instead of the Mwave DSP, e.g. a 760L, 760LD, 760EL, 760ELD or maybe also a 765L. But I won’t do that today. It’s already much too late. Should have gone to bed about two hours ago…

Now playing: Auld Lang Syne (monophonic on the phone :-)

Massachusetts held its primary election yesterday and strangely enough, my preferred candidate for governor, Deval Patrick, won overwhelmingly, by a nearly two to one margin over both of his competitors. In past years, the primary election has been followed by a “unity breakfast” the next morning so all the losing candidates can pledge fealty to the winner. As the breakfast has become a tired tradition identified with “old politics,” they did away with it this year (perhaps at Deval’s urging). Instead, again to my surprise, they held a unity rally about a block away from my house in Adams Park (no relation) in Roslindale. Deval was introduced by Boston Mayor Menino, a politican who has somehow turned a complete lack of public speaking skills into an asset: Deval’s speech was pretty great. A little something for everyone, and genuinely engaging. I attempted to record it on my pocket MP3 player, but apparently I ran out of batteries early on so it’s not worth posting. Although Deval has been cast as the furthest left of the candidates, I was struck by his extremely moderate position on most issues. (Standardized testing: good, but needs improvement; economics: need to have several bottom lines, including a profit bottom line and a people bottom line; personal responsibility needs to be balanced with societal responsibility; etc..) Anyway, the crowd loved it: Apparently there was no experienced political handler present to orchestrate this event. Deval’s charismatic speech was followed by several less important and less eloquent speakers. Usually, you would want to build up from worst to best. In any event, Chris Gabrieli, the second place finisher, has rebounded instantly and was up there committing to work every day until November on getting Deval elected — I won’t be surprised if Gabrieli ends up in a development-czar role in a Patrick administration. The last place finisher (and original frontrunner) Tom Reilly was nowhere to be seen, a fact that I’m sure will be prominent in tomorrow’s reporting on the event. Where’s the unity without the Attorney General? Everyone’s bracing for a horrid onslaught of fear-mongering campaign ads from the Republicans. My hope is that Massachusetts citizens are a bit wiser than the rest of the country and it will backfire. I won’t hold my breath, however. (As a side benefit, I finally met Adam Gaffin, universalhubmeister, for the first time, as well as his eight year old daughter Greta. Greta is now famous for rejecting Deval Patrick’s plan for longer school days.)

There are just three days left to get discount registration for XTech WebDev London: our new one-day training event on Rails, Ajax, REST and web application design and development. It will be held in London on 31 October 2006. It's a great opportunity to get yourself and your team up to date with the latest web development technologies. Our speakers are real world practitioners who will tell you about the pitfalls as well as the promises. You will hear:

• Andy Budd on designing with web standards
• Jeremy Keith on Ajax, what it is, and its appropriate use
• Tom Coates on the building web applications as part of Web 2.0
• Leigh Dodds on the REST model for web applications and its benefits
• Matt Biddulph and Edd Dumbill on real-world Ruby on Rails

Additionally, everybody gets a copy of Cal Henderson's Building Scalable Web Sites, a buffet lunch and plenty of time to talk with the speakers and other attendees. We start at a developer-friendly time of 10am, which also gives plenty of time for those coming from further than London. There'll also be social events in the evening where you can continue networking and learning in more relaxed surroundings. Register now to attend at the cheaper price of 275.

This is my first post in Debian Planet. Last sunday I was asigned an AM, zobel. He's a very helpful guy. It was a great birthday gift because I didn't expect to get an AM so fast, NM is know for being a long process. I've begun to work in the first steps of P&P questions already although I'm not going as fast I'd like because I've hitten by tons of TODO tasks just after finishing exams but I hope to get more involved in the Debian community and development quickly.

Yesterday was the international Software Freedom Day, and the Linux Accra User Group, which I just found out about last week, held a small expo in the "India-Ghana Kofi Annan Center for Excellence in Information and Communications Technology". On the program was a keynote speech by the group members, introducing the concept of Free Software, an exhibition of Linux installations and some programs as well as the showing of the first Open Source movie, blender-made movie "Elephants Dream" and its making-of.What I did not expect at such a meeting would be such a Linux guru: Swedish guy, who was an Amiga fan but had to start using PCs in November 1991(!) and looked for an operating systen, heard of Linux and used it since then. For all those newbies as myself: That was when "Linux From Scratch" did not exist, but you had to do it that way anyways, since there were no distributions. He has been living in Ghana vor 10 years now, bound by a family, the warm weather and by a job where he get's paid to do OpenSource development. Envy, anyone? Read more about him on his recently opened blog.
Someone already uploaded his pictures of the event, my pictures will be uploaded in a short while.In other news: At the College in Tema, where I am working at the moment, we agreed on installing Linux on the library computers to let the students have a shot at it, if they want, and after that the enrollment in the regular labs will be discussed. I shall also give an introction lesson to the IT teachers so that they can help a student during class, should he try to use Linux.