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.)
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.
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...
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:
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.
> 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.
My experience is that something like 25% percent of the people who run open source projects are just "like this" and there's nothing you can do about it. If you end up forced to deal with them because there aren't other contributors who can step in, or because they're the BDFL of the project, your best bet is just to move on and/or fork it to do what you need. I have probably half a dozen soft forks I maintain myself because the project leads are impossible to work with for exactly this reason.
This isn't about open source explicitly, to be clear. It's just more obvious and visible when it's happening because there's often 1:1 contact on bug trackers. Likewise, it obviously doesn't excuse shitty entitled behavior from issue reporters, of which there is plenty. I'm only making a comment about what I've observed from developers.
It's a problem where they stare themselves blind on what the ideal rule or code or mechanism should be, not realizing the requirement is something entirely different like "a user should never lose their data".
These people have no idea how to build products and have never read anything on the subject.
This is mostly why I don’t bother trying to fix things is open source projects. IME, people are dramatically less professional (meaning communicating clearly, considering input, etc) then I see at work. The exceptions tend to be projects mostly run by people doing it as their day job for a big company.
If I have a choice between fixing an issue locally vs interacting with a large upstream project - who tend to always have a Person B (someone who isn't equipped to handle the subject but will nontheless form a premature opinion and attack anyone who challenges it), then I ALWAYS fix it locally because it takes more effort to convince Person B. Sometimes they silently fix it in a couple of years later, other times another project comes in and renders their project (and my local fix) obsolete.
Perhaps projects should have policies and codes of conduct that protect them against this type of harmful behavior.
Lol, having a policy against miscommunication is not going to make it less common.
Edit: note also that there were _two_ harmful misunderstandings here: Person B misunderstood Person A, but Person A also misunderstood Person B’s question. A Code of Conduct is not going to help.
A code of conduct might be able to help, but not by banning rudeness or defensiveness. If a code of conduct succeeds as part of as an effort to develop or maintain a generous culture of patience, assuming good faith, thanking others for their work, and gentleness regarding mistakes, that could short-circuit some of these interactions.
Like when B highlights that this change in suspend behavior was not only documented but '6 months of work', it kinda seems like they were defensive or irritated because they felt like their hard work to implement a useful feature was being discounted. If they felt like that work was recognized, they might have been less defensive about defending the original idea for their future and more curious about why the bug reporter wanted the behavior they wanted.
Same thing for Person A; if they had been less inclined to read Person B's question as critical, they might have explained themselves more completely earlier on.
A code of conduct treated as a rulebook to cite against people would definitely not help, but a skilled moderator pointing to a policy that encourages people to slow down, listen, be curious, or to a shared statement of values that makes people feel relaxed and safe, or to something that evokes pride in their shared participation in the project... that could have gotten this resolved more quickly.
Some projects have maintainers/authors whose kindness, deliberateness, or thoughtfulness seems to flow downstream to later contributors as a norm. Something like a code of conduct could serve in part just to encode that explicitly as a community aspiration.
But yeah you can't just say that being confusing, confused, frustrated, or frustrating is g allowed lol
A code of conduct will only prevent certain language from being used but will not change B's perception of the bug report which I assume involves his own code.
How about a communication center of excellence producing weekly communication quality reports? You won’t be able to access the project page until you have read the latest report and answered three quick questions to verify that you have read the report.
I should reword part of this; it’s not like pulling teeth, it’s like _having my own teeth pulled_. I imagine pulling teeth could be pretty cathartic by comparison.
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.
'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:
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:
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:
(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.)
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)
Docs:
https://www.freedesktop.org/software/systemd/man/systemd-sle...
https://www.freedesktop.org/software/systemd/man/systemd-sus...