On Wed, Sep 12, 2018 at 3:45 PM Matthias Clasen <mclasen(a)redhat.com> 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.