24. The Awakening

Under Linux, BSD and everything UNIX, the high uptime was always one of the most valued assets, especially for servers. Windows users were traditionally enjoying the BSOD at random moments.

But they were also enjoying another features before Linux ever had them: hibernation (officially known as "suspend to disk"), and standby (officially known as "suspend to RAM"). Since a desktop user doesn't need to have the computer running 24/7, yet he would like to be able to "freeze" it and recover to the saved state quickly, these were great features. Laptop users will enjoy them even more, as the power is a scarce resource when you're on the way.

I remember how surprised I was to see that both hibernation and wake-up were practically instantaneous starting with Windows 2000, compared to the slow BIOS-based procedure used by Windows 98 on an old HP laptop. After almost a decade of "hibernation and awakening", the availability and reliability of these features in Linux is one of the first things I look after a new installation on any of my home systems.

Alas, the current status of the suspend features in the Linux kernel is best described by the word broken: Barely Reliable Overlooked Kernel Erratic Nap.

I always have problems when I change a distro, or even when I upgrade to the next version. With FC5 I had a reliable hibernation on the laptop. Ubuntu 5.04 managed to hibernate my desktop, but I lost this with 5.10. SuSE 9.3 hibernated my PC with kernel 2.6.11, but SuSE 10.0 broke it completely: kernel 2.6.13. FC6 restored the sleeping capabilities, but Pardus broke them again, while still being able to suspend to RAM on my laptop. On its side, Mandriva 2007 brought back the suspend to disk for my PC, and RHEL5 and Kubuntu 7.04 can cope with my laptop almost perfectly. In this entirely foolish saraband, I was never able to make anything go to sleep with neither of CentOS4, Debian Sarge, Slackware.

Yes, I know: the BIOS might be "defective" with regards to the DSDT, no matter the kernel says it can cope with it: «ACPI (supports S0 S1 S3 S4 S5)». Patches are available, but is this really a task for the end-user? An ACPI DSDT patch in initrd is a distinct possibility, howevr none of the distros I tried had it.

While the old power management interface APM was superseded by ACPI, the power management features that work with your computer and a given version of an open-source operating system can never be foretold.

There is more than a single possibility to make your computer suspend: the swsusp support in the kernel, the suspend2 patch, and the userspace µswsusp. No one can tell you what should work with your computer.

At the desktop environment's level, there is also some duplication in the front-end helper applets that allow you to suspend: we can count KLaptop (dead but walking in some distros), KPowersave, gnome-power-manager, the new kde-guidance-powermanager, and possibly some others.

Unless the efforts to make Linux have a better power management for a broader range of hardware will be better focused, it will still be regarded as a difficult operating system, built using a chaotic development model.

But why is that we want to put our computers to sleep (err... not for good), instead of just shutting them down, then powering them up again? It might be about the booting speed.

I am personally satisfied with the speed my computers are booting. I don't care that much if they take 30 or 60 seconds to get from death into X. Some other people do care.

The classical init system (sysvinit/sysv-rc) has been doing a good job in starting, supervising and stopping all the processes on Linux systems for 15 years now, not to mention that it used to do its job on Unix System V since 1983. When comes to the speed of booting a modern Linux system, various approaches — usually involving parallel execution — have been tried in order to improve it: initng (Init Next Generation), runit (somehow similar to BSD's RC), pinit, and of course Ubuntu's sexy upstart.

While progress is generally a positive idea, having several distros starting their own init system is crazy: this is going to make the respective distros incompatible with other distros, and this will also render your previous knowledge of sysvinit useless. In the process, all the systems unsing the new and experimental init systems will definitely not be production-ready, as the risk of not booting correctly is significantly increased compared to those using the verified System V init.

When something is broken (power management), they don't fix it, but when something works (sysvinit), they're trying to break it. I am afraid this is the way Linux works nowadays. Maybe they need a different way of awakening to discover what is really important: through meditation (zazen).