On Tue, Oct 2, 2018 at 10:12 AM, Lennart Poettering
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 through
> > 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", and "turning
> 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
> planned changes.
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...
We support it as best we can. We can't fix broken firmware or binary
drivers, but yes, in cases where the kernel itself is at fault, it is
just as supported as anything else we enable. The exception is secure
boot, where it is completely disabled. There has been some talk of
trying to find a solution that will not break the trust model, but I
have not seen any patches there. There is plenty of documentation as
to how to enable hibernation. For people who want that functionality,
I am happy to have them test it. If there is an actual kernel problem
around it, we handle that with about the same priority as an alsa bug
or suspend bug. If it is a non kernel problem, there is nothing we
> I don't agree that the way we have been doing this is
> 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?
You want things that are potentially buggy and can eat data? How long
have we had btrfs enabled now?
Things which are known to not work on a sizeable percentage of
hardware that the driver claims to support? nouveau would top the list
Things which a small subset of users actually care about and usually
work for them, but most people don't care? CAN, various obscure
network protocols, filesystems, we have a ton of them.
I do not think that we should disable any of these by default. One of
the advantages of Fedora is the ability to experiment, develop, test,
or work with things which just cannot be supported under a
contract/SLA type environment.
> It really is simple. You don't cripple a mechanism so that
> 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?
It is known to be buggy on some hardware, and yes, it is a neutral
mechanism. There are plenty of mechanisms in the kernel which can
completely destroy a system with bad policy. We trust userspace to
have a sane policy around them. We tend to not make recommendations
as to what people choose to use on their own systems, but we
absolutely suggest that desktop environments with a large number of
users not write a bad policy around them. Now people are asking to
cripple the mechanism so that Gnome users can default to poor policy.
Why should non gnome users have to change their systems at all to
accommodate a gnome desktop policy?
> Lennart Poettering, Red Hat
> 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: