Summary
A few months after Linus Torvalds released the first version of Linux, he found himself arguing publicly with someone whose work had helped shape the project in the first place. If you’re fuzzy on the terminology, what the Linux kernel actually does is central to the argument that followed because Torvalds and Andrew Tanenbaum fundamentally disagreed over how that core of an operating system should be designed. Tanenbaum was a respected computer science professor, the creator of MINIX, and the author of a widely used textbook on operating system design. Torvalds had used MINIX himself, and the story of how he created Linux and why it became free software is closely tied to the Unix-like systems and development tools already around him. The MINIX newsgroup was also one of the places where early Linux development took shape. Then, on January 29, 1992, Tanenbaum posted a message to comp.os.minix with a subject line that made his opinion pretty clear. The post that called Linux obsolete “Writing a monolithic kernel in 1991 is a giant step back into the 1970s” The message came with a wonderfully blunt title, “LINUX is obsolete.” Tanenbaum’s case focused heavily on how Linux was put together. Linux used a monolithic kernel, where major pieces such as memory management, filesystems, networking, and device drivers largely ran together inside the kernel. MINIX followed the microkernel school of thought, keeping the kernel itself much smaller and moving more services into separate processes that communicated with one another. Tanenbaum had a clear preference for that design. He saw microkernels as a cleaner, more dependable foundation for operating systems that would have to survive changing hardware and growing complexity, and he was confident enough to write that “the debate is essentially over” and “microkernels have won.” His concerns also reached beyond kernel architecture. Linux had been built specifically around Intel’s 386 processor, and Torvalds was happy to use hardware-specific features whenever they were useful. Tanenbaum saw that as a risky bet because RISC processors were gaining momentum, and an operating system closely entangled with one processor family could become a headache once the hardware world moved on. In 1992, that concern was pretty easy to take seriously. Linux was still young, supported a narrow slice of hardware, and hadn’t yet developed the portability that would later become one of its defining strengths. Tanenbaum argued that anyone waiting for a modern free Unix-like system would be better off putting their faith in a portable microkernel project, with GNU representing one of the more promising directions at the time. Torvalds had one advantage Tanenbaum couldn’t dismiss Linux already worked Torvalds replied about eleven hours later, and he didn’t try to pretend Linux represented some grand triumph of operating system theory. Well, with a subject like this, I’m afraid I’ll have to reply. Apologies to minix-users who have heard enough about linux anyway. I’d like to be able to just “ignore the bait”, but … Time for some serious flamefesting! GNU’s operating system effort still didn’t have a usable kernel, while Linux could already be downloaded, compiled, modified, broken, patched, and improved by anyone willing to dig in. The history of GNU’s tools ending up around Torvalds’ kernel also explains why Linux is sometimes called GNU/Linux, even though most people call the finished operating systems Linux today. Torvalds boiled that advantage down to a line that has aged remarkably well: Linux “wins heavily on points of being available now.” That availability let Linux gather users and contributors while the architectural debate was still raging. People ran it on real hardware, reported bugs, sent patches, ported software, and steadily widened what the kernel could handle. If the GNU kernel had been ready last spring, I’d not have bothered to even start my project: the fact is that it wasn’t and still isn’t. Linux wins heavily on points of being available now. The discussion on comp.os.minix kept going for days as programmers argued over performance, portability, reliability, and the tradeoffs between monolithic kernels and microkernels. Tanenbaum was thinking several hardware generations ahead and asking how an operating system should hold up as machines and reliability demands changed. At the same time, Torvalds had a kernel people could install that week and start improving themselves. Working code gave Linux room to grow while everyone kept arguing over what the ideal operating system should look like. The 386 problem didn’t stay a problem The hardware-bound kernel learned to travel Tanenbaum’s portability criticism may be the part of the 1992 argument that changed the most since Linux had a few decades to evolve. Early Linux really was tightly tied to the 386, and leaving it that way would’ve made Tanenbaum’s warning look remarkably prescient. Instead, developers spent years prying the kernel loose from the assumptions built around Torvalds’ original machine and carrying it onto hardware that would’ve been hard to imagine when the project began. Linux now supports architectures including ARM, ARM64, PowerPC, RISC-V, IBM’s s390, LoongArch, and x86, among others. Several share very little with the 386 at the center of Tanenbaum’s criticism. Android gives used beyond desktop PCs. It uses the Linux kernel and runs largely on ARM-based hardware, putting Linux inside billions of phones and tablets. The kernel also spread through servers, networking gear, embedded systems, appliances, and an enormous pile of specialized hardware far removed from the desktop PC Torvalds originally had in front of him. Linux also ended up at the opposite end of the computing spectrum, powering every machine on the TOP500 list of the world’s fastest supercomputers since 2017. Portability absolutely mattered, and Linux’s success depended in part on developers spending years grinding through the exact class of problems Tanenbaum had warned about. The kernel’s early dependence on the 386 became one of those limitations the project kept engineering its way out of until the original complaint barely resembled the Linux that exists today. The old argument came back in 2006 One flame war apparently wasn’t enough The 1992 exchange stuck around largely because Usenet left behind such a good paper trail. The posts were archived, quoted, and eventually republished, including in the 1999 book Open Sources, which made the whole argument unusually easy to drag back into circulation. In 2006, Tanenbaum published an article in Computer magazine called “Can We Make Operating Systems Reliable and Secure?” This time, he focused on reliability and security, arguing that isolating operating system components could keep one faulty driver or service from taking the whole system down. That kind of fault containment had always been one of the strongest arguments for microkernel-style designs. People immediately tied the article back to the old Linux debate. Slashdot resurfaced the 1992 exchange, Torvalds jumped in again, and Tanenbaum later published a follow-up of his own. By 2006, Linux had already become a massive success, yet the technical concerns behind Tanenbaum’s position hadn’t evaporated. Microkernels and related designs still offer real advantages in systems where isolation, reliability, and containing failures carry a lot of weight. Linux’s rise settled one part of the argument pretty decisively. Its architecture clearly left plenty of room to grow. The larger debate over how operating systems should be designed never really went away. The “obsolete” kernel ended up almost everywhere The dead-end got crowded The traditional desktop is still the obvious holdout. Windows and macOS continue to dominate there, according to Statcounter, although Linux’s desktop market share has been growing. That gives the whole story a slightly comic twist, since desktop PCs were the environment Linux originally grew out of. GNU’s own kernel project followed the path Tanenbaum considered more promising. The Hurd embraced a microkernel-based design and is one of the stranger examples of an open-source project still unfinished after decades of development. It never became the widely used free Unix-like operating system Linux eventually turned into. Tanenbaum had identified technical weaknesses in Linux, including some that developers spent years fixing. He treated those early weaknesses as a better guide to the project’s future than they turned out to be. Being available turned out to be a powerful advantage Tanenbaum’s 1992 argument still holds up as serious technical reasoning. What aged badly was treating Linux’s early compromises as a useful forecast of how far the project could eventually go. Torvalds had working code and people willing to improve it. As hardware changed, Linux changed with it. That turned out to be plenty.