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. Every time I talk to someone about battery life on Linux vs. Windows it turns out they aren't even comparing similar hardware. Or if they are, they're comparing completely dissimilar workloads (e.g. compiling a ton of stuff while it is running Linux, basically using Chrome to look at the internet in Windows). Please note I am not saying you are incorrect. I am simply pointing out that statements like that without quantifiable data do nothing other than spread misconception. > singular regression - which Intel folks have picked up on the > upstream bug I filed and we're doing a back and forth so hopefully > it'll get sorted soon. > > >> >> Of course Apple has fewer hardware-related bugs to deal with. We all >> know the reasons for that. > > The singular reason from which all other stem is that power management > on laptops is a priority to them. And they have the documentation and hardware engineers accessible to them to do it. >>Even if we blocked on suspend, >> realistically, it wouldn't magically prevent hardware-dependent issues >> with suspend. We still wouldn't magically be testing on all hardware, >> or be any more predisposed to block on a suspend issue on a specific >> device even if we happened to find it. Your system-specific regression >> would not be a blocker even if we added suspend in general to the >> release criteria and committed to the development resources necessary >> to fix major issues in it. > > This isn't just about Fedora bringing some things to the table to make > power management better; it's a question whether and how to get > upstream more interested in it, and my reasoning for suggesting they > aren't is when my particular regression came up I was surprised to > learn from the Fedora kernel team that laptops don't get much upstream > testing. If they aren't looking for such regressions, they will not be The models the upstream developers use get testing. They don't go out of their way to test the very large variety of hardware (which implies a variety of firmware, which is important) out there. At LPC last week, I saw a lot of XPS 13 machines, new macbooks (at least 1/2 of which were running OS X), and Thinkpads. Anything outside of that gets into the weeds. > 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. josh _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx
