Prioritizing needed features over cosmetic or QOL changes

Desktop
#1

Two years ago a request was created to incorporate the hibernate option to the “power off / Log out” menu. This shutdown option, which is present under…

image
image588×571 36.9 KB

is not listed as a viable power option. There are extensions that allow to bring it back but these are prone to breaking after each update. Then again, we are talking about a feature which is already present somewhere else in the same platform, so why not just have it officially listed there.

The ticket has no assignee and no information that would indicate how a request such as issue 4392 would be prioritized over it.

Is there a way the community can influence what items make it to the next sprint?

1 Like
#2

GNOME is not a company: there are no sprints, and you don’t influence the community. You either do the job, or you don’t; and if you don’t, you can still pay somebody to do it.

In this particular case, after reading the issues, I think you are missing the point that the GNOME Shell maintainer has explained to you: hibernation does not work reliably. This is the opinion of the Linux kernel and system level developers; it can break across kernel versions, there is no attempt being made to support it on multiple classes of hardware, and does not work with security features like Secure Boot. Additionally, it depends on installation details that cannot be controlled by the desktop.

If you managed to make your Power settings show the Hibernate button, then you’re on your own: you’ve already “voided the warranty”, so to speak, as the default for GNOME Settings does not include hibernation.

2 Likes
#3

GNOME is not a company: there are no sprints, and you don’t influence the community. You either do the job, or you don’t; and if you don’t, you can still pay somebody to do it.

While it is not a company, decisions are made (such as in this case, not including a feature). Not because I decide to develop the feature and do a PR it would mean it would be added if the general consensus within the gnome development team is that the feature shouldn’t be present, am I right? Or would it be added if I decided to do a PR with it?

In this particular case, after reading the issues, I think you are missing the point that the GNOME Shell maintainer has explained to you: hibernation does not work reliably. This is the opinion of the Linux kernel and system level developers; it can break across kernel versions, there is no attempt being made to support it on multiple classes of hardware, and does not work with security features like Secure Boot. Additionally, it depends on installation details that cannot be controlled by the desktop.

If hibernate is not working reliably, then why are they still including it? The screenshot I attached shows the hibernate function is present in the latest version of GNOME and I didn’t have to add anything to get it there.

gsettings lists the option under:

org.gnome.settings-daemon.plugins.power power-button-action ‘hibernate’|

image
image1030×608 46.8 KB

If you managed to make your Power settings show the Hibernate button, then you’re on your own: you’ve already “voided the warranty”, so to speak, as the default for GNOME Settings does not include hibernation.

But, this is not the case, GNOME does allow to hibernate if the power button is pressed. What I’m asking for is to have the same option (which they already provide) in the form of a menu.

#4

Nobody can pre-approve a PR before it exists. Any PR needs to get written, tested, reviewed before it can even have a chance at being merged. For a PR of this nature, you would probably have to decide on the devices you are going to support. This can easily get into the thousands of devices. Adding an option is not really very helpful, if those devices haven’t been tested and the option does not work on some hardware.

It may be that this is not the job of an upstream project, you may have to get involved with a distribution that has significant resources for testing and hardware compatibility.

#5

We have a long explanation here about why hibernate should not be exposed to users. It needs a lot of work to meet basic quality expectations before we would reconsider this. And nobody seems to care about doing that work. (If you asked this question 10 years ago, I would have given you the exact same answer, except without the pointer to this explainer doc.)

#6

And fundamentally, the problems here are mostly kernel level issues. GNOME desktop developers do not have the expertise to help with these.

#7

While I do understand the points in the document, I believe users should be empowered, given the choice to having the feature enabled if they know what they are doing (I have UEFI, Secure Boot and TPM2. Hibernation still works for me.). I find the current solution inconsistent and incomplete. On one hand users are told is a bad thing because it doesn’t work for everyone but on the other they are shown the means to achieve the very same thing in another section of GNOME, basically still exposed to users, just more obscure. Similar MS Windows behavior, allowing users to change certain settings from the registry but providing no user interface for them.

You may disagree with this but it is how it feels more organic. If the underlying platform (kernel and systemd), supports it, I believe the graphical interface should still allow for it. If there is an issue with hibernation that needs fixing in the kernel or systemd, then these should be taken care over there and not within the DE. Perhaps enabling it from Settings (similarly to what is currently the case for the power button, as shown in the screenshot).

Power to the user!

#8

By definition, users cannot debug or fix kernel issues, so there is no possible way they can be granted more power in this scenario. If they could, they would be developers.

If your system has secure boot, and it works, then you are probably not using a signed kernel. The distribution is almost always the one who gets the decision on those kernel security policies, not the user. Because again, a user cannot be expected to debug issues with kernel configurations and patches.

#9

Users can debug kernel issues in the same way they can be help debugging GNOME issues. They might not do this on their own but I have seen a fair share of non dev users doing kernel bisects to determine when an issue or regression was introduced. Something explained in plain language at kernel.org.

As the conversation goes, there are no points on why the current state of the code in GNOME allows to hibernate in one section and bans it outright on another.

What’s the logic making it acceptable to hibernate if you are within the settings but not ok if you want to do it from the menu? If users can choose to assign the hibernate action to a button within GNOME settings, they should have the a similar option to assign hibernate to the power menu within settings as well.

Why do users have to yet again resort to extensions to enable a feature which is already present?

If GNOME felt so strong about hibernation, then there wouldn’t be an option for it within gnome-settings-daemon nor GNOME settings. Searching the git repo for “hibernate” would only return comments on why it is not a present feature.

#10

The difference with allowing hibernation as the action to take when you’re out of power is the only alternative is to power off. If we don’t allow hibernate, then you’re going to imminently lose all your data no matter what. With hibernate, there is some chance it might work and you won’t lose all your data. In contrast, offering hibernation as an option on the desktop when we know that it’s not expected to work is a much tougher ask.

Please remember that if hibernation works for you, you’re probably missing either secure boot or kernel lockdown. You also probably have a swap partition, which makes it impossible to maintain desktop responsiveness. So if hibernation does work for you, that’s not actually great.

#11

But this is not debugging. It is only the first step, debugging means also writing the code and actually fixing the issue. I wish more users were able to do that but sadly they cannot.

I cannot speak for other developers but, at least from my observation, GNOME is made up of multiple people who may have differing opinions on what the current state of anything should be, and may feel strongly about different things.

3 Likes
#12

With hibernate, there is some chance it might work and you won’t lose all your data. In contrast, offering hibernation as an option on the desktop when we know that it’s not expected to work is a much tougher ask.

So this is part of the point I’m trying to make. I’m not saying enable hibernation for everyone, just enable it for those that knowing that the setting is available, have activated it already.

Like in my case, I went to Settings and activated the option given by GNOME to use hibernation when the power button is pressed. Since I have already enabled hibernation by using the very methods GNOME provides, what’s the harm of also displaying it for me in the menu?

Please remember that if hibernation works for you, you’re probably missing either secure boot or kernel lockdown. You also probably have a swap partition, which makes it impossible to maintain desktop responsiveness. So if hibernation does work for you, that’s not actually great.

We can let the Kernel and Systemd fellows work on that part, since it is out of the scope of a DE. As long as they support it, I’m willing to use it (for as long as it works in my setup).

#13

Has anyone noticed that if I:

  • Ask to remove hibernation as an option in Settings, I get a negative answer.
  • Ask to add hibernation as an option in the power menu, I also get a negative answer.

What is the GNOME team willing to do about hibernation? It seems it is impossible to get to a resolution that result in a consistent user experience behavior. Isn’t consistency one of the key design principles? I’m not just talking about consistency in the UI but consistency in Interactions and the platform as a whole.

#14

I believe I explained pretty clearly why it’s OK for hibernation to be an option for critical power, but not a normal option the desktop menu.

If you really want us to remove the critical power option, I guess we could do that, to avoid giving any impression that it’s something that would be expected to work. shrug

#15

Oh wow, sorry, that’s what I missed. I’d be in favor of removing that. (It’s only available if systemd reports that hibernation might work.)

#16

For what it’s worth it appears that Google is working on enabling encrypted hibernation support with Secure Boot enabled: [PATCH 00/10] Encrypted Hibernation - Evan Green

2 Likes
#17

Well, if this is in the works, maybe it wouldn’t be a bad idea to wait rather than reverting things again in the future.