On Tue, Nov 8, 2016 at 4:45 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Tue, Nov 8, 2016 at 1:14 AM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> On Mon, Nov 7, 2016 at 4:37 PM, Adam Williamson >> <adamwill@xxxxxxxxxxxxxxxxx> wrote: >>> On Mon, 2016-11-07 at 13:30 -0800, Chris Murphy wrote: >>>> A considerable reason why any developer with a laptop would pick >>>> Windows or macOS these days is because power management is so much >>>> better, that it's even considered basic. There is no such thing as a >>>> suspend regression bug on macOS - I've never even heard of such a >>>> thing let alone encountered it. >>> >>> I think you're kind of overselling this because you happened to run >>> into a suspend regression this cycle. I've been suspending two laptops >>> and a desktop (with two displays) for the last, like, six years without >>> significant issues. When I ran into an issue with Rawhide it got fixed >>> pretty fast. It's really not that awful. >> >> In the 4.7 cycle a bunch of Fedora 24 folks got hit with a hibernation >> regression. I don't know which part you think I'm selling let alone >> over selling. This isn't limited to suspend or hibernation bugs, but >> all sorts of other optimizations to get better battery life. I'm in >> fact not experiencing a battery life problem on this new HP, but on >> the Mac I do, and I know plenty of people who have crummy battery life >> running Fedora compared to Windows. So this isn't just about a > > It would be interesting to know what hardware they have and workloads > they are using that are similar between Linux and Windows. The Fedora > kernel team did some battery life investigations between the two on > identical hardware and found the differences to be negligible. The > biggest finding is that streaming video (hangouts, skype, etc) was > terrible on battery life universally. I'd expect the biggest difference to come from use cases with high idle state. If the CPU or GPU aren't in lower idle states, it'll eat up battery a lot faster. And that's what I see on the Mac, maybe 2.5 hours Fedora and 4.5 hours macOS. Terminal, texteditor, web browser looking at static pages with minimal content, using the same ad blockers in the same build version of FireFox. My suspicion, since top on both OS's shows about the same idleness, is the discrete GPU isn't being turned off when it could be on Fedora, where it is automatically on macOS. Over on the HP, it's the same workloads as the Mac, and I get pretty much the same useful life whether Windows or Fedora - but the sample size for Windows is pretty small due largely to the fact it was blown away in the first week. >> found early on. When they're looking for particular regressions, they >> are found early on. Not rocket science. This responsibility also lies >> with hardware manufacturers, but how can the testing and reporting be >> made easier, as in, more automated? > > Reporting is not the problem. We get tons of reports. It's > recreating the problem, on the workload the user has, on the same > hardware. It's about access and data, not reporting. I don't understand this. Are you saying that the bug report lacks basic system information attachments? It lacks specific problem data collection attachments? Or that there are problems for which the user can't help upstream, upstream must have physical access to the hardware? Every hardware related bug report I've looked at on kernel.org, developers routinely ask users for rather obscure information from the system. The system has this information, but there's nothing that helps automate its collection and attachment to the bug report. The user then has to manually collect what's asked for, and then manually attach it to the bug report. I see a significant minority of bug reports where a developer asks for more information and there's never a response again from the user. This isn't possible with Apple's bug reporter. System information reports are required attachments, and it contains a lot of information including power management states, the power management log, system log, and so on. -- Chris Murphy _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
