The Pneumatic Bakery (or, Why Microkernels are Still Dead)

Imagine you are hired to run a commercial bakery that produces 100,000 loaves of bread a day. The very first thing you do is take the finely milled flour, the giant industrial vats of gooey sourdough starter, and the massive walk-in ovens, and you put them in three completely separate, hermetically sealed warehouses scattered across town. To bake a single loaf of bread, a worker in the mixing warehouse has to stuff a measuring cup of flour into a brass pneumatic tube, shoot it over to the fermentation warehouse, wait for a stamped, notarized receipt to come back through the tube, and stand around doing absolutely jack squat while the oven slowly cools down in the third warehouse. Meanwhile, the delivery trucks are idling outside, burning through expensive diesel, and your customers are banging on the glass storefront wondering why it takes three hours to buy a single bagel.

Nobody in their right mind would build a factory this way. The physical overhead destroys the throughput. Your bakery would go bankrupt by Tuesday morning.

If you were to draw a side-by-side comparison of this disaster, on the left, you would have a chaotic kitchen where a chef just grabs flour directly off the counter the millisecond he needs it. On the right, you would have a guy furiously stuffing flour into a complex, multi-warehouse pneumatic tube network, staring blankly at a wall while he waits for a delivery confirmation.

We do exactly this in software engineering. We map Inter-Process Communication (IPC), CPU cache invalidation, and context switches 1:1 to isolated workers standing around a factory doing nothing while waiting for a single cup of flour to travel through a tube.

And yet, there is a very specific, deeply stubborn strain of amnesia that infects fresh computer science graduates roughly every fifteen years. They look at a sprawling, monolithic kernel like Linux, vomit a little in their mouths at the sheer, duct-taped ugliness of millions of lines of C code freely touching whatever memory they want, and decide they are going to resurrect the pure, pristine, academic beauty of the microkernel.

This is the original, unkillable siren song of the Architecture Astronaut.

I was reading a blog post arguing we should revisit microkernels yesterday. The core premise is incredibly familiar, echoing through the hallowed halls of academia since the late eighties: modern hardware is just so blindingly fast now that the old performance penalties simply do not matter anymore, meaning we can finally isolate our device drivers from our file systems and live in modular, crash-proof harmony.

Hardware is magical now, so we can finally have perfectly clean abstraction boundaries, right?

Wrong.

(Attention, seL4 microkernel bigots: Yes, I know your formally verified darling got fastpath IPC down to roughly 200 cycles on ARM processors. We are building general-purpose desktop operating systems here, not smartcards or toasters or missile guidance chips. Take your shiny theoretical toys back to the embedded systems lab and let the grown-ups talk.)

The fundamental problem with the modern-hardware argument is that it treats computer architecture like a frictionless vacuum where math somehow ceases to exist just because your clock speed went up. The theorists assume that because we have gigahertz processors and NVMe drives, we can afford to pay a little bureaucratic overhead to keep our code separated into neat, logically sound little boxes. But hardware wizardry cannot cheat physics. If you want to see exactly how physics violently asserts itself against academic theory, go read the Hacker News critiques on cache invalidation in that thread.

Let's do the math. Which, in English, means looking at exactly what those commenters are pointing out: a processor's L1 cache reference takes roughly 0.5 ns, while a main memory reference takes 100ns. That L1 cache is the chef keeping a handful of flour right on the cutting board. It is instantaneous. It is practically baked into the silicon of the CPU core itself. When your code is running in a single, massive monolithic kernel space, the processor can happily churn through that L1 cache, grabbing exactly what it needs, exactly when it needs it, without asking anyone for permission.

But modern CPUs are incredibly finicky, high-strung racehorses. They only go fast if you keep their feedbag completely full of exactly the right data at all times. The L1 cache is tiny, the L2 cache is slightly less tiny, and grabbing data from main memory is the equivalent of the chef leaving the kitchen, getting in his car, driving to the supermarket, and standing in line at the checkout counter just to buy a single egg.

When you force a context switch for file caches in a microkernel—because some idealist insisted that the file system belongs in its own highly secure, isolated warehouse—you aren't just paying a tiny, predictable toll for the pneumatic tube ride. You are forcefully ripping the CPU away from what it was doing, making it save all its registers, and dumping its short-term memory. You are violently, completely flushing the CPU cache.

You are literally emptying the bakery's entire supply room just to send one pneumatic tube.

By the time the processor context-switches over to the file system process, does its little cryptographically secure handshake, grabs the raw block of data from the disk driver, and context-switches all the way back to the application, the L1 cache is dead and cold. The chef has to walk all the way back to the main memory warehouse to fetch every single spatula, whisk, and bowl he was just using two nanoseconds ago. Multiply that by millions of operations per second, and your blazing fast modern hardware is suddenly trying to harvest an entire field of wheat using a pair of rusty nail clippers.

We already fought this war. Back in 1992, we had the famous 1992 Torvalds vs. Tanenbaum debate, which serves as the historical genesis of the pragmatist versus idealist holy war. Andrew Tanenbaum argued for the elegant, modular microkernel where every component is cordoned off for its own safety, predicting that monolithic kernels were a dinosaur, a massive step backward, a throwback to the bad old days of unmaintainable spaghetti code.

Linus Torvalds, acting as the ultimate, unapologetic duct-tape programmer, was busy actually building something people could use. He argued for a monolithic kernel where everything shares the same massive memory space and the chef just grabs whatever flour he needs right off the kitchen counter without asking for a hall pass. Linus didn't care about theoretical purity. He cared about whether his shiny new 386 processor could compile code fast without freezing up.

Torvalds won. He won because he respected the physical reality of the silicon over the theoretical beauty of the diagram. Today, Linux runs the entire freaking internet, every Android phone in existence, and the global stock exchanges, while Tanenbaum’s beloved MINIX is a historical footnote used to teach undergrads how page tables work.

Even Apple, a company that practically worships clean design and would happily charge you three thousand dollars for a sleeker pneumatic tube, had to abandon the pure Mach microkernel dream. When they were building OS X, they started with Mach, fully intending to build a beautiful, academically pure system. Device drivers were going to live in user space, completely isolated, so that if your printer driver crashed, the rest of the computer wouldn't even blink.

But the user interface kept stuttering. Dragging a window across the screen felt like dragging a grand piano through a swamp. They eventually realized that passing messages back and forth across the user-space boundary—between the window manager, the networking stack, and the file system—was completely destroying their throughput. The constant cache flushing was suffocating the processors.

So they compromised, swallowed their pride, and shipped the messy, duct-taped XNU hybrid architecture. They shoved huge chunks of the OS back into the monolithic kernel space simply to survive the apocalyptic message-passing overhead that comes from isolating everything.

General-purpose computing is inherently, fundamentally messy. You have applications demanding memory, network packets arriving completely out of order, and device drivers behaving like drunken toddlers. You cannot cleanly separate these concerns without paying a massive, physics-mandated tax. Abstraction boundaries never pay for their own overhead. The duct-tape programmers who just dump everything into one big kernel memory space win every single time because they understand that a computer is a physical machine made of sand and copper, not a chalkboard in a computer science lecture hall.

If you are designing a general-purpose operating system in the real world, physics still applies. So stop writing think-pieces about resurrecting Mach, stop trying to shoot your flour across town in a pneumatic tube, just build a messy, monolithic system, and ship the damn product.