On Tue, Nov 8, 2016 at 1:14 AM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Mon, Nov 7, 2016 at 4:37 PM, Adam Williamson
<adamwill(a)fedoraproject.org> 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