Quotes of the week [LWN.net]

We know bug reports come from everyone, there is no such thing as "bug free software", and none of us are claiming it. What we are claiming is that you should stick to the tree that is tested by as many people as possible the closest (i.e. mainline) as that gets you the most bug fixes, as well as the ability to use the kernel community to help you out when you have problems. Otherwise you are on your own with your 2.5million lines added franken-kernel that no one will touch if they have a choice not to.

— Greg Kroah-Hartman

Simply repeating "upstream first" over and over again and telling people that doing anything else is just silly isn't really helping move things forward. People have heard this but for a good chunk of the industry there's a big gap between that simple statement and something that can be practically acted on in any sort of direct fashion, it can easily just come over as dismissive and hostile. It's going to be much more productive to acknowledge the realities people are dealing with and talk about how people can improve their engagement with upstream, make the situation better and close the gaps.

— Mark Brown

When someone says "pretty simple" regarding cryptography, it's often neither pretty nor simple.

— Alex Elsayed

The point is, I suspect that the block layer community is all about throughput and the talk about latency and interactivity is seen as an annoying distraction.

Like the kids making noise about doing detours for catching Pokémons in the back seat of the car while you're in the driving seat, driving to some percieved important destination. If you see what I mean. Their problems is not really your problem, so you don't care much. It will be more "yeah yeah, we'll see about your Pokémons. Someday."

— Linus Walleij

to post comments

Quotes of the week

Posted Sep 22, 2016 12:02 UTC (Thu) by spender (guest, #23067) [Link]

Greg keeps repeating this lie by omission that the latest "stable" upstream kernels get you the most bug fixes, suggesting they have the least number of bugs, and therefore the latest upstream kernel must be the most stable and secure release. Anyone doing kernel development and backporting work, specifically to older kernels as well as the latest as Greg is (and we have been for over a decade), surely must know that isn't the case. He's seen doing this as well on security mailing lists, making sure to point out every rare time where a stable kernel picks up an important security fix that a distro did not, nevermind that it pales in comparison to the number of times a distro is able to report that a newly introduced vulnerability doesn't affect their kernels. There's no such thing as a free lunch -- you get bug fixes and also the largest amount of newly introduced bugs and regressions. As Mark Brown notes, handwaving facts and reality away doesn't help anyone.

I blame the poor methodology in articles like https://lwn.net/Articles/410606/ for perpetuating and validating this myth. Distros do the brunt of CVE requesting, so it's no surprise that they'd generally only be requesting CVEs for issues that affect kernels they ship (as I already noted here: https://lwn.net/Articles/410674/). Even a simple automated process of reporting the difference in versions between a fixes: tag on commits with specific keywords would paint a very different picture. I would suggest not to focus specifically on commits with stable cc'd as many still fall through the cracks and it leaves out the entirety of the net subsystem, which in my experience is a major source of vulnerabilities, but generally doesn't get recognized as such due to the different handling it receives.

-Brad

The most popular tree

Posted Sep 23, 2016 13:28 UTC (Fri) by epa (subscriber, #39769) [Link] (5 responses)

Surely "the tree that is tested by as many people as possible" would be Android?

The most popular tree

Posted Sep 24, 2016 0:18 UTC (Sat) by giraffedata (guest, #1954) [Link]

Surely "the tree that is tested by as many people as possible" would be Android?

Touche.

The most popular tree

Posted Sep 24, 2016 13:37 UTC (Sat) by micka (subscriber, #38720) [Link]

Well, yes, if you include "thoroughly tested in production" :)

The most popular tree

Posted Sep 24, 2016 20:28 UTC (Sat) by flussence (guest, #85566) [Link] (2 responses)

There is no single Android tree — just a twisty maze of SoCs and blobs, all subtly broken.

The most popular tree

Posted Sep 24, 2016 23:06 UTC (Sat) by excors (subscriber, #95769) [Link] (1 responses)

In that case, the tree tested by the most people is probably one of the many Android trees; the second most tested is another Android tree; the third is another; and you have to go a very long way down the list before you reach the latest mainline kernel.

When you're selling tens of millions of a single device model, and many models based on the same or similar SoC, you can afford to get a lot of QA people to hammer buttons on the phone until it crashes, and then users will quickly find the remaining crashers (and hopefully automatic log uploading or customer support will get the bug report to the right place). And once you've done that, you can stick with the same kernel version for years and continually improve its stability. If you rebase the kernel you'll have to start all over again.

(None of this testing will find security bugs, but nobody really cares about security anyway.)

The most popular tree

Posted Sep 25, 2016 9:19 UTC (Sun) by micka (subscriber, #38720) [Link]

> and then users will quickly find the remaining crashers (and hopefully automatic log uploading or customer support will get the bug report to the right place)

But those will not get fixed, for the most of them (because product already sold, already released, we're working on the next one, we don't really care).

> And once you've done that, you can stick with the same kernel version for years

with the bugs mentioned above still there. Oh, we fixed it in the next product, which shares the same kernel from 2009, but we didn't fix it in the previous product.

Quotes of the week

Posted Sep 25, 2016 16:37 UTC (Sun) by ksandstr (guest, #60862) [Link]

The block layer community is all about resting on yesterdecade's laurels and not incorporating throughput measurements into buffer management. You know, Linux used to be the fastest thing around on 4096-core SGI clusters with utilization-limited throughput, infinite memory, and no interactive tasks. Rock ye not the boat.

As for reasons, I'll wager that they simply aren't up to it.