On Friday, the Linux kernel merged a patch series that had been grinding forward since 2020: the complete removal of strncpy() from the kernel tree. In the end, 362 commits from roughly 70 contributors touched hundreds of files — filesystem drivers, networking stacks, architecture support code — replacing the notoriously footgun-prone C function with strscpy(), a safer counterpart that had been available in the kernel since 2019. Kees Cook, the kernel’s security-hardening lead, marked the occasion with a Mastodon post whose understated tone belied the scale: “We can remove strncpy() from the Linux kernel finally!”

The reaction across Hacker News and Phoronix this week has been the expected mix of reverence and nostalgia. Six years. Three hundred sixty patches. No regressions that stuck.

It’s a genuinely impressive piece of systems programming. And it’s also a data point in a much less comfortable conversation that the software industry keeps sidestepping.

The Patch Count Is a Census

Look past the commit log and the numbers tell a second story. Seventy contributors over six years averages to roughly a dozen active people per year working on what was, at base, a mechanical refactor — sed on steroids, with judgment calls about buffer sizes and null-termination semantics sprinkled in. That’s a thin bench for work that touches nearly every subsystem.

And that’s the optimistic read, because those 70 names include maintainers who reviewed and signed off, not just people who wrote patches. The actual cohort of developers who understood the replacement semantics well enough to author non-trivial conversions was smaller. Much smaller.

“Half the people who touched this could retire tomorrow and the other half are already burned out,” one longtime kernel contributor told me in a Signal exchange this week, speaking on condition I not add to their inbox. “We’re celebrating the end of a function and nobody wants to say out loud that the function outlasted most of the people who knew why it was dangerous.”

There’s something there. strncpy has been understood as hazardous since the 1990s. It was formally deprecated in the kernel’s own coding style documentation years before the removal effort began. Nobody was defending it on the merits. The barrier was never whether it should go — it was whether enough people with sufficiently deep, subsystem-specific knowledge existed to make it go without breaking production systems.

The C Knowledge Cliff Isn’t Hypothetical Anymore

For most of the past decade, warnings about the dwindling supply of systems-level C programmers were treated as a bit of a genre exercise — think pieces that reliably appeared between Rust-conf talks, the kind of thing that got retweeted by people whose laptops had never compiled a kernel.

The strncpy purge makes the attrition tangible. This wasn’t a greenfield module written by a funded team with a roadmap. It was the kind of unglamorous, cross-cutting maintenance work that depends entirely on institutional memory distributed across a volunteer-and-corporate-maintainer ecosystem. The kind of work nobody’s startup vests.

And it took six years. Not because the problem was conceptually hard, but because the people qualified to do it on, say, the PowerPC board file or the JFS driver were exactly the people whose attention was constantly being pulled to newer, higher-profile fires. The refactor kept shipping in increments because nobody could do it all at once — the knowledge was too fragmented.

This is the narrowing funnel the industry doesn’t want to reckon with. CS enrollments remain strong, but the fraction of graduates who have written a kernel module, or who can reason about a buffer overflow in C rather than just reach for a memory-safe language, continues to shrink. Rust-in-Linux is a genuinely exciting project, and I’m glad it exists. But Rust is not going to maintain the thirty years of C that already ship in every data center and embedded controller on Earth.

What the Applause Doesn’t Ask

The celebration around the strncpy removal is earned. Cook and the contributors deserve every bit of it. But the applause also serves as a convenient way to not ask the harder question: if removing one bad string function from one codebase required this much sustained, specialized effort, what’s the plan for the next hundred?

The kernel isn’t unique here. Every major C codebase that underpins critical infrastructure — glibc, OpenSSL, the firmware blobs in your router — faces the same demographic math. The people who wrote those codebases are aging out. The people replacing them are fewer, and they’re arriving with a different mental model, one shaped by languages that don’t require you to hold buffer semantics in your head at all times.

None of this is an argument against memory safety. It’s an observation that the transition creates a genuinely awkward intermediate period where the old code must still be maintained by a shrinking set of people, while the safety guarantees of the new code sit on the other side of an FFI boundary that itself requires C expertise to audit. The strncpy purge is a case study in how long that intermediate period lasts and how thinly stretched it leaves the people in it.

The Quiet Metric That Matters

If you want one number to watch, it’s not the patch count. It’s the bus factor — the number of people whose simultaneous departure would render a subsystem unmaintainable. The strncpy removal demonstrated, inadvertently, that for significant swaths of the kernel tree, that number hovers somewhere between one and three.

“I don’t think most people in this industry understand how close to the edge we’re running on maintainer bandwidth,” a security engineer who worked on the conversion effort told me, pausing our conversation to handle a page. “We just removed one function and it felt like a moon landing.”

That’s the real headline from June 2026, hiding in plain sight beneath the commit message. The function is gone. The people who could do this again are not exactly abundant. And most of the institutions that depend on their work have no plan for what comes after them.

Sources