Back in the APM days, everything was easy. You called an ioctl on /dev/apm, and the kernel made a BIOS call. After that, it was all up to the hardware. Sure, it never really worked properly, and it was basically impossible to debug what the hardware actually did. And then ACPI came along, and nothing worked at all. Several years later, we're almost back to where we were with APM. But what's actually happening when you hit that sleep key?

Without the ability to suspend and resume, laptop users are doomed to spend several hours of their lives waiting for machines to boot and shutdown. This is, clearly, suboptimal. APM made it fairly easy to implement this, because almost everything was handled by the BIOS. And that, in a nutshell, is one of the primary reasons why ACPI ended up in charge.

The biggest problem with APM is that it left policy in hardware. Don't want to suspend on lid closure? The OS doesn't get any say in the matter, though if you're lucky there might be a BIOS option to control it. Would prefer it if the BIOS didn't scribble all over the contents of your video registers while it tries to reprogram them (probably back to the defaults of the Windows drivers...)? Sucks to be you. Want the sleep button to trigger suspend to disk, not suspend to RAM? A-ha ha ha.

ACPI deals with that problem, by moving almost all the useful functionality out of hardware. The downside of this is that the functionality needs to be reimplemented in the OS.

Full Story.

Also:

• Install and Enable DVD playback and w32codecs in Ubuntu

• How to select and generate locales on Ubuntu
• Automating interactions with your netgear router