| ▲ | giamma 2 days ago | ||||||||||||||||||||||||||||||||||
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 2 days ago | parent | next [-] | ||||||||||||||||||||||||||||||||||
> 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. | |||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||
| ▲ | staticassertion 2 days ago | parent | prev [-] | ||||||||||||||||||||||||||||||||||
> 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. | |||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||