I think the OP was referring to Windows' sleep - actually Windows does a great job of confusing with it. There are 3 variants of "sleep":
1. Suspend (to RAM) - this effectively powers down most of the computer including disks, leaving the RAM and certain CPU parts and other chips powered to a certain extent (such as the network adapters that can wait for "wake up" packages).
Suspend is the fastest to "boot", usually a few seconds. Disadvantage is that it consumes some power (very little though) and if the power is cut, it will lose all unsaved data.
2. Hibernate (Suspend to disk) - writes all memory data (and maybe some more stuff) to the swap partition then powers off the computer for good. At every boot cycle, the kernel checks if a valid hibernation memory image is present, then it loads it.
Hibernate is the slowest to boot back to, it has to reload the image from the swap partition then power back every component to the way it was before.
3 Hybrid sleep - Its the mix of the above, it writes the hibernation image then puts the computer in sleep. Good if the computer loses power (such as a laptops battery runs out or the power is cut from a desktop). If the computer doesnt lose power, it will wake up from suspend, otherwise it will wake from hibernate.
This is the best of the 3 ways - it can be fast or slow but always reliable.
Hybrid sleep is introduced only in recent kernels (3.6?) - it works from the command line with (as root):
echo suspend > /sys/power/disk; echo disk > /sys/power/state
There are probably other ways to trigger it, this is the lowest level working one.
Possible problems: As there are a bewildering combination of chipsets available in the PC world, you just might get a combination that has some quirks not documented or just not included in your distro so you might get problems at wake up.
Now the issues usually come because certain board makers were lazy/incompetent/whatever and they didnt implement fully compliant/working ACPI calls to the BIOS, instead they deviated with fixes on the driver side (of course, packaged for Windows) - these fixes had to be imported to the Linux drivers by either trial and error or finding the flaws in other ways (documentation etc) - some arent implemented at all . So because of these "quirks" some chips dont behave as they should because they have broken ACPI tables so a fully compliant approach isnt working.
I found that usually the fglrx and nvidia drivers work just fine (i am sure there are cases where they dont) for lower level/older/widespread chips - i had a nvidia 7600GS, a nvidia 8200, nvidia Quadro NVS 285 and a Quadro NVS 135M (the Dell 630 laptop) and more recently a AMD 7560D (part of a A8-5500 APU). All these worked/work just fine with suspend/hibernate using Ubuntu and Debian and their respective proprietary drivers.
Especially the APU's case is interesting because the fglrx driver hasnt got that good reputation. Maybe the 7 series APUs are better supported or something, this chips is as stable as the nvidias before it.
Originally Posted by selfprogrammed
Avoid hiberate-to-disk as that requires writing over your swap partition, and restarting the machine other than the one correct way, will fail in interesting destructive ways.
This probably keeps changing with every kernel release.
Not in my experience. I have a Dell 630 laptop with nvidia card (with the nvidia driver) and it does sleep and hibernate just fine. Never ever had "destructive" issues with returning from hibernation - at very least the hibernation image was deemed corrupt and the computer did a full boot (i had all sorts of stuff opened). I agree you can loose data but obviously you should save everything (even if you let the programs open) before hibernating.
Sleep/hibernate works just fine on my desktop too - i had a AM2+ board before with onboard nvidia 8200 graphics and it slept and hibernated just fine. Now i have a A8-5500 APU and a Gigabyte board and it sleeps and hibernates well using the fglrx driver (although lately i just leave it on). Once i built acomputer for someone that had a AMD 6670 card and tha too was hibernating/sleeping (used my hdd in it).