Hi,
it depends on how you look at it. You are looking at it from the point of having the largest fail safety, then yes. However, as I see this, it is mostly about preventing battery drain. i.e. enable users to suspend their machines for a day or two and continue working on battery afterwards.
With this criteria, you get: 1. simple 'suspend': - High battery drain - Fails on power loss + Fast suspend + Fast resume
2. suspend-then-hibernate: + Low battery drain + No failure on power loss + Fast suspend + Fast resume
3. hybrid-suspend: - High battery drain + No failure on power loss - Slow suspend + Fast resume
And with this criteria suspend-then-hibernate clearly wins.
You potentially get some more complications with s2i (suspend to idle) in the future. One could for example leave the WiFi and TCP/IP connections established for a period of time during suspend (but still freeze userspace otherwise).
Benjamin
On Thu, 2018-09-13 at 17:03 -0700, Adam Williamson wrote:
On Thu, 2018-09-13 at 16:55 -0700, Adam Williamson wrote:
On Thu, 2018-09-13 at 16:16 +0200, Benjamin Berg wrote:
Hi,
On Thu, 2018-09-13 at 10:06 -0400, Bastien Nocera wrote:
This needs to be disabled in systemd, as I mentioned in the previous thread. This means it would still work in GNOME if somebody enables the feature in systemd, as would be expected.
Yeah, I agree that disabling it in systemd by default is likely the best way forward for F29. If we can get enough testing, then it may be possible to enable hibernation again for F30.
gsd-power has no configuration option to change the behaviour. It will simply use SuspendThenHibernate rather than Suspend when the method is available.
Continuing the slight tangent from earlier - why was this preferred to hybrid-sleep, given that systemd apparently implements hybrid-sleep? Off the top of my head I can think of only one tiny benefit of suspend- then-hibernate over hybrid-sleep: after 3 hours it doesn't drain the battery at all any more. Is that really a big enough benefit to outweigh the drawback of *always* requiring the slower, much-more- likely-to-fail 'resume-from-hibernation' behaviour after 3 hours or more?
hybrid-sleep would also seem to address the "hibernate *sometimes* works, but not often enough for us to support it or default to it" problem quite nicely...because it only uses hibernation as a last resort, when power is completely drained so resume from sleep is no longer possible. Think about it this way, we have three choices:
- simple 'suspend': always uses the more reliable mechanism *unless*
you lose power, at which point you have DEFINITELY lost your system state
- suspend-then-hibernate: always uses the more reliable mechanism for
three hours, then *ALWAYS* falls back to the less reliable mechanism. Will be substantially more risky than 1) for any case where the system sleeps for more than 3 hours, but retains power. Will only be safer than 1) when the system sleeps for more than 3 hours, then loses power.
- hybrid-sleep: always uses the more reliable mechanism *unless* you
lose power, at which point it gives the less reliable mechanism a shot. If it works, great! If it doesn't, you are no worse off than under 1). 2) has no advantages over 3) either, so far as I can see, except that if you sleep for a really long time and 'hibernate' actually happens to work on your system, maybe you have a little more battery life left when you resume.
I don't see how 3) isn't the winner there, assuming the implementation is good. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...