On Mon, Aug 1, 2016 at 7:58 PM, Liam <liam.bulkley@xxxxxxxxx> wrote: > > > On Fri, Jul 29, 2016, 12:18 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> >> 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? >> >> >> 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. They're hardware and firmware dependent, they also depend on the style and reputation the DE development team wants to have. I think it's completely reasonable for a team to withhold options that will suck for most of their users. Apple definitely doesn't provide such an option. I don't think Microsoft does either. Apple has a "clamshell" mode with some of their laptops, one of which I happen to have. If power, an external display, and USB keyboard are connected, I can wake a laptop with lid closed (the sleep on lid closing is an immutable policy) and use the laptop while it's closed. The idea is that the laptop all wired up as it is, will be on a flat smooth surface with sufficient cooling, and the external display gets all of the graphics processing and memory (this is a single display mode where the internal display is disabled). > >> >> > 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. OK and they have no options for lid closure policy. You get one. So why are you trusting their decision to withhold and not GNOME? > >> 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. Apple has two or three laptop models at a time, with the rest of what they ship being sub-models that vary on memory, drive, and display size. There are more GPU models shipping per year than entire laptop models Apple ships in a decade. > >> 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. So you're basically saying that sleep is unreliable on your laptop? And therefore you want more power management policy options presented in the GUI, all of which historically have a vastly greater chance of being more unreliable than suspend to RAM? And you want them exposed to all users in some kind of drop down menu? The options sound to me like: should work but might be buggy for some people, shit (poweroff), and more shit (unsupported hibernation)? What toggle am I missing out of this list of bad UI/Ux? If the laptop is suspended and about to run out of power... we're screwed. Why? Because we don't support hibernation, and that'd be a prerequiste to support hybrid sleep. In that case the system can write out a hibernation file, but then do suspend to RAM. If battery power goes critical and the laptop powers off, it can resume from the hibernation file. Apple does this. There are some firmwares that support wake from sleep for the purpose of creating a hibernation file and then powering off, and it sets an NVRAM variable so it knows not to do a normal boot but to suck the hibernation file off a special partition for resume. There are patches for this Intel Rapid Start Tech in the kernel, but Intel has killed it off. So it doesn't really matter anymore going forward. Possibly the better way to handle hibernation would be via GRUB loading the hibernation image rather than having to read a kernel, initramfs, unpack it, just to go discover the hibernation file, read that, and then resume. But that requires a lot more interaction between DE and the bootloader, and crossing project boundaries in free software is its own challenge. Another problem Apple doesn't have. > >> 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. OK well it seems distinctly not reasonable to me to add a pile of superfluous options, most of which increase the chance of data loss or even hardware meltdown, just so you can work around a bug. But maybe I'm not understanding the problem. -- Chris Murphy -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/desktop@xxxxxxxxxxxxxxxxxxxxxxx
