On Friday, December 6, 2019 11:22:34 AM MST Chris Murphy wrote: > 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. If anything, you're the one with a weird definition of the term. It's supported in Fedora. It's there. Out of box. It seems it's not supported on a specific configuration, from what you've provided, but it's supported on the vast majority of systems, where that specific configuration is not in use. > 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/ And yet, it's enabled by default. > 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). No, I describe it as relying on vendor keys. This is a fundamental flaw in Secure Boot. > 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. Bypassing a flawed system, which was originally designed to limit the operating systems that could be installed on hardware. Please do not forget the history of "Secure Boot", or it's original intentions. > 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? If the swap partition is encrypted, it's not possible to modify it in a manner that would compromise security, only in a manner which would make the data invalid, and only if using `discard` for that luks container. > 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. If the user chooses to run something, that's up to them. I've given you the solution. > 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. That's simply not the case. I explained that what you provided is easily mitigated, with proper configuration. It is a non-issue. > 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. Again, a solution to the problem was provided. If you have an issue with it, we can discuss that off-list, or in a new thread specific to that issue. A more relevant mailing list for that would be fedora-users, where users commonly ask for assistance with configuration. > > 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. What are you suggesting is "private terminology", other than "GNOME Spin"? You know that I'm referring to what others call "Workstation", which is a misnomer in my opinion. It's simply false to say that hibernation is not supported. Not only is it supported, there's a big button for it in the major DEs. I have not tested GNOME, but I'd be willing to be it's there, unless something has changed with the shutdown menu since the version of GNOME 3 used in RHEL 7. Please do let me know if GNOME is missing that button in Fedora, so that I may open a feature request on behalf of GNOME users in Fedora. > 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. See above. It works out of box. I will take that further to say that it works consistently, so long as you don't select a different kernel image to resume. On some hardware, you would be correct that hibernation does not work, but that is not the case with most systems, and is irrelevant of the degree to which Fedora supports it, which is that the option is available for use in the major DEs and on the command line. > 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. I make no claims as to the reliability of hibernation, I cannot test that on all hardware. I make no claims to ones ability to even run the Linux kernel on all hardware. I don't have enough hardware to test support on a wide variety of systems, and I would not claim that it works or does not work based solely on the systems that I have available. > 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. Well, hold on. I don't either, but I also don't claim that something which is clearly supported is not, simply because there is not a release blocker for it, an arbitrary criterion. It is supported in Fedora, and that's the extent of it. As Fedora contributors, we cannot possibly test all hardware configurations, and to create a whitelist of hardware to allow hibernation on would be absurd. Perhaps a blacklist, based on user reports, but that's all I could suggest there. > 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.' I make no claims at being right. You may notice that, in other threads, and at certain points in this thread, I have learned something about a part of the stack that I don't work with, like UEFI + Secure Boot specific kernel limitations. You were the one that brought that to my attention, which has led to my writing a note to open a bug report. Unless I have a solution in mind, or the suggestion of somebody else would break either my workflow or the workflow of the users I support, or I view it as a breaking change for Fedora's silent majority userbase, I generally don't like to pipe in on these things, because people often see those taking issue with their suggestions as hostile. That seems to be the case here. I intend no hostility, I'm just trying to suggest a better way, that doesn't needlessly break things. > > 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. That is simply not the case. While most new consumer x86_64 hardware comes with UEFI on by default, unless it came with Windows installed, Secure Boot is normally disabled. As for "default policy upon installation by Fedora", what the GNOME Spin chooses to do is not the same as what Fedora as a whole does. > And that means hibernation is not presently possible by default on those > systems. Simply because somebody decided to disable the feature, as a "security" measure. > 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. There's no need to sign the hibernation image to begin with. That is an arbitrary requirement that has been thrown in for absolutely no reason that I can think of. You're not booting from the hibernation image. It doesn't need to be signed to comply with the absurd requirements of "Secure Boot". -- 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
