On Thursday, December 5, 2019 8:12:13 PM MST Chris Murphy wrote:
Using the word to be defined in the definition is insufficient and
vague. It's meaningless.
Feature existence is not support. The community members make a thing
supported, and it's only by community effort and prioritization that
features are supported. The track record of hibernation support, such
as it is, is best effort, but not blocking. If it breaks, Fedora ships
with it broken. There are flat out not enough resources to treat it
with any higher priority than this - it's not a new issue either.
Nonetheless, it is "supported" in Fedora. Several of the major Spins, for
example, the KDE Spin, even have a big button for it in the Application
Launcher widget. We don't need for it to be a blocker for it to be supported.
There are far too many things Fedora can do for each one to be a blocker.
The hibernation image is not signed, thus malicious code could be
injected into the image, and loaded and executed upon resume. Contrary
to you merely saying things as if that makes them true, there is in
fact a security issue with hibernation that is incongruent with the
purpose of Secure Boot. It would be no different than allowing
arbitrary loading of unsigned kernel modules, which is also disallowed
by default on Secure Boot systems.
The purpose of Secure Boot is to limit what boots to vendor keys. We've
circumvented that, but that doesn't make it a "Secure" system.
It makes very little sense to disallow loading of unsigned kernel modules, or
resuming from an unsigned swap partition, so long as they're encrypted.
Whoever implemented this, in my opinion, was misguided.
> What are you suggesting the UX is atrocious for? Modifying the
swappiness
> value? I have come across situations where a system without swap OOMs,
> and
> effectively freezes up as a result, causing the user to hard-boot the
> system, but I have never seen that with a system where swap was at least
> 1x the amount of RAM.
The thread I cited contains an example of a consistently reproducible
unprivileged compile that acts like a fork bomb that will take down
the system, including one with swap size = 1x RAM. It reproduces on
baremetal and in a VM. The time to OOM providing some chance of
recovery is *extended* the bigger swap is. Thus the problem is
actually made worse.
That's not a problem. That's the system doing what you've told it. If you
don't want it to do that, put quotas on that user. This is what we do in
enterprise environments, for example.
> It doesn't really make any sense to dismiss this. If
it's deemed necessary
> for there to be a blocker, we can make a new blocker. That's a
> non-issue.
You asked who told me that it's not supported, I referenced you the
thread discussing that point in detail, and yet you're still being
dismissive. You have a hypocrisy problem when you accuse others of
being dismissive, and yet being dismissive of others is your default
position.
That's because it is supported. It works out of box, and several DEs even have
a button for it. I don't know if GNOME does, but the GNOME Spin has always
been a bit special.
The only time it wouldn't work seems to be in one of those special UEFI +
Secure Boot cases.
--
John M. Harris, Jr.
Splentity