On Thu, Jul 28, 2016 at 5:48 PM, Liam <liam.bulkley@xxxxxxxxx> wrote: > > > On Wed, Jul 27, 2016 at 7:14 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> > wrote: >> >> On Wed, Jul 27, 2016 at 7:55 AM, Alexander Bisogiannis >> <alexixor@xxxxxxxxx> 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? > 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. Their setups are reliable because their test matrices are tiny compared Windows or even Linux. 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. > 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. 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. -- Chris Murphy -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/desktop@xxxxxxxxxxxxxxxxxxxxxxx
