On Wed, Sep 12, 2018 at 3:45 PM Matthias Clasen <mclasen@xxxxxxxxxx> wrote:
If it works, why should we make it configurable ? I don't think anybody wants their battery drained...
I'm not omniscient, but I can think of at least a few reasons from the top of my head:
* Hibernation doesn't work well on your hardware, but suspend does. This can mean that hibernate doesn't work at all, or that it fails randomly in 1 out of 10 attempts (my personal experience, some firmware is just lovely).
* You prefer fast wake-up time (or e.g. that you don't need to decrypt your hard drive again) to a longer hibernation resume and you know it won't be long before you're going to wake up the device (e.g. an office laptop, to be woken up each morning).
* You want to prevent people from inadvertently booting OS2 while OS1 is hibernated, because that can easily destroy filesystems (when they are mounted to both). A real world example is Linux+Windows installed on a desktop/laptop with a Windows partition mounted in Linux. If user1 suspends Linux (which later hibernates), a user2 starts the computer and boots into Windows, and then later anyone boots into Linux again (which resumes from hibernation), the Windows filesystem can easily get corrupted. This would not happen if the computer was always just suspended, but can easily happen if the system starts stealthily hibernating later (and you can even disable it).
Don't take me wrong, I think this behavior is great and is a much better default for a general audience. But you asked why would anyone want to configure it, and I believe there are solid use cases and their users shouldn't thrown under the bus. I have at least one colleague who said he really prefers standard suspend over suspend-then-hibernate. There will be users like this.
What corner cases are you thinking of ?
In my original email I wrote "swap partition missing, resume= argument missing". One more can be "swap too small". Maybe systemd can all of it handle well. I'm interested to know whether this has been tested at least in some extent, or whether more QA focus is appreciated here. Since this will affect all Fedora 29 users, we should ensure it will not break spectacularly in common cases.
_______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
