On Fri, Dec 6, 2019 at 7:46 AM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> wrote: > > 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. And now you're using private terminology, and it amounts to denialism and arguing rather than issue progression. It's tedious and makes the conversation as pointless as talking to a wall. >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. And likewise there are minimum expectations of reliability for something to be enabled by default, and hibernation does not qualify. https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/Q5KQC2SZW42I7ABJGXOZNHQLIBLU5DFO/ > > > 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. In the first paragraph you correctly state Secure Boot limits what boots to code that's been signed by Fedora's signing key (or alternatively user keys, if so configured). And in the second you describe a means of thwarting Secure Boot by permitting arbitrary code execution, and advocate for this by default, while also questioning the decision making capacity of others. What does encryption have to do with it? Do you think encryption mimics or is akin to code signing? Does it provide error detection or error correction? If you change a single block of encrypted data do you think upon decryption there's EIO or some kind of warning? > > > > 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. You're making excuses for an unprivileged process fork bombing a default installation. And you're also changing the goal post by blaming the user. The topic, set by you, is the assertion that you've never seen a system freeze up when swap size is at least 1x RAM. I have provided a reproducer that contradicts this. And instead of acknowledging that, either at face value or testing it yourself, you proceed with totally off topic distractions that also blame the user. It's a debate style that is intended to generate more debate without conclusion or progression of the issues, and I consider it intellectually dishonest. > > > 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. More private terminology, as if you think repeating it will make it stick. The difference with my repetition is it's backed by dozens of conversations among various developers and stakeholders in the Fedora community considering it not supported, it isn't me personally asserting a belief or fantasy. It doesn't work out of the box with sufficient consistency or predictability to consider it supported or supportable. You'll find myriad upstream and downstream bug reports about hibernation that languish indefinitely. Some do get fixed. Whether it works depends on make/model, the firmware revision, and kernel version. A common theme in the discussion thread I cite earlier in this email, is corrupt hibernation images on resume. I have two computers that exhibit this behavior. I do not consider that it works out of the box at all. If I take a very selfish point of view about only my experiences I would say it's 100% broken out of the box. But being one to recognize the lay of the land is complex, I don't take only my own experiences to be the way of things, like you are. I'm not dismissive of other people's experiences, as you are. I use an inclusive language: it works for some, it doesn't work for others. It's sufficiently unreliable and unpredictable that it cannot reasonably be considered supported or supportable on Fedora without either a lot more resources, or a white list of hardware. Your style of debate is grating and can be summarized as: 'I am always right and you are always wrong, you should do things my way because you are doing it wrong and everyone doing things differently than I want them is wrong and misguided.' It's annoying. > > The only time it wouldn't work seems to be in one of those special UEFI + > Secure Boot cases. It's not special. It happens to be the default firmware and configuration of most new x86_64 hardware, and the default policy upon installation by Fedora. And that means hibernation is not presently possible by default on those systems. There is no agreement by distributions how to handle hibernation image signing that upstream will accept and Fedora isn't likely to carry out of tree patches for such a thing. -- Chris Murphy _______________________________________________ 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
