On Fri, Jul 29, 2016, 12:18 PM Chris Murphy <lists@colorremedies.com> wrote:
On Thu, Jul 28, 2016 at 5:48 PM, Liam <liam.bulkley@gmail.com> wrote:
>
>
> On Wed, Jul 27, 2016 at 7:14 PM Chris Murphy <lists@colorremedies.com>
> wrote:
>>
>> On Wed, Jul 27, 2016 at 7:55 AM, Alexander Bisogiannis
>> <alexixor@gmail.com> wrote:
>> > On 27/07/16 14:33, Bastien Nocera wrote:
>> >>
>> >> That's nice they make cooking laptops in backpacks a low priority. At
>> >> least
>> >> it's still on IRC!
>> >
>> >
>> > Default behavior should be to suspend.
>> > The problem is removing the option from the user.
>>
>> What other option is there? I'm thinking of handing the user razor
>> blades and telling them to go play on the freeway is not a good idea?
>> Because that's basically what either a poweroff or hibernation option
>> would look like. It's a b.s. option. Both of them require other work
>> before a DE could offer the option while also pretending to care about
>> user data. So if some other DE's are just ignorant of system
>> capability and let the user willfully engage in data loss, well...
>> that's their choice but I can certainly agree with a DE not giving
>> users the option in a GUI to shoot themselves in the foot.
>>
>
> The option to let the user decide what they need in order to get their work
> done.

This is sufficiently vague that I have no idea what you're referring
to. What option?

>> Because that's basically what either a poweroff or hibernation option

The option to decide what actions should be taken upon lid closure, and those actions are context dependent. 


> Apple can get by with not offering, out of the box, some of these tools
> (though, as I've mentioned before, their default desktop is hugely more
> powerful than any linux de in terms of empowering the user) b/c their setups
> are very reliable (and they do user testing).

If we keep the thread on topic, power management, Apple has a distinct
advantage no one else has right now: They create the hardware and the
software. And a big part of power management is also in firmware.

... that's kinda my point. Apple can afford to be, somewhat, stingy with their GUI options (if need be, read "power management options") because you can actually trust their decisions will, likely, with for you.

Their setups are reliable because their test matrices are tiny
compared Windows or even Linux.

I don't believe that's the entirety of it, or, at least, it send to undersell the software problems on OUR end.
Currently, the Linux kernel doesn't do a great job with reliably freezing/saving userspace,  storing hardware state and then moving to a lower power state.

Their control of firmware permits them
to always reliably and quickly do suspend to RAM, and even transition
from suspend to RAM to disk, even when that hibernation file is on an
encrypted volume.

Hmm, now I'm wondering if I responded to the wrong person...
Btw, yes, I agree with that assessment.

> Additionally, if you think that suspend is MUCH more reliable (and,
> considering its use in this case, it better have a 6 9s success rate across
> arbitrary hardware---and I know it's nowhere close to meeting that criteria)
> than poweroff/hibernation, we have unbelievably divergent experiences in
> this area.

If there's a sane way to blacklist hardware that's known to have
suspend problems, I think it's completely reasonable for the DE to do
something like 'sync && poweroff -f' in a critical power situation;
with an option and warning about the black listing if the user chooses
suspend.

Perhaps, but I'm not sure why we we're working so hard just so we can provide a particular experience that is of very arguable worth (even if it worked everytime).
I'm only asking for three toggles: what to do when closing the lid on AC vs battery, and what to do if the laptop is suspended and about to run out of power.
If those options seem to be too much I'll gladly read the user testing that indicates such.

But for now hibernation is really off the table, not least of which
are the kernel team doesn't consider it a priority, it doesn't work
yet with Secure Boot until the encrypted swap patches are available,
and the dracut and installer upstreams sort out whose responsibility
it is to supply the resume=<hibernationfilelocation> hint to the
kernel. Until that all work is done, I think it's reasonable for a DE
to not lie to the user by even presenting hibernation as if it's a
valid option.


No, it's obviously better not to deceive the user. Until hibernation works with secure boot and encrypted swaps I certainly agree it makes sense but to advertise hibernation to THOSE users. To the everyone else, I think exposing hibernation seems reasonable. Similarly, allowing the user to set policy for AC vs battery seems reasonable.


Best/Liam