Re: The logic behind remove "Restart" and hide "Power Off" in User menu.

[William Jon McCann <william jon mccann gmail com>]

Hi,

On Sat, Feb 26, 2011 at 11:39 AM, Gendre Sebastien <korbe romandie com> wrote:
> Le samedi 26 février 2011 à 09:02 +0100, Johannes Schmid a écrit :
>> There is absolutely no information about why suspend is the default
>> apart
>> from telling that this is what happens when you close the lid on a
>> laptop.
>> I think you can argue that it might be a reasonable default for
>> laptops
>> but it is not at all a reasonable default for a desktop PC. And this
>> is
>> not discussed at all in the linked page.
>
> About suspend when close the lid, it's juste a change of logic.
>
> Before, you need to change yourself the parameter depending to the
> situation. In some cases, you need to keep the laptop in activity (ex:
> download files) when you close the lid. But in other cases, it's not
> necessary.
>
> Instead of require a constant change of the parameter like before (in
> Gnome 2.XX), Gnome 3 change it automatcaly. So, by default, Gnome 3
> suspend the laptop when you clode the lid and when a software should not
> be stopped it interrupts the proceedings of standby.
>
> This solution has some advantages. Ex: You start a long transcoding of a
> HD video and you want to go sleep. You just close the lid and go to bed.
> The laptop don't go to standby and continue to transcode. When it
> finish, it turn to standby.

This seems to be a very common misconception of how inhibit works.
The reason I chose the word inhibit was to differentiate it from
"block".  Inhibiting suspend does not block suspend.  An inhibit
informs the system proactively of a certain condition.  For example,
inhibiting idleness doesn't mean the system won't honor an explicit
user request to lock the screen (go idle).  It informs the system that
despite other indications of idleness (lack of mouse and keyboard
activity), there is something still going on (say, watching a video).
This information is used to inform automatic behaviors of the system.
So, in this case, the screen won't lock or power off automatically
while the inhibiting activity exists.

Inhibiting automatic suspend works in a similar way.  It doesn't block
the human initiated request to suspend.  It only informs the system
that automatic suspend shouldn't occur for some specific reason.

So, inhibit is closer to inform than mandate.  And we respect humans
more than apps.  But the nice thing about apps is they don't have any
feelings to hurt (yet).

...
> And the choice to have Suspend but not Power Off in the User menu
> encourages them to waste energy.

I'm usually inclined to ignore claims like this that don't provide any
supporting evidence.  But since you're probably going to keep on
saying it anyway...

Encouraging the use of suspend will very likely result in a dramatic
power savings for many people.  If you only have the options: a)
continue to run at full power b) stop everything you're doing, save
all your work, close all your apps, lose all your state, wait for the
system to power off; you have a problem.  In this case, your selfish
motivations are in opposition to low power consumption.  That's not
going to turn out well.  And no amount of preaching will change that.

What you need is something that doesn't have to make that trade.
Maybe something that doesn't force me to abruptly and jarringly
interrupt my activities and efficiently uses power at the same time.
Do we have such a thing?

It is also worth pointing out that you can't really measure waste in
absolute terms anyway.  Waste is subjective: it means to use
carelessly or without value.  I think it is pretty clear that, for
many, there is value in suspending instead of stopping activities.
So, we're spending a tiny tiny bit of energy here in the suspend case
in order that we may save a tremendous amount of energy in others.
That isn't waste - that is investment.

We'll achieve even more impressive power savings when we enable
suspend on system idleness.  Which for portable systems will result in
much improved battery run times.  There's that win-win again.

Jon