On Tue, Oct 02, 2018 at 11:12:44AM -0500, Justin Forbes wrote: > On Tue, Oct 2, 2018 at 10:18 AM, Lennart Poettering > <mzerqung@xxxxxxxxxxx> wrote: > > On Di, 02.10.18 14:34, Hans de Goede (hdegoede@xxxxxxxxxx) wrote: > > > >> Ok fair enough. Keeping it easy for users to try out hibernate is > >> a valid argument. > > > > This is just weird. Why would GNOME expose a button to regular user > > that reads "hey, press me, please use this feature, but it's not going > > to work, and nobody is going to help you with it or fix bugs, > > kthxbye". That's just awful UI. > > > > Quite frankly, this is quite ridiculous. GNOME is not the only user of > > this, we shouldn't expose crap that doesn't work in the UI, regardless > > what the UI looks like. GNOME has every right to assume that what the > > underlying layers advertise works. And when it doesn't then the > > underlying layers should stop advertising this. I have to say I agree with Justin on this. The main reason is that I think hibernate "mostly works", as long as the configuration is correct (resume= is present, swap is not encrypted with an ephemeral key, etc). I'll start a separate thread asking people about their experiences so that we can gather some more anecdata. > If systemd is truly just a proxy for the mechanism, there is no actual > policy there, why would systemd bother filtering it out at all? I have been working on (simple) patches [1] to both improve detection when we should disable hibernation (e.g. resume= is missing) and to make it easy to do this through configuration (set AllowHibernation= in /etc/systemd/sleep.conf). Behaviour of systemd should improve a bit once those are merged. But this argument is convincing for me: before, I wanted to set the policy in systemd rpm, e.g. by setting AllowHibernation=no once that's possible. But it is clear that g-s-d is making the policy choice here, so the policy change should be reverted there. [1] https://github.com/systemd/systemd/pull/10262 Zbyszek _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
