[Discuss] With AI, 2, 000 Vulnerabilities per Linux kernel release

[rrose at pobox.com (Randall Rose)]

> Number go down is a mathematical certainty unless new bugs are
> introduced faster than bugs can be identified and fixed.

Yes, it's in the "certainty unless" category.  Identifying something as being 
in the "certainty unless" category doesn't tell you much either way.

Also, to adapt one of Kent's points:

Even if in theory the number of outstanding CVEs will tend toward zero over a 
number of years given continued effort, still, if an OS is at any point known 
to be insecure because the number of CVEs known to attackers *at that moment* 
exceeds what the developers can fix in a reasonable time, there may not be 
enough interest in saving that OS.

Perhaps the future is in formally verified open-source kernels written in Rust
https://dl.acm.org/doi/10.1145/3625275.3625401

(or OSes could be built on the existing formally-verified microkernel, seL4)

On Fri, Sep 4, 2026, at 2:05 PM, Rich Pieri wrote:
> On Fri, 04 Sep 2026 13:08:24 -0400
> "Randall Rose" <rrose at pobox.com> wrote:
>
>> I'm not sure this reasoning is conclusive -- it seems to imply that
>> "number go down" must be true no matter what.  That's as implausible
>> as a doomster's assumption that "number go up" is inevitable.
>
> It's basic arithmetic: Say that there are 2000 bugs in a program. I fix
> 1 bug. Now there are 1999 bugs in this program. This total does not go
> up when a tool identifies a previously undiscovered bug. The total
> number of bugs is still 2000 minus the 1 that I fixed. I just now know
> I have another bug to fix and then it's down to 1998 total bugs.
>
> Number go down is a mathematical certainty unless new bugs are
> introduced faster than bugs can be identified and fixed.
>
> -- 
> \m/ (--) \m/