On Di, 02.10.18 07:26, Justin Forbes (jmforbes(a)linuxtx.org) wrote:
> What is new is that GNOME (g-s-d) now uses it be default
> by choosing suspend-then-hibernate as suspend action when
> hibernation is available.
Right, so systemd really is just proxying, and Gnome is now creating a
policy. It does not change the underlying issue, we shouldn't cripple
a mechanism because someone wants to introduce a new undesirable
Uh, the mechanism is already "crippled", I mean, that's the key of the
issue: the hibernation mechanism apparently doesn't have the quality
and does not receive the love it needs for the Fedora community to
support it properly.
There is a difference between a "policy default to off",
off the mechanism". I would expect a new policy defaulting to off
would actually default to whatever is currently there. When a user
upgrades from F28 to F30, it seems wrong that their power
configuration would change in a way that is unexpected, and frankly
more difficult to manage. A regular user can run gnome-tweaks and
decide on lid behavior. A regular user cannot edit the kernel command
line once a system is booted. Now, it requires root. And we are
making it harder for people to edit it as a system boots with other
So let me ask then: is it the Fedora kernel team's intention to
support hibernation well enough that it can work for "regular users"?
With the above you suggest the code quality and will to support is
good enough for "regular users" to be exposed to it.
It was my assumption that everybody agreed that precisely that was not
the case and that hibernation is at best a "tech preview" that only
users who know what they do should enable, i.e. those which know how
to edit the kernel cmdline...
I don't agree that the way we have been doing this is sub-optimal
all. In fact, I think this proposed patch is the sub-optimal way. My
point is, new features, particularly with possible undesirable
results, are often defaulted to off under a "tech preview" model. The
mechanism in the kernel is not new. it may not work for everyone, but
it has been working fairly well for those who it does work for. Why
would we change them when a piece of userspace (that some of them
might never even use) wants to create a poor default policy?
Can you give examples of other kernel subsystems that are also
advertised as available by the Fedora kernel, and part of the core
kernel RPM but are of this "tech preview" kind?
It really is simple. You don't cripple a mechanism so that you
install a bad default policy. The kernel is providing a plain and
neutral mechanism here. If people agree that the default policy is
Well, it's not a "neutral mechanism" if you don't intend to properly
support it and if you know it's known to be buggy, and you apparently
suggest that people not use it?
Lennart Poettering, Red Hat