[giamma]

Is the intention of the author to use the number of years bugs stay "hidden" as a metric of the quality of the kernel codebase or of the performance of the maintainers? I am asking because at some point the articles says "We're getting faster".

IMHO a fact that a bug hides for years can also be indication that such bug had low severity/low priority and therefore that the overall quality is very good. Unless the time represents how long it takes to reproduce and resolve a known bug, but in such case I would not say that "bug hides" in the kernel.

[cogman10]

> IMHO a fact that a bug hides for years can also be indication that such bug had low severity/low priority

Not really true. A lot of very severe bugs have lurked for years and even decades. Heartbleed comes to mind.

The reason these bugs often lurk for so long is because they very often don't cause a panic, which is why they can be really tricky to find.

For example, use after free bugs are really dangerous. However, in most code, it's a pretty safe bet that nothing dangerous happens when use after free is triggered. Especially if the pointer is used shortly after the free and dies shortly after it. In many cases, the erroneous read or write doesn't break something.

The same is true of the race condition problems (which are some of the longest lived bugs). In a lot of cases, you won't know you have a race condition because in many cases the contention on the lock is low so the race isn't exposed. And even when it is, it can be very tricky to reproduce as the race isn't likely to be done the same way twice.

[turtletontine]

> …lurked for years and even decades. Heartbleed comes to mind.

I don’t know much about Heartbleed, but Wikipedia says:

> Heartbleed is a security bug… It was introduced into the software in 2012 and publicly disclosed in April 2014.

Two years doesn’t sound like “years or even decades” to me? But again, I don’t know much about Heartbleed so I may be missing something. It does say it was also patched in 2014, not just discovered then.

[staticassertion]

> IMHO a fact that a bug hides for years can also be indication that such bug had low severity/low priority and therefore that the overall quality is very good.

It doesn't seem to indicate that. It indicates the bug just isn't in tested code or isn't reached often. It could still be a very severe bug.

The issue with longer lived bugs is that someone could have been leveraging it for longer.

[galangalalgol]

Worst case is that it doesn't even cause correctness issues in normal use, only when misused in a way that is unlikely to happen unintentionally.