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:
1) simple 'suspend': always uses the more reliable mechanism *unless*
you lose power, at which point you have DEFINITELY lost your system
state
2) 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.
3) 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(a)lists.fedoraproject.org
To unsubscribe send an email to desktop-leave(a)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...