5 ms·

If you're a Linux user and you can get S3 support on your laptop's firmware, make sure to check out systemd's suspend-then-hibernate! It gives you the same beha

by pxc 4y ago

If you're a Linux user and you can get S3 support on your laptop's firmware, make sure to check out systemd's suspend-then-hibernate! It gives you the same behavior as macOS, so your laptop will still have good battery capacity if you close it and walk away for a whole week. (It's unlikely to feel like truly 'instant on' unless you're running an open-source UEFI like Coreboot. But S3 resume is still very fast, just a couple seconds at most.) Docs: https://www.freedesktop.org/software/systemd/man/systemd-sleep.conf.html https://www.freedesktop.org/software/systemd/man/systemd-sle... https://www.freedesktop.org/software/systemd/man/systemd-suspend-then-hibernate.service.html https://www.freedesktop.org/software/systemd/man/systemd-sus...

BadBadJellyBean 4y ago
Yes it's awesome. If you just shut the lid for a short time it's instant on if you open it again and if you keep it shut for longer it goes to hibernate. I think that is the perfect compromise. And with new SSDs restore form disk doesn't really take long.
cypress66 4y ago
Back when I sometimes used a laptop, I had that same feature enabled on windows. Is that feature still supported by Microsoft?
- rahimnathwani 4y ago
  Are you talking about hybrid sleep? IIRC that does both hibernate and sleep at the same time, i.e. it writes memory to disk and then goes to sleep. I guess it would feel roughly the same, except: - unnecessary disk writes (for the times you slept only for a short time) - keeps using battery until power runs out (rather than after some interval or at some non-zero battery level)
zozbot234 4y ago
Note that suspend-then-hibernate is badly broken in some systemd versions. It will always wait until the battery is drained to 5% SOC before waking up and trying to hibernate - of course, this can easily fail and lead to lost data, plus a completely drained battery (with the ensuing wear-and-tear on the battery itself). What's especially broken about this is that options intended to set a different behavior for hibernation are ignored, the 5% threshold is effectively made mandatory. Fixes for this issue are apparently ongoing and not yet ready for release. Reference: https://github.com/systemd/systemd/issues/25269 https://github.com/systemd/systemd/issues/25269
- b112 4y ago
  Note that suspend-then-hibernate is badly broken in some systemd versions What?! How could this be??!
- pxc 4y ago
  tl;dr: if you're not on a bleeding edge rolling release, this will probably be fixed before the affected versions hit you. If not, read below for a summary of what happened, a workaround, and a proper fix you can apply as a patch. God that's annoying as hell. Apparently the Systemd dev who added this functionality intended it for a different use case than mine or yours. They revised their implementation to better serve their original purpose without realizing it broke our (mis)use of their feature. For convenience for anyone running a sufficiently bleeding edge distro to have this very latest release already, here's a direct link to a comment with a configuration workaround which restores the old behavior: https://github.com/systemd/systemd/issues/25269#issuecomment-1311583322 https://github.com/systemd/systemd/issues/25269#issuecomment... And here's the PR for the formal fix, which combines the old behavior (new config value name, read carefully) with that new 5% emergency fallback behavior, for folks who want to patch it themselves: https://github.com/systemd/systemd/pull/25374 https://github.com/systemd/systemd/pull/25374 It's not merged yet but maintainers have approved it for merging with a few comments on config value names, so it should be safe to add as a patch.
  - db48x 4y ago
    Man, reading systemd issue #25269 is like pulling teeth. Person A reports that he wants to hibernate after being suspended for 30 minutes, and that it used to work and is now broken. Person B doesn’t understand why, so asks why 30 minutes and not 4 hours? Person A thinks Person B is judging them for their personal preferences, and says that they chose 30 minutes because they like it. Person B then deduces that Person A is an idiot who thinks that the systemd default behavior should be determined Person A’s personal preferences. What Person A really wants is to pull their laptop out in the morning and have it still be at 90% charge instead of 5% (or 0%!) charge. Given no other configuration options, they chose to have it hibernate after 30 minutes. They would not choose to configure the delay to 4 hours because then the battery would be a lower the next morning. Then Person C comes along and tries to correct the misunderstandings by suggesting that there’s no reason why it cannot do both at the same time. Person B is still focused on improving safety, and still sees the configurable time as unsafe (because someone might configure it for longer than their battery can last), and misunderstands Person C. Person C has to return and reexplain, with amplification from Person D, that the default behavior should be to hibernate when the battery is low for safety, but also to hibernate at the expiration of the timer, if the timer fires first. This would satisfy everyone, even the weirdos who want their battery to stay charged when they’re not using their laptop. Person B finally understands and says that would be fine. Elapsed time? 6.5 excruciating days, plus two more days for Person E to push a patch. Then Persons F, G, H, I and J chime in to add their own amplifying explanations, congratulations, thanks, etc. Even I wanted to re–explain it to Person B.
acchow 4y ago
“Same behavior as macOS” minus the instant on…
- pxc 4y ago
  'Instant on' isn't a macOS feature. It's a chipset feature, which is extremely clear when you take a look at an M1 MacBook Pro and an Intel MacBook Pro— both, of course, running macOS— resuming from sleep side-by-side. You can see an example here: https://www.youtube.com/watch?v=wjyrfAK6Ib4 https://www.youtube.com/watch?v=wjyrfAK6Ib4 It's also mediated substantially by firmware, which is apparent if you examine the resume time of an Intel laptop running Coreboot instead of the chipset manufacturer's original firmware: https://www.youtube.com/watch?v=vxNalLoFclU https://www.youtube.com/watch?v=vxNalLoFclU Resume from suspend is at about 06:15, and looks like about half as much time (between 1 and 2 seconds) as the Intel MacBook Pro's resume time in the previous video (2-4 seconds). And strictly speaking, macOS actually turns on kinda slowly compared to other desktop operating systems. It's one of the first things I notice whenever I start spending time on a Mac again! Here's one comparison, for example, on identical hardware: https://www.youtube.com/watch?v=6UXCreX57H8 https://www.youtube.com/watch?v=6UXCreX57H8 And this is still true today in comparable laptops with fast SSDs, even with the Mx chips: https://www.youtube.com/watch?v=xsioUHMxCsw https://www.youtube.com/watch?v=xsioUHMxCsw (And none of that matters relative to what you quoted, because 'sleeping, then hibernating after a bit' is indeed the same behavior, whether your firmware handles the hardware wakeup part of the process quickly or slowly.)

by pxc 4y ago

BadBadJellyBean 4y ago

Yes it's awesome. If you just shut the lid for a short time it's instant on if you open it again and if you keep it shut for longer it goes to hibernate. I think that is the perfect compromise. And with new SSDs restore form disk doesn't really take long.

cypress66 4y ago

Back when I sometimes used a laptop, I had that same feature enabled on windows. Is that feature still supported by Microsoft?

rahimnathwani 4y ago
Are you talking about hybrid sleep? IIRC that does both hibernate and sleep at the same time, i.e. it writes memory to disk and then goes to sleep. I guess it would feel roughly the same, except: - unnecessary disk writes (for the times you slept only for a short time) - keeps using battery until power runs out (rather than after some interval or at some non-zero battery level)

zozbot234 4y ago

Note that suspend-then-hibernate is badly broken in some systemd versions. It will always wait until the battery is drained to 5% SOC before waking up and trying to hibernate - of course, this can easily fail and lead to lost data, plus a completely drained battery (with the ensuing wear-and-tear on the battery itself). What's especially broken about this is that options intended to set a different behavior for hibernation are ignored, the 5% threshold is effectively made mandatory. Fixes for this issue are apparently ongoing and not yet ready for release. Reference: https://github.com/systemd/systemd/issues/25269 https://github.com/systemd/systemd/issues/25269

b112 4y ago
Note that suspend-then-hibernate is badly broken in some systemd versions What?! How could this be??!
pxc 4y ago
tl;dr: if you're not on a bleeding edge rolling release, this will probably be fixed before the affected versions hit you. If not, read below for a summary of what happened, a workaround, and a proper fix you can apply as a patch. God that's annoying as hell. Apparently the Systemd dev who added this functionality intended it for a different use case than mine or yours. They revised their implementation to better serve their original purpose without realizing it broke our (mis)use of their feature. For convenience for anyone running a sufficiently bleeding edge distro to have this very latest release already, here's a direct link to a comment with a configuration workaround which restores the old behavior: https://github.com/systemd/systemd/issues/25269#issuecomment-1311583322 https://github.com/systemd/systemd/issues/25269#issuecomment... And here's the PR for the formal fix, which combines the old behavior (new config value name, read carefully) with that new 5% emergency fallback behavior, for folks who want to patch it themselves: https://github.com/systemd/systemd/pull/25374 https://github.com/systemd/systemd/pull/25374 It's not merged yet but maintainers have approved it for merging with a few comments on config value names, so it should be safe to add as a patch.
- db48x 4y ago
  Man, reading systemd issue #25269 is like pulling teeth. Person A reports that he wants to hibernate after being suspended for 30 minutes, and that it used to work and is now broken. Person B doesn’t understand why, so asks why 30 minutes and not 4 hours? Person A thinks Person B is judging them for their personal preferences, and says that they chose 30 minutes because they like it. Person B then deduces that Person A is an idiot who thinks that the systemd default behavior should be determined Person A’s personal preferences. What Person A really wants is to pull their laptop out in the morning and have it still be at 90% charge instead of 5% (or 0%!) charge. Given no other configuration options, they chose to have it hibernate after 30 minutes. They would not choose to configure the delay to 4 hours because then the battery would be a lower the next morning. Then Person C comes along and tries to correct the misunderstandings by suggesting that there’s no reason why it cannot do both at the same time. Person B is still focused on improving safety, and still sees the configurable time as unsafe (because someone might configure it for longer than their battery can last), and misunderstands Person C. Person C has to return and reexplain, with amplification from Person D, that the default behavior should be to hibernate when the battery is low for safety, but also to hibernate at the expiration of the timer, if the timer fires first. This would satisfy everyone, even the weirdos who want their battery to stay charged when they’re not using their laptop. Person B finally understands and says that would be fine. Elapsed time? 6.5 excruciating days, plus two more days for Person E to push a patch. Then Persons F, G, H, I and J chime in to add their own amplifying explanations, congratulations, thanks, etc. Even I wanted to re–explain it to Person B.

acchow 4y ago

“Same behavior as macOS” minus the instant on…

pxc 4y ago
'Instant on' isn't a macOS feature. It's a chipset feature, which is extremely clear when you take a look at an M1 MacBook Pro and an Intel MacBook Pro— both, of course, running macOS— resuming from sleep side-by-side. You can see an example here: https://www.youtube.com/watch?v=wjyrfAK6Ib4 https://www.youtube.com/watch?v=wjyrfAK6Ib4 It's also mediated substantially by firmware, which is apparent if you examine the resume time of an Intel laptop running Coreboot instead of the chipset manufacturer's original firmware: https://www.youtube.com/watch?v=vxNalLoFclU https://www.youtube.com/watch?v=vxNalLoFclU Resume from suspend is at about 06:15, and looks like about half as much time (between 1 and 2 seconds) as the Intel MacBook Pro's resume time in the previous video (2-4 seconds). And strictly speaking, macOS actually turns on kinda slowly compared to other desktop operating systems. It's one of the first things I notice whenever I start spending time on a Mac again! Here's one comparison, for example, on identical hardware: https://www.youtube.com/watch?v=6UXCreX57H8 https://www.youtube.com/watch?v=6UXCreX57H8 And this is still true today in comparable laptops with fast SSDs, even with the Mx chips: https://www.youtube.com/watch?v=xsioUHMxCsw https://www.youtube.com/watch?v=xsioUHMxCsw (And none of that matters relative to what you quoted, because 'sleeping, then hibernating after a bit' is indeed the same behavior, whether your firmware handles the hardware wakeup part of the process quickly or slowly.)