I spent an afternoon deep in a debugging rabbit hole (kernel logs, mailing list threads, driver regressions) and somewhere in that mess, a thought occurred to me.
Linux carries decades of legacy decisions that nobody can cleanly remove because backwards compatibility is treated as sacred. Old interfaces, old subsystems, old assumptions: they stick around because removing them breaks something, somewhere, for someone. There have been attempts to modernize. systemd, PipeWire, Wayland. But these transitions take years, they're never fully clean, and the fragmentation they leave behind is a constant source of pain.
The root cause is structural: Linux has no single owner. Nobody has the authority to say "this is deprecated, it's gone in 18 months, move on." So bad decisions from 1995 are still partially load-bearing in 2026.
The obvious answer is a clean-break fork, a kernel that says: no legacy baggage, modern interfaces only. But forks fail because they lose contributors. The reason Linux is good is the thousands of engineers from Intel, AMD, Qualcomm, Google, and Red Hat who upstream their work. A fork starts with a handful of people and hardware support collapses.
Unless the fork doesn't have to be isolated from mainline at all.
That's the idea. Here's what actually making it happen would look like.
Step 1: Audit the Legacy
Before anything else, someone has to do the unglamorous work of cataloguing the legacy decisions worth removing: bad abstractions, redundant subsystems, interfaces that exist purely for historical compatibility, architectural patterns that made sense decades ago and actively cause problems now.
This isn't purely a technical task. It requires people who know the kernel deeply enough to distinguish "legacy but harmless" from "legacy and actively harmful." The output is a concrete list: these things stay, these things go, here is why, here is what replaces them.
Without this foundation, the fork has no clear identity. It's just mainline with a different name.
Step 2: Define the New Architecture and Commit to It
Once you know what you're removing, you need a coherent vision of what replaces it. Not a document full of compromises, but an actual architectural position with clear, enforceable rules about how things are done in the fork.
The history of Linux modernization efforts is littered with good ideas that got watered down by consensus-seeking until they were indistinguishable from what they replaced. The fork needs someone with genuine authority to say "no, that violates the architecture" and have that decision hold. This is the hardest step socially. It requires the kind of opinionated, decisive leadership that open source communities structurally resist.
Step 3: Build the Agentic Porting System
Here's what makes the fork viable instead of just idealistic: it doesn't wall itself off from mainline. It stays connected through a smart porting pipeline.
When a fix lands in mainline (a driver update, a security patch, a performance improvement), an agentic system watches the commit, determines whether it's relevant to the fork, adapts it to fit the fork's architecture, and queues it for integration. The fork keeps receiving the work of the entire Linux contributor ecosystem without inheriting the legacy those contributors also maintain in mainline.
Greg Kroah-Hartman's stable kernel tree already does a manual version of this, backporting fixes from mainline to older supported kernels. The missing piece has always been the intelligence layer: a system that understands the semantic intent of a patch, reasons about architectural differences between the two trees, rewrites the patch to fit, and knows when it needs a human — something that doesn't exist yet. That's buildable now in a way it wasn't a few years ago.
Step 4: Build the Integration Tests and Decide Who Owns Them
The porting system is only as trustworthy as the tests that validate its output. Kernel testing is notoriously hard, hardware-in-the-loop testing is expensive, and the surface area is enormous. A test suite comprehensive enough to actually trust the agentic system would likely become a project as large as the kernel itself. That's probably the most underestimated part of this whole idea.
The question of who builds and maintains it is as important as the technical question of how. It can't be purely community-driven or it will have the same coverage gaps that mainline has. It needs dedicated engineering resources, which means institutional backing: a foundation, a consortium of hardware vendors, or a company with a strong enough interest in the fork succeeding to fund the infrastructure.
A companion tool worth building alongside this: something that lets anyone contribute test cases without needing kernel development knowledge. Describe the expected behavior, the hardware scenario, the edge case — the tool handles the translation into actual tests. Widening that contributor pool significantly changes the economics of keeping the suite comprehensive over time.
Without this, the agentic system is flying blind and the fork ships regressions.
Step 5: Ship It and Hold the Line
Every architectural vision eventually meets the reality of people depending on it. The vision either holds or it doesn't. A fork that compromises freely enough eventually becomes indistinguishable from what it was trying to replace.
The work of keeping a vision intact over time is quieter than the work of defining it, but it's just as important. Consistency has to be treated as a feature, not a constraint. That means being comfortable saying no to things that don't fit, and being comfortable saying "not yet" to things that might fit eventually but aren't ready. Architectural integrity isn't a gate that slows things down. It's what makes the whole thing worth building in the first place.
None of this is technically impossible. The hard parts are organizational and economic. It needs people with the resources and the patience to see it through, and the willingness to make unpopular decisions and stand behind them.
The integration test suite is probably the hardest part of this whole thing, not the agentic system. And yes, not all legacy is removable. Some of it is load-bearing compatibility that real hardware depends on. The audit in Step 1 exists precisely for that reason. The goal was never to remove everything, just the stuff that has no business being there anymore.