4 ms·

> the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors

> the simple truth of the matter is that regular kernel developers continue to insert bugs at such a rate that there should be little need for malicious actors to add more. Dmitry Vyuko[0] estimated in 2019 that each kernel release contains >20,000 bugs. As an outsider looking in, it seems that the kernel needs a lot more boots on the ground focusing on maintenance. [0] https://www.youtube.com/watch?v=iAfrrNdl2f4 https://www.youtube.com/watch?v=iAfrrNdl2f4 ~0:00-3:30 for statement.

cortesoft 5y ago
20,000 NEW bugs?! Or is it the same 20,000 that keep being brought along every release?
cratermoon 5y ago
I don't know if 20,000 is a large or small number for a codebase the size of the linux kernel. How about bugs per line of code? In Code Complete, Steve McConnell writes "Industry Average: about 15 – 50 errors per 1000 lines of delivered code" As of 2020, there were 27.8 million lines in the kernel git repo. By McConnell's measure, the number of bugs in the kernel is rounding error.
- deleted 5y ago
  [deleted]
exmadscientist 5y ago
> As an outsider looking in, it seems that the kernel needs a lot more boots on the ground focusing on maintenance. Following kernel development a decade ago, that was exactly my opinion as well. Maintenance of older, creakier stuff gets little attention. Adding shiny new buggy features was all the rage. Code and architecture review was spotty at best, and a lot of shiny new things caused damage to old things, but no one cared because the new things were shiny.
hinkley 5y ago
I feel like I've had this conversation at work at least a few times. It's the ratio between new code and maintenance. Can you solve this by adding more maintainers? Yes. Can you solve it by reallocating people to maintenance? Maybe (depends if they decide to quit instead). But you can also flip it and ask if this feature focus is really helping or hurting. The parts of the work that look like 'feature factory' work should be treated as suspect. On some projects that can be half of the new work. We get so consumed trying to figure out if we can do something that we don't stop to think if we should. In a volunteer organization, however, you have to create a certain amount of busy work in order to make sure that new volunteers have stepping stones to becoming bigger contributors. Did this need to be done? No, but we needed a way to get Tom from point A to point C, where we really need his help, and so we had him do B even though it's not really much of a priority.

cortesoft 5y ago

20,000 NEW bugs?! Or is it the same 20,000 that keep being brought along every release?

cratermoon 5y ago

I don't know if 20,000 is a large or small number for a codebase the size of the linux kernel. How about bugs per line of code? In Code Complete, Steve McConnell writes "Industry Average: about 15 – 50 errors per 1000 lines of delivered code" As of 2020, there were 27.8 million lines in the kernel git repo. By McConnell's measure, the number of bugs in the kernel is rounding error.

deleted 5y ago
[deleted]

exmadscientist 5y ago

> As an outsider looking in, it seems that the kernel needs a lot more boots on the ground focusing on maintenance. Following kernel development a decade ago, that was exactly my opinion as well. Maintenance of older, creakier stuff gets little attention. Adding shiny new buggy features was all the rage. Code and architecture review was spotty at best, and a lot of shiny new things caused damage to old things, but no one cared because the new things were shiny.

hinkley 5y ago

I feel like I've had this conversation at work at least a few times. It's the ratio between new code and maintenance. Can you solve this by adding more maintainers? Yes. Can you solve it by reallocating people to maintenance? Maybe (depends if they decide to quit instead). But you can also flip it and ask if this feature focus is really helping or hurting. The parts of the work that look like 'feature factory' work should be treated as suspect. On some projects that can be half of the new work. We get so consumed trying to figure out if we can do something that we don't stop to think if we should. In a volunteer organization, however, you have to create a certain amount of busy work in order to make sure that new volunteers have stepping stones to becoming bigger contributors. Did this need to be done? No, but we needed a way to get Tom from point A to point C, where we really need his help, and so we had him do B even though it's not really much of a priority.