On Thursday, December 5, 2019 6:17:16 PM MST Chris Murphy wrote: > On Thu, Dec 5, 2019 at 4:49 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> > wrote: > > > > > > On Thursday, December 5, 2019 1:40:02 PM MST Chris Murphy wrote: > > > > > Hibernation is out of scope to rely on, let alone make a default, for > > > at least the following reasons: > > > a. It's not sufficiently well supported upstream for regressions that > > > may appear in new kernels, and not supported by the Fedora kernel > > > team. > > > > > > > > I'm not sure who told you this, but that's not the case. Hibernation is > > supported in Fedora. > > > No it isn't. But as I've asked you for your definition of "support" > and you still haven't, and I've offered my own and you haven't > disputed it, I win. That's the short version because you have a track > record of not reading provided references. For the long version: There's nothing to "win". This isn't a competition. We're all on the same side here. My definition of "supported in Fedora" is.. supported in Fedora. You can do it in Fedora. Without modifying anything. In my DE, for example, I'd do that by pressing Alt + F1, the Super key, or click the KDE icon in the left of my primary screen's Panel, Leave -> Hibernate. > > > b. It's disabled by kernel lockdown on UEFI Secure Boot systems. > > > > > > > > How so? What "kernel lockdown" are you referring to? > > > [ 1.097121] Lockdown: swapper/0: Hibernation is restricted; see man > kernel_lockdown.7 > > And also the above kernel list email thread mentions it also. I'm > surprised you haven't heard of it, it's been around for quite a long > time as it's an obvious attack vector that obviates the point of > Secure Boot. I don't have a personal system that uses UEFI, much less "Secure Boot", so I things that affect those systems in Fedora, but not the versions of RHEL I work with, I have no reason to follow normally. I'll take a look, however. "Secure Boot" is a misnomer, by the way, and hibernation is not a security issue. Suspension is, but not hibernation. > > What are you talking about? You should have at least 1x RAM for swap > > whether you use hibernation or not. If you're having issues, you can > > adjust the swappiness as needed. There is no "effective loss of the > > system" involved. ...snip... > In the case where swap is used heavily, rather than incidentally, the > UX is atrocious. The resulting swap thrashing is ai bad the system is > functionally lost and it's completely reasonable for a user to force > power off. 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. > > > d. There's no release criterion. Therefore the project wouldn't block > > > release on any discovered bugs. Serious bugs would likely lead to > > > reverting any use of hibernation by default, and so it's not at all > > > likely it'll become supported by default. > > > > > > > > Blockers are dynamic. We can make new blockers if we need them. > > > There's actual background study and work to be done before a release > criterion is accepted. Saying things doesn't make them true. The > criterion itself needs to be written, test cases produced and sanity > checked, and perhaps most importantly: who will be fixing the blocker > bugs? You need willing people to be available from multiple teams, > each having enough resources to ensure it gets highly escalated fixes. 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. -- 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
