[Oneiric-Topic] Simplifying system sleep functions

[Tony Espy]

On 04/21/2011 11:49 AM, Ted Gould wrote:
> On Thu, 2011-04-21 at 11:34 -0400, Tony Espy wrote:
>> On 04/19/2011 08:09 PM, Jason Warner wrote:
>>> Hi Everyone - Sending this on behalf of John Lea, desktop design lead.
>>>
>>> ==============================================
>>>
>>> Currently Ubuntu contains two separate sleep functions, suspend and
>>> hibernate.  This choice confuses users and is a un-necessary
>>> complication to 'sleeping' the computer.  The proposed change is to
>>> combine both 'suspend' and 'hibernate' into a single 'sleep' function.
>>>    When the user presses 'sleep', the computer should both suspend and
>>> hibernate simultaneously.  The computer remains suspended for a set
>>> period of time (e.g. 30min) or until the battery charge falls below a
>>> set level.  At the point the suspend state is discarded, and if  the
>>> user wakes the computer after this point their state is restored from
>>> hibernate.  However if the user wakes the computer before the suspend
>>> state is discarded, the computer is restored from 'suspend' and the
>>> 'hibernate' state is discarded.
>>
>> I'm not a fan of this idea.
>>
>> If suspend works for the vast majority of users, why complicate it by
>> adding a timed "auto-hibernate" to the equation?  As a few folks have
>> pointed out, what if hibernate fails?  What if the BIOS doesn't properly
>> support a wake timer?
>>
>> I'm pretty sure the latter criteria for triggering hibernate ( critical
>> low-battery event while suspended ) already works.  It essentially wakes
>> the system from suspend, the power manager notices the battery is
>> critically low, and invokes a hibernate.  The timed scenario would work
>> in a similar manner, except that after a timer event wakes the system,
>> the power manager would have to have added logic to trigger the hibernate.
>>
>> I'm much more in favor of hiding or even removing hibernate from the UI,
>> as long as it remains an option for "critical low-battery" event for
>> those systems that properly support hibernate.
>
> I think these are all valid cases, but I think that we should support
> this feature.  I think how we should handle this is with a whitelist if
> machines that we know hibernate works on.  We can provide instructions
> on adding your machine to that list if you want.  Otherwise machines
> that get certified by a vendor that cares about Ubuntu could ship their
> machine in that whitelist.

Two words come to mind..."maintenance nightmare".  ;)

After having lived through OEM-hell the last three months dealing with 
ACPI stress testing and hibernate failures on Sandy Bridge machines, the 
idea of maintaining a whitelist of machines that are known to have a 
working hibernate function, doesn't seem very practical to me.

> What I think this does, and I don't believe it's really a bad thing, is
> makes it so there are effectively two Ubuntu experiences.  That which
> you get from installing off of the CD on random hardware, and that which
> you get when you use a hardware vendor that cares about Ubuntu.  I think
> that we need to make the experience the best we can for hardware vendors
> that want to participate in Ubuntu -- and provide reasonable fallback
> for those who don't.

Personally, if we really want to consider this idea, I think we need to 
put cycles into making hibernate work better first ( faster, more user 
feedback, ... ).

Another alternative would be to explore something more radical, along 
the lines of what OS X does, which actually tries to combine hibernate 
and sleep as opposed to running them in a serial fashion as proposed.

/t