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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
