The boot system that was in universal use until a few years ago was SystemV. This harked back to the early days of Unix, and while it was an acceptable system at the time, priorities change. We no longer use a gang of men in white coats to bring a computer online.
The way computers work has changed too. Ten years ago, you had a hard disk, which existed on a known controller and that was pretty much it. Now there are many more ways to connect storage to a computer and networked filesystems are more common.
Upstart was a project designed to save time and resources in the system startup. Using an event system, the idea was that certain processes get run on demand and aren't just started willy nilly when the computer starts up – for example, there's no point running your printer daemon if there is no printer attached.
Retaining compatibility with old init scripts, it makes extensive use of D-BUS messaging to manage processes and a rule-based system for service activation. Originally released for Ubuntu 6.10 and also adopted by Fedora 9, the Upstart system has managed to bring some sense to the startup procedure and cut precious seconds off the start time too, where parallelisations have been made (spawning more than one task at a time).
Borrowing heavily from the concepts used in Apple's launchd service, which takes care of the init process for Mac OS X, the new SystemD init system does some seemingly crazy things. The idea here is that if you are not using the maximum CPU and disk resource, you aren't doing enough work.
SystemD aims to parallelise as much as possible, essentially starting all the tasks simultaneously, more or less.
SystemD
Usually this doesn't happen, because many services or daemons rely on others to be already running. But, crucially, that doesn't mean they are going to immediately use them. For example, some daemons may rely on the logging daemon being started, in case they want to write log messages. It doesn't mean that they actually need to write a log message then and there, just that they need to be able to if required.
The SystemD solution to this sort of activity is to pretend to the daemon that the other service is actually already running, allowing it to start up as well. In cases where, for example, the daemon did try to write to the log, the kernel buffers would hold the information until the logging daemon had finished starting up.
That's just one of the concepts behind this fascinating approach to the startup process. You can find out more on Lennart Poettering's blog at http://0pointer.de/blog/projects/systemd.html.
A big change like this is bound to be controversial, and there are no end of people arguing about SystemD right now, but the startup scripts are probably one of the most ancient things in a modern Linux distro. These won't go away overnight though – if ever.
Upstart promised (and delivered) a new way of doing things, but few distros apart from Ubuntu have actually implemented many native rulesystems.
Checking your boot speed with bootchart
1. Get bootchart
On Fedora and some other distros, you'll find the bootchart package in the repositories. It's also a fairly simple build from scratch.
2. Reboot with Bootchart
Assuming you have installed it OK, all you need to do is reboot and choose the Bootchart option (or the option you modified earlier.
3. Makechart
When the system has booted up, just open a terminal and type bootchart. This builds a chart out of the log data you collected.
