So init is going to be replaced with something that is event-driven, in order to deal with modern systems' dynamicity. I think that this step is necessary at some point, although not going far enough. I'd like to have an init system that is driven partially by events and partially by goals. While the system attempts to achieve a goal, for example "display login prompt", it would defer processing of events that don't help in achieving the goal (such as starting the mailer). For that to work, however, the init daemon needs an overview of the "big picture" as well as ways to find out enough about the dynamic configuration so it can determine what is important and what isn't.

Well John Howard said he wanted to start a nuclear debate in Australia. Seems it has already started on Planet Linux Australia. I figure I might as well have a meandering blog post about alternative energy and current world events, since I've just been immersing myself in the best news I can obtain with my crappy cable package in a country not renowned for its awareness of world affairs. Firstly, since there's been talk about nuclear power, I'd like to offer my thoughts on Iran, and how it's sounding like Iraq all over again. People are getting in a flap about Iran enriching uranium. Iran says that they don't want "the bomb", they only want nuclear power to meet their energy demands. Now if this is true, then surely should applaud a country that sits on a chunk of the Middle East's oil reserves looking to use something other than oil for its energy needs. I for one don't know if you need to "enrich" uranium to use it for a nuclear reactor, or whether it's good enough "as is". But let's just assume that Iran's intentions are as they have said, then it's going to be Iraq all over again. The US said Iraq had weapons of mass destruction. The US is saying Iran is enriching uranium for the purposes of making a bomb. So far the former claim hasn't been proven, so what's to say the latter is true either? Let's say the nuclear debate in Australia determines that it'd be a good a thing for Australia to go nuclear. How is Australia enriching uranium for electricity generation any different to Iran doing it? (Other than Australia is in the Coalition of the Willing, and Iran is in the Axis of Evil). Speaking of Iran being in the Axis of Evil, how is Iran supplying weapons to Hezbollah fundamentally any different to the US supplying weapons to Israel? Oh, and is anyone allowed to criticise Jewish people without being called anti-Semitic? Since when is invading a neighbouring country considered okay? I am so glad Australia is an island nation. These countries with land borders, sheesh... Anyway, back to alternative energy. I'm a greenie, (with a lowercase "g") so I'm open to nuclear power, but it does frighten the willies out of me, with things like Chernobyl. I'd never heard of a Pebble Bed Modular Reactor until Paul wrote of it. It certainly sounds safer than previous methods of nuclear reaction. But of alternatives. Wind, for example, doesn't need to be big and arguably ugly. These guys in the UK have made a very sexy and quiet wind turbine. I don't know how it stacks up in terms of cost or output to the traditional three-bladed wind turbines like what I've photographed in Southern California, but they're supposed to be quiet, which is apparently one of the (many) arguments that landowners like farmers have against wind generation in general. This Australian company has come up with a very small, but less sexy wind turbine, that I believe to be fairly cheap. Finally, in terms of generation, and I've written about this before, but I find the Tower of Power to be a fascinating concept in natural energy generation. Where am I going with this ramble? No idea. I do think rapidly developing countries like China should completely leapfrog over the era of oil and move to renewably generated electricity. Maybe they can get the manufacturing costs down of the equipment, and it'll be less of a big deal in terms of cost for the rest of the world to adopt it. Whew. What a ramble. Don't start me on flushing toilets with drinking water.

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

Today, I've been quite busy with "real life". First of all, I retrieved keys for my new room (see below), and was busy half of the day with packing stuff. Around noon, I had to go to a funeral. A friend of mine has died, most likely from cancer (maybe smoking-related, I don't know). He was very active for a NPO helping people with the internet. We'll really miss him there, too. In the afternoon I packed more of my stuff together, bought some new things; then took a break to go dancing - I started taking a Balboa class today - and finally took most of my stuff to my new room. Until around midnight I was cleaning the room, fighting the "malfunctioning" doors of the huge wardrobe and moving stuff in. Tomorrow I'll probably spend my first night in the new room. This is a shot of the new room. I don't have a wide angle lense, so that is the best I could do (I have the lens on my Amazon Wishlist, but it's horribly expensive...). It's the plain room, nothing of my stuff in there yet. The first thing I did was putting up some nice yellow curtains, to add some color. The flash makes some funny light effects with the mirrors of the wardrobe on this picture. ;-) The room isn't huge, but it's well done. The bed fits in behind the door, a desk will fit next to the bed, and there is this huge wardrobe. The mirrors on it make the room appear larger and brighter. Now with some sunny colors this will be a room I can enjoy. I'll probably post another picture when I've added some more color to the room. I have a couple of nice computer artworks printed out to hang to the walls. Oh, and the linux sourcecode poster. ;-) (No, I probably won't put that one up. It's mostly gray. It wouldn't match the room. It will be interesting how my life will change the next months. I'll be doing a lot more dancing - I intend to join a Boogie sports club, learn Balboa and Boogie and train Lindy Hop - and since I'll be living closer to the city, I expect to go out more. And I hope the people I'll live with in that house are fun, so we'll be spending some time together. We have a pool table and a dart board in the living room, and a perfect spot for placing a projector. Also since I've passed my final exams, I'll now focus on my final thesis. My topic is about semantic wikis [wikipedia.org], at my university and a research institute. The last months, I had been rather bored with university life; the thesis will likely set the course for the next few years of my life: research, entrepreneurship or just working at some larger company.

Thanks to LWN I was reminded of the, erm, interesting license and security guarantee of qmail. Specifically:

In March 1997, I offered $500 to the first person to publish a verifiable security hole in the latest version of qmail: for example, a way for a user to exploit qmail to take over another account. My offer still stands. Nobody has found any security holes in qmail. [...] In May 2005, Georgi Guninski claimed that some potential 64-bit portability problems allowed a remote exploit in qmail-smtpd.'' This claim is denied. Nobody gives gigabytes of memory to each qmail-smtpd process, so there is no problem with qmail's assumption that allocated array lengths fit comfortably into 32 bits.

Erm. Well. I'm not sure what to say. Assuming that array lengths (size_t, IIRC) is a 32-bit type even on 64-bit architectures is wrong. Defending it is insanity. NP: Layered, Antibreak

Wikipedia has been in the news a lot lately. Some of the articles are quite insightful:

• Know It All: Can Wikipedia conquer expertise? in the July 31 New Yorker.
• The Hive in the September issue of the Atlantic Monthly

Each article examines a different aspect of Wikipedia knowledge and culture, and they fit together nicely (although presumably unintentionally). Both articles are proof that traditional print media can still be relevant and coexist semi-peacefully with peer production efforts like Wikipedia. They are also excellent examples of something other than a knee-jerk defensive reaction by incumbent media to a perceived threat (e.g., this FOX news story or Britannica’s response to Nature’s article comparing Wikipedia to Brittanica). Meanwhile, an interesting unrelated Wikipedia commentary in the blogosphere:

• Seven Wikipedia Fallacies by enfant terrible James Grimmelmann. It’s nice to see James blogging more, now that his judicial clerkship is over. (Is he still an enfant terrible now that he has finished his clerkship? Only time will tell.)

There are many question what needs to be resolved to allow the new python-defaults into etch. There are some packages that would become uninstallable by that now, and the task is to just check them and fix them: ethereal-dev, gaby, gforge-plugin-scmsvn, gnome-tasksel, gnuradio-examples, gr-audio-alsa, gr-audio-jack, gr-audio-oss, gr-usrp, gr-wxgui, guml, hplip, ifrit, ldaptor-utils, ldaptor-webui, lfm, libghc6-missingpy-dev, mboxcheck-applet, med-bio, memaid-pyqt, mock, musiclibrarian, ocfs2console, omniidl4, omniidl4-python, plywood, positron, pydict, pyftpd, pykdeextensions, pymol, pyntor, pypanel, pyrad, pyslide, python-dispatch, python-gdal, python-gdchart, python-gdchart2, python-gdk-imlib-1.2, python-glade-1.2, python-gnome-1.2, python-gnuradio, python-gtk-1.2, python-ldaptor, python-mapscript, python-metakit, python-moinmoin, python-notify, python-numeric-tutorial, python-phidgets, python-protocols, python-sip-qt3, python-turbojson, python-usrp, python-zeroc-ice, pythoncad, pytone, releaseforge, rubrica, scalemail, scanerrlog, scigraphica, snappea, snappea-dev, spikeproxy, sql-editor, viewcvs, viewcvs-query, wireshark-dev, xen-ioemu-3.0, xen-utils-3.0, xkeysw-config, yum, zeroc-ice For example, gforge-plugin-scmsvn depends on viewcvs which needs to be converted to the new policy. Everyone can take his share - just choose any package, look why it becomes uninstallable (perhaps via a dependency becoming uninstallable) and fix it. Oh, and please set the urgency to high and make sure prior to upload that the package still works. (This is only the list on i386, but experience has shown that once it's resolved for the first architecture, it isn't too hard to resolve it for the other architectures also.) Update: Some packages are already in the progress, e.g. ethereal-dev depends on wireshark-dev which depends on omniidl4 which has been NMUed already. Well, like always: Check what the issue is before fixing it. And if binNMUs help, please just tell us. 2. Update: It would be really helpful if someone could take care of viewcvs. 3. Update: The most important open issues are: viewcvs, mapserver, moin (whereas viewcvs has a good version in experimental, maintainer is contacted). Also, these programs might need some love to get converted to the new standard or have otherwise real NMUs: blogtk boa-constructor codeville drpython fnorb freeloader forg fvwm-crystal gco gdebi gdeskcal gnome-btdownload python-visual gaby guml ldaptor scalemail lfm missingpy mboxcheck-applet yum mock musiclibrarian ocfs2-tools plywood positron pyftpd pyntor pyrad pyslide python-gdchart pygdchart2 libmetakit2.4.9.3 moin pythoncad pytone rubrica scanerrlog snappea spkproxy

I'm (again) looking for a piece of software that might do just what I need, before I go out and reinvent the wheel. This time, I need something that can coordinate all the configuration files for the various services that make up an online presence, namely bind, apache, postfix and the smaller things I forgot. It should be robust (at least, there should be a "rebuild everything" button. It should allow me to form groups of domains, for example if I want .com and .org treated the same, but also allow exceptions (when only the .org has an alias for the board of directors). And it does not need a

I am not a good coder. In my mind a coder is determined by how much he loves C (or, in clinical cases, assembler). I hate C and avoid it whenever I can, because I am always off-by-one, and often even in more then one place, which make debugging even more .. fun. Currently I am coding an application that is centred around use of artificial neural networks (more precisely a multilayer perceptron). The NN part must be done in C for speed and memory usage (imagine adding and multiplying hundreds of millions of floating values just for one operation .. and having to do that for 10 000 times for training .. while holding the whole data set in RAM, because you access every single value of it every second). With that in mind I engineered my system in such a way that the C part can be reduced to a couple simple operations that I can adapt from examples of the NN library. And still I barely wrote those pieces. Working with MySQL in C is pure pain, for example. The rest of the system is in Python and I must say that Python is a godsend by itself, without even comparing it to C. I am now so used to Python when I was debugging my C program, I automatically wrote a chunk of Python into it and was very surprised when it did not work. With that in mind, to ease the pain for further generations of neural network researchers, I will (someday) find some time and write Python wrappers for the nice and cool Lightweight Neural Network C library that I am currently using here. BTW: I found that SourceForge is packed full with great software projects, but it is very hard to find those projects in Google. Morale - seeking for good free software? wajig (or apt-get) it! then sourceforge it! then freshmeat it! and only then google it.

Our server has not been reachable from inside T-Online today. The reason is that they seem to inflate TTL on DNS entries to reduce load on their servers. This field is there for a reason. People might decide to tune it when they expect changes, for example when moving services to another machine, like I did today. And will do again next week for some of the domains, as this is only a temporary home (in fact, it is a dd'ed image from the old machine running as a Xen instance on a spare IP now, to make the migration easier.

Here's a quick HOWTO to get you started with the QEMU emulator, the Debian installer (etch beta 3), and SELinux. If you execute the following steps you'll be left with an SELinux-enabled Debian unstable QEMU image, but not with a complete working and perfectly configured SELinux system. A more detailed article about SELinux will probably follow... Basic Debian unstable install in QEMU:

1. Install QEMU:
   apt-get install qemu
2. Download the latest Debian etch installer ISO image (etch beta 3, currently):
   wget http://cdimage.debian.org/cdimage/etch_di_beta3/i386/iso-cd/debian-testing-i386-binary-1.iso
3. Create a QEMU image which will hold the Debian installation:
   qemu-img create -f qcow /path/to/debian.img 5000M
4. Boot directly from the ISO image and install Debian into the QEMU image (I won't go into the details of the installation itself; Wolfang Lonien has nice HOWTOs for that: part 1, part 2, video):
   qemu -hda /path/to/debian.img -boot d -cdrom debian-testing-i386-binary-1.iso
5. After the installation is done, configure the system, tweak /etc/apt/sources.list if needed, and then dist-upgrade to the latest stuff:
   apt-get update && apt-get dist-upgrade
6. That's about it for the basic Debian install, you can now shutdown the OS and QEMU (type "halt" in the emulated Debian, wait for the shutdown to complete, press CTRL+ALT+2 to switch to the QEMU console, and type "quit").

Creating a QEMU overlay image: QEMU has a nice feature called overlay images which allows you to "clone" an image, where the new (overlay) image will only store the "diffs" to the original one, thus saving lots of space. This also allows you to remove the overlay image at any time and restart from the original image (which is nice for testing stuff which may break).

1. Create an overlay image based on the previously installed Debian image:
   qemu-img create -b /path/to/debian.img -f qcow /path/to/debian_selinux_overlay.img
2. Now boot into the new overlay image:
   qemu -hda /path/to/debian_selinux_overlay.img

Basic SELinux setup:

1. SELinux wants to label all the files on your system (all inodes actually), so your filesystem(s) need the so-called extended attributes (xattr) and "security labels" (both are kernel options) which most modern file systems now support. For ext3 (for example) you need these config options:
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_SECURITY=y
Luckily the Debian kernels are xattr-enabled by default so we don't have to do anything at all here.
2. Install the basic SELinux packages and the source package of the SELinux reference policy:
   apt-get install checkpolicy policycoreutils selinux-policy-refpolicy-src
3. I noticed a bug in the current Debian packages (the setfiles utility is in the wrong place, see #384850), but there's a simple workaround:
   ln -s /sbin/setfiles /usr/sbin/setfiles
4. Now we can (re-)label the file system:
   cd /etc/selinux/refpolicy/src/policy
make relabel
   This will build the reference policy from source and relabel your file system (this will take a while).
   There might be some warnings (and maybe you'll notice further bugs), but they seem not to be critical.
5. We can now (almost) enable SELinux, but before we can reboot we need to work around another bug (#384852), otherwise SELinux will not be enabled when we reboot:
   ln -s /etc/selinux/refpolicy/src /etc/selinux/targeted
6. Now reboot the emulated Debian system, and at the GRUB console add the kernel option selinux=1 to enable SELinux in the kernel (press "e" to edit the boot options).
7. You'll get tons of SELinux log messages while the system boots, that's normal at this point, don't worry.
   Then you can type "sestatus", which should print some information on the running SELinux system. If it says "SELinux status: disabled" something went wrong.

Congratulations! You now have a QEMU image with minimal SELinux support and you can start playing with it, tweaking the policy, finding and reporting bugs, reading tons of documentation on how SELinux actually works etc. etc. As SELinux is (half?) a release-goal for Debian etch, it would be nice if many people could test it before the release, and this is one method to do so without breaking your production systems. Update: You don't really need user_xattr support for SELinux, only xattr support (for security.selinux xattrs) for the filesystem you use, which is available per default in Debian kernels (thanks Russell Coker).

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.

In a mailing list to which I subscribe there is currently a discussion on US politics with the inevitable discussion of <span style="font-weight: bold;">wasted votes</span>. As I don't want to waste my writing on this topic on a closed list I'm posting to my blog.<br /><br />There is ongoing discussion on the topic of <span style="font-style: italic;">wasted votes</span>. As a matter of principle, if a vote is considered to be wasted, then that should be considered a failure of the electoral system.<br /><br />Having representatives for regions makes some sense in that a regional representative will have more interest in the region than a central government with no attachment to the region. I expect that representatives of regions were initially used because it was not feasible for people to vote for people that weren't geographically local. Now there is no real requirement for geographical locality (only a very small fraction of the voters get to meet the person they are voting for anyway) but having a representative for a region still makes sense.<br /><br />The requirement for a regional representative means that if you live in a region mostly filled with people who disagree with you then your vote won't change much. For example I live in a strong Labor region so the REAL fight for the lower house seat (both state and federal) occurs in the Labor party room.<br /><br />My vote for the senate counts as that is done on a state-wide basis. So of the two votes entered in one election one of them can be considered to not be <span style="font-style: italic;">wasted</span>.<span style="font-weight: bold;"></span><br /><br />For the US system, the electoral college was developed in a time when it was impossible for the majority of voters to assess the presidential candidates, and it solved the requirements of those times reasonably well. Today it is quite easy to add up all the votes and use either a simple majority or the "Australian ballot".<br /><br />Currently there is some controversy over the actions of Senator Joe Lieberman who lost the support of his party and then immediately declared that he would stand as an independent candidate. I believe that this illustrates a failure of the electoral system. It should be possible to have multiple candidates from each party on the list. In the Australian system it is possible to do that, but as they are in random order on the voting cards no-one would be sure of which candidate of the winning party would get the seat unless there were actual reasons for preferring one candidate over another (which sadly often isn't the case). This is good for voters (the minority of voters who care enough about internal party policies to prefer one party candidate over another should make the decision) but not good for the candidates who want a better chance of winning without actually demonstrating that they can represent their voters better than other candidates.<br /><br />The Australian government system has nothing equivalent to the US presidential election. The prime minister is voted in by the members of parliament. So there is little chance of getting multiple candidates from one party contesting one position. For the US presidential election I think that the best thing to do would be to have an "Australian ballot" and permit multiple candidates from each party. For example you could have Bush and Cheney running as candidates for president with each promising to make the other their VP if they get elected. With the Australian ballot it wouldn't matter if you put Bush and Cheney as the last two votes on your ticket, the order you use for them will still matter.<br /><br />I think that with the US presidential and state governor elections there is enough knowledge of the candidates among the voters to make it worth-while for each of the major parties to run multiple candidates.<br /><br />One of many advantages of having multiple candidates is that you might have real debates. If the main candidates from the two big parties have a set of strict rules for their debate that prevents any surprise then the people who are the less likely candidates from those parties (and who therefore have less to lose) could go for a no-holds-barred debate with a selection of random members of the public asking questions.<br /><br />Of course none of this is likely to happen. Any serious change would have the potential to adversely affect at least one of the major parties, and any improvement would necessarily have a negative impact on most of the current politicians. Votes ARE being wasted, and most politicians seem to like it that way.

I attend many presentations and have seen many that had a lower quality than they should have. Some things are difficult to change (for example I have difficulty speaking slowly). But there are some things that are easy to change that many people seem to get wrong and I will list some that stand out to me.<br /><br />Unreadable presentation notes. You have to use a reasonably large font for it to be read by most people in the room. This means probably a maximum of about 16 lines of text on the screen. I have attended some presentations where I couldn't read the text from the middle of the room!<br /><br />Too many slides. On a few occasions I have heard people boasting about how many slides they are going to use. An average of more than one slide per minute does not mean that you have done a good talk, it may mean the exact opposite. One of my recent talks had 8 slides of main content plus an introductory slide while waiting for people to arrive and a Q/A slide with my email address and some URLs for the end. The speaking slot was 30 minutes giving an average of a slide every 3-4 minutes.<br /><br />Paging through slides too quickly. If you have 60 slides for a one hour talk then you will have no possibility of going through them at a reasonable speed (see above). Even if you have a reasonable number of slides you may go through some of them too quickly. On one occasion a presentation included a slide with text that was too small to read, I tried to count the lines of text but only got to 30 before the presenter went to the next slide.<br /><br />Using slides as reading material for after the lecture. Sure it can be useful for people to review your notes after the lecture, and it's generally better to give them the notes than to have them be so busy writing notes that they miss somehting you say. But if you want to have something verbose and detailed that can't be spoken about in the lecture then the thing to do is to write a paper for the delegates to read. Serious conferences have papers that they publish (minimum length is generally 4 solid A4 pages) which are presented by a talk of 30 to 60 minutes. That way people get a talk as an introduction and they get some serious reference material if they want to know more. Also people who miss the talk can read the paper and get much of the value. Is it not possible for slides to take the place of a paper.<br /><br />Bad diagrams. Diagrams should be really simple (see the paragraph about readable text). It is OK to have diagrams that don't stand alone and need to be described, a lecture is primarily about talking not showing pictures.<br /><br />When simplifying diagrams make sure that they still represent what actually happens. Simplifying diagrams such that they don't match what you are talking about doesn't help.<br /><br />Animations. The only thing that is animated in the front of the room should be the person giving the presentation. Otherwise just do the entire thing in flash, publish it on the web, and don't bother giving a talk.<br /><br />Staged content, particularly when used as a <span style="font-style: italic;">surprise</span>. Having a line of text appear with every click of the mouse forces the audience to stay with you every step of the way. This may work for primary school students but does not work for an intelligent audience. Give them a screen full at a time and let them read it in any order that they like. This is worst when they someone tries to surprise the audience with a punchy line at the end of every paragraph. Surprising the audience once per talk is difficult. Trying to do it every paragraph is just annoying.<br /><br />One final tip that isn't as serious but is not obvious enough to deserve a mention. Use black text on a white background, this gives good contrast that can be seen regardless of color-blindness and with the bright background the room is lit up even if all the lights are off. The audience wants to see you and sometimes this is only possible by projector light. Also the more light that comes out of the projector the less heat that builds up inside, it can really mess up a presentation if the projector overheats.

A typical web page will consist of dozens of files - images, javascript, CSS. Web browsers usually load 2 files in parallel (recommended by the HTTP/1.1 spec to use max 2 keep-alive connections). If you are including many javascript files in your <head /> element, these will probably be loaded first, the images second. This is the effect of images appearing "late" over slow connections. However, if your page can be displayed without the javascript (which is very recommendable because of accessibility issues), you might want the browser to load the images first. If your page totally relies on JavaScript - bad luck for you. In order to improve your load times, you can use some simple techniques. For example by putting images on a separate server (e.g. images-amazon.com, yahoos yimg.com, static.flickr.com, photos1.blogger.com). This is a common practise for large sites, for several reasons:

• A web server serving exclusively static images can use a more lightweight, more performant web server software
• It can benefit from different caching strategies
• It can benefit from different hardware choice (e.g. slower CPU but more memory; raid not really needed, better to have two servers etc. pp.)
• Images usually make up a large chunk of the traffic - but they're easy to replicate to a worldwide mirror network
• Authentication, cookies etc. don't need to be sent
• Might be outsourced, since it doesn't contain business data
• Images can be loaded via separate http connections

The last point is the inspiration for this posting - while your web server is still busy building some dynamic web page or serving some Ajax requests, your image server could already be sending out the images. This might give the user the impression that your web site is much faster. Most users are broadband - but they still have some latency. In fact, latency has increased for many users with broadband due to interleaving on DSL lines, for example; ping is higher with regular DSL lines in germany than it was with modems or ISDN. Some relevant pages: HTTP/1.1 Pipelining [w3.org], Mozilla pipelining FAQ [mozilla.org]

Opensource has some scalability limits. A recent blog post shows that e.g. Gentoo is suffering from similar effects as Debian. I believe this is a matter of size, so I doubt that Ubuntu will be immune to this just by it's Code of Conduct and similar things. There is this well-known idiom: "too many cooks spoil the broth" - I think this applies to Opensource work, too. Given that we all want "democratic" work, without having a cabal do the important decisions, I see only one way to resolve this. Subprojects. Just like a distribution doesn't inherit all the software package communities problems, we should try to avoid "aggregating" all the issues at a distribution level. And if you take for example Gnome, many developers are involved only in a few applications, and the communities in each application are probably not of the "critical mass". Examples of such subprojects in Debian include:

• installer work
• architecture porters
• team maintainance of large package sets

Maybe we can find a way to make more use of these effects, that smaller groups usually work together much better. I'm not sure yet how to add extra "sub-communities". Some like team maintainance oranize themselves, which is probably best. Some parts can move to freedesktop, becoming "upstream", and joining efforts with other distributions. Some were created on "alioth". So I think Debian is already on the right track here. Anyway, I'm not a "key player" in Debian, and I'm probably not going to change this. But I'll personally try to follow some simple guidelines to make life nicer for everyone.

• I try to not participate in flame wars. If a mailing list is frequently ridden by flame wars, it's best to leave it alone. There will just be new flamewars coming up again and again. Instead, I try to use mailinglists with fewer people, that maybe are more on-topic.
• I don't read threads that obviously got out of hand.
• I don't read debian-devel. It's a waste of time.
• I try to keep out of other peoples work. Either I become a "serious" contributor, or I let them do what they think it's best. I'm likely less capable of seeing how it all works together if I'm not closely involved. Pinging or filing "wishlist" bugs is of course okay, but you have to accept the decision of those doing the actual work.
• I try to keep stuff away from the full community. Discussing it within a smaller group (the people who actually do the job) is more productive, and you probably won't get much extra results from asking a larger group - but you'll end up with lots more fighting.

LWN has an article up about how RPM is forked, with no single agreed-upon upstream and lots of distros going off and patching it on their own:

Fedora currently ships version 4.4.2, and even the Fedora development repository has not gone beyond that. SUSE remains at 4.4.2, and the current RHEL offerings have rather older versions.

(And Debian's at 4.4.1+a year of patches.) rpm is not the only peice of software that is a major component of many linux distributions but has no agreed-upon upstream maintainer, and thus effectively one fork per distro. Another such peice of software is cron. Vixie cron was last released in '93. In many distributions it's still used, but in eg, Debian, the package is the result of 13 years of patches on top of that release. The debian version number is 3.0pl1-96. That's ninty-six versions based on 3.0pl1. The Red Hat sub-version is in the fourtys. There's no standard version anymore, just this pile of patches, and other piles of patches in other distributions. If we're lucky, they at least share the same security fixes. Another example is makedev, which was had its last upstream release in '98 and is at patchlevel 82 in Debian. Or netcat, last released in '96, patchlevel 32 in Debian, and a fork/rewrite at netcat.sourceforge.net. Or xgalaga, whose upstream author has fallen off the net and last released it in '98. The Debian package, which I maintain, is at patchlevel 37, and seeme to be the only place a lot of people can find to send patches to. But I don't want to be its upstream maintainer. This is the kind of thing that makes me gibber in horror when people at Ubuntu talk about Debian and other distros being part of an "ecosystem of software". I don't want to be part of an ecosystem; I'd rather be part of something that works not something that muddles through via massive trial-and-error and redundancy. Biomass is another word for "shit". But I digress.. The most productive thing I've seen done to try to address this general problem is the Unmaintained Free Software wiki, which tries to track this software and find new maintainers. That has managed to match up some software with interested people (though it failed with xgalaga), but I think it actually works less well for big and important software that ends up forked and maintained separately by the major linux distributions. I, myself, am beginning to use the degree of divergence from upstream as an indicator of how well a distribution maintains a given peice of software, with more divergence == bad. A distro that's doing a good job will a) get their patches integrated upstream and b) should work with other distros to find a new developer if upstream goes missing or insane. This is the inverse of what people might naively consider a good metric of how much work a distro is doing, but I think it leads to better software in the long run.