Kernel bugs hide for 2 years on average. Some hide for 20
Long‑lived bugs are common, not unique to Linux
- Commenters note that multi‑year bugs exist in all large systems (Firefox, Windows, CSP in browsers, etc.).
- The kernel study is seen less as an indictment of Linux and more as a useful lens on where bugs cluster and how to prioritize review.
- Deep bugs often require rare timing or usage patterns, so they survive until some new workload or stress mode exposes them.
Monolithic vs microkernel design
- Several argue that millions of lines in supervisor mode mean a single kernel bug can compromise everything, and that modern systems should move toward microkernels (e.g., seL4/Genode).
- Others push back: microkernels help with crash isolation, but compromise of a critical userspace driver (USB, GPU, FS, network) can still lead to total system compromise.
- There’s debate over NT, Mach, XNU: early NT and L4‑style kernels are praised; Mach called inefficient; XNU described as having “microkernel aspects” largely eroded over time.
Windows, NTFS, and filesystems
- Some praise NT as a solid kernel but complain about Windows userland.
- NTFS is defended as “strict but powerful,” with strong guarantees (locking, sharing modes, write ordering, delete‑on‑close, network coherency), contrasted with POSIX’s looser semantics.
- Others counter that these strict semantics can cause their own pain and that Linux’s VFS + ext4 behavior is practically stronger than bare POSIX.
Open source vs binaries and AI models
- One thread compares closed‑source binaries to “open weights” AI models.
- Several insist that “open source” rightly implies human‑readable, maintainable source, not just a reverse‑engineerable binary.
Rust, memory safety, and kernel bugs
- Many anticipate “rewrite it in Rust” claims; others mock that reflex.
- Consensus: Rust is excellent for eliminating memory‑safety bugs but cannot prevent all logic errors, spec misunderstandings, or subtle concurrency and DMA issues.
- Others emphasize Rust’s richer type system, RAII, typestate, and lock APIs as powerful tools for modeling state machines and avoiding certain logic and concurrency bugs.
- There’s disagreement over how much Rust reduces logic bugs vs merely changing their mix, and whether unsafe Rust is actually harder than C/C++.
Bug data, sampling, and bias
- The dataset only covers fixes tagged with “Fixes:”, ~28% of fix commits. Some see this as a major limitation; others say 28% is a very large sample if not biased.
- Commenters point out systemic biases:
- Unused or rarely used subsystems (e.g., CAN) naturally have long‑lived bugs.
- Code that gets refactored more often will “clear” embedded bugs without ever identifying them.
- Heavy‑use subsystems and high‑impact areas draw more testing and faster fixes.
Severity vs lifetime
- Debate on whether long‑lived bugs imply low severity.
- One side: if a bug sits unnoticed for years, perhaps it rarely matters in practice.
- Others: many severe vulnerabilities (use‑after‑free, races) lurk for years precisely because they rarely crash; they’re exploitable but not accidentally triggered.
- The race‑condition median lifetime being much longer than null derefs is seen as intuitive: timing‑sensitive bugs are harder to trigger, detect, and reproduce.
Concurrency and the difficulty of “correct” code
- Several comments stress that writing correct multithreaded code on modern hardware is inherently hard, regardless of language.
- Tooling (static analyzers, valgrind‑like tools, formal methods) can surface decade‑old bugs even in code written by large, expert teams.
- Some see cooperative multitasking and constrained concurrency models as a practical way to avoid many classes of subtle bugs.
Security projects and ecosystem dynamics
- grsecurity is mentioned as an example of long‑standing, non‑upstreamed hardening work; their patches have often pre‑empted bugs that get rediscovered years later.
- There’s friction between the desire to upstream mitigations and the effort/hostility perceived in the mainline process, plus grsecurity’s business model.
Article UX and workflow comments
- Readers complain about non‑clickable commit hashes and odd styling that looks like links.
- Some want the analysis pipeline used for proactive bug‑finding on current commits, not just retrospective statistics.
- Others highlight that many users and vendors are on very old kernels with backports, so “bug age” is also shaped by deployment lag, not just code quality.