[1996]

> This hasn't been my experience with Windows in the last 5 years. Truth be told it's pretty stable by now and for me, issues like that are rare.

Good sleep on windows has only returned recently.

After years of great sleep on Windows 7, there have been massive changes following the introduction of ACPI S0.

Case in point: I got a nice laptop for classes like 4 years ago and it did NOT implement either S3 or S4 mode, which caused a MASSIVE problem in Linux. I found out about the issue on mailing list: the bios simply didn't implement at all this part of ACPI, instead of exposing the hooks based on the OS detection. It was to reduce problems in theory, but it brought many more in practice.

Connected standby (S0idle) was very flaky on Windows 10, and very often the laptop would eat the battery overnight instead of going to sleep.

[WorldMaker]

I don't think a lot of Windows users notice when hardware has things like missing ACPI states because Windows since Vista tends to treat a lot of drivers as potentially "sleep hostile" and does all sorts of crazy tricks to paper over bad driver behavior, including sometimes hard shutting off/rebooting hardware on tough timeout limits (depending on hardware class) and fakes sleep/suspend as best as it can given whatever limits it comes across. The few times I've ever skimmed the ACPI/Power Events event logs in Windows, it's an amazing glimpse into some real wild goings on that rarely seem noticeable from a user level, but clearly indicate that drivers are as much of a mess as ever and Windows does a lot of work to make it look like things are fine, everything is fine, and system is peacefully sleeping (as hardware gets kicked under the table for acting up).

I'm not sure if there are direct lessons there for Linux driver handling as Microsoft has huge test labs that do forward these sorts of event logs to the hardware manufacturers and is in a position to expect at least some of them to do better next time (either next driver update or next hardware refresh).