The operating system running your servers is built on ideas from 1969: processes, files, a hierarchical file system, a shell and pipes, a single powerful kernel trusted with everything. POSIX, the standard that codified Unix's interfaces, dates from 1988. Linux is a brilliant reimplementation of those ideas, not a departure from them.
That longevity is a testament to how good the ideas were. It's also worth asking whether we've stopped looking for better ones. Most of today's security problems, from kernel exploits to supply-chain attacks to the CrowdStrike outage two weeks ago, trace back in part to one design decision: an enormous amount of code runs with full privileges inside one monolithic kernel.
What a different design looks like
The main alternative has been around almost as long as Unix: the microkernel. Keep only the essentials in the kernel, like scheduling, memory management and message passing between processes, and run everything else, including drivers, file systems and network stacks, as separate, unprivileged processes. A buggy driver crashes and restarts. It doesn't take the machine down.
The other big idea is capability-based security. In Unix, a program runs with all the permissions of its user and can try to open any file or socket. In a capability system, a program can only touch the resources it was explicitly handed a reference to. Least privilege is built into the design, instead of bolted on with SELinux policies.
Who's trying
seL4 is the most remarkable. It's a small microkernel with a formal mathematical proof that its code implements its specification, so whole classes of bugs, including buffer overflows and privilege escalations within the kernel, are proven absent. It runs in military drones, aerospace and other places where failure is unacceptable, and it's governed by the seL4 Foundation, under the Linux Foundation. It's not a desktop or server operating system, but it's proof that a provably correct kernel is achievable.
Google Fuchsia is a capability-based operating system built on its own microkernel, Zircon. It actually shipped, quietly, on Google's Nest Hub smart displays from 2021. But Google scaled the project back in its 2023 layoffs, and it no longer looks like the planned successor to Android or ChromeOS.
Redox OS is a microkernel operating system written in Rust, so the memory-safety bugs that dominate C codebases can't occur in most of its code. It's a small, determined project and fun to try in a VM. It isn't production-ready.
GNU Hurd, the Free Software Foundation's microkernel-based kernel, has been in development since 1990. Debian still publishes an unofficial Hurd port. It's the cautionary tale: elegant design, decades of work, and never quite usable at scale.
Huawei's HarmonyOS NEXT is the newest and possibly the most consequential. Unveiled as a developer beta this June, it drops Android compatibility entirely and runs on Huawei's own microkernel, HongMeng. It isn't open in the way Linux is, and its motivation is as much geopolitical as technical. But it's a real attempt to ship a non-Unix, non-Windows operating system to hundreds of millions of phones.
Why Linux keeps winning anyway
Every challenger runs into the same wall: everything else is built for what already exists. Hardware vendors write Linux drivers. Software is written for POSIX. Engineers know Linux. Cloud images, container runtimes, observability tools and security products all assume it. A technically better kernel with no drivers and no software is a research project.
And Linux keeps absorbing the challengers' best ideas:
- Rust is now accepted in the Linux kernel for new drivers, bringing memory safety to exactly the parts of the kernel most likely to have bugs.
- eBPF lets safe, verified programs run in the kernel, the closest thing to microkernel-style isolation for extensions without rewriting the kernel.
- Namespaces, seccomp and Landlock have brought capability-like confinement to processes, the building blocks of containers and sandboxes.
- Micro-VMs like Firecracker isolate workloads with tiny, purpose-built hypervisors, so a kernel bug in one guest doesn't reach another.
Don't settle for good enough
Linux absorbing good ideas is real progress, but it isn't a reason to stop looking. Retrofitting safety onto a design from 1991 has limits. Every Rust driver still sits beside millions of lines of C in the same address space, and every eBPF program still trusts the kernel underneath it.
The challengers matter because they're where better ideas get proven, and some of them deserve more than curiosity:
- Use them where they fit. seL4 for systems where failure is unacceptable. Micro-VMs and unikernels for isolating untrusted workloads.
- Fund the research. Most of the operating systems work that could replace today's designs runs on tiny teams. A fraction of what the industry spends patching kernel vulnerabilities would go a long way.
- Design for replaceability. Applications that rely on standard interfaces and portable runtimes, rather than every quirk of one kernel, keep the door open for whatever comes next.
- Question the defaults. When something needs kernel privileges, ask why, as the CrowdStrike outage forced everyone to.
Unix and Linux earned their reign. The way to honor that isn't to assume they're the last word. It's to keep building, testing and funding the systems that might do better, and to be ready to use them when they do.
Since then
Added October 2026. Rust in the Linux kernel stopped being an experiment in December 2025, when the kernel's maintainers declared it a permanent part of the project. And Microsoft started moving security software out of the Windows kernel in the wake of CrowdStrike, which is the microkernel argument winning in practice, piece by piece.