Guilherme Monteiro · São Paulo, SP

O Linux não é sagrado: MINIX, Tanenbaum e os mitos que sobreviveram a 1992

O debate de 1992 entre Tanenbaum e Torvalds, o código do Linux 0.01 e do MINIX e trinta anos de pesquisa sobre microkernels, para separar o documentado do folclore.

4 de outubro de 202668 min de leitura

Resumo

Em 29 de janeiro de 1992, Andrew S. Tanenbaum, professor da Vrije Universiteit de Amsterdã e autor do MINIX, abriu no grupo comp.os.minix um tópico chamado "LINUX is obsolete". Escreveu que o Linux era "a giant step back into the 1970s" [1]. Trinta e quatro anos depois, o Linux roda em todos os 500 supercomputadores mais rápidos do mundo [2] e é a base do kernel do Android [3]. Seria fácil declarar o professor derrotado e encerrar o assunto. Este artigo volta aos posts originais, ao código do Linux 0.01 e do MINIX 2 e aos papers que mediram bugs, IPC e recuperação de drivers, para separar o documentado do folclore. Quem diz que o Linux é cópia do MINIX erra. Quem trata o Linux como inventor de tudo e olha para o macOS, os BSDs e o Windows com desdém também erra. O Linux venceu pela licença e por chegar na hora certa. Na confiabilidade, o argumento técnico do Tanenbaum continua de pé, o próprio Linux foi absorvendo pedaços dele, e boa parte do que se atribui ao Linux apareceu antes em outros sistemas.

Os mitos que circulam por aí

Uso Linux todo dia, em casa e no trabalho, e trabalho com FreeBSD também. Gosto dos dois. É justamente por isso que me incomoda o tom de seita que a conversa sobre sistemas operacionais costuma tomar. De um lado, aparece o crítico que trata o Linux como uma cópia malfeita do MINIX e jura que o Tanenbaum, que teria sido professor do Linus, o renegou desde o primeiro dia. Do outro, aparece o devoto que acha que o Linux inventou os contêineres, que o macOS é brinquedo de quem não sabe usar terminal, que BSD é coisa de museu e que todo driver do Windows é uma bomba-relógio.

As duas visões têm em comum o desinteresse pelos documentos. E os documentos existem. O debate de 1992 está arquivado palavra por palavra [1], [4]. O código da primeira versão do Linux continua no kernel.org [5]. Tanenbaum escreveu longamente sobre a origem do Linux quando um instituto de Washington acusou Torvalds de plágio em 2004 [6]. As certificações UNIX ficam num registro público da Open Group [7]. A Microsoft documenta como os drivers do Windows rodam [8], e a FreeBSD documenta desde quando existem os jails [9].

Os mitos que este texto checa são estes, cada um com a resposta curta que os fatos dão:

Mito	O que os documentos mostram
"O Linux é cópia do MINIX"	Falso quanto ao código. Torvalds desenvolveu em cima do MINIX, copiou o layout do sistema de arquivos e se inspirou no livro, mas o código é dele, e quem diz isso é o próprio Tanenbaum [6].
"Tanenbaum era professor do Linus"	Falso. Torvalds estudava em Helsinque; Tanenbaum, em Amsterdã, diz que o encontrou uma vez [10], [6].
"Tanenbaum chamou o Linux de retrocesso"	Verdadeiro, em 1992. Na mesma mensagem ele disse que não estava infeliz com o Linux, e em 2004 o defendeu [1], [6].
"Torvalds nunca admitiu nada"	Falso. Ele concordou que microkernels "are nicer" e pediu desculpas em público no dia seguinte [1], [4].
"O Linux venceu por ser tecnicamente superior"	Em boa parte, falso. Os próprios protagonistas atribuem a vitória ao atraso do GNU e ao processo contra o BSD [1], [11], [6].
"O Linux nem é UNIX"	Verdadeiro sobre a marca. Falso se a ideia for que um sistema Linux não consegue passar na certificação: um já passou [12].
"O ABI do Linux vive quebrando"	Falso para programas. Verdadeiro, e de propósito, para drivers dentro do kernel [13].
"Microkernel é lento por natureza"	Exagero. O Mach era lento; em 1993 o L3 já entregava mensagens vinte vezes mais rápido, e o Linux sobre L4 perdia 5% [14], [15].
"O macOS é microkernel porque usa Mach"	Falso. No XNU, Mach e BSD rodam juntos em modo kernel [16], [17].
"O Linux inventou os contêineres"	Falso. O jail do FreeBSD saiu em 2000; a primeira versão dos cgroups entrou no Linux em 2008 [9], [18].
"O Linux não tem nada de microkernel"	Falso. FUSE, UIO, VFIO e os escalonadores em eBPF tiram pedaços do kernel ou os isolam, sem mudar a arquitetura [19], [20], [21].
"Microkernel é sinônimo de seguro"	Exagero. O próprio Tanenbaum escreveu que segurança de nível militar nunca foi objetivo do MINIX [22].

O resto do artigo mostra de onde sai cada linha dessa tabela.

O que era o MINIX

O MINIX nasceu para caber numa sala de aula. Tanenbaum o escreveu para acompanhar o livro Operating Systems: Design and Implementation, de 1987, e o código-fonte era vendido separadamente pela Prentice Hall por US$ 69 [6]. Na discussão de 1992, ele explicou que a limitação era deliberada: "An explicit design goal was to make it run on cheap hardware so students could afford it. In particular, for years it ran on a regular 4.77 MHZ PC with no hard disk" [4]. Na mesma mensagem, disse que a versão para o PC original vendia o dobro da versão para 286/386.

Chamar o MINIX de brinquedo malfeito erra a intenção. O MINIX era pequeno porque o objetivo era ensinar. Mas é verdade que ele não servia como sistema de produção, e Tanenbaum não queria que servisse. Em 2004, ele contou que o comp.os.minix chegou a 40.000 assinantes e que recebia 200 e-mails por dia pedindo recursos, como "I need pseudoterminals and I need them by Friday". A resposta costumava ser "No." O motivo: "everyone was trying to turn MINIX into a production-quality UNIX system and I didn't want it to get so complicated that it would become useless for my purpose, namely, teaching it to students" [6]. Em fevereiro de 1992 ele já dizia a mesma coisa no grupo: tinha recusado memória virtual, paginação, links simbólicos e sistemas de janelas porque queria "keep the system simple enough for students to understand" [4]. Ele achava que esse espaço seria ocupado logo pelo GNU ou pelo BSD de Berkeley.

A licença também pesava. A Prentice Hall queria royalties de quem vendesse o sistema comercialmente, e os advogados encheram o MINIX de "boilerplate", ainda que, segundo Tanenbaum, "there was never any intention of really enforcing this against universities or students" [6]. Em 1992, a cópia custava US$ 169, a licença permitia duas cópias de segurança, e professores podiam fazer cópias ilimitadas para os alunos [4]. Quem melhorava o sistema, porém, só podia distribuir diferenças em relação à versão oficial. Charles Hedrick, da Rutgers, escreveu no mesmo debate que tinha largado a comunidade MINIX porque a licença, "while amazingly friendly", dificultava a vida de quem queria uma versão para 386: "all they could distribute were diffs", o que tornava a instalação inviável para um usuário novo [4]. A liberação completa demorou. Em 7 de abril de 2000, Tanenbaum anunciou no comp.os.minix: "Better late than never. I finally got permission from Prentice Hall to change the MINIX license to the BSD license. The lawyers sort of sat on this for two years" [23]. Nessa altura, o Linux já tinha seis anos de versão 1.0 [24].

Por dentro do MINIX: tudo é mensagem

O código do MINIX 2.0.4, a última versão da série 2, mostra o que Tanenbaum chamava de microkernel. Ele continua disponível em redistribuições não oficiais, como a de David Given [25]. O comentário no topo de kernel/proc.c resume a arquitetura: "The only system calls that exist in MINIX are sending and receiving messages. These are done by trapping to the kernel with an INT instruction" [25]. Na biblioteca para 386, as funções _send, _receive e _sendrec põem o destino e o endereço da mensagem em registradores, indicam a operação e executam int 33 [25].

A mensagem tem tamanho fixo. Em include/minix/type.h, o tipo message é uma união de seis formatos, de mess_1 a mess_6, cada um com uma combinação de inteiros, longs e ponteiros, mais os campos de origem e de tipo [25]. O kernel não aloca buffer nem mantém fila de mensagens. A entrega segue o princípio do encontro (rendezvous): mini_send copia a mensagem direto para o destinatário se ele já estiver bloqueado esperando por ela; caso contrário, quem enviou fica bloqueado numa fila presa ao destinatário até que este chame receive [25]. O mesmo código percorre a cadeia de remetentes bloqueados para detectar dois processos tentando enviar um para o outro, e devolve ELOCKED em vez de deixar o sistema travar.

As permissões já eram mínimas. Processos de usuário só podem usar a operação combinada, que envia e espera a resposta, e só podem falar com dois destinos: "User processes are only allowed to send to FS and MM" [25]. Na prática, um read() vira, dentro da biblioteca, uma mensagem para o sistema de arquivos (FS), e o FS conversa com a tarefa do disco também por mensagem. A tabela de tarefas em kernel/table.c mostra a divisão: TTY, placas de rede DP8390 e RTL8139, Sound Blaster, impressora, controladoras de disco, disquete, memória, relógio e a tarefa de sistema eram tarefas compiladas na imagem do kernel, enquanto o gerenciador de memória (MM), o FS e o INIT eram processos separados [25].

Essa é a régua de 1992. Tanenbaum escreveu no post original que o sistema de arquivos e o gerenciador de memória rodavam como processos separados e que os drivers de I/O também eram processos, "in the kernel, but only because the brain-dead nature of the Intel CPUs makes that difficult to do otherwise" [1]. Os drivers do MINIX 1 e 2 rodavam em modo kernel, como os do Linux. A diferença estava na forma: cada driver era uma tarefa com laço de mensagens própria, e não uma função chamada diretamente.

O desenho tinha um preço que apareceu no debate. Com um único processo FS atendendo um pedido de cada vez, quem lia um disquete lento travava quem queria fazer outra coisa. Richard Tobin, da Universidade de Edimburgo, reclamou: "I find the single-threaded file system a serious pain when using Minix" [4]. Tanenbaum respondeu que "A multithreaded file system is only a performance hack. When there is only one job active, the normal case on a small PC, it buys you nothing" [4]. Para quem ensinava, era detalhe. Para quem usava o sistema todo dia, não era.

Agosto de 1991: um hobby que não copiava código

Em 25 de agosto de 1991, Linus Torvalds, estudante da Universidade de Helsinque, postou no comp.os.minix: "I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones". No mesmo post ele perguntou o que as pessoas gostavam ou não no MINIX, "as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things)". O pós-escrito foi direto: "Yes - it's free of any minix code, and it has a multi-threaded fs. It is NOT protable (uses 386 task switching etc)" [10].

As notas da versão 0.01, de setembro de 1991, repetem a afirmação e explicam a dependência: "Although linux is a complete kernel, and uses no code from minix or other sources, almost none of the support routines have yet been coded. Thus you currently need minix to bootstrap the system" [26]. O Linux nasceu dentro do MINIX, compilado nele e instalado a partir dele. A dependência era de ambiente, não de código.

Jyrki Kuoppala perguntou quanto do sistema era em C e se dava para portá-lo para o Amiga. A resposta de Torvalds, em 26 de agosto, é um retrato honesto do projeto: "Simply, I'd say that porting is impossible. It's mostly in C, but most people wouldn't call what I write C. It uses every conceivable feature of the 386 I could find, as it was also a project to teach me about the 386" [10]. Ele explicou que cada tarefa tinha um segmento de 64 MB, com no máximo 64 tarefas em 4 GB, que alguns arquivos em C eram "almost as much assembler as C" e que o resultado era "a porters nightmare". Kuoppala também pediu sistemas de arquivos em modo usuário. Torvalds achou viável quase toda a lista, "except maybe for the user-mode filesystems" [10]. O pedido seria atendido catorze anos depois, com outro nome.

O que havia dentro do Linux 0.01

O tarball original continua no kernel.org. Os arquivos têm datas entre 15 de junho e 17 de setembro de 1991, a maioria (60) entre 11 e 17 de setembro. Pelas minhas contas, são 88 arquivos, e os fontes em C, os cabeçalhos e o assembly somam 9.877 linhas [5]. A árvore já tem a cara que o kernel manteria por décadas: boot/ com o setor de boot e o código de entrada em modo protegido, kernel/, mm/, fs/, lib/, include/, init/main.c e um utilitário em tools/ que monta a imagem final.

A organização mostra o desenho monolítico desde o primeiro dia. O diretório kernel/ tem 3.511 linhas e guarda o escalonador, o fork, os sinais e também os drivers: hd.c para o disco AT, console.c, serial.c, keyboard.s e tty_io.c [5]. Não há tarefa de driver nem mensagem. O sistema de arquivos chama o driver de disco como quem chama qualquer função. O gerenciamento de memória inteiro cabe em 298 linhas, entre mm/memory.c e mm/page.s, e o sistema de arquivos em 2.771 [5].

A tabela de chamadas de sistema, em include/linux/sys.h, tem 67 entradas, de sys_setup a sys_setsid: a de número 1 é exit, depois vêm fork, read, write, open e close [5]. Nem todas funcionavam. Em kernel/sys.c, 15 delas só devolvem -ENOSYS, entre elas sys_mount, sys_umount, sys_rename, sys_mknod e sys_ptrace [5]. O Linux 0.01 não montava sistemas de arquivos nem renomeava arquivos.

O código também mostra para quem ele foi escrito. O arquivo include/linux/config.h traz duas configurações de disco, LINUS_HD e LASU_HD, com a geometria dos discos de cada máquina e o comentário "Amount of ram memory (in bytes, 640k-1M not discounted). Currently 8Mb" [5]. O dispositivo raiz era fixo no código. A troca de contexto, em include/linux/sched.h, é a macro switch_to, que faz um ljmp para o segmento de estado da tarefa do 386: o "386 task switching" do anúncio, literalmente [5]. O limite de 64 tarefas também está lá (NR_TASKS 64), com o relógio a 100 Hz.

E há as digitais do MINIX, todas de ambiente ou de formato. O Makefile roda chmem +65000 tools/build [5]; chmem é um utilitário do MINIX, escrito por Tanenbaum, que ajusta a memória reservada para um executável [25]. O mesmo Makefile avisa: "If you don't have '-mstring-insns' in your gcc (and nobody but me has :-)" [5]. Em include/linux/fs.h, os números dos dispositivos são "same as minix, so we can use the minix file system", os nomes de arquivo têm no máximo 14 caracteres e o número mágico do superbloco é 0x137F [5], o mesmo SUPER_MAGIC definido no sistema de arquivos do MINIX [25]. Nenhuma dessas marcas é código copiado. Quanto ao estado da versão, o próprio Torvalds, em julho de 1992, escreveu que o código da 0.01 "weren't actually runnable" e que a versão "didn't actually come with any binaries": era um gesto para quem tinha demonstrado interesse [10].

A versão usável foi a 0.02. Em 5 de outubro de 1991, Torvalds anunciou no comp.os.minix, com o assunto "Free minix-like kernel sources for 386-AT": "Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?". O post avisava que "Full kernel source is provided, as no minix code has been used", e também que "These sources still need minix-386 to be compiled" [10]. A frase sobre o Hurd envelheceu como piada: "Hurd will be out in a year (or two, or next month, who knows)".

O sistema de arquivos emprestado

A herança mais concreta é o formato do disco. O artigo de Rémy Card, Theodore Ts'o e Stephen Tweedie sobre o ext2 conta que "In its very early days, Linux was cross-developed under the Minix operating system. It was easier to share disks between the two systems than to design a new filesystem, so Linus Torvalds decided to implement support for the Minix filesystem in Linux" [27]. Os autores elogiam o sistema de arquivos do MINIX como "efficient and relatively bug-free", mas apontam dois limites: endereços de bloco de 16 bits, que restringiam o volume a 64 MB, e nomes de arquivo de no máximo 14 caracteres.

A saída passou por uma camada que o Linux 0.01 não tinha. Para facilitar a entrada de novos sistemas de arquivos, o kernel ganhou um Virtual File System (VFS), "initially written by Chris Provenzano, and later rewritten by Linus Torvalds" [27]. Sobre ele, o Extended File System entrou no Linux 0.96c, em abril de 1992, e subiu os limites para 2 GB e 255 caracteres. Ainda tinha problemas: não separava os três carimbos de tempo e controlava blocos e inodes livres com listas encadeadas que se desordenavam com o uso e fragmentavam o disco. Em janeiro de 1993 saíram, em versão alfa, dois sucessores: o Xia, "heavily based on the Minix filesystem kernel code", e o ext2, derivado do ext e desenhado para crescer [27]. O Xia nasceu mais estável; o ext2 venceu porque foi corrigido e ampliado.

Implementar um formato de disco compatível é diferente de copiar o código que o lê. Isso vale para o MINIX do mesmo jeito que vale para o suporte a NTFS ou a FAT no Linux de hoje.

A licença que mudou duas vezes

A primeira licença do Linux não era a GPL. As notas da 0.01 dizem: "This kernel is (C) 1991 Linus Torvalds, but all or part of it may be redistributed provided you do the following: Full source must be available (and free)" [26]. A versão original também proibia cobrar pela distribuição. Nas notas da 0.12, Torvalds anunciou a troca: "I've had a couple of requests to make it compatible with the GNU copyleft, removing the 'you may not distribute it for money' condition. I agree" [28]. A GPL passou a valer a partir de 1º de fevereiro de 1992.

Janeiro de 1992: "LINUX is obsolete"

O post de Tanenbaum saiu em 29 de janeiro de 1992 [1]. Ele começou se apresentando como alguém que via o MINIX como passatempo ("something that I do in the evening when I get bored writing books") e cujo trabalho de verdade era pesquisar sistemas operacionais. Depois listou dois problemas do Linux.

O que Tanenbaum escreveu

O primeiro era arquitetural. Tanenbaum definiu o sistema monolítico como aquele em que "the whole operating system is a single a.out file that runs in 'kernel mode'" e citou UNIX, MS-DOS, VMS e MULTICS como exemplos. Entre os exemplos de microkernel, citou Amoeba, Chorus, Mach e "the not-yet-released Windows/NT". E decretou: "among the people who actually design operating systems, the debate is essentially over. Microkernels have won." Sobre o Linux: "LINUX is a monolithic style system. This is a giant step back into the 1970s. That is like taking an existing, working C program and rewriting it in BASIC. To me, writing a monolithic system in 1991 is a truly poor idea" [1].

O segundo era portabilidade. Tanenbaum previu que os chips RISC iriam "gradually take over from the 80x86 line" e escreveu: "I think it is a gross error to design an OS for any specific architecture, since that is not going to be around all that long." Concluiu: "LINUX is tied fairly closely to the 80x86. Not the way to go" [1].

Quem diz que Tanenbaum chamou o Linux de retrocesso está certo, porque a frase existe. Só que, na mesma mensagem, ele escreveu "Don't get me wrong, I am not unhappy with LINUX" [1]. A crítica era de arquitetura, num grupo de discussão técnica, e chegou uns cinco meses depois do anúncio de agosto.

O que Torvalds respondeu

Torvalds respondeu no mesmo dia, e sem diplomacia. Chamou de "brain-damages of minix" as limitações que Tanenbaum atribuía ao seu trabalho de professor e escreveu "I can only hope (and assume) that Amoeba doesn't suck like minix does" [1]. No mérito, porém, concedeu o principal: "True, linux is monolithic, and I agree that microkernels are nicer. [...] From a theoretical (and aesthetical) standpoint linux looses."

O argumento dele era outro: "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" [1]. Sobre portabilidade, defendeu que o Linux era mais portável que o MINIX no nível que importava para o usuário, o da API: "I made linux as conformant to standards as I knew how (without having any POSIX standard in front of me)". E admitiu o resto: "I also agree that linux takes the non-portability to an extreme" [1].

Tanenbaum voltou no dia 30 com a frase mais citada da discussão: "I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful you are not my student. You would not get a high grade for such a design :-)" [4]. Na mesma mensagem, fez a previsão que envelheceu pior: "5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5".

O pedido de desculpas

Ainda em 30 de janeiro, Torvalds postou uma mensagem com o assunto "Apologies (was Re: LINUX is obsolete)": "And reply I did, with complete abandon, and no thought for good taste and netiquette. Apologies to ast [...] I over-reacted, and am now composing a (much less acerbic) personal letter to ast." Ele manteve a posição técnica ("I still think that's not the case, although some of the criticisms are valid") e assinou como "Linus 'my first, and hopefully last flamefest' Torvalds" [4].

O retrato de um Torvalds arrogante e incapaz de autocrítica não sobrevive à leitura do tópico. Ele foi grosseiro, sim. No mesmo dia, pediu desculpas e reconheceu que parte das críticas procedia.

A réplica técnica de 31 de janeiro

A mensagem seguinte de Torvalds, já sem insultos, é a melhor defesa técnica que ele fez em 1992, e quase ninguém a cita. Sobre o sistema de arquivos multithread, ele respondeu que a coisa só é um truque de desempenho "on a microkernel": "When writing a unix the 'obsolete' way, you automatically get a multithreaded kernel: every process does it's own job, and you don't have to make ugly things like message queues to make it work efficiently" [4]. É o argumento do estado compartilhado, catorze anos antes de ele o escrever por extenso.

Sobre portabilidade, separou a interface da implementação: "Yes, the /implementation/ is hardware-specific, but there's a HUGE difference [...] linux API is portable (not due to my clever design, but due to the fact that I decided to go for a fairly-well-thought-out and tested OS: unix.)" [4]. E fez a conta do tamanho: o código-fonte completo do Linux tinha cerca de 200 kB comprimido, enquanto só a parte dependente de 386 do Mach, i386.tar.Z, passava de 800 kB [4]. Também devolveu a acusação ao MINIX: se o sistema era portável porque rodava em máquinas que não tinham sido feitas para Unix, então "minix is portable, but you can rewrite that as 'doesn't use any features', and still be right" [4].

O resto do tópico

O apêndice da O'Reilly reproduz 36 mensagens, e a maioria não é de nenhum dos dois protagonistas [4]. Elas mostram que a comunidade de 1992 entendeu o debate melhor do que muita gente entende hoje.

Theodore Ts'o, do MIT, que mais tarde seria coautor do ext2, respondeu a Tanenbaum em 31 de janeiro. Disse que a quantidade de código específico de 80386 no Linux "is probably not much more than what is in a Minix implementation", e bem menor que o código específico de VAX no BSD 4.3. E fechou com uma frase que resume a escolha de muita gente: "the fact remains that Linux is here, and GNU isn't [...] Minix doesn't count because it's not free. :-)" [4]. Ele também tinha uma explicação para o consenso acadêmico: "since only researchers write papers about operating systems, ipso facto micro kernels must be the right approach" [4].

Charles Hedrick, da Rutgers, foi mais seco: "The history of software shows that availability wins out over technical quality every time. That's Linux' major advantage" [4]. Douglas Graham, da Bell-Northern Research, perguntou que literatura imparcial sustentava o "Microkernels have won", calculou o Linux em "about 12000 lines of code" e escreveu: "I don't see how splitting that into tasks and blasting messages around would improve it" [4]. Para ele, o problema do MINIX não era desempenho: "adding features is a royal pain".

Houve quem propusesse o meio-termo. Lawrence Foard, do Worcester Polytechnic Institute, contou que estava escrevendo código de IPC para o Linux que permitiria rodar drivers e sistemas de arquivos como processos de usuário, ressalvando que seriam "significantly slower" e que "it would be a mistake to move everything outside the kernel" [4]. Ele também acusou os teóricos de nunca testarem as próprias ideias. Tanenbaum respondeu em caixa alta, "I AM NOT A THEORIST", e listou o que via como prova: a OSF apostava o negócio no Mach 3.0, a USL no Chorus, o Amoeba estava implementado e o QNX tinha, segundo lhe disseram, 200.000 sistemas instalados. "Microkernels are not a pipe dream. They represent proven technology" [4].

O lado de Tanenbaum também teve defensores. David Miller, que se apresentou como observador, aplaudiu os dois autores, mas perguntou: "Why split fundemental os functions, such as memory management, into user processes?" [4]. Michael Haardt intitulou sua mensagem "why I think AST is right". E Randy Burns, da Sun, fez uma aposta que parecia sensata: "It may well be that in 2-3 years when ultra cheap BSD variants and Hurd proliferate, that Linux will be obsolete" [4].

Licença e controle: a parte que ninguém lembra

Em 3 de fevereiro, Tanenbaum abriu outro tópico, "Unhappy campers", porque estava recebendo e-mails irritados ("10 messages from the 43,000 readers"). Defendeu o preço do MINIX, comparou com o Coherent a US$ 99 e o 4.4BSD a US$ 800, e escreveu que a questão do software livre era "100% emotional" [4]. Depois perguntou se Torvalds deixaria o Linux escapar do seu controle, se outras pessoas poderiam modificá-lo e vendê-lo.

A resposta de Torvalds, em 6 de fevereiro, cabe em duas palavras: "I won't." Ele contou que já tinha sondado a criação de uma lista "linux-kernel" que decidiria as versões, porque não teria hardware para suportar tudo, citando SCSI, e que Ts'o já tinha feito "some heavy changes even to 0.10" [4]. Tanenbaum, em 5 de fevereiro, tinha feito a previsão oposta: coordenar mil programadores espalhados pelo mundo seria "as easy as herding cats", e "Anyone who says you can have a lot of widely dispersed people hack away on a complicated piece of code and avoid total anarchy has never managed a software project" [4]. A história do kernel desde então é uma refutação longa dessa frase.

Quem era o "Ken Thompson" do tópico

O apêndice do livro Open Sources, da O'Reilly, que reproduz o debate, diz que nele aparece "user-hacker Ken Thompson (one of the founders of Unix)" [4]. O cabeçalho da mensagem, no próprio apêndice, diz outra coisa: "From: kt4@prism.gatech.EDU (Ken Thompson)", "Organization: Georgia Institute of Technology", 3 de fevereiro de 1992. O texto é curto e sensato: "I would generally agree that microkernels are probably the wave of the future. However, it is in my opinion easier to implement a monolithic kernel. It is also easier for it to turn into a mess in a hurry as it is modified" [4]. Nada no cabeçalho liga o autor ao criador do Unix. Kevin Brown, da Universidade de Houston, respondeu como se falasse com o criador do Unix ("I figure you've got years of experience with monolithic kernels :-)"), o que sugere que a confusão, ou a piada, começou no próprio grupo [4]. Tudo indica um homônimo com conta na Georgia Tech, e a identificação feita pela O'Reilly não se sustenta no documento que ela mesma publica.

Por que o Linux ganhou

A visão mística diz que o Linux venceu porque era melhor. Os protagonistas contam uma história mais prosaica, e contam a mesma.

Torvalds, em janeiro de 1992: se o kernel do GNU estivesse pronto na primavera anterior, ele nem teria começado; "Linux wins heavily on points of being available now" [1]. O GNU tinha escolhido o Hurd, sobre o Mach, como kernel oficial em 1991, mas a primeira versão de teste, o Hurd 0.1, só saiu em 6 de setembro de 1996, e o GNU 0.2 em junho de 1997 [29]. A essa altura o Linux 1.0 já tinha mais de dois anos: saiu em 13 de março de 1994 [24].

O BSD de Berkeley era o candidato natural, e estava pronto tecnicamente. Ficou preso nos tribunais, e os detalhes do processo explicam por que o atraso pesou tanto.

Berkeley, o 386BSD e os seis arquivos

Kirk McKusick, que trabalhou no Computer Systems Research Group (CSRG) de Berkeley, conta a história no mesmo livro da O'Reilly [30]. Em junho de 1989, Berkeley lançou a Networking Release 1, o código de rede e os utilitários que não dependiam de licença da AT&T: "the first freely-redistributable code from Berkeley". Keith Bostic propôs então ir além. Bostic, Mike Karels e McKusick passaram meses revendo a distribuição arquivo por arquivo para remover o que vinha do 32/V da AT&T. Sobraram "only six remaining kernel files that were still contaminated and which could not be trivially rewritten". Berkeley decidiu lançar o resto assim mesmo, com o nome de Networking Release 2, em junho de 1991, por uma taxa de US$ 1.000 [30].

Em menos de seis meses, Bill Jolitz escreveu substitutos para os seis arquivos e publicou um sistema completo e inicializável para PCs 386, o 386/BSD, por FTP anônimo: "Within weeks he had a huge following" [30]. Lynne Jolitz, coautora do trabalho, conta que o 386BSD 0.0 saiu em março de 1992, depois de dois anos de documentação do porte na revista Dr. Dobb's Journal, e que o 386BSD 0.1 saiu em 14 de julho de 1992 [31]. Segundo McKusick, Jolitz não conseguia acompanhar a enxurrada de correções por causa do emprego de tempo integral, e um grupo de usuários formou o NetBSD para manter o sistema [30]. A primeira versão do NetBSD, a 0.8, é de 20 de abril de 1993 [32]. O FreeBSD nasceu no começo de 1993 a partir dos três últimos coordenadores do "Unofficial 386BSD Patchkit", e o FreeBSD 1.0 saiu em dezembro de 1993, ainda baseado na Net/2 [33].

O processo, passo a passo

Enquanto isso, uma empresa, a Berkeley Software Design, Inc. (BSDi), somou os seis arquivos de Jolitz à Net/2 e começou a vender o sistema com fontes e binários em janeiro de 1992, por US$ 995, com anúncios que mandavam ligar para 1-800-ITS-Unix [30]. A Unix System Laboratories (USL), subsidiária majoritária da AT&T, mandou uma carta exigindo que a empresa parasse de chamar o produto de Unix e largasse o telefone. A BSDi trocou o número e os anúncios. A USL processou mesmo assim, alegando código proprietário e segredos industriais, e pediu uma liminar para suspender as vendas [30].

Na audiência preliminar, o juiz aceitou o argumento da BSDi de que ela só distribuía o que a Universidade da Califórnia distribuía, mais seis arquivos, e mandou a USL refazer a queixa com base apenas nesses seis ou ver o caso arquivado. A USL refez o processo contra a BSDi e contra a universidade, pedindo também a suspensão da Net/2 [30]. Em dezembro de 1992, o juiz federal Dickinson R. Debevoise, de Nova Jersey, ouviu os argumentos. Cerca de seis semanas depois, publicou uma decisão de quarenta páginas que negou a liminar e derrubou todas as queixas menos duas, sugerindo que o caso fosse primeiro a uma corte estadual. A universidade entrou na segunda-feira seguinte com uma ação na Califórnia, acusando a USL de não dar o crédito devido ao código BSD incluído no System V [30].

Logo depois, a Novell comprou a USL da AT&T. Segundo McKusick, o presidente da Novell, Ray Noorda, disse em público que preferia competir no mercado a competir no tribunal. As negociações começaram no verão de 1993 e terminaram em janeiro de 1994: três arquivos saíram dos 18.000 da Net/2, outros receberam pequenas mudanças, e cerca de 70 passaram a levar copyright da USL, sem deixar de ser redistribuíveis [30]. O 4.4BSD-Lite saiu em junho de 1994, e o acordo garantia que a USL não processaria quem o usasse como base. O FreeBSD teve até o fim de julho de 1994 para parar de distribuir o produto baseado na Net/2, levou até novembro para refazer o sistema sobre o 4.4BSD-Lite e lançou o FreeBSD 2.0 em dezembro [33].

Some as datas. Entre o lançamento comercial da BSDi, em janeiro de 1992, e o FreeBSD 2.0, em dezembro de 1994, quem quisesse um BSD livre para PC conviveu com quase três anos de incerteza jurídica. É exatamente o período em que o Linux foi da versão 0.12 à 1.0 e trocou a licença própria pela GPL [28], [24]. Hedrick já previa o problema em fevereiro de 1992: seu sistema ideal era o 4.4BSD, mas "4.4's release date has a history of extreme slippage" [4].

O que os dois lados disseram depois

Os dois lados do debate concordam sobre o efeito. Torvalds disse à revista Meta em novembro de 1993: "If 386BSD had been available when I started on Linux, Linux would probably never had happened" [11]. Tanenbaum, em 2004: "This delay in getting free BSD out there gave Linux the breathing space it needed to catch on. If it hadn't been for the lawsuit, undoubtedly BSD would have filled the niche for a powerful, free UNIX clone as it was already a stable, mature system with a large following" [6].

Junte a isso a licença. O Linux era GPL desde fevereiro de 1992 [28], e o MINIX só virou BSD em 2000 [23]. Em 1992, quem queria um Unix livre para PC 386 tinha um sistema disponível, que aceitava contribuições e deixava qualquer um redistribuir. Esse sistema era o Linux. O mérito de Torvalds foi enorme e não precisa de exagero: ele estava pronto quando os outros não estavam, e soube aceitar o código de quem chegava.

2004: o relatório que acusou Linus de cópia

O mito da cópia ganhou versão "oficial" em maio de 2004. Kenneth Brown, presidente da Alexis de Tocqueville Institution (AdTI), de Washington, publicou Samizdat, um texto datado de 20 de maio de 2004 que questionava a origem do código do Linux e o crédito dado a Torvalds [34].

Tanenbaum respondeu no mesmo dia, 20 de maio, numa página chamada "Some Notes on the 'Who wrote Linux' Kerfuffle". Contou que Brown viajou a Amsterdã para entrevistá-lo em 23 de março de 2004 e se esquivou quando perguntado sobre o financiamento. A transcrição é seca: "AST: Is Microsoft one of them? KB: We have multiple funding sources" [6]. Dois anos depois, Tanenbaum escreveu sem rodeio que "Microsoft paid a guy named Ken Brown to write a book saying Linus stole Linux from my MINIX 1 system" [35]. A afirmação é de Tanenbaum. Na entrevista de 2004, Brown só repetiu que tinha "multiple funding sources" [6].

O núcleo da resposta de 2004 desmonta o mito melhor do que qualquer defensor do Linux faria:

Thus, of course, Linus didn't sit down in a vacuum and suddenly type in the Linux source code. He had my book, was running MINIX, and undoubtedly knew the history (since it is in my book). But the code was his. The proof of this is that he messed the design up. [6]

Tanenbaum continua: em vez de escrever um novo sistema de arquivos e um novo gerenciador de memória sobre o microkernel, "Linus rewrote the whole thing as a big monolithic kernel, complete with inline assembly code :-(". E conclui: "producing a system that was fundamentally different from the base he started with seems pretty good proof that it was a redesign" [6].

A acusação de cópia também foi testada com código. Alexey Toptygin, contratado como consultor para o próprio Brown, comparou o Linux 0.01, 0.11, 0.12 e versões posteriores com o MINIX. Entregou o resultado a Brown em 17 de maio de 2004: "my analysis found no evidence whatsoever that any code was copied one way or the other" [36]. O relatório técnico achou "Only 4 actual similarities", e em cada caso "the similarity was required by external factors (the C standard, the POSIX standard, the minix filesystem format)" [37]. Segundo Toptygin, Brown passou a conversa seguinte tentando convencê-lo de que ele tinha errado, porque "it was clearly impossible for one person to write an OS" [36].

Torvalds respondeu ao relatório com ironia. À LinuxWorld, mandou um e-mail que começava assim: "Ok, I admit it. I was just a front-man for the real fathers of Linux, the Tooth Fairy and Santa Claus" [38]. A brincadeira seguia: o Papai Noel tinha contatos na Universidade de Helsinque por ser finlandês.

Tanenbaum fez uma ressalva que os fãs de Linux costumam pular. Ele acha que Torvalds deu crédito de menos aos antecessores: "In science it is considered important to credit people for their ideas, and I think Linus has done this far less than he should have. Ken and Dennis are the real heros here. But Linus' sloppiness about attribution is no reason to assert that Linus didn't write Linux" [6]. E também deixou claro onde estava a sua discordância: "My only regret is that he didn't develop Linux based on the microkernel technology of MINIX" [6].

A ACM resumiu o legado do MINIX de forma equilibrada ao dar a Tanenbaum o Software System Award de 2023: o prêmio foi "For MINIX, which influenced the teaching of Operating Systems principles to multiple generations of students and contributed to the design of widely used operating systems, including Linux" [39]. O MINIX influenciou o desenho do Linux. Não lhe deu o código.

Professor e aluno?

Uma variação do mito diz que Tanenbaum foi professor de Torvalds, e que o aluno teria traído o mestre. O post de 1991 vem de uma conta da Universidade de Helsinque [10]; Tanenbaum dava aula na Vrije Universiteit, em Amsterdã [1]. Em 2004 ele escreveu: "Linus and I are not 'enemies' or anything like that. I met him once and he seemed like a nice friendly, smart guy" [6]. Em 2006, repetiu: "I met him once. He is a pleasant fellow and very smart. We may disagree on some technical issues, but that doesn't make us enemies" [35]. O "Be thankful you are not my student" de 1992 era retórica, justamente porque Torvalds não era aluno dele. O próprio tópico deixa isso claro duas vezes. Torvalds respondeu que não tiraria nota boa de qualquer jeito, porque tinha brigado com "the person here at the university that teaches OS design", em Helsinque. E Tanenbaum, no "Unhappy campers" de 3 de fevereiro, escreveu sobre portabilidade: "Surely Linus' OS professor pointed this out" [4]. Quem fala do professor de outra pessoa não é o professor dela.

"O Linux nem é UNIX"

Aqui o mito acerta mais do que erra. UNIX é marca registrada da Open Group, e só pode usá-la o produto que passa na suíte de testes da especificação e assina o contrato de licença da marca. O macOS 26 Tahoe, por exemplo, está registrado como UNIX 03 desde 29 de agosto de 2025, para Macs com Apple Silicon e com Intel [7]. As distribuições Linux comuns não estão nesse registro, então chamá-las de UNIX é tecnicamente errado. O Linux também não é BSD: ele não deriva do código de Berkeley e foi escrito do zero [26].

Dois detalhes desmontam a versão exagerada do argumento. O primeiro: a certificação é de um produto completo, não de um kernel. O registro da Open Group diz "macOS version 26.0 Tahoe", não "XNU" [7]. Dizer que um kernel é "certificado UNIX" é confundir as coisas, seja o XNU, seja o Linux.

O segundo: um sistema baseado em Linux já passou na certificação. O Huawei EulerOS 2.0, rodando nos servidores KunLun, aparece no registro UNIX 03 com data de registro de 8 de setembro de 2016 e renovação prevista para 8 de setembro de 2022 [12]. Passou na mesma suíte de testes que o macOS. Logo, a ideia de que "o Linux não respeita POSIX" não se sustenta como regra técnica. Não encontrei documento oficial que explique por que as distribuições comuns não se certificam. Minha leitura é que a marca não compensa o custo para quem já vende suporte de Linux, mas isso é opinião. Em 1992, Torvalds já dizia ter feito o Linux "as conformant to standards as I knew how", ainda sem a norma POSIX à mão [1].

O resumo honesto: o Linux não é UNIX no papel, porque não tem a marca. Na prática, um Linux certificado provou que não é por falta de capacidade técnica.

"O ABI do Linux vive quebrando"

Este mito mistura duas interfaces diferentes, e a documentação do kernel separa as duas na primeira página. Greg Kroah-Hartman escreveu o texto que explica por que o Linux não tem interface estável para drivers, e abre com um aviso: "Please realize that this article describes the in kernel interfaces, not the kernel to userspace interfaces" [13].

Sobre a interface que os programas usam, o texto não deixa margem: "The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is very stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still work just fine on the latest 2.6 kernel release" [13]. Quem diz que as syscalls mudam a cada versão está errado.

A interface interna, a que os drivers usam, muda de propósito. O mesmo documento cita pelo menos três reformas na pilha USB e explica que, quando um desenvolvedor encontra um jeito melhor, "function names may change, structures may grow or shrink, and function parameters may be reworked", e todos os usuários dentro da árvore são corrigidos de uma vez [13]. A recomendação para quem tem driver fora da árvore é colocá-lo dentro. E para quem não pode, porque o driver é fechado: "good luck, you are on your own here, you leech" [13].

Aqui o Linux leva uma crítica justa. A escolha tem custo real para quem compra hardware cujo driver o fabricante mantém fora da árvore: quando a interface interna muda, esse driver precisa ser adaptado, e o próprio documento admite que acompanhar a mudança "is also a rough job" [13]. O argumento do projeto é que o custo cai em quem não manda o código para o mainline, e isso é coerente. Mas o usuário que só quer a placa de rede funcionando paga a conta do mesmo jeito. Dizer que o problema não existe é tão errado quanto dizer que as syscalls quebram.

Quando o kernel remove código

Outro mito recente diz que o ReiserFS foi retirado do kernel por motivação política. O registro mostra outra coisa. Em fevereiro de 2022, Jan Kara, da SUSE, propôs a depreciação com esta justificativa: "Reiserfs is relatively old filesystem and its development has ceased quite some years ago. Linux distributions moved away from it towards other filesystems such as btrfs, xfs, or ext4. To reduce maintenance burden on cross filesystem changes [...] let's add a deprecation notice when the filesystem is mounted and schedule its removal to 2025" [40]. A remoção entrou no Linux 6.13 e apagou cerca de 32,8 mil linhas [41]. É a mesma lógica da interface instável: código sem mantenedor dentro da árvore vira peso para quem mexe nas interfaces compartilhadas.

Microkernel contra monolito, com números

Tirando os insultos, o debate de 1992 tinha uma pergunta técnica legítima: vale a pena tirar do modo kernel o que não precisa estar lá? Trinta anos de pesquisa deram dados para os dois lados.

O argumento do Tanenbaum: os bugs moram nos drivers

Em 2001, Andy Chou, Dawson Engler e colegas de Stanford aplicaram verificadores estáticos automáticos ao código do Linux e do OpenBSD. A conclusão para o Linux 2.4.1 foi que "the vast majority of bugs are in drivers", e que a taxa de erro do código de driver é de três a sete vezes maior que a do resto do kernel. No verificador de travas, "the error rate for drivers is almost seven times higher than the error rate for the rest of the kernel" [42].

O Windows tinha o mesmo problema, medido de outro jeito. Em 2003, Michael Swift, Brian Bershad e Henry Levy, da Universidade de Washington, abriram o artigo do Nooks com um número da Microsoft: "In Windows XP, for example, drivers account for 85% of recently reported failures" [43]. O Nooks isolava drivers do Linux em domínios de proteção leves dentro do próprio espaço de endereçamento do kernel e os reiniciava em caso de falha. Em 2.000 testes de injeção de falhas, "Nooks recovered automatically from 99% of the faults that caused Linux to crash" [43]. O sistema tinha cerca de 22.000 linhas, contra 2,4 milhões do kernel da época. Os drivers continuavam rodando no anel 0, o mesmo nível de privilégio do resto do kernel, e a proteção vinha das tabelas de páginas [43].

Tanenbaum usou esses dados em 2006, num artigo com Jorrit Herder e Herbert Bos na IEEE Computer. O raciocínio é aritmético: se o código tem de 6 a 16 bugs por mil linhas, "Using a conservative estimate of 6 bugs per 1000 lines of code the Linux kernel probably has something like 15,000 bugs; Windows has at least double that" [44]. Num kernel monolítico, um driver com defeito roda no mesmo espaço de endereçamento que todo o resto. A documentação da Microsoft descreve o problema no Windows com uma clareza que eu gostaria de ver mais vezes: "All code that runs in kernel mode shares a single virtual address space. As a result, a kernel-mode driver isn't isolated from other drivers or the operating system. [...] If a kernel-mode driver crashes, it causes the entire operating system to crash" [8].

O Linux merece, aqui, um dado a seu favor que os críticos raramente citam. Em 2011, Nicolas Palix, Julia Lawall e colegas repetiram o estudo de Chou nas versões 2.6.0 a 2.6.33. O kernel mais que dobrou de tamanho no período, mas o número de falhas por linha caiu. O diretório drivers ainda concentrava a maior quantidade absoluta de falhas e, com o drivers/staging, respondia por 57% do código desde o 2.6.30. A taxa de falhas dele, porém, "is now below that of other directories, such as arch (HAL) and fs (file systems)", e desde o 2.6.19 está "right at the average" [45]. A revisão por pares melhorou os drivers. O que não mudou foi a consequência de um bug que sobra: no Linux, ele roda com privilégio total.

Nesse ponto, o Linux leva crítica justa, e o próprio Torvalds forneceu a munição. Em setembro de 2009, na LinuxCon, ele disse: "We're getting bloated and huge. Yes, it's a problem". E completou: "sometimes it's a bit sad that we are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary" [46]. Quem trata o kernel Linux como modelo de elegância está defendendo algo que o próprio autor não defende.

MINIX 3: drivers fora do kernel e um servidor que os ressuscita

O MINIX 3 é a resposta de Tanenbaum a esses números, e ele foi mais longe que o MINIX 2. No artigo da IEEE Computer, a arquitetura é descrita em camadas. O microkernel trata interrupções, processos, escalonamento e IPC, e oferece um pequeno conjunto de chamadas de kernel a drivers e servidores autorizados, como ler o espaço de endereçamento de um usuário ou escrever em portas de I/O permitidas. "The clock driver shares the microkernel's address space, but is scheduled as a separate process. No other drivers run in kernel mode" [44]. Cada driver de disco, terminal, rede, impressora ou áudio roda num processo próprio, em modo usuário, protegido pela MMU, e precisa pedir ao kernel para tocar no hardware. O servidor de arquivos tinha 4.500 linhas de código executável, e o kernel, 4.000: com a mesma estimativa de 6 bugs por mil linhas, "the total number of bugs in the kernel is probably only about 24 (vs. 15,000 for Linux and far more for Windows)" [44].

A troca de mensagens manteve a ideia do MINIX 2 e ganhou um complemento. O IPC "is done by passing fixed-length messages using the rendezvous principle", com cópia direta do remetente para o destinatário, mais um mecanismo de notificação assíncrona: eventos que não podem ser entregues ficam marcados como pendentes num mapa de bits na tabela de processos. Interrupções viram notificações, e o kernel as converte em mensagens normais quando o driver está pronto para recebê-las [44]. Como não há fila nem buffer de mensagens no kernel, não há como esgotar memória do kernel com mensagens. As permissões ficaram mais finas: para cada processo, o sistema restringe as primitivas de IPC, os destinos permitidos e o uso de notificações, e processos de usuário só falam com os servidores POSIX [44].

O componente novo é o servidor de reencarnação (reincarnation server). O artigo de Herder, Bos, Gras, Homburg e Tanenbaum no DSN 2007 descreve como ele funciona [47]. Um driver é iniciado pelo utilitário service com o binário, um nome estável, a lista exata de privilégios, um período de heartbeat e, opcionalmente, um script de política para a recuperação. O servidor de reencarnação é o pai de todos os processos de sistema e fica sabendo na hora quando um deles sai, entra em pânico ou morre por exceção de CPU ou de MMU. Ele também pede heartbeats periódicos e inicia a recuperação depois de N respostas perdidas, o que pega processos presos em laço infinito. O servidor de arquivos pode pedir a troca de um driver de disco que viole o protocolo, e o usuário pode mandar reiniciar um driver ou trocá-lo por uma versão corrigida com o sistema rodando [47]. Um servidor de dados (data store) publica o novo endereço de IPC do driver reiniciado, e quem depende dele é avisado. O driver de disco que morre no meio de uma leitura é reiniciado, e o servidor de arquivos reemite as operações pendentes, porque I/O de bloco é idempotente.

Os números do artigo são concretos. Num teste de rede com wget baixando um arquivo de 512 MB enquanto o driver RealTek 8139 era morto em intervalos de 1 a 15 segundos, todas as transferências terminaram com o checksum correto, e a perda de vazão ficou entre 25% e 1% [47]. No disco SATA, lendo 1 GB com o driver morto em intervalos parecidos, a perda foi de 62% a 7%, também sem corromper dados. Na injeção de falhas no driver Ethernet DP8390, rodando no emulador Bochs, foram mais de 12.500 falhas injetadas e 347 travamentos detectáveis, e "The subsequent recovery was successful in 100% of the induced failures"; no hardware real, o sucesso passou de 99% [47]. O custo de adaptação de um driver comum foi de exatamente cinco linhas na biblioteca compartilhada de drivers.

Os próprios autores listam os limites, e é aí que a honestidade do trabalho aparece. O desenho não lida com falhas bizantinas, como um driver de disco que responde que gravou e grava lixo; não detecta corrupção silenciosa de dados; não cura bugs determinísticos que voltam depois do reinício; e não resolve hardware quebrado [47]. O FAQ do projeto mede o custo do isolamento: "MINIX 3 is 5-10% slower" que o MINIX 2, que tinha drivers em modo kernel, e "our priority has been reliability, not performance" [48]. Em 2008, o European Research Council deu a Tanenbaum uma bolsa de 2,5 milhões de euros para construir um sistema confiável, e o MINIX 3.3.0 saiu com licença BSD, suporte a x86 e ARM Cortex-A8 e área de usuário compatível com o NetBSD [49].

O argumento do Torvalds: estado compartilhado

Torvalds respondeu ao debate em maio de 2006, no fórum Real World Technologies, e o argumento dele não era desempenho. Era complexidade:

The fundamental result of access space separation is that you can't share data structures. That means that you can't share locking, it means that you must copy any shared data, and that in turn means that you have a much harder time handling coherency. All your algorithms basically end up being distributed algorithms. [50]

Para ele, a separação em espaços de endereçamento troca bugs de memória por bugs de coordenação entre processos, que são mais difíceis de entender. Na mesma mensagem, ele atacou de frente a ideia do servidor de reencarnação: "the argument that you can 'just reload' a failed service and not take the whole system down is equally flawed. Anybody who has ever done distributed programming should know by now that when one node goes down, often the rest comes down too" [50]. E descartou o termo da moda: "As to the whole 'hybrid kernel' thing - it's just marketing" [50].

O argumento é sério, e os dados do MINIX 3 respondem só a uma parte dele. Para falhas transitórias de drivers de rede e de disco, onde o protocolo tolera repetição, o reinício funcionou em quase todos os casos medidos [47]. Para estado compartilhado de verdade, como um sistema de arquivos com metadados em memória, os próprios autores do MINIX 3 admitem que o reinício não basta e que é preciso somar checksums de ponta a ponta [47]. Torvalds exagera quando chama de falho o argumento do reinício. Tanenbaum exagerava quando vendia o isolamento como solução geral.

Desempenho: o problema era o Mach, não a ideia

Em 1992, Tanenbaum citou os artigos de Rick Rashid comparando o Mach 3.0 com sistemas monolíticos como evidência de que o desempenho tinha deixado de ser problema [1]. A afirmação era prematura. Gernot Heiser e Kevin Elphinstone, que trabalharam décadas no L4, resumem o começo dos anos 1990: "The typical cost for a one-way message was around 100 µs, which was too high for building performant systems", e a resposta da indústria foi "a trend to move core services back into the kernel" [51].

Jochen Liedtke mostrou em 1993 que o custo vinha da implementação. No artigo "Improving IPC by Kernel Design", apresentado no SOSP, ele reconstruiu do zero a parte de processos e comunicação do microkernel L3 em torno de um único objetivo, a velocidade do IPC. Num 486-DX50, calculou o mínimo teórico de uma mensagem curta em 172 ciclos, ou 3,5 µs, mirou em 350 ciclos e chegou a 250 ciclos, 5 µs [14]. Em relação ao Mach, o ganho foi "from a factor of 22 (8-byte messages) to 3 (4-Kbyte messages)". O artigo mede até o custo de entrar e sair do kernel: no Mach, a chamada mach_thread_self levava 18 µs, num processador em que a ida e volta mínima ao kernel custava 2 µs [14].

Dois anos depois, em "On µ-Kernel Construction", Liedtke formulou o critério que guiaria a família L4: um conceito só é tolerado dentro do microkernel "only if moving it outside the kernel, i.e. permitting competing implementations, would prevent the implementation of the system's required functionality" [52]. E escreveu uma frase que deveria incomodar quem usa o debate de 1992 como arma: "µ-kernels are inherently not portable. Instead, they are the processor dependent basis for portable operating systems" [52]. O microkernel mais rápido da época era tão preso ao processador quanto o Linux 0.01. Tanenbaum tinha razão sobre a arquitetura e estava errado ao achar que ela vinha junto com portabilidade de graça.

A linhagem L4 continuou. A tabela de Heiser e Elphinstone mostra o custo de uma mensagem entre espaços de endereçamento caindo de 5 µs no L4 original de 1993 para 0,09 µs no seL4 de 2013, num Core i7 Haswell a 3,4 GHz, ou 301 ciclos; num ARM11 a 532 MHz, o seL4 levava 188 ciclos [51]. Em 1997, Hermann Härtig, Michael Hohmuth, Liedtke e colegas, em Dresden, portaram o Linux para rodar sobre o L4 e mediram: "For L4Linux, the AIM benchmarks report a maximum throughput which is only 5% lower than that of native Linux. The corresponding penalty is 5 times higher for a co-located in-kernel version of MkLinux, and 7 times higher for a user-level version of MkLinux" [15]. O MkLinux rodava sobre o Mach. Um microkernel bem projetado custava 5%; o Mach custava muito mais.

Tanenbaum, em 2004, dizia aceitar uma perda bem maior: "I would easily give up 20% in performance for a system that was robust, reliable" [53]. É uma posição legítima para quem projeta sistema crítico. É uma posição difícil de vender para quem roda um data center.

O que os outros fizeram antes, ou melhor

Esta é a parte que a visão mística do Linux mais gosta de pular. Dominar supercomputadores e celulares [2], [3] não torna o Linux autor de todas as boas ideias, e várias das que hoje parecem "coisa de Linux" apareceram antes em outros sistemas.

macOS e XNU: UNIX certificado, mas não microkernel

O macOS tem o que nenhuma distribuição Linux comum tem: o registro UNIX 03. O macOS 26 Tahoe foi registrado em 29 de agosto de 2025, em Apple Silicon e em Intel [7]. O registro se repete a cada versão: o macOS 15 Sequoia tinha sido registrado em 12 de setembro de 2024 [54]. Quem trata o macOS como brinquedo está desprezando um sistema de desktop de massa que passa na suíte de conformidade da Open Group versão após versão. A Apple também usa microkernel onde o risco é maior: o processador do Secure Enclave "runs an Apple-customized version of the L4 microkernel" [55].

O mito do outro lado diz que o macOS é microkernel porque o XNU tem o Mach dentro. A própria Apple desmente, e vale olhar por dentro. O README do código do XNU o descreve como "a hybrid kernel combining the Mach kernel developed at Carnegie Mellon University with components from FreeBSD and a C++ API for writing drivers called IOKit"; na árvore, osfmk guarda os subsistemas derivados do Mach e bsd guarda os do BSD [56]. Do Mach vêm as abstrações: tasks, que são unidades de posse de recursos com espaço de endereçamento, um espaço de nomes de direitos de porta e uma ou mais threads; e portas, "Secure, simplex communication channels, accessible only via send and receive capabilities (known as port rights)" [17]. No nível da armadilha para o kernel, a interface da maior parte dessas abstrações é feita de mensagens para portas do kernel, e o Mach Interface Generator (MIG) gera os stubs que escondem isso do programador [17].

Parece microkernel, mas a Apple explica logo depois: "in OS X, Mach is linked with other kernel components into a single kernel address space. This is primarily for performance; it is much faster to make a direct call between linked components than it is to send messages or do remote procedure calls (RPC) between separate tasks" [17]. A Apple conclui que, no OS X, "Mach is not primarily a communication hub between clients and servers". A documentação de arquitetura avisa que "OS X uses the term kernel somewhat differently than you might expect" e que "The OS X kernel environment includes the Mach kernel, BSD, the I/O Kit, file systems, and networking components" [16]. Os drivers do I/O Kit são extensões carregadas "into kernel space" [16]. Tanenbaum foi mais duro em 2006: o Mac OS X "is sort of microkernelish", mas "Since all of it runs in kernel mode (to get that little extra bit of performance) it is not a true microkernel" [35]. Pela régua de 1992, o XNU está do mesmo lado do Linux. Quem elogia o macOS por ser "Mach" e ataca o Linux por ser monolítico está usando dois pesos.

Onde a Apple foi além do Linux foi nos drivers de terceiros. A documentação do DriverKit diz: "The drivers you build with DriverKit run in user space, rather than as kernel extensions, which improves system stability and security" [57]. A página sobre extensões de kernel informa que elas foram depreciadas e que, a partir do macOS Big Sur, o sistema não carrega por padrão extensões que usam interfaces de kernel depreciadas [58]. Na prática, a Apple empurra os fabricantes de periféricos para fora do modo kernel com uma política de plataforma. O Linux não tem nada equivalente para drivers em geral, e explico adiante o que ele tem.

FreeBSD: jails em 2000, ZFS e DTrace antes do Linux

Os contêineres costumam ser contados como uma história do Linux. O isolamento de sistema operacional em produção apareceu antes no FreeBSD. A página de manual diz: "The jail utility appeared in FreeBSD 4.0" [9]. O FreeBSD 4.0 foi anunciado em 14 de março de 2000 [59]. No mesmo ano, Poul-Henning Kamp e Robert Watson apresentaram o desenho no SANE 2000: o jail "provides the ability to partition the operating system environment, while maintaining the simplicity of the UNIX 'root' model", e o uso mais popular até ali era "providing virtual machine services in Internet Service Provider environments" [60].

No Linux, as peças chegaram aos poucos. O namespace de montagem apareceu no 2.4.19 [61]. Os cgroups estrearam no 2.6.24 [18], lançado em 24 de janeiro de 2008 [62]. Criar um namespace de usuário sem privilégio só passou a ser possível no Linux 3.8 [63]. O modelo do Linux, com primitivas separadas que o espaço de usuário combina, acabou mais flexível, e foi sobre ele que a indústria de contêineres cresceu. Mas o jail veio antes.

Duas ferramentas que os administradores de Linux invejaram por anos também vieram de fora. O ZFS foi "Originally developed at Sun Microsystems" [64], e as notas do FreeBSD 7.0 registram: "Support for Sun's ZFS has been added" [65]. O 7.0 saiu em 27 de fevereiro de 2008 [66]. O DTrace foi apresentado por Bryan Cantrill, Michael Shapiro e Adam Leventhal, da equipe de kernel do Solaris na Sun, no USENIX de 2004, como uma ferramenta capaz de instrumentar kernel e programas "in a unified and absolutely safe fashion", com "zero probe effect" quando desligada [67]. O FreeBSD 7.1, de 4 de janeiro de 2009, trouxe o DTrace "imported from OpenSolaris" [68], [69]. O manual do FreeBSD ainda abre o capítulo assim: "DTrace [...] was developed by Sun™ as a tool for locating performance bottlenecks in production and pre-production systems" [70]. O eBPF, que hoje cumpre esse papel no Linux, só ganhou a chamada de sistema bpf() no Linux 3.18, lançado em 7 de dezembro de 2014 [71].

Windows NT: o falso microkernel que voltou ao kernel

O Windows é o alvo preferido da turma que ama Linux, e merece crítica: os drivers de modo kernel dele caem pelo mesmo motivo que os do Linux, como a própria Microsoft documenta [8]. Também merece a crítica de marketing. Em 1992, Tanenbaum citou o "not-yet-released Windows/NT" como exemplo de microkernel [1]. Em 2004, corrigiu: "Microsoft claimed that Windows NT 3.51 was a microkernel. It wasn't. It wasn't even close. Even they dropped the claim with NT 4.0" [53]. O "kernel híbrido" que Torvalds chamou de "just marketing" é, em boa parte, este [50].

O NT também tem pedigree, que costuma ser esquecido. Tanenbaum conta que a Microsoft contratou David Cutler, um dos arquitetos principais do VMS da DEC, para liderar a equipe que produziu o Windows NT, e acrescenta que "Operating system designers of Cutler's quality are few and far between" [72].

A melhor fonte sobre o desenho do NT e sobre o recuo do NT 4.0 é um documento da própria Microsoft, o "Windows NT Kernel-mode User and GDI White Paper", ainda arquivado no Microsoft Learn [73]. Ele descreve o NT 3.51 em camadas: a camada de abstração de hardware (HAL) na base, um "microkernel" que cuida de interrupções, chamadas de procedimento adiadas, escalonamento de threads e sincronização, e o Executive por cima. O mesmo texto admite que o NT "has fallen squarely into the modified microkernel or macrokernel camp": desde a primeira versão, o gerenciador de memória, o cache, os sistemas de arquivos, os protocolos de rede, o servidor de rede e o gerenciamento de processos rodavam em modo kernel [73]. O que ficava fora eram os subsistemas de ambiente. O plano original previa Win32, OS/2 e POSIX como ambientes de igual para igual; o Win32 acabou como uma "aplicação" privilegiada da qual todo o resto dependia, e o gerenciador de janelas (USER) e a interface gráfica (GDI) rodavam num processo de usuário, o CSRSS.EXE [73].

No NT 4.0, a Microsoft trouxe USER e GDI para dentro do kernel, e o documento explica por quê com números. O modelo cliente-servidor exigia um buffer de memória compartilhada de 64 KB e várias trocas de contexto entre threads e processos por chamada gráfica. Num Pentium 100, uma transição cliente-servidor custava de 60 a 70 microssegundos, contra 4 a 5 de uma transição para o modo kernel [73]. A mudança economizava de 256 KB a 1 MB de memória de trabalho e deixava o PowerPoint de 15% a 20% mais rápido. Os drivers gráficos, que antes rodavam em parte no CSRSS, passaram a rodar inteiros em modo kernel [73].

O argumento da Microsoft para não temer a mudança é o mesmo de Torvalds. O documento diz que "No commercial operating system is based on a pure microkernel design", porque o desenho puro "is too computationally expensive", e pergunta qual a diferença prática entre um sistema que trava e um que continua rodando "but loses all access to persistent storage" quando o sistema de arquivos em modo usuário morre [73]. Sobre a GDI, admite: se o processo gráfico do NT 3.51 falhasse, o usuário veria "a system that appears to have crashed" [73]. A Microsoft fez no NT 4.0, em nome do desempenho, a troca que Tanenbaum criticava no Linux.

Anos depois, o Windows ganhou um mecanismo que o Linux não tem no mesmo grau: um framework oficial para drivers em modo usuário. Segundo a Microsoft, "UMDF drivers abstract hardware functionality, run in the user-mode environment, and can access various services". Cada driver roda dentro de um processo hospedeiro, gerenciado por um serviço, e um componente em modo kernel, o reflector, faz a ponte [74]. Há limites: "File system drivers, display drivers (for full display devices, not display-only display devices), and print drivers cannot be UMDF drivers" [74]. Ainda assim, para muitas classes de dispositivo, o Windows oferece de série o isolamento de driver que o Linux oferece só em nichos.

O Linux de hoje: monolítico, com janelas para fora

O Linux não virou microkernel, e os números mostram o tamanho do que continua dentro. Contei as linhas dos arquivos .c, .h, .S e .rs do tarball do Linux 7.2, publicado em 17 de agosto de 2026: são 37,7 milhões de linhas em 65.637 arquivos. O diretório drivers sozinho tem 26 milhões, 69% do total; arch vem depois, com 6,7% [75]. O Linux 0.01 tinha 9.877 linhas [5]. Quase tudo o que cresceu roda em modo kernel, no mesmo espaço de endereçamento, e um módulo carregado depois do boot tem o mesmo privilégio do código que estava lá desde o começo, como o artigo do Nooks já descrevia [43].

Ainda assim, o kernel foi abrindo janelas para fora do modo kernel, ou para dentro dele com rede de segurança. Algumas são respostas diretas ao que Tanenbaum e os usuários do MINIX pediam em 1992.

FUSE: o pedido de 1991, atendido em 2005

Em agosto de 1991, Jyrki Kuoppala pediu sistemas de arquivos em modo usuário, e Torvalds respondeu que talvez fosse a única coisa da lista que não daria para fazer [10]. O FUSE entrou no Linux 2.6.14, lançado em 27 de outubro de 2005, descrito pelo KernelNewbies como algo que "Allows to implement a fully functional filesystem in a userspace program" [76]. A documentação do kernel define o sistema de arquivos em espaço de usuário como aquele em que "data and metadata are provided by an ordinary userspace process", e lista as peças: um módulo de kernel (fuse.ko), uma biblioteca (libfuse) e o utilitário fusermount [19]. O recurso que ela destaca é a montagem sem privilégio: o daemon roda com as permissões de quem montou, e o exemplo citado é o sshfs. Se o daemon morre, a conexão com o kernel acaba e o sistema de arquivos para de responder; o kernel segue rodando [19]. É o modelo de servidor do MINIX aplicado a uma classe de sistemas de arquivos.

UIO e VFIO: drivers em espaço de usuário, com e sem IOMMU

O UIO, documentado no kernel desde 2006, permite escrever a maior parte de um driver em espaço de usuário. A documentação lista as vantagens com franqueza: "bugs in your driver won't crash the kernel" e "updates of your driver can take place without recompiling the kernel" [77]. O alcance é limitado: dispositivos já atendidos por subsistemas como rede, serial ou USB "are no candidates for an UIO driver" [77].

O VFIO, que entrou no Linux 3.6, lançado em 30 de setembro de 2012 [78], resolveu o problema que o UIO deixava aberto. Um driver em espaço de usuário que programa DMA pode escrever em qualquer lugar da memória, e aí o isolamento vira enfeite. A documentação do VFIO o descreve como "an IOMMU/device agnostic framework for exposing direct device access to userspace, in a secure, IOMMU protected environment", o que permite "safe, non-privileged, userspace drivers" [20]. O texto critica o UIO, que "has no notion of IOMMU protection, limited interrupt support, and requires root privileges to access things like PCI configuration space" [20]. O uso principal é dar a uma máquina virtual acesso direto a um dispositivo, o que, nas palavras da documentação, "turns the VM into a userspace driver". O MINIX 3 propunha a mesma proteção: no artigo do DSN 2007, o driver que quer fazer DMA com segurança primeiro pede ao kernel para configurar a I/O MMU [47].

eBPF e sched_ext: código no kernel, com verificador e plano de fuga

O eBPF vai pelo caminho oposto: leva código para dentro do kernel, mas só depois de checá-lo. A chamada bpf() entrou no Linux 3.18, e o KernelNewbies resumiu: "eBPF programs are similar to kernel modules. [...] eBPF verifier statically determines that the program terminates and is safe to execute" [71]. A documentação do verificador detalha as duas etapas: primeiro, uma checagem do grafo de fluxo que proíbe laços e código inalcançável; depois, uma simulação de todos os caminhos possíveis, instrução por instrução, acompanhando o tipo de cada registrador e da pilha [79]. A proteção vem de uma checagem feita antes da carga, e essa ideia está mais perto do seL4 do que do MINIX.

O sched_ext, que entrou no Linux 6.12, lançado em 17 de novembro de 2024 [80], leva isso ao escalonador. Ele é "a scheduler class whose behavior can be defined by a set of BPF programs", e a documentação promete: "The system integrity is maintained no matter what the BPF scheduler does. The default scheduling behavior is restored anytime an error is detected, a runnable task stalls, or on invoking the SysRq key sequence SysRq-S" [21]. Um escalonador com defeito é derrubado e o kernel volta ao padrão. Troque "escalonador" por "driver" e "padrão" por "nova instância" e a frase poderia estar no artigo do servidor de reencarnação.

Rust: a mesma pergunta, outra resposta

A aposta mais recente ataca a classe de bug que Chou mediu nos drivers sem tirar os drivers do modo kernel. O suporte a Rust entrou no Linux 6.1, em 2022, num estado tão inicial que, segundo a LWN, "No system with a production 6.1 kernel will be running any Rust code" [81]. Três anos depois, o quadro mudou. Na Maintainers Summit de dezembro de 2025, o consenso dos mantenedores foi que o Rust deixava de ser experimental e passava a ser parte permanente do kernel, e a etiqueta "experimental" seria removida [82]. Na sessão, Miguel Ojeda contou que o driver Binder do Android em Rust tinha entrado no 6.18 e que aparelhos com Android 16 e kernel 6.12 já saíam com o módulo ashmem escrito em Rust: "millions of real devices running kernels with Rust code now" [83]. Greg Kroah-Hartman disse que os drivers em Rust "are indeed proving to be far safer than those written in C" e que nenhum CVE tinha sido emitido para código Rust do kernel até ali. Dave Airlie, mantenedor do subsistema gráfico, disse que o DRM estava "about a year away" de recusar drivers novos em C. Torvalds encerrou a questão dizendo que, depois de quase cinco anos, tinha chegado a hora [83]. No Linux 7.2, pelas minhas contas, os arquivos .rs somam 182.584 linhas, menos de meio por cento do total [75].

O ponto técnico é que Rust e microkernel respondem à mesma pergunta de jeitos diferentes. O MINIX 3 aceita que o driver vai ter bug e isola o estrago com a MMU [44]. O Rust tenta impedir que uma classe de bug de memória chegue a existir, mas o driver continua no anel 0 e um erro de lógica continua podendo derrubar o sistema. A segunda via tem uma vantagem para o projeto: preserva o que Torvalds defendeu em 2006, o estado compartilhado entre subsistemas [50].

Onde o Linux continua monolítico

Drivers, pilha de rede, sistemas de arquivos principais e gerenciamento de memória continuam em modo kernel, no mesmo espaço de endereçamento [75]. FUSE, UIO e VFIO são saídas opcionais para nichos. O eBPF e o sched_ext põem dentro do kernel código verificado ou descartável, e o Rust troca isolamento por segurança de linguagem. Nenhuma dessas peças muda a arquitetura que Tanenbaum criticou em 1992. Quem diz que o Linux "já é meio microkernel" exagera. Quem diz que ele ignorou a crítica também.

Onde o microkernel venceu

A previsão de Tanenbaum de que os microkernels dominariam o desktop e o servidor não se cumpriu. Mas existem lugares onde a falha custa caro e o código precisa ser pequeno, e nesses lugares o microkernel ganhou.

seL4: um kernel com prova matemática

Em 2009, Gerwin Klein e colegas do NICTA e da UNSW publicaram no SOSP a verificação formal do seL4, "a third-generation microkernel of L4 provenance", que "comprises 8,700 lines of C code and 600 lines of assembler". O artigo descreve "the first formal proof of functional correctness of a complete, general-purpose operating-system kernel", verificada por máquina [84]. Os autores ligam o resultado ao tamanho: "With truly small kernels it becomes possible to take security and robustness further, to the point where it is possible to guarantee the absence of bugs" [84]. É o argumento de 1992, agora com prova.

O preço aparece no mesmo artigo. A prova inteira, com bibliotecas e partes geradas, soma 200.000 linhas de script do Isabelle, e os autores provaram mais de 150 invariantes sobre o estado do kernel [84]. Escrever o kernel custou 2,2 pessoas-ano, contando o protótipo em Haskell. A prova custou cerca de 20 pessoas-ano, das quais 11 foram específicas do seL4 e o resto foi ferramenta e pesquisa reaproveitável. Os autores comparam com a regra da indústria para certificação Common Criteria EAL6, de US$ 10 mil por linha, que daria US$ 87 milhões para o seL4 com garantia bem menor [84]. Os bugs que a prova achou no código C não eram falhas de algoritmo: eram, na maioria, erros de digitação, leitura errada da especificação e checagens esquecidas, e mesmo assim muitos bastavam para derrubar o kernel ou abrir uma vulnerabilidade [84]. A conta não fecha para 37 milhões de linhas. Heiser e Elphinstone escrevem que "even 9,000 SLOC pushed the limits of what was achievable" [51].

L4 em bilhões de aparelhos

A família L4 saiu do laboratório. Segundo Heiser e Elphinstone, uma versão embarcada do Pistachio teve "massive-scale commercial deployment when Qualcomm adopted it as a protected-mode real-time OS for the firmware of their wireless modem processors", e roda no processador de segurança dos aparelhos iOS recentes; a nota de rodapé diz: "Total deployment is now in the billions" [51]. O PikeOS, um clone comercial da segunda versão do L4, foi certificado para aviônica e roda em aviões e trens [51]. Em todos os kernels L4, os drivers rodam em modo usuário, com exceção do driver do temporizador e do controlador de interrupções, e os autores dizem que pôr drivers não verificados dentro do kernel "would obliterate any guarantees" [51]. Tanenbaum, em 2004, apontava também o QNX como "An example of commercially successful microkernel" [6], e em 2006 listou QNX, Integrity, PikeOS, Symbian e L4Linux como prova de que "clearly I am not alone in seeing something in microkernels" [35].

O MINIX dentro de quase todo PC Intel

A ironia mais citada da história é a de 2017. O MINIX 3 roda dentro do Intel Management Engine (ME), o subsistema de gerenciamento que funciona abaixo do sistema operacional nas máquinas Intel. Na Embedded Linux Conference Europe de 2017, em Praga, Ronald Minnich, do Google, descreveu os "anéis" abaixo do kernel: "Ring -3 is 'the one that has people really worried'. It runs MINIX 3 and is where the ME runs." Ele brincou que esse era o "year of MINIX 3 on the desktop", porque há mais máquinas com ME do que com Linux, macOS ou Windows. Ali rodam pilhas IPv4 e IPv6, sistemas de arquivos, drivers e servidores web. O ME "can reimage the system even if the power is turned off as long as it is plugged into the wall and the network", segundo o relato da LWN publicado em 20 de novembro de 2017 [85]. Na Black Hat Europe do mesmo ano, Mark Ermolov e Maxim Goryachy mostraram como rodar código não assinado no ME [86].

Tanenbaum escreveu uma carta aberta à Intel, endereçada a "Mr. Krzanich". A cópia mais antiga no Internet Archive é de 7 de novembro de 2017 [22]. O tom é de ironia e incômodo. Ele agradece por pôr o MINIX "inside the ME-11 management engine chip used on almost all recent desktop and laptop computers in the world", diz que isso talvez faça do MINIX "the most widely used computer operating system in the world" e reclama que ninguém o avisou [22]. Depois vem a parte que mais importa para este artigo: "I certainly hope Intel did thorough security hardening and testing before deploying the chip, since apparently an older version of MINIX was used. Older versions were primarily for education and newer ones were for high availability. Military-grade security was never a goal" [22].

O mito de que microkernel é sinônimo de seguro morre aqui, pela mão do autor do MINIX. O microkernel isola componentes e reduz o código privilegiado, o que ajuda a segurança. Ele não substitui auditoria, e o MINIX mais usado do planeta roda dentro de um firmware que o dono da máquina não audita. O problema do ME é de governança, não de arquitetura de kernel, e o próprio Tanenbaum separou as coisas: "that is Intel's business decision and a separate issue from the code it runs" [22].

O MINIX 3 hoje

O site do projeto ainda descreve o MINIX 3 como "designed to be highly reliable, flexible, and secure", com "a tiny microkernel running in kernel mode with the rest of the operating system running as a number of isolated, protected, processes in user mode" [87]. A página de recursos resume a arquitetura em três frases curtas: "Tiny microkernel that runs in kernel mode", "Each device driver is a separate user-mode process" e "Reincarnation server can reload failed drivers" [88]. O repositório oficial, porém, mostra um projeto parado: a tag mais recente é a v3.3.0 e o último commit no ramo principal é de 14 de novembro de 2018 [89]. A ideia continua viva no seL4, no L4 dos modems e no QNX. O MINIX virou, sobretudo, peça de firmware e de sala de aula.

O placar

Os números lado a lado

Medida	Dado	Fonte
Tamanho do Linux 0.01	88 arquivos, 9.877 linhas (contagem minha)	[5]
Tamanho do Linux 7.2	37,7 milhões de linhas, 69% em `drivers` (contagem minha)	[75]
Rust no Linux 7.2	182.584 linhas, cerca de 0,5% (contagem minha)	[75]
Kernel do MINIX 3	cerca de 4.000 linhas, só o driver de relógio em modo kernel	[44]
Kernel do seL4	8.700 linhas de C e 600 de assembly	[84]
IPC no Mach, começo dos anos 1990	cerca de 100 µs por mensagem	[51]
IPC no L3, 486 a 50 MHz	5 µs, de 3 a 22 vezes mais rápido que o Mach	[14]
IPC no seL4, Core i7 de 2013	0,09 µs (301 ciclos)	[51]
NT 3.51, Pentium 100	60 a 70 µs por troca cliente-servidor contra 4 a 5 µs para o kernel	[73]
Custo de rodar o Linux sobre L4	5% de vazão a menos	[15]
Custo do isolamento no MINIX 3	5% a 10% mais lento que o MINIX 2	[48]
Bugs em drivers, Linux 2.4.1	taxa de 3 a 7 vezes a do resto do kernel	[42]
Drivers nas falhas do Windows XP	85% das falhas reportadas	[43]
Drivers do Linux, 2.6.19 a 2.6.33	taxa de falhas na média do kernel	[45]
Recuperação de drivers no MINIX 3	100% no emulador, mais de 99% em hardware real	[47]
Recuperação no Nooks (Linux)	99% das falhas que derrubariam o Linux	[43]
Custo da prova do seL4	cerca de 20 pessoas-ano, 200.000 linhas de Isabelle	[84]
Licenças	Linux na GPL em 1992; 4.4BSD-Lite, livre do processo, em 1994; MINIX em BSD em 2000	[28], [30], [33], [23]

Onde Tanenbaum acertou

Acertou no diagnóstico de confiabilidade. Os bugs se concentram nos drivers [42], [43], e num kernel monolítico um driver ruim derruba tudo, como a Microsoft documenta para o Windows [8] e como vale para o Linux. Acertou que um desenho com drivers isolados permite recuperar falhas que, num kernel monolítico, seriam fatais, e o MINIX 3 mediu isso [47]. Acertou que código privilegiado pequeno é o que permite garantias fortes: o seL4 só foi provado correto porque tem 8.700 linhas de C [84]. Acertou que o microkernel teria espaço onde a falha custa caro, dos modems da Qualcomm [51] ao Secure Enclave [55]. E acertou o efeito do processo contra o BSD sobre o sucesso do Linux, coisa que o próprio Torvalds confirmou [11], [6].

Onde Tanenbaum errou

Errou feio no mercado. Disse que o debate estava "essentially over" e que "Microkernels have won" [1]; o desktop e o servidor seguiram monolíticos ou híbridos, inclusive o XNU que ele mesmo classificou como "not a true microkernel" [35] e o NT, que levou a parte gráfica para o kernel justamente por desempenho [73]. Disse que o 80x86 "is not going to be around all that long" [1]; o macOS 26 ainda é certificado UNIX em Macs Intel, em 2025 [7], e o Linux mantém documentação própria para x86 ao lado de mais quinze arquiteturas [90]. Previu que em cinco anos "everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5" [4]; em 1997 o GNU estava na versão 0.2 [29]. Previu que coordenar programadores espalhados pelo mundo seria "as easy as herding cats" [4], e o projeto que ele imaginava anárquico hoje roda nos 500 maiores supercomputadores [2]. Tratou portabilidade como virtude do microkernel, quando Liedtke escreveria em 1995 que microkernels "are inherently not portable" [52]. Também usou o Windows NT como exemplo de microkernel em 1992 [1], para depois admitir que não era [53].

Onde Torvalds acertou

Acertou que estar disponível valia mais do que ser elegante [1]. Acertou que portabilidade de API importa mais para o usuário do que portabilidade do kernel. A troca para a GPL em 1992 [28], oito anos antes da troca do MINIX para a licença BSD [23], deu ao Linux a base de colaboradores que o MINIX recusou de propósito [6]. Acertou ao abrir o desenvolvimento cedo: em fevereiro de 1992 já sondava uma lista "linux-kernel" e aceitava mudanças pesadas de Ts'o desde a versão 0.10 [4]. Seu argumento de 2006 sobre o custo do estado compartilhado em microkernels é sério, a Microsoft usou o mesmo raciocínio no NT 4.0 [73], e ajuda a entender por que poucos sistemas de propósito geral seguiram esse caminho [50].

Onde Torvalds errou ou recuou

O "won't be big and professional" [10] ficou para a história como a previsão mais errada do tópico. A segunda é o "porting is impossible" de 1991 [10]: o kernel hoje tem documentação para dezesseis arquiteturas de processador [90]. Ele mesmo concedeu em 1992 que, do ponto de vista teórico, "linux looses" [1], e admitiu que a não portabilidade tinha ido "to an extreme" [1]. Em 2006, chamou de "flawed" a ideia de recarregar um serviço que falhou [50], e os experimentos do MINIX 3 e do Nooks mostram recuperação em mais de 99% das falhas de driver testadas [47], [43]. Em 2009, disse que o kernel estava "huge and bloated" [46]. E Tanenbaum tem razão quando diz que Torvalds creditou pouco os antecessores [6].

Conclusão: ótimo, não sagrado

Em 1992, um professor disse que o Linux era um passo de volta aos anos 1970, e um estudante respondeu que pelo menos estava disponível agora. Os dois tinham razão no que diziam, e cada um errou no que deixou de considerar.

O Linux merece o lugar que tem. Venceu porque estava pronto e livre de verdade em 1992, e porque aceitou contribuição de quem chegasse enquanto o MINIX recusava pedidos e o BSD estava no tribunal [6], [30]. Ganhar assim tem mérito, e foi assim que o software livre ganhou quase tudo o que ganhou.

Só que vencer não transforma o projeto em referência de arquitetura. O kernel Linux é monolítico, roda 26 milhões de linhas de drivers em modo kernel [75], e o próprio criador o chamou de inchado [46]. A crítica de Tanenbaum à confiabilidade continua de pé, e as respostas mais fortes a ela vieram de fora do Linux: o seL4 provado correto [84], o MINIX 3 recarregando drivers [47], o L4 nos modems [51], o UMDF do Windows [74] e o DriverKit da Apple [57]. O Linux respondeu à crítica do jeito dele, com FUSE, VFIO, eBPF e, agora, Rust [19], [20], [71], [83]. São respostas boas, mas não são a resposta que Tanenbaum pediu.

O crítico que chama o Linux de cópia do MINIX precisa ler o que o autor do MINIX escreveu: "the code was his" [6]. O devoto que acha que o Linux inventou tudo precisa ler as notas de lançamento do FreeBSD 4.0, o artigo do DTrace e o white paper do NT [59], [67], [73]. Os dois precisam ler o tópico de 1992 inteiro. Ali, Torvalds concorda que microkernels "are nicer" [1], e Tanenbaum diz que não está infeliz com o Linux [1].

Gosto de Linux. Uso todo dia, e continuo usando. Mas um kernel é ferramenta, e ferramenta a gente avalia pelo que os documentos mostram, não pela fé de quem a usa.

Fontes

Cada fonte abaixo foi lida (texto completo ou trecho relevante) durante a pesquisa. Sob cada referência está o que ela sustenta neste artigo. As citações são literais, e os horários históricos estão em GMT, como aparecem nos cabeçalhos originais.

[1]A. S. Tanenbaum e L. Torvalds, “LINUX is obsolete,” mensagens no grupo comp.os.minix, 29 jan. 1992, arquivadas pelo Linux Information Project. [Online]. Disponível em: https://www.linfo.org/obsolete.html ↩
- Post de Tanenbaum de 29/01/1992 (12:12:50 GMT): "a giant step back into the 1970s", "Microkernels have won", "the not-yet-released Windows/NT" como exemplo de microkernel, "LINUX is tied fairly closely to the 80x86. Not the way to go", "I think it is a gross error to design an OS for any specific architecture", "Don't get me wrong, I am not unhappy with LINUX", drivers do MINIX "in the kernel, but only because the brain-dead nature of the Intel CPUs", citação dos artigos de Rick Rashid sobre o Mach 3.0.
- Resposta de Torvalds de 29/01/1992 (23:14:26 GMT): "True, linux is monolithic, and I agree that microkernels are nicer", "linux looses", "If the GNU kernel had been ready last spring...", "Linux wins heavily on points of being available now", "as conformant to standards as I knew how", "non-portability to an extreme", "brain-damages of minix", "doesn't suck like minix does".
- Cabeçalho "Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam".
[2]ZDNet, “Linux Totally Dominates Supercomputers,” republicado por Linux.com, 15 nov. 2017. [Online]. Disponível em: https://www.linux.com/news/linux-totally-dominates-supercomputers-1/ ↩
- "All 500 of the world's fastest supercomputers are running Linux" na lista TOP500 de novembro de 2017; os dois últimos sistemas fora do Linux rodavam AIX.
[3]Android Open Source Project, “Kernel overview,” consultado em 4 out. 2026. [Online]. Disponível em: https://source.android.com/docs/core/architecture/kernel ↩
- "The Android kernel is based on an upstream Linux Long Term Supported (LTS) kernel."
[4]C. DiBona, S. Ockman e M. Stone (orgs.), “Appendix A: The Tanenbaum-Torvalds Debate,” em Open Sources: Voices from the Open Source Revolution. Sebastopol: O'Reilly, 1999. [Online]. Disponível em: https://www.oreilly.com/openbook/opensources/book/appa.html ↩
- Tanenbaum, 30/01/1992 (13:44:34 GMT): "I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful you are not my student...", "5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5", MINIX feito para rodar em PC de 4,77 MHz sem disco; versão PC vendia 2 para 1.
- Torvalds, "Apologies (was Re: LINUX is obsolete)", 30/01/1992 (15:38:16 GMT): "Apologies to ast", "I over-reacted", "some of the criticisms are valid", "my first, and hopefully last flamefest".
- Introdução da O'Reilly chama o participante de "user-hacker Ken Thompson (one of the founders of Unix)"; cabeçalho da mensagem: "kt4@prism.gatech.EDU (Ken Thompson)", "Organization: Georgia Institute of Technology", 03/02/1992; citação "microkernels are probably the wave of the future... easier to implement a monolithic kernel...".
- Tobin: "I find the single-threaded file system a serious pain when using Minix"; Tanenbaum: "A multithreaded file system is only a performance hack".
- Torvalds, 31/01/1992: "you automatically get a multithreaded kernel", "linux API is portable", fonte completa de cerca de 200 kB contra mais de 800 kB do i386.tar.Z do Mach, "minix is portable, but you can rewrite that as 'doesn't use any features'"; resposta sobre o professor de Helsinque ("the person here at the university that teaches OS design").
- Outros participantes: Ts'o ("is probably not much more than what is in a Minix implementation", "Linux is here, and GNU isn't", "ipso facto micro kernels must be the right approach"); Hedrick ("availability wins out over technical quality every time", "all they could distribute were diffs", "4.4's release date has a history of extreme slippage"); Graham ("about 12000 lines of code", "adding features is a royal pain"); Foard ("significantly slower"); Tanenbaum ("I AM NOT A THEORIST", QNX com 200.000 sistemas, "proven technology"); Miller; Haardt ("why I think AST is right"); Burns ("Linux will be obsolete"); Kevin Brown ("years of experience with monolithic kernels").
- "Unhappy campers" (03/02/1992): "10 messages from the 43,000 readers", MINIX a US$ 169, Coherent a US$ 99, 4.4BSD a US$ 800, "100% emotional", "Surely Linus' OS professor pointed this out"; Tanenbaum (05/02): "as easy as herding cats", "has never managed a software project"; Torvalds (06/02): "I won't.", lista "linux-kernel", Ts'o com "some heavy changes even to 0.10". Apêndice com 36 mensagens.
[5]L. Torvalds, “linux-0.01.tar.gz,” código-fonte do Linux 0.01, set. 1991, arquivo histórico do kernel.org (contagem de arquivos e linhas feita pelo autor). [Online]. Disponível em: https://cdn.kernel.org/pub/linux/kernel/Historic/linux-0.01.tar.gz ↩
- Contagem feita por mim com o tarball baixado em 4 out. 2026: 88 arquivos; arquivos .c, .h e .s somam 9.877 linhas; datas dos arquivos entre 15 jun. e 17 set. 1991, 60 deles entre 11 e 17 set. kernel/ 3.511 linhas; mm/memory.c + mm/page.s 298 linhas; fs/ 2.771 linhas.
- include/linux/sys.h: 67 entradas na tabela de syscalls, de sys_setup a sys_setsid; kernel/sys.c: 15 funções que só devolvem -ENOSYS (entre elas sys_mount, sys_umount, sys_rename, sys_mknod, sys_ptrace).
- include/linux/config.h: LINUS_HD, LASU_HD, "Amount of ram memory (in bytes, 640k-1M not discounted). Currently 8Mb". include/linux/sched.h: NR_TASKS 64, HZ 100, macro switch_to com ljmp para o TSS.
- Makefile: "chmem +65000 tools/build" e "If you don't have '-mstring-insns' in your gcc (and nobody but me has :-)". include/linux/fs.h: números de dispositivo "same as minix, so we can use the minix file system", NAME_LEN 14, SUPER_MAGIC 0x137F.
[6]A. S. Tanenbaum, “Some Notes on the 'Who wrote Linux' Kerfuffle,” Vrije Universiteit, 20 maio 2004. [Online]. Disponível em: https://www.cs.vu.nl/~ast/brown/ ↩
- Data: 20 de maio de 2004. Livro Operating Systems: Design and Implementation com o código do MINIX em 1987; disquetes por US$ 69 na Prentice Hall; boilerplate não aplicado a universidades/estudantes; 40.000 assinantes no comp.os.minix; 200 e-mails por dia, "No."; "everyone was trying to turn MINIX into a production-quality UNIX system...".
- O processo contra a BSDi "gave Linux the breathing space it needed to catch on"; Brown voou a Amsterdã em 23/03/2004; "AST: Is Microsoft one of them? KB: We have multiple funding sources".
- "He had my book, was running MINIX... But the code was his. The proof of this is that he messed the design up"; "Linus rewrote the whole thing as a big monolithic kernel"; "pretty good proof that it was a redesign"; QNX como "commercially successful microkernel"; crítica à atribuição: "Linus has done this far less than he should have... Ken and Dennis are the real heros"; "I met him once"; "My only regret is that he didn't develop Linux based on the microkernel technology of MINIX".
[7]The Open Group, “UNIX 03: Apple Inc., macOS version 26.0 Tahoe on Apple silicon-based Mac computers,” registro de 29 ago. 2025. [Online]. Disponível em: https://www.opengroup.org/openbrand/register/brand3725.htm ↩
- macOS 26.0 Tahoe registrado como UNIX 03 em 29-Aug-2025 (Apple Silicon; há registro equivalente para Intel); o registro nomeia o produto macOS, não o kernel.
[8]Microsoft, “User Mode and Kernel Mode,” Windows drivers, Microsoft Learn, consultado em 4 out. 2026. [Online]. Disponível em: https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode ↩
- "All code that runs in kernel mode shares a single virtual address space... If a kernel-mode driver crashes, it causes the entire operating system to crash."
[9]FreeBSD Project, “jail(8),” FreeBSD System Manager's Manual, consultado em 4 out. 2026. [Online]. Disponível em: https://man.freebsd.org/cgi/man.cgi?query=jail&sektion=8 ↩
- "The jail utility appeared in FreeBSD 4.0."
[10]L. Torvalds, “LINUX's History,” 31 jul. 1992, com as mensagens de 1991 no grupo comp.os.minix (25 ago., resposta a J. Kuoppala em 26 ago., anúncio da versão 0.02 em 5 out.). [Online]. Disponível em: https://www.cs.cmu.edu/~awb/linux.history.html ↩
- Post de 25/08/1991 (20:57:08 GMT), Organization: University of Helsinki: "just a hobby, won't be big and professional like gnu", "my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons)", "it's free of any minix code", "It is NOT protable".
- Resposta a Jyrki Kuoppala (26/08/1991): "Simply, I'd say that porting is impossible. It's mostly in C, but most people wouldn't call what I write C. It uses every conceivable feature of the 386 I could find, as it was also a project to teach me about the 386"; segmentos de 64 MB, máximo de 64 tarefas em 4 GB; "almost as much assembler as C"; "a porters nightmare"; "except maybe for the user-mode filesystems".
- Texto de julho de 1992: "0.01 sources weren't actually runnable", "0.01 didn't actually come with any binaries".
- Anúncio da 0.02 (05/10/1991), "Free minix-like kernel sources for 386-AT": "Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?", "no minix code has been used", "These sources still need minix-386 to be compiled", "Hurd will be out in a year (or two, or next month, who knows)".
[11]M. Linksvayer, “The Choice of a GNU Generation: An Interview With Linus Torvalds,” Meta Magazine, nov. 1993. [Online]. Disponível em: https://gondwanaland.com/meta/history/interview.html ↩
- Torvalds: "If 386BSD had been available when I started on Linux, Linux would probably never had happened."
[12]The Open Group, “UNIX 03: Huawei Technology Co., Ltd., Huawei EulerOS 2.0 on Huawei KunLun Mission Critical Server,” registro de 8 set. 2016. [Online]. Disponível em: https://www.opengroup.org/openbrand/register/brand3622.htm ↩
- Huawei EulerOS 2.0 on Huawei KunLun Mission Critical Server, UNIX 03, "Registered on: 8-Sep-2016"; certificado P1204 com renovação em 8 set. 2022. (O comunicado da Huawei fala em 2019; o artigo usa a data do registro.)
[13]G. Kroah-Hartman, “The Linux Kernel Driver Interface,” documentação do kernel Linux, consultado em 4 out. 2026. [Online]. Disponível em: https://docs.kernel.org/process/stable-api-nonsense.html ↩
- "this article describes the in kernel interfaces, not the kernel to userspace interfaces"; syscall interface "is very stable over time, and will not break"; programas pré-0.9 rodando no 2.6; pelo menos três reformas da pilha USB; "function names may change, structures may grow or shrink"; "trying to keep up with an ever changing kernel interface is also a rough job"; "good luck, you are on your own here, you leech".
[14]J. Liedtke, “Improving IPC by Kernel Design,” em Proc. 14th ACM Symp. on Operating Systems Principles (SOSP 1993), Asheville, 1993. [Online]. Disponível em: https://os.itec.kit.edu/downloads/improving-ipc.pdf ↩
- 486-DX50: mínimo teórico de 172 ciclos (3,5 µs), meta de 350, resultado de 250 ciclos (5 µs); ganho sobre o Mach "from a factor of 22 (8-byte messages) to 3 (4-Kbyte messages)"; mach_thread_self a 18 µs contra 2 µs de ida e volta mínima ao kernel.
[15]H. Härtig, M. Hohmuth, J. Liedtke et al., “The Performance of µ-Kernel-Based Systems,” 16th ACM Symposium on Operating Systems Principles (SOSP), Saint-Malo, out. 1997. [Online]. Disponível em: https://os.inf.tu-dresden.de/pubs/sosp97/ ↩
- SOSP 1997: "For L4Linux, the AIM benchmarks report a maximum throughput which is only 5% lower than that of native Linux. The corresponding penalty is 5 times higher for a co-located in-kernel version of MkLinux, and 7 times higher for a user-level version of MkLinux"; MkLinux sobre microkernel derivado do Mach.
[16]Apple, “Kernel Architecture Overview,” Kernel Programming Guide (arquivo de documentação), consultado em 4 out. 2026. [Online]. Disponível em: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/Architecture/Architecture.html ↩
- "OS X uses the term kernel somewhat differently than you might expect"; "The OS X kernel environment includes the Mach kernel, BSD, the I/O Kit, file systems, and networking components"; KEXTs carregadas "into kernel space"; drivers do I/O Kit implementados como KEXTs.
[17]Apple Inc., “Mach Overview,” em Kernel Programming Guide, Documentation Archive, consultado em 4 out. 2026. [Online]. Disponível em: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/Mach/Mach.html ↩
- Tasks: "units of resource ownership; each task consists of a virtual address space, a port right namespace, and one or more threads"; Ports: "Secure, simplex communication channels, accessible only via send and receive capabilities (known as port rights)"; "At the trap level, the interface to most Mach abstractions consists of messages sent to and from kernel ports"; mach_msg_overwrite_trap; MIG.
- "in OS X, Mach is linked with other kernel components into a single kernel address space. This is primarily for performance; it is much faster to make a direct call between linked components than it is to send messages or do remote procedure calls (RPC) between separate tasks"; "Mach is not primarily a communication hub between clients and servers".
[18]M. Kerrisk (ed.), “cgroups(7),” Linux manual page, consultado em 4 out. 2026. [Online]. Disponível em: https://man7.org/linux/man-pages/man7/cgroups.7.html ↩
- "The initial release of the cgroups implementation was in Linux 2.6.24."
[19]The Linux Kernel documentation, “FUSE Overview,” consultado em 4 out. 2026. [Online]. Disponível em: https://docs.kernel.org/filesystems/fuse/fuse.html ↩
- "A filesystem in which data and metadata are provided by an ordinary userspace process"; "FUSE is a userspace filesystem framework. It consists of a kernel module (fuse.ko), a userspace library (libfuse.*) and a mount utility (fusermount)"; "One of the most important features of FUSE is allowing secure, non-privileged mounts [...] A good example is sshfs"; "The filesystem daemon is running with the privileges of the mounting user"; a conexão "exists until either the daemon dies, or the filesystem is umounted".
[20]The Linux Kernel documentation, “VFIO - ‘Virtual Function I/O’,” consultado em 4 out. 2026. [Online]. Disponível em: https://docs.kernel.org/driver-api/vfio.html ↩
- "an IOMMU/device agnostic framework for exposing direct device access to userspace, in a secure, IOMMU protected environment"; "safe, non-privileged, userspace drivers"; "turns the VM into a userspace driver"; UIO "has no notion of IOMMU protection, limited interrupt support, and requires root privileges to access things like PCI configuration space".
[21]The Linux Kernel documentation, “Extensible Scheduler Class,” consultado em 4 out. 2026. [Online]. Disponível em: https://docs.kernel.org/scheduler/sched-ext.html ↩
- "a scheduler class whose behavior can be defined by a set of BPF programs"; "The system integrity is maintained no matter what the BPF scheduler does. The default scheduling behavior is restored anytime an error is detected, a runnable task stalls, or on invoking the SysRq key sequence SysRq-S".
[22]A. S. Tanenbaum, “An Open Letter to Intel,” Vrije Universiteit, nov. 2017. [Online]. Disponível em: https://www.cs.vu.nl/~ast/intel/. Cópia do Internet Archive de 7 nov. 2017: https://web.archive.org/web/20171107134506/http://www.cs.vu.nl/~ast/intel/ ↩
- Carta a "Mr. Krzanich": MINIX "inside the ME-11 management engine chip"; "the most widely used computer operating system in the world"; "The L4 microkernel has been running inside smartphone chips for years"; "apparently an older version of MINIX was used... Military-grade security was never a goal"; "that is Intel's business decision and a separate issue from the code it runs". Cópia mais antiga no Internet Archive: 7 nov. 2017.
[23]A. S. Tanenbaum, “MINIX is now available under the BSD license,” mensagem no grupo comp.os.minix, 7 abr. 2000, reproduzida no FAQ do MINIX. [Online]. Disponível em: https://minix1.woodhull.com/faq/mxlicense.html ↩
- Tanenbaum, 07/04/2000: "Better late than never. I finally got permission from Prentice Hall to change the MINIX license to the BSD license. The lawyers sort of sat on this for two years."
[24]kernel.org, “Index of /pub/linux/kernel/v1.0/,” consultado em 4 out. 2026. [Online]. Disponível em: https://cdn.kernel.org/pub/linux/kernel/v1.0/ ↩
- Arquivos do Linux 1.0 datados de 13-Mar-1994.
[25]A. S. Tanenbaum et al., código-fonte do MINIX 2.0.4 (kernel/proc.c, kernel/table.c, include/minix/type.h, fs/const.h), redistribuição não oficial “Minix QD” mantida por D. Given. [Online]. Disponível em: https://github.com/davidgiven/minix2 ↩
- kernel/proc.c: "The only system calls that exist in MINIX are sending and receiving messages. These are done by trapping to the kernel with an INT instruction"; mini_send copia direto se o destino espera, senão bloqueia o remetente numa fila; detecção de deadlock com ELOCKED; "User processes are only allowed to send to FS and MM".
- include/minix/type.h: message como união de mess_1 a mess_6, com m_source e m_type. lib/i386/rts/_sendrec.s: _send, _receive, _sendrec com int SYSVEC (33).
- kernel/table.c: tarefas TTY, DP8390, RTL8139, Sound Blaster, impressora, discos, disquete, memória, relógio e SYSTEM compiladas no kernel; MM, FS e INIT como processos.
- fs/const.h: SUPER_MAGIC 0x137F. commands/simple/chmem.c: "Author: Andy Tanenbaum".
[26]L. Torvalds, “RELEASE NOTES for Linux v0.01,” set. 1991. [Online]. Disponível em: https://www.kernel.org/pub/linux/kernel/Historic/old-versions/RELNOTES-0.01 ↩
- "uses no code from minix or other sources"; "you currently need minix to bootstrap the system"; licença original: "(C) 1991 Linus Torvalds... Full source must be available (and free)".
[27]R. Card, T. Ts'o e S. Tweedie, “Design and Implementation of the Second Extended Filesystem,” Proceedings of the First Dutch International Symposium on Linux, ISBN 90-367-0385-9. [Online]. Disponível em: https://web.mit.edu/tytso/www/linux/ext2intro.html ↩
- Linux "cross-developed under the Minix operating system"; suporte ao FS do MINIX para compartilhar discos; FS do MINIX "efficient and relatively bug-free"; limites de 64 MB e 14 caracteres; Extended File System em abril de 1992 no 0.96c, com 2 GB e 255 caracteres.
[28]L. Torvalds, “RELEASE NOTES for Linux v0.12,” 1992. [Online]. Disponível em: https://www.kernel.org/pub/linux/kernel/Historic/old-versions/RELNOTES-0.12 ↩
- Troca para a GPL: "make it compatible with the GNU copyleft, removing the 'you may not distribute it for money' condition. I agree"; vale a partir de 1º de fevereiro.
[29]GNU Project, “History,” página do GNU Hurd, cópia do Internet Archive de 2024. [Online]. Disponível em: https://web.archive.org/web/2024/https://www.gnu.org/software/hurd/history.html ↩
- Hurd sobre Mach como kernel oficial do GNU a partir de nov. 1991; GNU Hurd 0.1 em 1996-09-06; GNU 0.2 em 1997-06-16.
[30]M. K. McKusick, “Twenty Years of Berkeley Unix: From AT&T-Owned to Freely Redistributable,” em Open Sources. Sebastopol: O'Reilly, 1999. [Online]. Disponível em: https://www.oreilly.com/openbook/opensources/book/kirkmck.html ↩
- BSDi vendendo a partir de janeiro de 1992 por US$ 995, telefone 1-800-ITS-Unix; processo da USL contra a BSDi e depois a Universidade da Califórnia; audiência de liminar em dezembro de 1992, negada cerca de seis semanas depois; acordo em janeiro de 1994 (três arquivos removidos de 18.000); 4.4BSD-Lite em junho de 1994; BSDI, NetBSD e FreeBSD tiveram de recomeçar a partir dele.
[31]L. Jolitz, “386BSD Release 0.1 Released on Bastille Day is Thirty-Three Years Old Today,” Lynne's Take on Tech, 14 jul. 2025. [Online]. Disponível em: https://lynnesblog.telemuse.net/2025/07/14/386bsd-release-0-1-released-on-bastille-day-is-thirty-three-years-old-today/ ↩
- 386BSD 0.0 em março de 1992, depois da série no Dr. Dobb's Journal; 386BSD 0.1 em 14 de julho de 1992.
[32]The NetBSD Project, “The History of the NetBSD Project,” consultado em 4 out. 2026. [Online]. Disponível em: https://www.netbsd.org/about/history.html ↩
- NetBSD 0.8 lançado em 20 de abril de 1993; projeto fundado em 1993 a partir do 386BSD.
[33]The FreeBSD Documentation Project, “Chapter 1. Introduction,” em FreeBSD Handbook, consultado em 4 out. 2026. [Online]. Disponível em: https://docs.freebsd.org/en/books/handbook/introduction/ ↩
- Origem no "Unofficial 386BSD Patchkit" no começo de 1993; FreeBSD 1.0 em dezembro de 1993 sobre a Net/2; acordo USL/Novell; prazo até o fim de julho de 1994 para parar de distribuir o produto Net/2; 4.4BSD-Lite como nova base; FreeBSD 2.0 em dezembro de 1994 (novembro para refazer o sistema).
[34]K. Brown e J. Orndorff, “Samizdat: And Other Issues Regarding the 'Source' of Open Source Code,” Alexis de Tocqueville Institution, 20 maio 2004. [Online]. Disponível em: https://www.itreview.org/documents/acrobat/040524.pdf ↩
- Relatório de Kenneth Brown (presidente da AdTI) e Justin Orndorff, datado de 20 de maio de 2004, questionando a origem do código do Linux e o crédito a Torvalds.
[35]A. S. Tanenbaum, “Tanenbaum-Torvalds Debate Part II,” Vrije Universiteit, 2006. [Online]. Disponível em: https://www.cs.vu.nl/~ast/reliable-os/ ↩
- "Tanenbaum-Torvalds Debate Part II" (2006): "I met him once. He is a pleasant fellow and very smart..."; "Microsoft paid a guy named Ken Brown to write a book saying Linus stole Linux from my MINIX 1 system"; Mac OS X "sort of microkernelish... Since all of it runs in kernel mode... it is not a true microkernel"; lista QNX, Integrity, PikeOS, Symbian, L4Linux; "clearly I am not alone in seeing something in microkernels".
[36]A. Toptygin, mensagem a A. S. Tanenbaum publicada em “Comparison of Linux Code with MINIX Code,” Vrije Universiteit, 2004. [Online]. Disponível em: https://www.cs.vu.nl/~ast/brown/codecomparison/ ↩
- Mensagem de Alexey Toptygin: trabalho de consultoria para Ken Brown; resultados enviados em 17 de maio; "my analysis found no evidence whatsoever that any code was copied one way or the other"; Brown achava "clearly impossible for one person to write an OS".
[37]A. Toptygin, “Source comparison of early linux and minix versions,” 2004. [Online]. Disponível em: https://www.cs.vu.nl/~ast/brown/codecomparison/alexey.html ↩
- Comparou Linux 0.01, 0.11, 0.12 (e posteriores) com MINIX: "Only 4 actual similarities were found"; "the similarity was required by external factors (the C standard, the POSIX standard, the minix filesystem format)".
[38]LinuxWorld News Desk, “Linus Torvalds Isn't the 'Father of Linux',” LinuxWorld, 17 maio 2004, cópia do Internet Archive de 10 jun. 2004. [Online]. Disponível em: https://web.archive.org/web/20040610132547/http://www.linuxworld.com:80/story/44841.htm ↩
- E-mail de Torvalds à LinuxWorld, 17 de maio de 2004: "Ok, I admit it. I was just a front-man for the real fathers of Linux, the Tooth Fairy and Santa Claus"; Papai Noel finlandês com contatos na Universidade de Helsinque.
[39]Association for Computing Machinery, “Andrew S Tanenbaum: ACM Software System Award 2023,” consultado em 4 out. 2026. [Online]. Disponível em: https://awards.acm.org/award_winners/tanenbaum_1309681 ↩
- ACM Software System Award 2023: "For MINIX, which influenced the teaching of Operating Systems principles to multiple generations of students and contributed to the design of widely used operating systems, including Linux."
[40]J. Kara, “[PATCH v2] reiserfs: Deprecate reiserfs,” mensagem na lista reiserfs-devel, fev. 2022, arquivada pela LWN. [Online]. Disponível em: https://lwn.net/Articles/886142/ ↩
- Jan Kara (endereço suse), fev. 2022: "development has ceased quite some years ago... To reduce maintenance burden... schedule its removal to 2025".
[41]Phoronix, “ReiserFS Has Been Deleted From The Linux Kernel,” consultado em 4 out. 2026. [Online]. Disponível em: https://www.phoronix.com/news/ReiserFS-Deleted-Linux-6.13 ↩
- ReiserFS removido no Linux 6.13; cerca de 32,8 mil linhas.
[42]A. Chou, J. Yang, B. Chelf, S. Hallem e D. Engler, “An Empirical Study of Operating Systems Errors,” 18th ACM Symposium on Operating Systems Principles (SOSP), 2001. [Online]. Disponível em: https://web.stanford.edu/~engler/metrics-sosp-01.pdf ↩
- Análise estática do Linux e do OpenBSD; no Linux 2.4.1 "the vast majority of bugs are in drivers"; drivers com taxa de erro de 3 a 7 vezes a do resto do kernel; "almost seven times higher" no verificador de travas.
[43]M. M. Swift, B. N. Bershad e H. M. Levy, “Improving the Reliability of Commodity Operating Systems,” em Proc. 19th ACM Symp. on Operating Systems Principles (SOSP 2003), Bolton Landing, 2003. [Online]. Disponível em: https://swift.sites.cs.wisc.edu/classes/cs736-fa06/papers/nooks.pdf ↩
- "In Windows XP, for example, drivers account for 85% of recently reported failures"; "Nooks recovered automatically from 99% of the faults that caused Linux to crash"; 2.000 testes de injeção; Nooks com cerca de 22.000 linhas contra 2,4 milhões do kernel; drivers continuam no anel 0, isolados por tabelas de páginas em domínios de proteção leves.
[44]A. S. Tanenbaum, J. N. Herder e H. Bos, “Can We Make Operating Systems Reliable and Secure?,” IEEE Computer, v. 39, n. 5, maio 2006. [Online]. Disponível em: https://www.cs.vu.nl/~ast/Publications/Papers/computer-2006a.pdf ↩
- Tanenbaum, Herder e Bos, IEEE Computer, maio 2006: 6 a 16 bugs por 1000 linhas; "Using a conservative estimate of 6 bugs per 1000 lines of code the Linux kernel probably has something like 15,000 bugs; Windows has at least double that".
- MINIX 3: "The clock driver shares the microkernel's address space, but is scheduled as a separate process. No other drivers run in kernel mode"; kernel com 4.000 linhas e servidor de arquivos com 4.500; "fixed-length messages using the rendezvous principle"; notificações assíncronas por mapa de bits.
[45]N. Palix, G. Thomas, S. Saha, C. Calvès, J. Lawall e G. Muller, “Faults in Linux: Ten Years Later,” em Proc. ASPLOS 2011, Newport Beach, 2011, pp. 305–318. [Online]. Disponível em: https://coccinelle.gitlabpages.inria.fr/website/papers/asplos11.pdf ↩
- Estudo do 2.6.0 ao 2.6.33; kernel mais que dobrou, taxa de falhas caiu; drivers com staging = 57% do código desde o 2.6.30; taxa de falhas dos drivers "is now below that of other directories, such as arch (HAL) and fs (file systems)" e, desde o 2.6.19, "right at the average".
[46]A. Modine, “Linus calls Linux 'bloated and huge',” The Register, 22 set. 2009. [Online]. Disponível em: https://www.theregister.com/2009/09/22/linus_torvalds_linux_bloated_huge/ ↩
- LinuxCon, 21/09/2009 (publicado 22/09/2009): "We're getting bloated and huge. Yes, it's a problem"; "not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary".
[47]J. N. Herder, H. Bos, B. Gras, P. Homburg e A. S. Tanenbaum, “Failure Resilience for Device Drivers,” em Proc. 37th IEEE/IFIP Int. Conf. on Dependable Systems and Networks (DSN 2007), Edimburgo, 2007, pp. 41–50. [Online]. Disponível em: https://www.few.vu.nl/~ast/Publications/Papers/dsn-2007.pdf ↩
- Funcionamento do servidor de reencarnação: utilitário service com binário, nome estável, privilégios, período de heartbeat e script de política; detecção de saída, pânico, exceção de CPU ou MMU, heartbeats perdidos; pedido de troca pelo servidor de arquivos; data store publicando o novo endpoint; reemissão de I/O de bloco pendente.
- Experimentos: RTL8139 com wget de 512 MB, checksums corretos e perda de vazão de 25% a 1%; SATA lendo 1 GB, perda de 62% a 7%, mesmo SHA-1; DP8390 no Bochs, mais de 12.500 falhas injetadas, 347 travamentos detectáveis, "The subsequent recovery was successful in 100% of the induced failures"; mais de 99% no hardware real; cinco linhas alteradas na biblioteca de drivers.
- Limites: falhas bizantinas, corrupção silenciosa, bugs determinísticos, hardware quebrado; "In general, end-to-end checksums are required to prevent silent" corruption. DMA: "To perform DMA safely a driver should first request the kernel to set up the I/O MMU".
[48]MINIX 3 Wiki, “Frequently Asked Questions,” consultado em 4 out. 2026. [Online]. Disponível em: https://wiki.minix3.org/doku.php?id=faq ↩
- "MINIX 3 is 5-10% slower" que o MINIX 2 (drivers em modo kernel); "our priority has been reliability, not performance"; licença BSD.
[49]MINIX 3 Wiki, “Release notes 3.3.0,” consultado em 4 out. 2026. [Online]. Disponível em: https://wiki.minix3.org/doku.php?id=www:download:releasenotes-3.3.0 ↩
- "In 2008, the European Research Council awarded Prof. Andrew S. Tanenbaum [...] an Advanced Grant of €2.5 million"; licença BSD; PC e ARM; "Userland is largely compatible with NetBSD and runs thousands of NetBSD packages".
[50]L. Torvalds, “Hybrid (micro)kernels,” fórum Real World Technologies, 9 maio 2006. [Online]. Disponível em: https://www.realworldtech.com/forum/?threadid=65915&curpostid=65936 ↩
- Torvalds, 09/05/2006: "The fundamental result of access space separation is that you can't share data structures... All your algorithms basically end up being distributed algorithms"; "As to the whole 'hybrid kernel' thing - it's just marketing".
[51]G. Heiser e K. Elphinstone, “L4 Microkernels: The Lessons from 20 Years of Research and Deployment,” ACM Trans. on Computer Systems, vol. 34, n. 1, art. 1, abr. 2016. [Online]. Disponível em: https://trustworthy.systems/publications/nicta_full_text/8988.pdf ↩
- "The typical cost for a one-way message was around 100 µs"; "a trend to move core services back into the kernel". Tabela de IPC: L4 de 1993 a 5 µs; seL4 de 2013 em Core i7 Haswell 3,4 GHz a 0,09 µs (301 ciclos); ARM11 532 MHz, 188 ciclos.
- Qualcomm: "massive-scale commercial deployment when Qualcomm adopted it as a protected-mode real-time OS for the firmware of their wireless modem processors"; "running on the security processor of all recent Apple iOS devices"; nota 2: "Total deployment is now in the billions"; PikeOS "certified for use in safety-critical avionics and deployed in aircraft and trains".
- Drivers: "make all device drivers user-level processes", exceto timer e controlador de interrupções; drivers não verificados no kernel "would obliterate any guarantees"; "even 9,000 SLOC pushed the limits of what was achievable".
[52]J. Liedtke, “On µ-Kernel Construction,” em Proc. 15th ACM Symp. on Operating Systems Principles (SOSP 1995), Copper Mountain, 1995. [Online]. Disponível em: https://os.itec.kit.edu/downloads/publ_1995_liedtke_ukernel-construction.pdf ↩
- Critério de minimalidade: "only if moving it outside the kernel, i.e. permitting competing implementations, would prevent the implementation of the system's required functionality"; "µ-kernels are inherently not portable. Instead, they are the processor dependent basis for portable operating systems".
[53]A. S. Tanenbaum, “Followup statement on Ken Brown's motivation,” Vrije Universiteit, 21 maio 2004. [Online]. Disponível em: https://www.cs.vu.nl/~ast/brown/followup/ ↩
- 21 de maio de 2004: "Microsoft claimed that Windows NT 3.51 was a microkernel. It wasn't. It wasn't even close. Even they dropped the claim with NT 4.0"; "I would easily give up 20% in performance for a system that was robust, reliable".
[54]The Open Group, “UNIX 03: Apple Inc., macOS version 15.0 Sequoia on Apple silicon-based Mac computers,” registro de 12 set. 2024. [Online]. Disponível em: https://www.opengroup.org/openbrand/register/brand3710.htm ↩
- macOS 15.0 Sequoia registrado como UNIX 03 em 12-Sep-2024.
[55]Apple, “Apple Platform Security,” guia em PDF, consultado em 4 out. 2026. [Online]. Disponível em: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf ↩
- "The Secure Enclave Processor runs an Apple-customized version of the L4 microkernel."
[56]Apple Inc., “XNU kernel,” README do repositório apple-oss-distributions/xnu, consultado em 4 out. 2026. [Online]. Disponível em: https://github.com/apple-oss-distributions/xnu ↩
- "XNU is a hybrid kernel combining the Mach kernel developed at Carnegie Mellon University with components from FreeBSD and a C++ API for writing drivers called IOKit"; "osfmk - Mach kernel based subsystems"; "bsd - BSD subsystems code"; roda em x86_64 e ARM64.
[57]Apple Inc., “DriverKit,” Apple Developer Documentation, consultado em 4 out. 2026. [Online]. Disponível em: https://developer.apple.com/documentation/driverkit ↩
- "Develop device drivers that run in user space."; "The drivers you build with DriverKit run in user space, rather than as kernel extensions, which improves system stability and security".
[58]Apple Inc., “Deprecated Kernel Extensions and System Extension Alternatives,” Apple Developer Support, consultado em 4 out. 2026. [Online]. Disponível em: https://developer.apple.com/support/kernel-extensions/ ↩
- Extensões de kernel depreciadas; "Starting with macOS Big Sur, macOS releases no longer load kernel extensions that use deprecated KPIs by default".
[59]FreeBSD Project, “FreeBSD 4.0 Announcement,” 14 mar. 2000. [Online]. Disponível em: https://www.freebsd.org/releases/4.0R/announce/ ↩
- Anúncio do FreeBSD 4.0-RELEASE, 14 mar. 2000.
[60]P.-H. Kamp e R. N. M. Watson, “Jails: Confining the omnipotent root,” 2nd International SANE Conference, 2000. [Online]. Disponível em: https://papers.freebsd.org/2000/phk-jails/ ↩
- Kamp e Watson, 2000: jail "provides the ability to partition the operating system environment, while maintaining the simplicity of the UNIX 'root' model"; uso mais popular "providing virtual machine services in Internet Service Provider environments".
[61]M. Kerrisk (ed.), “mount_namespaces(7),” Linux manual page, consultado em 4 out. 2026. [Online]. Disponível em: https://man7.org/linux/man-pages/man7/mount_namespaces.7.html ↩
- Seção HISTORY: mount namespaces no Linux 2.4.19.
[62]kernel.org, “Index of /pub/linux/kernel/v2.6/,” consultado em 4 out. 2026. [Online]. Disponível em: https://cdn.kernel.org/pub/linux/kernel/v2.6/ ↩
- linux-2.6.24.tar.gz datado de 24-Jan-2008.
[63]M. Kerrisk (ed.), “namespaces(7),” Linux manual page, consultado em 4 out. 2026. [Online]. Disponível em: https://man7.org/linux/man-pages/man7/namespaces.7.html ↩
- "since Linux 3.8, no privilege is required to create a user namespace".
[64]FreeBSD Documentation Project, “Chapter 23. The Z File System (ZFS),” FreeBSD Handbook, consultado em 4 out. 2026. [Online]. Disponível em: https://docs.freebsd.org/en/books/handbook/zfs/ ↩
- ZFS "Originally developed at Sun Microsystems".
[65]FreeBSD Project, “FreeBSD 7.0-RELEASE Release Notes,” 2008. [Online]. Disponível em: https://www.freebsd.org/releases/7.0R/relnotes/ ↩
- "Support for Sun's ZFS has been added."
[66]FreeBSD Project, “FreeBSD 7.0-RELEASE Announcement,” 27 fev. 2008. [Online]. Disponível em: https://www.freebsd.org/releases/7.0R/announce/ ↩
- Anúncio do FreeBSD 7.0-RELEASE, 27 fev. 2008.
[67]B. M. Cantrill, M. W. Shapiro e A. H. Leventhal, “Dynamic Instrumentation of Production Systems,” USENIX Annual Technical Conference, Boston, jun. 2004. [Online]. Disponível em: https://www.usenix.org/legacy/event/usenix04/tech/general/full_papers/cantrill/cantrill.pdf ↩
- Cantrill, Shapiro e Leventhal (Solaris Kernel Development, Sun), USENIX 2004: DTrace instrumenta usuário e kernel "in a unified and absolutely safe fashion"; "zero probe effect".
[68]FreeBSD Project, “FreeBSD 7.1-RELEASE Release Notes,” 2009. [Online]. Disponível em: https://www.freebsd.org/releases/7.1R/relnotes/ ↩
- DTrace e dtrace(1) "have been imported from OpenSolaris".
[69]FreeBSD Project, “FreeBSD 7.1-RELEASE Announcement,” 4 jan. 2009. [Online]. Disponível em: https://www.freebsd.org/releases/7.1R/announce/ ↩
- Anúncio do FreeBSD 7.1-RELEASE, 4 jan. 2009.
[70]FreeBSD Documentation Project, “DTrace,” FreeBSD Handbook, consultado em 4 out. 2026. [Online]. Disponível em: https://docs.freebsd.org/en/books/handbook/dtrace/ ↩
- "DTrace... was developed by Sun™ as a tool for locating performance bottlenecks in production and pre-production systems."
[71]Kernel Newbies, “Linux 3.18,” consultado em 4 out. 2026. [Online]. Disponível em: https://kernelnewbies.org/Linux_3.18 ↩
- Lançamento em 7 dez. 2014; syscall bpf(): "eBPF programs are similar to kernel modules. They are loaded by the user process and automatically unloaded when process exits. [...] eBPF verifier statically determines that the program terminates and is safe to execute".
[72]A. S. Tanenbaum, “Rebuttal to Ken Brown,” Vrije Universiteit, 6 jun. 2004. [Online]. Disponível em: https://www.cs.vu.nl/~ast/brown/rebuttal/ ↩
- 6 de junho de 2004: David Cutler, "one of the principal architects of the operating system for the DEC VAX, VMS", contratado pela Microsoft para liderar o Windows NT; "Operating system designers of Cutler's quality are few and far between".
[73]Microsoft, “MS Windows NT Kernel-mode User and GDI White Paper,” TechNet, arquivado no Microsoft Learn (Previous Versions), consultado em 4 out. 2026. [Online]. Disponível em: https://learn.microsoft.com/en-us/previous-versions/cc750820(v=technet.10) ↩
- Camadas: HAL, "microkernel" (interrupções, DPCs, escalonamento, sincronização) e Executive; "From the start the Windows NT architecture has fallen squarely into the modified microkernel or macrokernel camp"; gerenciador de memória, cache, sistemas de arquivos, objeto/segurança, protocolos e servidor de rede e processos em modo kernel desde a primeira versão; Win32 como "application" privilegiada; USER e GDI no CSRSS.EXE no NT 3.51.
- Motivos da mudança no NT 4.0: buffer compartilhado de 64K, trocas de contexto; transição cliente-servidor num Pentium 100 "in the order of 60-70 m seconds", contra "4 to 5 m seconds" para modo kernel (a página renderiza "µ" como "m"; leio como microssegundos, que é a única leitura compatível com a ordem de grandeza); economia de 256K a 1 MB de working set; PowerPoint 15 a 20 por cento mais rápido; drivers gráficos inteiros em modo kernel.
- "No commercial operating system is based on a pure microkernel design. The reason is simple: the pure microkernel design is commercially impractical because it is too computationally expensive"; "What is the practical difference [...] between an operating system that crashes from time to time and one that continues running but loses all access to persistent storage?"; GDI do NT 3.51 falhando: "a system that appears to have crashed".
[74]Microsoft, “Overview of UMDF,” Windows drivers, Microsoft Learn, atualizado em 15 dez. 2021. [Online]. Disponível em: https://learn.microsoft.com/en-us/windows-hardware/drivers/wdf/overview-of-the-umdf ↩
- "UMDF drivers abstract hardware functionality, run in the user-mode environment"; processo hospedeiro, driver manager e reflector; "File system drivers, display drivers (...), and print drivers cannot be UMDF drivers".
[75]The Linux Kernel Archives, “linux-7.2.tar.xz,” 17 ago. 2026 (contagem de arquivos e linhas feita pelo autor). [Online]. Disponível em: https://cdn.kernel.org/pub/linux/kernel/v7.x/ ↩
- Contagem feita por mim em 4 out. 2026 sobre o tarball oficial (data no índice: 17-Aug-2026): 65.637 arquivos .c/.h/.S/.rs, 37.730.727 linhas; drivers/ 26.034.547 linhas (69,0%); arch/ 6,7%; sound/ 4,4%; fs/ 4,3%; kernel/ 1,5%; mm/ 0,6%; arquivos .rs 182.584 linhas (cerca de 0,5%). Na mesma data, o kernel.org listava 7.2.9 como estável (3 out. 2026) e 7.3-rc6 como mainline.
[76]Kernel Newbies, “Linux 2.6.14,” consultado em 4 out. 2026. [Online]. Disponível em: https://kernelnewbies.org/Linux_2_6_14 ↩
- Lançamento em 27 out. 2005; FUSE: "Allows to implement a fully functional filesystem in a userspace program".
[77]H.-J. Koch, “The Userspace I/O HOWTO,” documentação do kernel Linux, 2006. [Online]. Disponível em: https://docs.kernel.org/driver-api/uio-howto.html ↩
- UIO (documento de 2006-12-11): "bugs in your driver won't crash the kernel"; "updates of your driver can take place without recompiling the kernel"; rede, serial ou USB "are no candidates for an UIO driver".
[78]Kernel Newbies, “Linux 3.6,” consultado em 4 out. 2026. [Online]. Disponível em: https://kernelnewbies.org/Linux_3.6 ↩
- Lançamento em 30 set. 2012, com o VFIO.
[79]The Linux Kernel documentation, “eBPF verifier,” consultado em 4 out. 2026. [Online]. Disponível em: https://docs.kernel.org/bpf/verifier.html ↩
- "First step does DAG check to disallow loops and other CFG validation"; "Second step starts from the first insn and descends all possible paths. It simulates execution of every insn and observes the state change of registers and stack".
[80]Kernel Newbies, “Linux 6.12,” consultado em 4 out. 2026. [Online]. Disponível em: https://kernelnewbies.org/Linux_6.12 ↩
- Lançamento em 17 nov. 2024, com o sched_ext.
[81]J. Corbet, “A first look at Rust in the 6.1 kernel,” LWN.net, 13 out. 2022. [Online]. Disponível em: https://lwn.net/Articles/910762/ ↩
- Rust entrou no 6.1; "No system with a production 6.1 kernel will be running any Rust code".
[82]J. Corbet, “The (successful) end of the kernel Rust experiment,” LWN.net, 10 dez. 2025. [Online]. Disponível em: https://lwn.net/Articles/1049831/ ↩
- Consenso da Maintainers Summit de 2025: o Rust no kernel deixa de ser experimental e passa a ser parte central e permanente; a etiqueta "experimental" será removida. (A frase original tem travessão; o artigo parafraseia.)
[83]J. Corbet, “The state of the kernel Rust experiment,” LWN.net, 13 dez. 2025. [Online]. Disponível em: https://lwn.net/Articles/1050174/ ↩
- Ojeda: driver Nova com partes no mainline; "Android binder driver was merged for 6.18"; Android 16 com kernel 6.12 entregando o módulo ashmem em Rust: "So there are millions of real devices running kernels with Rust code now".
- Kroah-Hartman: drivers em Rust "are indeed proving to be far safer than those written in C"; "no such CVE has yet been issued". Airlie: DRM "about a year away" de exigir Rust em drivers novos. Torvalds: "after nearly five years, the time had come".
[84]G. Klein et al., “seL4: Formal Verification of an OS Kernel,” 22nd ACM Symposium on Operating Systems Principles (SOSP), out. 2009. [Online]. Disponível em: https://www.sigops.org/s/conferences/sosp/2009/papers/klein-sosp09.pdf ↩
- seL4 "comprises 8,700 lines of C code and 600 lines of assembler"; "the first formal proof of functional correctness of a complete, general-purpose operating-system kernel"; "With truly small kernels it becomes possible... to guarantee the absence of bugs"; NICTA e UNSW.
- Prova com 200.000 linhas de script Isabelle; "We have proved over 150 invariants"; kernel com custo total de 2,2 py incluindo Haskell; prova "in total about 20 py", seL4-specific "11 py"; regra de US$ 10 mil por linha para EAL6 daria "$87M for seL4"; bugs da segunda prova "mainly typos, misreading the specification, or failing to update all relevant code parts", suficientes para "crash the kernel or create security vulnerabilities".
[85]J. Edge, “Replacing x86 firmware with Linux and Go,” LWN.net, 20 nov. 2017. [Online]. Disponível em: https://lwn.net/Articles/738649/ ↩
- Jake Edge, 20/11/2017, sobre a palestra de Ronald Minnich (Google) na ELCE 2017 em Praga: "Ring -3... It runs MINIX 3 and is where the ME runs"; "year of MINIX 3 on the desktop"; pilhas IPv4/IPv6, sistemas de arquivos, drivers, servidores web; "can reimage the system even if the power is turned off".
[86]M. Ermolov e M. Goryachy, “How to Hack a Turned-Off Computer, or Running Unsigned Code in Intel Management Engine,” Black Hat Europe 2017. [Online]. Disponível em: https://www.blackhat.com/eu-17/briefings.html#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine ↩
- Palestra de Mark Ermolov e Maxim Goryachy na Black Hat Europe 2017, "How to Hack a Turned-Off Computer, or Running Unsigned Code in Intel Management Engine" (citada só para a existência e o título da palestra).
[87]MINIX 3, “What Is MINIX 3?,” consultado em 4 out. 2026. [Online]. Disponível em: https://www.minix3.org/ ↩
- "designed to be highly reliable, flexible, and secure"; "a tiny microkernel running in kernel mode with the rest of the operating system running as a number of isolated, protected, processes in user mode".
[88]MINIX 3 Wiki, “Features,” consultado em 4 out. 2026. [Online]. Disponível em: https://wiki.minix3.org/doku.php?id=www:documentation:features ↩
- "Tiny microkernel that runs in kernel mode"; "Each device driver is a separate user-mode process"; "Reincarnation server can reload failed drivers".
[89]Stichting MINIX Research Foundation, “minix: Official MINIX sources,” repositório no GitHub, tag v3.3.0 e commit 4db99f4 de 14 nov. 2018, consultado em 4 out. 2026. [Online]. Disponível em: https://github.com/Stichting-MINIX-Research-Foundation/minix ↩
- Tag mais recente v3.3.0; último commit no ramo principal: 4db99f4, 14/11/2018 07:26 UTC (04:26 BRT), "Remove building with NOCRYPTO option".
[90]The kernel development community, “CPU Architectures,” documentação do kernel Linux, consultado em 4 out. 2026. [Online]. Disponível em: https://docs.kernel.org/arch/index.html ↩
- Lista de arquiteturas documentadas: ARC, ARM, ARM64, LoongArch, m68k, MIPS, Nios II, OpenRISC, PA-RISC, powerpc, RISC-V, s390, SuperH, Sparc, x86, Xtensa (16).

Itens checados que não entraram como fonte

Samizdat e financiamento da AdTI: a afirmação de que a Microsoft pagou Brown aparece no artigo só como afirmação de Tanenbaum [35]; não usei fontes secundárias (Wikipedia, Linux.com) para afirmá-la como fato.
QNX: a documentação oficial (QNX SDP 8.0, "The Philosophy of the QNX OS") foi consultada, mas a página acessível não descreve os drivers em espaço de usuário; o artigo cita o QNX só pelo que Tanenbaum escreveu.
GNU Hurd: gnu.org bloqueou acesso direto (403); usei a cópia do Internet Archive.
Just for Fun (L. Torvalds e D. Diamond, 2001): procurei o texto para citar trechos sobre 1991, mas o Internet Archive só oferece empréstimo restrito e a busca interna falhou. Não citei o livro. Usei como memória primária o texto do próprio Torvalds de julho de 1992 ("LINUX's History") [10].
Contagens de linhas do Linux 0.01 e do Linux 7.2 são minhas, feitas nos tarballs oficiais do kernel.org em 4 out. 2026 (arquivos .c, .h, .s/.S e .rs, linhas físicas, sem descontar comentários). Outras ferramentas (cloc, sloccount) dão números menores.
White paper do NT: a página do Microsoft Learn mostra "m seconds" onde o original usava o símbolo µ. Tratei como microssegundos.
QNX: não consegui baixar documentação de arquitetura que sustente afirmações próprias; o QNX aparece só pelas palavras de Tanenbaum e de Heiser e Elphinstone.
osr2006.pdf (artigo de Tanenbaum na ACM SIGOPS OSR, 2006) é um PDF escaneado sem camada de texto e não foi usado.

Abstract

On January 29, 1992, Andrew S. Tanenbaum, a professor at the Vrije Universiteit in Amsterdam and the author of MINIX, opened a thread in the comp.os.minix group called "LINUX is obsolete". He wrote that Linux was "a giant step back into the 1970s" [1]. Thirty-four years later, Linux runs on all 500 of the world's fastest supercomputers [2] and is the basis of the Android kernel [3]. It would be easy to declare the professor defeated and close the matter. This article goes back to the original posts, to the code of Linux 0.01 and MINIX 2 and to the papers that measured bugs, IPC and driver recovery, to separate what is documented from folklore. Those who say Linux is a copy of MINIX are wrong. Those who treat Linux as the inventor of everything and look down on macOS, the BSDs and Windows are wrong too. Linux won because of its license and because it arrived at the right time. On reliability, Tanenbaum's technical argument still stands, Linux itself has been absorbing pieces of it, and much of what is credited to Linux appeared first in other systems.

The myths going around

I use Linux every day, at home and at work, and I work with FreeBSD too. I like both. That is exactly why the cult-like tone that conversations about operating systems tend to take bothers me. On one side is the critic who treats Linux as a botched copy of MINIX and swears that Tanenbaum, supposedly Linus's professor, disowned him from day one. On the other is the devotee who thinks Linux invented containers, that macOS is a toy for people who can't use a terminal, that BSD belongs in a museum and that every Windows driver is a time bomb.

What the two views have in common is a lack of interest in the documents. And the documents exist. The 1992 debate is archived word for word [1], [4]. The code of the first version of Linux is still on kernel.org [5]. Tanenbaum wrote at length about the origin of Linux when a Washington institute accused Torvalds of plagiarism in 2004 [6]. UNIX certifications are kept in a public register run by The Open Group [7]. Microsoft documents how Windows drivers run [8], and FreeBSD documents how long jails have existed [9].

These are the myths this text checks, each with the short answer the facts give:

Myth	What the documents show
"Linux is a copy of MINIX"	False as to the code. Torvalds developed on top of MINIX, copied its filesystem layout and drew on the book, but the code is his, and the one who says so is Tanenbaum himself [6].
"Tanenbaum was Linus's professor"	False. Torvalds studied in Helsinki; Tanenbaum, in Amsterdam, says he met him once [10], [6].
"Tanenbaum called Linux a step backwards"	True, in 1992. In the same message he said he was not unhappy with Linux, and in 2004 he defended it [1], [6].
"Torvalds never admitted anything"	False. He agreed that microkernels "are nicer" and apologized publicly the next day [1], [4].
"Linux won because it was technically superior"	Largely false. The protagonists themselves attribute the victory to GNU's delay and to the lawsuit against BSD [1], [11], [6].
"Linux isn't even UNIX"	True about the trademark. False if the idea is that a Linux system cannot pass the certification: one already has [12].
"The Linux ABI keeps breaking"	False for programs. True, and on purpose, for drivers inside the kernel [13].
"Microkernels are slow by nature"	Overstated. Mach was slow; in 1993 L3 was already delivering messages twenty times faster, and Linux on top of L4 lost 5% [14], [15].
"macOS is a microkernel because it uses Mach"	False. In XNU, Mach and BSD run together in kernel mode [16], [17].
"Linux invented containers"	False. FreeBSD's jail came out in 2000; the first version of cgroups entered Linux in 2008 [9], [18].
"Linux has nothing of a microkernel"	False. FUSE, UIO, VFIO and eBPF schedulers take pieces out of the kernel or isolate them, without changing the architecture [19], [20], [21].
"Microkernel means secure"	Overstated. Tanenbaum himself wrote that military-grade security was never a goal of MINIX [22].

The rest of the article shows where each line of this table comes from.

What MINIX was

MINIX was born to fit in a classroom. Tanenbaum wrote it to accompany the 1987 book Operating Systems: Design and Implementation, and the source code was sold separately by Prentice Hall for US$69 [6]. In the 1992 discussion, he explained that the limitation was deliberate: "An explicit design goal was to make it run on cheap hardware so students could afford it. In particular, for years it ran on a regular 4.77 MHZ PC with no hard disk" [4]. In the same message, he said the version for the original PC sold twice as many copies as the 286/386 version.

Calling MINIX a botched toy misses the intent. MINIX was small because the goal was teaching. But it is true that it was not fit to be a production system, and Tanenbaum did not want it to be. In 2004, he recounted that comp.os.minix reached 40,000 subscribers and that he got 200 emails a day asking for features, such as "I need pseudoterminals and I need them by Friday". The answer was usually "No." The reason: "everyone was trying to turn MINIX into a production-quality UNIX system and I didn't want it to get so complicated that it would become useless for my purpose, namely, teaching it to students" [6]. In February 1992 he was already saying the same thing in the group: he had turned down virtual memory, paging, symbolic links and window systems because he wanted to "keep the system simple enough for students to understand" [4]. He thought that niche would soon be filled by GNU or by Berkeley's BSD.

The license weighed in too. Prentice Hall wanted royalties from anyone who sold the system commercially, and the lawyers filled MINIX with "boilerplate", even though, according to Tanenbaum, "there was never any intention of really enforcing this against universities or students" [6]. In 1992, a copy cost US$169, the license allowed two backup copies, and professors could make unlimited copies for their students [4]. Anyone who improved the system, however, could only distribute differences from the official version. Charles Hedrick, of Rutgers, wrote in the same debate that he had left the MINIX community because the license, "while amazingly friendly", made life hard for anyone who wanted a 386 version: "all they could distribute were diffs", which made installation unworkable for a new user [4]. Full release took a long time. On April 7, 2000, Tanenbaum announced on comp.os.minix: "Better late than never. I finally got permission from Prentice Hall to change the MINIX license to the BSD license. The lawyers sort of sat on this for two years" [23]. By then, Linux 1.0 was six years old [24].

Inside MINIX: everything is a message

The code of MINIX 2.0.4, the last release of the 2 series, shows what Tanenbaum called a microkernel. It is still available in unofficial redistributions, such as David Given's [25]. The comment at the top of kernel/proc.c sums up the architecture: "The only system calls that exist in MINIX are sending and receiving messages. These are done by trapping to the kernel with an INT instruction" [25]. In the 386 library, the functions _send, _receive and _sendrec put the destination and the message address in registers, indicate the operation and execute int 33 [25].

Messages have a fixed size. In include/minix/type.h, the message type is a union of six formats, from mess_1 to mess_6, each with a combination of ints, longs and pointers, plus the source and type fields [25]. The kernel neither allocates buffers nor keeps message queues. Delivery follows the rendezvous principle: mini_send copies the message straight to the recipient if it is already blocked waiting for it; otherwise, the sender is blocked in a queue attached to the recipient until the latter calls receive [25]. The same code walks the chain of blocked senders to detect two processes trying to send to each other, and returns ELOCKED instead of letting the system deadlock.

Permissions were already minimal. User processes can only use the combined operation, which sends and waits for the reply, and can only talk to two destinations: "User processes are only allowed to send to FS and MM" [25]. In practice, a read() becomes, inside the library, a message to the file system (FS), and the FS talks to the disk task by message too. The task table in kernel/table.c shows the division: TTY, the DP8390 and RTL8139 network cards, Sound Blaster, printer, disk controllers, floppy, memory, clock and the system task were tasks compiled into the kernel image, while the memory manager (MM), the FS and INIT were separate processes [25].

That is the 1992 yardstick. Tanenbaum wrote in the original post that the file system and the memory manager ran as separate processes and that the I/O drivers were also processes, "in the kernel, but only because the brain-dead nature of the Intel CPUs makes that difficult to do otherwise" [1]. The drivers of MINIX 1 and 2 ran in kernel mode, like those of Linux. The difference was in form: each driver was a task with its own message loop, not a function called directly.

The design had a price that showed up in the debate. With a single FS process serving one request at a time, anyone reading a slow floppy blocked anyone who wanted to do something else. Richard Tobin, of the University of Edinburgh, complained: "I find the single-threaded file system a serious pain when using Minix" [4]. Tanenbaum replied that "A multithreaded file system is only a performance hack. When there is only one job active, the normal case on a small PC, it buys you nothing" [4]. For someone teaching, it was a detail. For someone using the system every day, it was not.

August 1991: a hobby that did not copy code

On August 25, 1991, Linus Torvalds, a student at the University of Helsinki, posted on comp.os.minix: "I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones". In the same post he asked what people liked or disliked about MINIX, "as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things)". The postscript was blunt: "Yes - it's free of any minix code, and it has a multi-threaded fs. It is NOT protable (uses 386 task switching etc)" [10].

The release notes of version 0.01, from September 1991, repeat the claim and explain the dependency: "Although linux is a complete kernel, and uses no code from minix or other sources, almost none of the support routines have yet been coded. Thus you currently need minix to bootstrap the system" [26]. Linux was born inside MINIX, compiled on it and installed from it. The dependency was one of environment, not of code.

Jyrki Kuoppala asked how much of the system was in C and whether it could be ported to the Amiga. Torvalds's answer, on August 26, is an honest portrait of the project: "Simply, I'd say that porting is impossible. It's mostly in C, but most people wouldn't call what I write C. It uses every conceivable feature of the 386 I could find, as it was also a project to teach me about the 386" [10]. He explained that each task had a 64 MB segment, with at most 64 tasks in 4 GB, that some C files were "almost as much assembler as C" and that the result was "a porters nightmare". Kuoppala also asked for user-mode file systems. Torvalds thought almost the whole list was feasible, "except maybe for the user-mode filesystems" [10]. The request would be granted fourteen years later, under another name.

What was inside Linux 0.01

The original tarball is still on kernel.org. The files are dated between June 15 and September 17, 1991, most of them (60) between September 11 and 17. By my count, there are 88 files, and the C sources, headers and assembly add up to 9,877 lines [5]. The tree already looks the way the kernel would look for decades: boot/ with the boot sector and the protected-mode entry code, kernel/, mm/, fs/, lib/, include/, init/main.c and a utility in tools/ that assembles the final image.

The organization shows the monolithic design from day one. The kernel/ directory has 3,511 lines and holds the scheduler, fork, signals and also the drivers: hd.c for the AT disk, console.c, serial.c, keyboard.s and tty_io.c [5]. There is no driver task and no message. The file system calls the disk driver the way it calls any other function. All of memory management fits in 298 lines, between mm/memory.c and mm/page.s, and the file system in 2,771 [5].

The system call table, in include/linux/sys.h, has 67 entries, from sys_setup to sys_setsid: number 1 is exit, followed by fork, read, write, open and close [5]. Not all of them worked. In kernel/sys.c, 15 of them just return -ENOSYS, among them sys_mount, sys_umount, sys_rename, sys_mknod and sys_ptrace [5]. Linux 0.01 could not mount file systems or rename files.

The code also shows who it was written for. The file include/linux/config.h has two disk configurations, LINUS_HD and LASU_HD, with the disk geometry of each machine and the comment "Amount of ram memory (in bytes, 640k-1M not discounted). Currently 8Mb" [5]. The root device was hard-coded. The context switch, in include/linux/sched.h, is the switch_to macro, which does an ljmp to the 386 task state segment: the "386 task switching" of the announcement, literally [5]. The limit of 64 tasks is there too (NR_TASKS 64), with the clock at 100 Hz.

And there are the fingerprints of MINIX, all of them about environment or format. The Makefile runs chmem +65000 tools/build [5]; chmem is a MINIX utility, written by Tanenbaum, that adjusts the memory reserved for an executable [25]. The same Makefile warns: "If you don't have '-mstring-insns' in your gcc (and nobody but me has :-)" [5]. In include/linux/fs.h, the device numbers are "same as minix, so we can use the minix file system", file names have at most 14 characters and the superblock magic number is 0x137F [5], the same SUPER_MAGIC defined in the MINIX file system [25]. None of these marks is copied code. As for the state of the release, Torvalds himself wrote in July 1992 that the 0.01 code "weren't actually runnable" and that the release "didn't actually come with any binaries": it was a gesture to those who had shown interest [10].

The usable release was 0.02. On October 5, 1991, Torvalds announced on comp.os.minix, with the subject "Free minix-like kernel sources for 386-AT": "Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?". The post warned that "Full kernel source is provided, as no minix code has been used", and also that "These sources still need minix-386 to be compiled" [10]. The line about the Hurd aged into a joke: "Hurd will be out in a year (or two, or next month, who knows)".

The borrowed file system

The most concrete inheritance is the disk format. The paper by Rémy Card, Theodore Ts'o and Stephen Tweedie on ext2 says that "In its very early days, Linux was cross-developed under the Minix operating system. It was easier to share disks between the two systems than to design a new filesystem, so Linus Torvalds decided to implement support for the Minix filesystem in Linux" [27]. The authors praise the MINIX file system as "efficient and relatively bug-free", but point to two limits: 16-bit block addresses, which restricted the volume to 64 MB, and file names of at most 14 characters.

The way out went through a layer that Linux 0.01 did not have. To make it easier to add new file systems, the kernel gained a Virtual File System (VFS), "initially written by Chris Provenzano, and later rewritten by Linus Torvalds" [27]. On top of it, the Extended File System entered Linux 0.96c, in April 1992, and raised the limits to 2 GB and 255 characters. It still had problems: it did not keep three separate timestamps, and it tracked free blocks and inodes with linked lists that became unsorted with use and fragmented the disk. In January 1993, two successors came out in alpha: Xia, "heavily based on the Minix filesystem kernel code", and ext2, derived from ext and designed to grow [27]. Xia was born more stable; ext2 won because it was fixed and extended.

Implementing a compatible disk format is different from copying the code that reads it. That holds for MINIX in the same way it holds for NTFS or FAT support in today's Linux.

The license that changed twice

The first Linux license was not the GPL. The 0.01 release notes say: "This kernel is (C) 1991 Linus Torvalds, but all or part of it may be redistributed provided you do the following: Full source must be available (and free)" [26]. The original version also forbade charging for distribution. In the 0.12 notes, Torvalds announced the change: "I've had a couple of requests to make it compatible with the GNU copyleft, removing the 'you may not distribute it for money' condition. I agree" [28]. The GPL took effect on February 1, 1992.

January 1992: "LINUX is obsolete"

Tanenbaum's post went out on January 29, 1992 [1]. He began by introducing himself as someone who saw MINIX as a pastime ("something that I do in the evening when I get bored writing books") and whose real job was researching operating systems. Then he listed two problems with Linux.

What Tanenbaum wrote

The first was architectural. Tanenbaum defined a monolithic system as one in which "the whole operating system is a single a.out file that runs in 'kernel mode'" and cited UNIX, MS-DOS, VMS and MULTICS as examples. Among the microkernel examples, he cited Amoeba, Chorus, Mach and "the not-yet-released Windows/NT". And he decreed: "among the people who actually design operating systems, the debate is essentially over. Microkernels have won." On Linux: "LINUX is a monolithic style system. This is a giant step back into the 1970s. That is like taking an existing, working C program and rewriting it in BASIC. To me, writing a monolithic system in 1991 is a truly poor idea" [1].

The second was portability. Tanenbaum predicted that RISC chips would "gradually take over from the 80x86 line" and wrote: "I think it is a gross error to design an OS for any specific architecture, since that is not going to be around all that long." He concluded: "LINUX is tied fairly closely to the 80x86. Not the way to go" [1].

Those who say Tanenbaum called Linux a step backwards are right, because the line exists. But in the same message he wrote "Don't get me wrong, I am not unhappy with LINUX" [1]. The criticism was about architecture, in a technical discussion group, and it came some five months after the August announcement.

What Torvalds replied

Torvalds replied the same day, and without diplomacy. He called the limitations that Tanenbaum blamed on his teaching job "brain-damages of minix" and wrote "I can only hope (and assume) that Amoeba doesn't suck like minix does" [1]. On the merits, however, he conceded the main point: "True, linux is monolithic, and I agree that microkernels are nicer. [...] From a theoretical (and aesthetical) standpoint linux looses."

His argument was a different one: "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" [1]. On portability, he argued that Linux was more portable than MINIX at the level that mattered to the user, the API: "I made linux as conformant to standards as I knew how (without having any POSIX standard in front of me)". And he admitted the rest: "I also agree that linux takes the non-portability to an extreme" [1].

Tanenbaum came back on the 30th with the most quoted line of the discussion: "I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful you are not my student. You would not get a high grade for such a design :-)" [4]. In the same message, he made the prediction that aged worst: "5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5".

The apology

Still on January 30, Torvalds posted a message with the subject "Apologies (was Re: LINUX is obsolete)": "And reply I did, with complete abandon, and no thought for good taste and netiquette. Apologies to ast [...] I over-reacted, and am now composing a (much less acerbic) personal letter to ast." He kept his technical position ("I still think that's not the case, although some of the criticisms are valid") and signed as "Linus 'my first, and hopefully last flamefest' Torvalds" [4].

The portrait of an arrogant Torvalds incapable of self-criticism does not survive a reading of the thread. He was rude, yes. The same day, he apologized and acknowledged that some of the criticisms were valid.

The technical reply of January 31

Torvalds's next message, by then without insults, is the best technical defense he made in 1992, and almost nobody cites it. On the multithreaded file system, he replied that it is only a performance hack "on a microkernel": "When writing a unix the 'obsolete' way, you automatically get a multithreaded kernel: every process does it's own job, and you don't have to make ugly things like message queues to make it work efficiently" [4]. It is the shared-state argument, fourteen years before he spelled it out.

On portability, he separated the interface from the implementation: "Yes, the /implementation/ is hardware-specific, but there's a HUGE difference [...] linux API is portable (not due to my clever design, but due to the fact that I decided to go for a fairly-well-thought-out and tested OS: unix.)" [4]. And he did the size math: the complete Linux source was about 200 kB compressed, while the 386-dependent part of Mach alone, i386.tar.Z, was over 800 kB [4]. He also turned the accusation back on MINIX: if the system was portable because it ran on machines that had not been made for Unix, then "minix is portable, but you can rewrite that as 'doesn't use any features', and still be right" [4].

The rest of the thread

The O'Reilly appendix reproduces 36 messages, and most of them are by neither protagonist [4]. They show that the 1992 community understood the debate better than many people do today.

Theodore Ts'o, of MIT, who would later co-author ext2, answered Tanenbaum on January 31. He said that the amount of 80386-specific code in Linux "is probably not much more than what is in a Minix implementation", and much smaller than the VAX-specific code in BSD 4.3. And he closed with a line that sums up the choice many people made: "the fact remains that Linux is here, and GNU isn't [...] Minix doesn't count because it's not free. :-)" [4]. He also had an explanation for the academic consensus: "since only researchers write papers about operating systems, ipso facto micro kernels must be the right approach" [4].

Charles Hedrick, of Rutgers, was drier: "The history of software shows that availability wins out over technical quality every time. That's Linux' major advantage" [4]. Douglas Graham, of Bell-Northern Research, asked what unbiased literature supported "Microkernels have won", put Linux at "about 12000 lines of code" and wrote: "I don't see how splitting that into tasks and blasting messages around would improve it" [4]. For him, MINIX's problem was not performance: "adding features is a royal pain".

Some proposed a middle ground. Lawrence Foard, of Worcester Polytechnic Institute, said he was writing IPC code for Linux that would let drivers and file systems run as user processes, with the caveat that they would be "significantly slower" and that "it would be a mistake to move everything outside the kernel" [4]. He also accused the theorists of never testing their own ideas. Tanenbaum answered in capitals, "I AM NOT A THEORIST", and listed what he saw as proof: OSF was betting its business on Mach 3.0, USL on Chorus, Amoeba was implemented and QNX had, he had been told, 200,000 installed systems. "Microkernels are not a pipe dream. They represent proven technology" [4].

Tanenbaum's side had defenders too. David Miller, who introduced himself as an observer, applauded both authors but asked: "Why split fundemental os functions, such as memory management, into user processes?" [4]. Michael Haardt titled his message "why I think AST is right". And Randy Burns, of Sun, made a bet that seemed sensible: "It may well be that in 2-3 years when ultra cheap BSD variants and Hurd proliferate, that Linux will be obsolete" [4].

License and control: the part nobody remembers

On February 3, Tanenbaum opened another thread, "Unhappy campers", because he was getting irritated emails ("10 messages from the 43,000 readers"). He defended MINIX's price, compared it with Coherent at US$99 and 4.4BSD at US$800, and wrote that the free software question was "100% emotional" [4]. Then he asked whether Torvalds would let Linux slip out of his control, and whether other people could modify it and sell it.

Torvalds's answer, on February 6, fits in two words: "I won't." He said he had already floated the idea of a "linux-kernel" list that would decide on releases, because he would not have the hardware to support everything, citing SCSI, and that Ts'o had already made "some heavy changes even to 0.10" [4]. Tanenbaum, on February 5, had made the opposite prediction: coordinating a thousand programmers spread around the world would be "as easy as herding cats", and "Anyone who says you can have a lot of widely dispersed people hack away on a complicated piece of code and avoid total anarchy has never managed a software project" [4]. The history of the kernel since then is a long refutation of that sentence.

Who was the "Ken Thompson" in the thread

The appendix of the O'Reilly book Open Sources, which reproduces the debate, says the thread features "user-hacker Ken Thompson (one of the founders of Unix)" [4]. The message header, in the appendix itself, says something else: "From: kt4@prism.gatech.EDU (Ken Thompson)", "Organization: Georgia Institute of Technology", February 3, 1992. The text is short and sensible: "I would generally agree that microkernels are probably the wave of the future. However, it is in my opinion easier to implement a monolithic kernel. It is also easier for it to turn into a mess in a hurry as it is modified" [4]. Nothing in the header ties the author to the creator of Unix. Kevin Brown, of the University of Houston, replied as if he were talking to the creator of Unix ("I figure you've got years of experience with monolithic kernels :-)"), which suggests the confusion, or the joke, began in the group itself [4]. Everything points to a namesake with a Georgia Tech account, and O'Reilly's identification does not hold up against the document it publishes itself.

Why Linux won

The mystical view says Linux won because it was better. The protagonists tell a more prosaic story, and they tell the same one.

Torvalds, in January 1992: if the GNU kernel had been ready the previous spring, he would not even have started; "Linux wins heavily on points of being available now" [1]. GNU had chosen the Hurd, on top of Mach, as its official kernel in 1991, but the first test release, Hurd 0.1, only came out on September 6, 1996, and GNU 0.2 in June 1997 [29]. By then Linux 1.0 was more than two years old: it came out on March 13, 1994 [24].

Berkeley's BSD was the natural candidate, and it was technically ready. It got stuck in the courts, and the details of the lawsuit explain why the delay weighed so much.

Berkeley, 386BSD and the six files

Kirk McKusick, who worked at Berkeley's Computer Systems Research Group (CSRG), tells the story in the same O'Reilly book [30]. In June 1989, Berkeley released Networking Release 1, the networking code and utilities that did not depend on an AT&T license: "the first freely-redistributable code from Berkeley". Keith Bostic then proposed going further. Bostic, Mike Karels and McKusick spent months reviewing the distribution file by file to remove whatever came from AT&T's 32/V. What was left were "only six remaining kernel files that were still contaminated and which could not be trivially rewritten". Berkeley decided to release the rest anyway, as Networking Release 2, in June 1991, for a fee of US$1,000 [30].

In less than six months, Bill Jolitz wrote replacements for the six files and published a complete, bootable system for 386 PCs, 386/BSD, by anonymous FTP: "Within weeks he had a huge following" [30]. Lynne Jolitz, co-author of the work, says that 386BSD 0.0 came out in March 1992, after two years of documenting the port in Dr. Dobb's Journal, and that 386BSD 0.1 came out on July 14, 1992 [31]. According to McKusick, Jolitz could not keep up with the flood of fixes because of his full-time job, and a group of users formed NetBSD to maintain the system [30]. The first NetBSD release, 0.8, is from April 20, 1993 [32]. FreeBSD was born in early 1993 from the last three coordinators of the "Unofficial 386BSD Patchkit", and FreeBSD 1.0 came out in December 1993, still based on Net/2 [33].

The lawsuit, step by step

Meanwhile, a company, Berkeley Software Design, Inc. (BSDi), added Jolitz's six files to Net/2 and began selling the system with sources and binaries in January 1992, for US$995, with ads telling people to call 1-800-ITS-Unix [30]. Unix System Laboratories (USL), a majority-owned subsidiary of AT&T, sent a letter demanding that the company stop calling its product Unix and drop the phone number. BSDi changed the number and the ads. USL sued anyway, alleging proprietary code and trade secrets, and asked for an injunction to halt sales [30].

At the preliminary hearing, the judge accepted BSDi's argument that it was only distributing what the University of California distributed, plus six files, and told USL to restate its complaint based solely on those six files or see the case dismissed. USL refiled against BSDi and against the university, also asking for Net/2 to be halted [30]. In December 1992, federal judge Dickinson R. Debevoise, of New Jersey, heard the arguments. About six weeks later, he issued a forty-page decision that denied the injunction and threw out all but two of the complaints, suggesting that the case go first to a state court. The following Monday, the university filed suit in California, accusing USL of failing to give due credit for the BSD code included in System V [30].

Soon after, Novell bought USL from AT&T. According to McKusick, Novell's president, Ray Noorda, said publicly that he would rather compete in the marketplace than in court. Negotiations began in the summer of 1993 and ended in January 1994: three files were removed from the 18,000 in Net/2, others received small changes, and about 70 began to carry a USL copyright while remaining freely redistributable [30]. 4.4BSD-Lite came out in June 1994, and the settlement guaranteed that USL would not sue anyone who used it as a base. FreeBSD had until the end of July 1994 to stop distributing its Net/2-based product, took until November to rebuild the system on 4.4BSD-Lite and released FreeBSD 2.0 in December [33].

Add up the dates. Between BSDi's commercial launch, in January 1992, and FreeBSD 2.0, in December 1994, anyone who wanted a free BSD for the PC lived with almost three years of legal uncertainty. That is exactly the period in which Linux went from version 0.12 to 1.0 and traded its own license for the GPL [28], [24]. Hedrick already foresaw the problem in February 1992: his ideal system was 4.4BSD, but "4.4's release date has a history of extreme slippage" [4].

What both sides said later

Both sides of the debate agree on the effect. Torvalds told Meta magazine in November 1993: "If 386BSD had been available when I started on Linux, Linux would probably never had happened" [11]. Tanenbaum, in 2004: "This delay in getting free BSD out there gave Linux the breathing space it needed to catch on. If it hadn't been for the lawsuit, undoubtedly BSD would have filled the niche for a powerful, free UNIX clone as it was already a stable, mature system with a large following" [6].

Add the license to that. Linux had been under the GPL since February 1992 [28], and MINIX only switched to BSD in 2000 [23]. In 1992, anyone who wanted a free Unix for a 386 PC had one system available that accepted contributions and let anyone redistribute it. That system was Linux. Torvalds's merit was enormous and needs no exaggeration: he was ready when the others were not, and he knew how to accept code from whoever showed up.

2004: the report that accused Linus of copying

The copying myth got an "official" version in May 2004. Kenneth Brown, president of the Alexis de Tocqueville Institution (AdTI), in Washington, published Samizdat, a text dated May 20, 2004 that questioned the origin of the Linux code and the credit given to Torvalds [34].

Tanenbaum replied the same day, May 20, on a page called "Some Notes on the 'Who wrote Linux' Kerfuffle". He recounted that Brown flew to Amsterdam to interview him on March 23, 2004 and dodged the question when asked about funding. The transcript is curt: "AST: Is Microsoft one of them? KB: We have multiple funding sources" [6]. Two years later, Tanenbaum wrote bluntly that "Microsoft paid a guy named Ken Brown to write a book saying Linus stole Linux from my MINIX 1 system" [35]. The claim is Tanenbaum's. In the 2004 interview, Brown only repeated that he had "multiple funding sources" [6].

The core of the 2004 reply takes the myth apart better than any Linux advocate could:

Thus, of course, Linus didn't sit down in a vacuum and suddenly type in the Linux source code. He had my book, was running MINIX, and undoubtedly knew the history (since it is in my book). But the code was his. The proof of this is that he messed the design up. [6]

Tanenbaum goes on: instead of writing a new file system and a new memory manager on top of the microkernel, "Linus rewrote the whole thing as a big monolithic kernel, complete with inline assembly code :-(". And he concludes: "producing a system that was fundamentally different from the base he started with seems pretty good proof that it was a redesign" [6].

The copying accusation was also tested against the code. Alexey Toptygin, hired as a consultant by Brown himself, compared Linux 0.01, 0.11, 0.12 and later versions with MINIX. He delivered the result to Brown on May 17, 2004: "my analysis found no evidence whatsoever that any code was copied one way or the other" [36]. The technical report found "Only 4 actual similarities", and in each case "the similarity was required by external factors (the C standard, the POSIX standard, the minix filesystem format)" [37]. According to Toptygin, Brown spent their next conversation trying to convince him that he was wrong, because "it was clearly impossible for one person to write an OS" [36].

Torvalds answered the report with irony. He sent LinuxWorld an email that began: "Ok, I admit it. I was just a front-man for the real fathers of Linux, the Tooth Fairy and Santa Claus" [38]. The joke went on: Santa Claus had contacts at the University of Helsinki because he was Finnish.

Tanenbaum made a caveat that Linux fans tend to skip. He thinks Torvalds gave too little credit to his predecessors: "In science it is considered important to credit people for their ideas, and I think Linus has done this far less than he should have. Ken and Dennis are the real heros here. But Linus' sloppiness about attribution is no reason to assert that Linus didn't write Linux" [6]. He also made clear where his disagreement lay: "My only regret is that he didn't develop Linux based on the microkernel technology of MINIX" [6].

The ACM summed up MINIX's legacy in a balanced way when it gave Tanenbaum the 2023 Software System Award: the prize was "For MINIX, which influenced the teaching of Operating Systems principles to multiple generations of students and contributed to the design of widely used operating systems, including Linux" [39]. MINIX influenced the design of Linux. It did not give it its code.

Professor and student?

A variation of the myth says Tanenbaum was Torvalds's professor, and that the student betrayed his master. The 1991 post comes from a University of Helsinki account [10]; Tanenbaum taught at the Vrije Universiteit, in Amsterdam [1]. In 2004 he wrote: "Linus and I are not 'enemies' or anything like that. I met him once and he seemed like a nice friendly, smart guy" [6]. In 2006, he repeated: "I met him once. He is a pleasant fellow and very smart. We may disagree on some technical issues, but that doesn't make us enemies" [35]. The 1992 "Be thankful you are not my student" was rhetoric, precisely because Torvalds was not his student. The thread itself makes this clear twice. Torvalds replied that he would not get a good grade anyway, because he had argued with "the person here at the university that teaches OS design", in Helsinki. And Tanenbaum, in the "Unhappy campers" thread of February 3, wrote about portability: "Surely Linus' OS professor pointed this out" [4]. Someone who talks about another person's professor is not that person's professor.

"Linux isn't even UNIX"

Here the myth gets more right than wrong. UNIX is a registered trademark of The Open Group, and only a product that passes the specification's test suite and signs the trademark license agreement may use it. macOS 26 Tahoe, for example, has been registered as UNIX 03 since August 29, 2025, for Macs with Apple Silicon and with Intel [7]. Common Linux distributions are not in that register, so calling them UNIX is technically wrong. Linux is not BSD either: it does not derive from Berkeley's code and was written from scratch [26].

Two details take apart the exaggerated version of the argument. The first: certification is for a complete product, not for a kernel. The Open Group register says "macOS version 26.0 Tahoe", not "XNU" [7]. Saying a kernel is "UNIX certified" confuses things, whether the kernel is XNU or Linux.

The second: a Linux-based system has already passed the certification. Huawei EulerOS 2.0, running on KunLun servers, appears in the UNIX 03 register with a registration date of September 8, 2016 and renewal due on September 8, 2022 [12]. It passed the same test suite as macOS. So the idea that "Linux doesn't respect POSIX" does not hold up as a technical rule. I found no official document explaining why common distributions do not get certified. My reading is that the trademark is not worth the cost for companies that already sell Linux support, but that is opinion. In 1992, Torvalds already said he had made Linux "as conformant to standards as I knew how", even without the POSIX standard at hand [1].

The honest summary: Linux is not UNIX on paper, because it does not have the trademark. In practice, a certified Linux proved that this is not for lack of technical capability.

"The Linux ABI keeps breaking"

This myth mixes up two different interfaces, and the kernel documentation separates them on its first page. Greg Kroah-Hartman wrote the text that explains why Linux has no stable interface for drivers, and it opens with a warning: "Please realize that this article describes the in kernel interfaces, not the kernel to userspace interfaces" [13].

On the interface that programs use, the text leaves no room for doubt: "The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is very stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still work just fine on the latest 2.6 kernel release" [13]. Anyone who says system calls change with every release is wrong.

The internal interface, the one drivers use, changes on purpose. The same document cites at least three overhauls of the USB stack and explains that, when a developer finds a better way, "function names may change, structures may grow or shrink, and function parameters may be reworked", and every user inside the tree is fixed at once [13]. The recommendation for anyone with an out-of-tree driver is to put it in the tree. And for those who can't, because the driver is closed: "good luck, you are on your own here, you leech" [13].

Here Linux takes a fair criticism. The choice has a real cost for anyone who buys hardware whose driver the manufacturer keeps out of the tree: when the internal interface changes, that driver has to be adapted, and the document itself admits that keeping up with the changes "is also a rough job" [13]. The project's argument is that the cost falls on those who don't send their code to mainline, and that is coherent. But the user who just wants the network card to work pays the bill all the same. Saying the problem doesn't exist is as wrong as saying system calls break.

When the kernel removes code

Another recent myth says ReiserFS was removed from the kernel for political reasons. The record shows something else. In February 2022, Jan Kara, of SUSE, proposed the deprecation with this rationale: "Reiserfs is relatively old filesystem and its development has ceased quite some years ago. Linux distributions moved away from it towards other filesystems such as btrfs, xfs, or ext4. To reduce maintenance burden on cross filesystem changes [...] let's add a deprecation notice when the filesystem is mounted and schedule its removal to 2025" [40]. The removal went into Linux 6.13 and deleted about 32.8 thousand lines [41]. It is the same logic as the unstable interface: code without a maintainer inside the tree becomes a burden for whoever touches the shared interfaces.

Microkernel versus monolith, with numbers

Setting the insults aside, the 1992 debate had a legitimate technical question: is it worth taking out of kernel mode whatever does not need to be there? Thirty years of research have produced data for both sides.

Tanenbaum's argument: the bugs live in the drivers

In 2001, Andy Chou, Dawson Engler and colleagues at Stanford ran automatic static checkers over the code of Linux and OpenBSD. Their conclusion for Linux 2.4.1 was that "the vast majority of bugs are in drivers", and that the error rate of driver code is three to seven times that of the rest of the kernel. For the lock checker, "the error rate for drivers is almost seven times higher than the error rate for the rest of the kernel" [42].

Windows had the same problem, measured another way. In 2003, Michael Swift, Brian Bershad and Henry Levy, of the University of Washington, opened the Nooks paper with a figure from Microsoft: "In Windows XP, for example, drivers account for 85% of recently reported failures" [43]. Nooks isolated Linux drivers in lightweight protection domains inside the kernel's own address space and restarted them when they failed. In 2,000 fault-injection tests, "Nooks recovered automatically from 99% of the faults that caused Linux to crash" [43]. The system had about 22,000 lines, against 2.4 million in the kernel of the time. The drivers kept running in ring 0, the same privilege level as the rest of the kernel, and the protection came from the page tables [43].

Tanenbaum used these data in 2006, in a paper with Jorrit Herder and Herbert Bos in IEEE Computer. The reasoning is arithmetic: if code has 6 to 16 bugs per thousand lines, "Using a conservative estimate of 6 bugs per 1000 lines of code the Linux kernel probably has something like 15,000 bugs; Windows has at least double that" [44]. In a monolithic kernel, a faulty driver runs in the same address space as everything else. Microsoft's documentation describes the problem on Windows with a clarity I would like to see more often: "All code that runs in kernel mode shares a single virtual address space. As a result, a kernel-mode driver isn't isolated from other drivers or the operating system. [...] If a kernel-mode driver crashes, it causes the entire operating system to crash" [8].

Here Linux deserves a data point in its favor that critics rarely cite. In 2011, Nicolas Palix, Julia Lawall and colleagues repeated Chou's study on versions 2.6.0 to 2.6.33. The kernel more than doubled in size over the period, but the number of faults per line fell. The drivers directory still held the largest absolute number of faults and, together with drivers/staging, had accounted for 57% of the code since 2.6.30. Its fault rate, however, "is now below that of other directories, such as arch (HAL) and fs (file systems)", and since 2.6.19 it has been "right at the average" [45]. Peer review improved the drivers. What did not change is the consequence of a bug that slips through: in Linux, it runs with full privilege.

At this point, Linux takes a fair criticism, and Torvalds himself supplied the ammunition. In September 2009, at LinuxCon, he said: "We're getting bloated and huge. Yes, it's a problem". And he added: "sometimes it's a bit sad that we are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary" [46]. Whoever treats the Linux kernel as a model of elegance is defending something its own author does not.

MINIX 3: drivers outside the kernel and a server that brings them back

MINIX 3 is Tanenbaum's answer to these numbers, and it went further than MINIX 2. In the IEEE Computer paper, the architecture is described in layers. The microkernel handles interrupts, processes, scheduling and IPC, and offers a small set of kernel calls to authorized drivers and servers, such as reading a user's address space or writing to permitted I/O ports. "The clock driver shares the microkernel's address space, but is scheduled as a separate process. No other drivers run in kernel mode" [44]. Each disk, terminal, network, printer or audio driver runs in its own process, in user mode, protected by the MMU, and has to ask the kernel to touch the hardware. The file server had 4,500 lines of executable code, and the kernel 4,000: with the same estimate of 6 bugs per thousand lines, "the total number of bugs in the kernel is probably only about 24 (vs. 15,000 for Linux and far more for Windows)" [44].

Message passing kept the idea from MINIX 2 and gained a complement. IPC "is done by passing fixed-length messages using the rendezvous principle", with a direct copy from sender to recipient, plus an asynchronous notification mechanism: events that cannot be delivered are marked as pending in a bitmap in the process table. Interrupts become notifications, and the kernel turns them into normal messages when the driver is ready to receive them [44]. Since the kernel has no message queues or buffers, there is no way to exhaust kernel memory with messages. Permissions became finer-grained: for each process, the system restricts the IPC primitives, the allowed destinations and the use of notifications, and user processes only talk to the POSIX servers [44].

The new component is the reincarnation server. The paper by Herder, Bos, Gras, Homburg and Tanenbaum at DSN 2007 describes how it works [47]. A driver is started by the service utility with the binary, a stable name, the exact list of privileges, a heartbeat period and, optionally, a policy script for recovery. The reincarnation server is the parent of all system processes and knows immediately when one of them exits, panics or dies from a CPU or MMU exception. It also requests periodic heartbeats and starts recovery after N missed replies, which catches processes stuck in an infinite loop. The file server can ask for a disk driver that violates the protocol to be replaced, and the user can have a driver restarted, or swapped for a fixed version, while the system runs [47]. A data store server publishes the restarted driver's new IPC endpoint, and whoever depends on it is notified. A disk driver that dies in the middle of a read is restarted, and the file server reissues the pending operations, because block I/O is idempotent.

The paper's numbers are concrete. In a network test with wget downloading a 512 MB file while the RealTek 8139 driver was killed at intervals of 1 to 15 seconds, every transfer completed with the correct checksum, and the throughput loss ranged from 25% to 1% [47]. On the SATA disk, reading 1 GB with the driver killed at similar intervals, the loss was 62% to 7%, again without corrupting data. In fault injection on the DP8390 Ethernet driver, running in the Bochs emulator, more than 12,500 faults were injected, with 347 detectable crashes, and "The subsequent recovery was successful in 100% of the induced failures"; on real hardware, success was over 99% [47]. Adapting an ordinary driver took exactly five lines in the shared driver library.

The authors themselves list the limits, and that is where the honesty of the work shows. The design does not handle Byzantine failures, such as a disk driver that reports a write and writes garbage; it does not detect silent data corruption; it does not cure deterministic bugs that come back after the restart; and it does not fix broken hardware [47]. The project's FAQ measures the cost of isolation: "MINIX 3 is 5-10% slower" than MINIX 2, which had its drivers in kernel mode, and "our priority has been reliability, not performance" [48]. In 2008, the European Research Council gave Tanenbaum a €2.5 million grant to build a reliable system, and MINIX 3.3.0 came out under the BSD license, with support for x86 and ARM Cortex-A8 and a userland compatible with NetBSD [49].

Torvalds's argument: shared state

Torvalds answered the debate in May 2006, on the Real World Technologies forum, and his argument was not performance. It was complexity:

The fundamental result of access space separation is that you can't share data structures. That means that you can't share locking, it means that you must copy any shared data, and that in turn means that you have a much harder time handling coherency. All your algorithms basically end up being distributed algorithms. [50]

For him, address-space separation trades memory bugs for coordination bugs between processes, which are harder to understand. In the same message, he went straight at the idea of the reincarnation server: "the argument that you can 'just reload' a failed service and not take the whole system down is equally flawed. Anybody who has ever done distributed programming should know by now that when one node goes down, often the rest comes down too" [50]. And he dismissed the fashionable term: "As to the whole 'hybrid kernel' thing - it's just marketing" [50].

The argument is serious, and the MINIX 3 data answer only part of it. For transient failures of network and disk drivers, where the protocol tolerates retries, restarting worked in almost every case measured [47]. For truly shared state, such as a file system with metadata in memory, the MINIX 3 authors themselves admit that restarting is not enough and that end-to-end checksums have to be added [47]. Torvalds exaggerates when he calls the restart argument flawed. Tanenbaum exaggerated when he sold isolation as a general solution.

Performance: the problem was Mach, not the idea

In 1992, Tanenbaum cited Rick Rashid's papers comparing Mach 3.0 with monolithic systems as evidence that performance was no longer a problem [1]. The claim was premature. Gernot Heiser and Kevin Elphinstone, who worked on L4 for decades, sum up the early 1990s: "The typical cost for a one-way message was around 100 µs, which was too high for building performant systems", and the industry's response was "a trend to move core services back into the kernel" [51].

Jochen Liedtke showed in 1993 that the cost came from the implementation. In the paper "Improving IPC by Kernel Design", presented at SOSP, he rebuilt the process and communication part of the L3 microkernel from scratch around a single goal: IPC speed. On a 486-DX50, he calculated the theoretical minimum for a short message at 172 cycles, or 3.5 µs, aimed for 350 cycles and reached 250 cycles, 5 µs [14]. Compared with Mach, the gain was "from a factor of 22 (8-byte messages) to 3 (4-Kbyte messages)". The paper even measures the cost of entering and leaving the kernel: on Mach, the mach_thread_self call took 18 µs, on a processor where the minimum round trip to the kernel cost 2 µs [14].

Two years later, in "On µ-Kernel Construction", Liedtke formulated the criterion that would guide the L4 family: a concept is tolerated inside the microkernel "only if moving it outside the kernel, i.e. permitting competing implementations, would prevent the implementation of the system's required functionality" [52]. And he wrote a sentence that should bother anyone who uses the 1992 debate as a weapon: "µ-kernels are inherently not portable. Instead, they are the processor dependent basis for portable operating systems" [52]. The fastest microkernel of the time was as tied to its processor as Linux 0.01. Tanenbaum was right about the architecture and wrong to think portability came with it for free.

The L4 lineage carried on. Heiser and Elphinstone's table shows the cost of a message between address spaces falling from 5 µs on the original 1993 L4 to 0.09 µs on the 2013 seL4, on a 3.4 GHz Core i7 Haswell, or 301 cycles; on a 532 MHz ARM11, seL4 took 188 cycles [51]. In 1997, Hermann Härtig, Michael Hohmuth, Liedtke and colleagues in Dresden ported Linux to run on top of L4 and measured: "For L4Linux, the AIM benchmarks report a maximum throughput which is only 5% lower than that of native Linux. The corresponding penalty is 5 times higher for a co-located in-kernel version of MkLinux, and 7 times higher for a user-level version of MkLinux" [15]. MkLinux ran on top of Mach. A well-designed microkernel cost 5%; Mach cost much more.

Tanenbaum, in 2004, said he would accept a much larger loss: "I would easily give up 20% in performance for a system that was robust, reliable" [53]. It is a legitimate position for someone designing a critical system. It is a hard one to sell to someone running a data center.

What others did earlier, or better

This is the part the mystical view of Linux most likes to skip. Dominating supercomputers and phones [2], [3] does not make Linux the author of every good idea, and several of the ones that look like "Linux things" today appeared first in other systems.

macOS and XNU: certified UNIX, but not a microkernel

macOS has what no common Linux distribution has: the UNIX 03 registration. macOS 26 Tahoe was registered on August 29, 2025, on Apple Silicon and on Intel [7]. The registration repeats with every release: macOS 15 Sequoia had been registered on September 12, 2024 [54]. Whoever treats macOS as a toy is dismissing a mass-market desktop system that passes The Open Group's conformance suite release after release. Apple also uses a microkernel where the risk is highest: the Secure Enclave processor "runs an Apple-customized version of the L4 microkernel" [55].

The myth on the other side says macOS is a microkernel because XNU has Mach inside. Apple itself refutes it, and it is worth looking inside. The README of the XNU code describes it as "a hybrid kernel combining the Mach kernel developed at Carnegie Mellon University with components from FreeBSD and a C++ API for writing drivers called IOKit"; in the tree, osfmk holds the Mach-derived subsystems and bsd holds the BSD ones [56]. From Mach come the abstractions: tasks, units of resource ownership with an address space, a port right namespace and one or more threads; and ports, "Secure, simplex communication channels, accessible only via send and receive capabilities (known as port rights)" [17]. At the trap level, the interface to most of these abstractions is made of messages to kernel ports, and the Mach Interface Generator (MIG) generates the stubs that hide this from the programmer [17].

It looks like a microkernel, but Apple explains right after: "in OS X, Mach is linked with other kernel components into a single kernel address space. This is primarily for performance; it is much faster to make a direct call between linked components than it is to send messages or do remote procedure calls (RPC) between separate tasks" [17]. Apple concludes that, in OS X, "Mach is not primarily a communication hub between clients and servers". The architecture documentation warns that "OS X uses the term kernel somewhat differently than you might expect" and that "The OS X kernel environment includes the Mach kernel, BSD, the I/O Kit, file systems, and networking components" [16]. I/O Kit drivers are extensions loaded "into kernel space" [16]. Tanenbaum was harsher in 2006: Mac OS X "is sort of microkernelish", but "Since all of it runs in kernel mode (to get that little extra bit of performance) it is not a true microkernel" [35]. By the 1992 yardstick, XNU is on the same side as Linux. Whoever praises macOS for being "Mach" and attacks Linux for being monolithic is using a double standard.

Where Apple went beyond Linux was with third-party drivers. The DriverKit documentation says: "The drivers you build with DriverKit run in user space, rather than as kernel extensions, which improves system stability and security" [57]. The page on kernel extensions states that they have been deprecated and that, starting with macOS Big Sur, the system does not load by default extensions that use deprecated kernel interfaces [58]. In practice, Apple pushes peripheral makers out of kernel mode through platform policy. Linux has nothing equivalent for drivers in general, and I explain below what it does have.

FreeBSD: jails in 2000, ZFS and DTrace before Linux

Containers are usually told as a Linux story. Operating-system isolation in production appeared first in FreeBSD. The man page says: "The jail utility appeared in FreeBSD 4.0" [9]. FreeBSD 4.0 was announced on March 14, 2000 [59]. That same year, Poul-Henning Kamp and Robert Watson presented the design at SANE 2000: jail "provides the ability to partition the operating system environment, while maintaining the simplicity of the UNIX 'root' model", and its most popular use until then was "providing virtual machine services in Internet Service Provider environments" [60].

In Linux, the pieces arrived gradually. The mount namespace appeared in 2.4.19 [61]. Cgroups debuted in 2.6.24 [18], released on January 24, 2008 [62]. Creating a user namespace without privilege only became possible in Linux 3.8 [63]. The Linux model, with separate primitives that user space combines, turned out more flexible, and the container industry grew on top of it. But the jail came first.

Two tools that Linux administrators envied for years also came from elsewhere. ZFS was "Originally developed at Sun Microsystems" [64], and the FreeBSD 7.0 release notes record: "Support for Sun's ZFS has been added" [65]. 7.0 came out on February 27, 2008 [66]. DTrace was presented by Bryan Cantrill, Michael Shapiro and Adam Leventhal, of Sun's Solaris kernel team, at USENIX 2004, as a tool able to instrument the kernel and programs "in a unified and absolutely safe fashion", with "zero probe effect" when disabled [67]. FreeBSD 7.1, from January 4, 2009, brought DTrace "imported from OpenSolaris" [68], [69]. The FreeBSD handbook still opens the chapter like this: "DTrace [...] was developed by Sun™ as a tool for locating performance bottlenecks in production and pre-production systems" [70]. eBPF, which plays that role in Linux today, only got the bpf() system call in Linux 3.18, released on December 7, 2014 [71].

Windows NT: the fake microkernel that went back into the kernel

Windows is the favorite target of the crowd that loves Linux, and it deserves criticism: its kernel-mode drivers crash for the same reason as Linux's, as Microsoft itself documents [8]. It also deserves the marketing criticism. In 1992, Tanenbaum cited the "not-yet-released Windows/NT" as an example of a microkernel [1]. In 2004, he corrected himself: "Microsoft claimed that Windows NT 3.51 was a microkernel. It wasn't. It wasn't even close. Even they dropped the claim with NT 4.0" [53]. The "hybrid kernel" that Torvalds called "just marketing" is, to a large extent, this one [50].

NT also has a pedigree that tends to be forgotten. Tanenbaum recounts that Microsoft hired David Cutler, one of the principal architects of DEC's VMS, to lead the team that produced Windows NT, and adds that "Operating system designers of Cutler's quality are few and far between" [72].

The best source on NT's design and on the NT 4.0 retreat is a document by Microsoft itself, the "Windows NT Kernel-mode User and GDI White Paper", still archived on Microsoft Learn [73]. It describes NT 3.51 in layers: the hardware abstraction layer (HAL) at the bottom, a "microkernel" that handles interrupts, deferred procedure calls, thread scheduling and synchronization, and the Executive on top. The same text admits that NT "has fallen squarely into the modified microkernel or macrokernel camp": from the first version, the memory manager, the cache, the file systems, the network protocols, the network server and process management ran in kernel mode [73]. What stayed outside were the environment subsystems. The original plan called for Win32, OS/2 and POSIX as environments on an equal footing; Win32 ended up as a privileged "application" on which everything else depended, and the window manager (USER) and the graphics interface (GDI) ran in a user process, CSRSS.EXE [73].

In NT 4.0, Microsoft brought USER and GDI into the kernel, and the document explains why with numbers. The client-server model required a 64 KB shared memory buffer and several context switches between threads and processes for each graphics call. On a Pentium 100, a client-server transition cost 60 to 70 microseconds, against 4 to 5 for a transition into kernel mode [73]. The change saved 256 KB to 1 MB of working-set memory and made PowerPoint 15% to 20% faster. The graphics drivers, which used to run partly in CSRSS, began to run entirely in kernel mode [73].

Microsoft's argument for not fearing the change is the same as Torvalds's. The document says that "No commercial operating system is based on a pure microkernel design", because the pure design "is too computationally expensive", and asks what the practical difference is between a system that crashes and one that keeps running "but loses all access to persistent storage" when the user-mode file system dies [73]. About GDI, it admits: if the NT 3.51 graphics process failed, the user would see "a system that appears to have crashed" [73]. In NT 4.0, in the name of performance, Microsoft made the trade that Tanenbaum criticized in Linux.

Years later, Windows gained a mechanism that Linux does not have to the same degree: an official framework for user-mode drivers. According to Microsoft, "UMDF drivers abstract hardware functionality, run in the user-mode environment, and can access various services". Each driver runs inside a host process, managed by a service, and a kernel-mode component, the reflector, bridges the two [74]. There are limits: "File system drivers, display drivers (for full display devices, not display-only display devices), and print drivers cannot be UMDF drivers" [74]. Even so, for many device classes, Windows offers out of the box the driver isolation that Linux offers only in niches.

Today's Linux: monolithic, with windows to the outside

Linux did not become a microkernel, and the numbers show the size of what remains inside. I counted the lines of the .c, .h, .S and .rs files in the Linux 7.2 tarball, published on August 17, 2026: 37.7 million lines in 65,637 files. The drivers directory alone has 26 million, 69% of the total; arch comes next, with 6.7% [75]. Linux 0.01 had 9,877 lines [5]. Almost everything that grew runs in kernel mode, in the same address space, and a module loaded after boot has the same privilege as the code that was there from the start, as the Nooks paper already described [43].

Even so, the kernel kept opening windows out of kernel mode, or into it with a safety net. Some are direct answers to what Tanenbaum and MINIX users asked for in 1992.

FUSE: the 1991 request, granted in 2005

In August 1991, Jyrki Kuoppala asked for user-mode file systems, and Torvalds answered that this was perhaps the one thing on the list that could not be done [10]. FUSE entered Linux 2.6.14, released on October 27, 2005, and KernelNewbies described it as something that "Allows to implement a fully functional filesystem in a userspace program" [76]. The kernel documentation defines a userspace file system as one in which "data and metadata are provided by an ordinary userspace process", and lists the pieces: a kernel module (fuse.ko), a library (libfuse) and the fusermount utility [19]. The feature it highlights is unprivileged mounting: the daemon runs with the permissions of whoever mounted it, and the example given is sshfs. If the daemon dies, the connection to the kernel ends and the file system stops responding; the kernel keeps running [19]. It is the MINIX server model applied to one class of file systems.

UIO and VFIO: drivers in user space, with and without an IOMMU

UIO, documented in the kernel since 2006, lets most of a driver be written in user space. The documentation lists the advantages frankly: "bugs in your driver won't crash the kernel" and "updates of your driver can take place without recompiling the kernel" [77]. Its reach is limited: devices already served by subsystems such as networking, serial or USB "are no candidates for an UIO driver" [77].

VFIO, which entered Linux 3.6, released on September 30, 2012 [78], solved the problem UIO left open. A user-space driver that programs DMA can write anywhere in memory, and then isolation becomes decoration. The VFIO documentation describes it as "an IOMMU/device agnostic framework for exposing direct device access to userspace, in a secure, IOMMU protected environment", which allows "safe, non-privileged, userspace drivers" [20]. The text criticizes UIO, which "has no notion of IOMMU protection, limited interrupt support, and requires root privileges to access things like PCI configuration space" [20]. The main use is to give a virtual machine direct access to a device, which, in the documentation's words, "turns the VM into a userspace driver". MINIX 3 proposed the same protection: in the DSN 2007 paper, a driver that wants to do DMA safely first asks the kernel to set up the I/O MMU [47].

eBPF and sched_ext: code in the kernel, with a verifier and an escape hatch

eBPF goes the opposite way: it brings code into the kernel, but only after checking it. The bpf() call entered Linux 3.18, and KernelNewbies summed it up: "eBPF programs are similar to kernel modules. [...] eBPF verifier statically determines that the program terminates and is safe to execute" [71]. The verifier documentation details the two steps: first, a check of the control-flow graph that forbids loops and unreachable code; then, a simulation of every possible path, instruction by instruction, tracking the type of each register and of the stack [79]. The protection comes from a check made before loading, an idea closer to seL4 than to MINIX.

sched_ext, which entered Linux 6.12, released on November 17, 2024 [80], brings this to the scheduler. It is "a scheduler class whose behavior can be defined by a set of BPF programs", and the documentation promises: "The system integrity is maintained no matter what the BPF scheduler does. The default scheduling behavior is restored anytime an error is detected, a runnable task stalls, or on invoking the SysRq key sequence SysRq-S" [21]. A faulty scheduler is kicked out and the kernel returns to the default. Swap "scheduler" for "driver" and "default" for "new instance", and the sentence could be in the reincarnation server paper.

Rust: the same question, another answer

The most recent bet goes after the class of bug that Chou measured in drivers without taking the drivers out of kernel mode. Rust support entered Linux 6.1, in 2022, at such an early stage that, according to LWN, "No system with a production 6.1 kernel will be running any Rust code" [81]. Three years later, the picture had changed. At the Maintainers Summit of December 2025, the maintainers' consensus was that Rust was no longer experimental and was becoming a permanent part of the kernel, and the "experimental" label would be removed [82]. In the session, Miguel Ojeda said that Android's Binder driver in Rust had been merged for 6.18 and that devices with Android 16 and kernel 6.12 were already shipping the ashmem module written in Rust: "millions of real devices running kernels with Rust code now" [83]. Greg Kroah-Hartman said that drivers in Rust "are indeed proving to be far safer than those written in C" and that no CVE had yet been issued for kernel Rust code. Dave Airlie, maintainer of the graphics subsystem, said DRM was "about a year away" from refusing new drivers written in C. Torvalds settled the matter by saying that, after nearly five years, the time had come [83]. In Linux 7.2, by my count, .rs files add up to 182,584 lines, less than half a percent of the total [75].

The technical point is that Rust and microkernels answer the same question in different ways. MINIX 3 accepts that the driver will have bugs and contains the damage with the MMU [44]. Rust tries to keep a class of memory bugs from existing at all, but the driver stays in ring 0, and a logic error can still bring the system down. The second path has an advantage for the project: it preserves what Torvalds defended in 2006, the state shared between subsystems [50].

Where Linux remains monolithic

Drivers, the network stack, the main file systems and memory management remain in kernel mode, in the same address space [75]. FUSE, UIO and VFIO are optional exits for niches. eBPF and sched_ext put verified or disposable code inside the kernel, and Rust trades isolation for language safety. None of these pieces changes the architecture Tanenbaum criticized in 1992. Whoever says Linux "is already half a microkernel" exaggerates. So does whoever says it ignored the criticism.

Where the microkernel won

Tanenbaum's prediction that microkernels would dominate the desktop and the server did not come true. But there are places where failure is expensive and code has to be small, and in those places the microkernel won.

seL4: a kernel with a mathematical proof

In 2009, Gerwin Klein and colleagues at NICTA and UNSW published at SOSP the formal verification of seL4, "a third-generation microkernel of L4 provenance", which "comprises 8,700 lines of C code and 600 lines of assembler". The paper describes "the first formal proof of functional correctness of a complete, general-purpose operating-system kernel", checked by machine [84]. The authors tie the result to size: "With truly small kernels it becomes possible to take security and robustness further, to the point where it is possible to guarantee the absence of bugs" [84]. It is the 1992 argument, now with a proof.

The price shows up in the same paper. The whole proof, with libraries and generated parts, adds up to 200,000 lines of Isabelle script, and the authors proved more than 150 invariants about the kernel state [84]. Writing the kernel cost 2.2 person-years, counting the Haskell prototype. The proof cost about 20 person-years, of which 11 were specific to seL4 and the rest went into tools and reusable research. The authors compare this with the industry rule of thumb for Common Criteria EAL6 certification, US$10,000 per line, which would come to US$87 million for seL4 with much weaker assurance [84]. The bugs the proof found in the C code were not algorithmic flaws: they were mostly typos, misreadings of the specification and forgotten checks, and even so many of them were enough to crash the kernel or open a vulnerability [84]. The math does not work for 37 million lines. Heiser and Elphinstone write that "even 9,000 SLOC pushed the limits of what was achievable" [51].

L4 in billions of devices

The L4 family left the lab. According to Heiser and Elphinstone, an embedded version of Pistachio saw "massive-scale commercial deployment when Qualcomm adopted it as a protected-mode real-time OS for the firmware of their wireless modem processors", and it runs on the security processor of recent iOS devices; the footnote says: "Total deployment is now in the billions" [51]. PikeOS, a commercial clone of the second version of L4, was certified for avionics and runs in aircraft and trains [51]. In every L4 kernel, drivers run in user mode, except for the timer driver and the interrupt controller, and the authors say that putting unverified drivers in the kernel "would obliterate any guarantees" [51]. Tanenbaum, in 2004, also pointed to QNX as "An example of commercially successful microkernel" [6], and in 2006 he listed QNX, Integrity, PikeOS, Symbian and L4Linux as proof that "clearly I am not alone in seeing something in microkernels" [35].

MINIX inside almost every Intel PC

The most cited irony of the story is from 2017. MINIX 3 runs inside the Intel Management Engine (ME), the management subsystem that runs below the operating system on Intel machines. At the 2017 Embedded Linux Conference Europe, in Prague, Ronald Minnich, of Google, described the "rings" below the kernel: "Ring -3 is 'the one that has people really worried'. It runs MINIX 3 and is where the ME runs." He joked that this was the "year of MINIX 3 on the desktop", because there are more machines with the ME than with Linux, macOS or Windows. Running there are IPv4 and IPv6 stacks, file systems, drivers and web servers. The ME "can reimage the system even if the power is turned off as long as it is plugged into the wall and the network", according to LWN's report, published on November 20, 2017 [85]. At Black Hat Europe that same year, Mark Ermolov and Maxim Goryachy showed how to run unsigned code on the ME [86].

Tanenbaum wrote an open letter to Intel, addressed to "Mr. Krzanich". The oldest copy in the Internet Archive is from November 7, 2017 [22]. The tone is ironic and uneasy. He thanks Intel for putting MINIX "inside the ME-11 management engine chip used on almost all recent desktop and laptop computers in the world", says this may make MINIX "the most widely used computer operating system in the world" and complains that nobody told him [22]. Then comes the part that matters most for this article: "I certainly hope Intel did thorough security hardening and testing before deploying the chip, since apparently an older version of MINIX was used. Older versions were primarily for education and newer ones were for high availability. Military-grade security was never a goal" [22].

The myth that microkernel means secure dies here, at the hand of MINIX's own author. A microkernel isolates components and reduces privileged code, which helps security. It does not replace auditing, and the most widely used MINIX on the planet runs inside firmware that the machine's owner does not audit. The ME problem is one of governance, not of kernel architecture, and Tanenbaum himself kept the two apart: "that is Intel's business decision and a separate issue from the code it runs" [22].

MINIX 3 today

The project's site still describes MINIX 3 as "designed to be highly reliable, flexible, and secure", with "a tiny microkernel running in kernel mode with the rest of the operating system running as a number of isolated, protected, processes in user mode" [87]. The features page sums up the architecture in three short phrases: "Tiny microkernel that runs in kernel mode", "Each device driver is a separate user-mode process" and "Reincarnation server can reload failed drivers" [88]. The official repository, however, shows a stalled project: the latest tag is v3.3.0 and the last commit on the main branch is from November 14, 2018 [89]. The idea lives on in seL4, in the L4 inside modems and in QNX. MINIX became, above all, a piece of firmware and of the classroom.

The scoreboard

The numbers side by side

Measure	Figure	Source
Size of Linux 0.01	88 files, 9,877 lines (my count)	[5]
Size of Linux 7.2	37.7 million lines, 69% in `drivers` (my count)	[75]
Rust in Linux 7.2	182,584 lines, about 0.5% (my count)	[75]
MINIX 3 kernel	about 4,000 lines, only the clock driver in kernel mode	[44]
seL4 kernel	8,700 lines of C and 600 of assembly	[84]
IPC on Mach, early 1990s	about 100 µs per message	[51]
IPC on L3, 50 MHz 486	5 µs, 3 to 22 times faster than Mach	[14]
IPC on seL4, 2013 Core i7	0.09 µs (301 cycles)	[51]
NT 3.51, Pentium 100	60 to 70 µs per client-server switch, against 4 to 5 µs into the kernel	[73]
Cost of running Linux on L4	5% less throughput	[15]
Cost of isolation in MINIX 3	5% to 10% slower than MINIX 2	[48]
Driver bugs, Linux 2.4.1	rate 3 to 7 times that of the rest of the kernel	[42]
Drivers in Windows XP failures	85% of reported failures	[43]
Linux drivers, 2.6.19 to 2.6.33	fault rate at the kernel average	[45]
Driver recovery in MINIX 3	100% in the emulator, over 99% on real hardware	[47]
Recovery in Nooks (Linux)	99% of the faults that would crash Linux	[43]
Cost of the seL4 proof	about 20 person-years, 200,000 lines of Isabelle	[84]
Licenses	Linux under the GPL in 1992; 4.4BSD-Lite, free of the lawsuit, in 1994; MINIX under BSD in 2000	[28], [30], [33], [23]

Where Tanenbaum was right

He was right in his diagnosis of reliability. Bugs concentrate in drivers [42], [43], and in a monolithic kernel a bad driver brings everything down, as Microsoft documents for Windows [8] and as holds for Linux. He was right that a design with isolated drivers makes it possible to recover from failures that would be fatal in a monolithic kernel, and MINIX 3 measured it [47]. He was right that small privileged code is what allows strong guarantees: seL4 could only be proven correct because it has 8,700 lines of C [84]. He was right that the microkernel would find room where failure is expensive, from Qualcomm's modems [51] to the Secure Enclave [55]. And he was right about the effect of the BSD lawsuit on Linux's success, something Torvalds himself confirmed [11], [6].

Where Tanenbaum was wrong

He got the market badly wrong. He said the debate was "essentially over" and that "Microkernels have won" [1]; the desktop and the server stayed monolithic or hybrid, including XNU, which he himself classified as "not a true microkernel" [35], and NT, which moved the graphics part into the kernel precisely for performance [73]. He said the 80x86 "is not going to be around all that long" [1]; macOS 26 is still certified as UNIX on Intel Macs in 2025 [7], and Linux keeps its own documentation for x86 alongside fifteen other architectures [90]. He predicted that in five years "everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5" [4]; in 1997, GNU was at version 0.2 [29]. He predicted that coordinating programmers spread around the world would be "as easy as herding cats" [4], and the project he imagined as anarchic now runs on the 500 largest supercomputers [2]. He treated portability as a virtue of the microkernel, when Liedtke would write in 1995 that microkernels "are inherently not portable" [52]. He also used Windows NT as an example of a microkernel in 1992 [1], only to admit later that it was not one [53].

Where Torvalds was right

He was right that being available was worth more than being elegant [1]. He was right that API portability matters more to the user than kernel portability. The switch to the GPL in 1992 [28], eight years before MINIX switched to the BSD license [23], gave Linux the contributor base that MINIX turned away on purpose [6]. He was right to open up development early: in February 1992 he was already floating a "linux-kernel" list and had been accepting heavy changes from Ts'o since version 0.10 [4]. His 2006 argument about the cost of shared state in microkernels is serious, Microsoft used the same reasoning in NT 4.0 [73], and it helps explain why few general-purpose systems went down that path [50].

Where Torvalds was wrong or backed down

The "won't be big and professional" [10] went down in history as the most mistaken prediction of the whole story. The second is the 1991 "porting is impossible" [10]: the kernel today has documentation for sixteen processor architectures [90]. He himself conceded in 1992 that, from a theoretical standpoint, "linux looses" [1], and admitted that its non-portability had gone "to an extreme" [1]. In 2006, he called the idea of reloading a failed service "flawed" [50], and the MINIX 3 and Nooks experiments show recovery from more than 99% of the driver failures tested [47], [43]. In 2009, he said the kernel was "huge and bloated" [46]. And Tanenbaum is right when he says that Torvalds gave little credit to his predecessors [6].

Conclusion: great, not sacred

In 1992, a professor said Linux was a step back to the 1970s, and a student replied that at least it was available now. Both were right about what they said, and each was wrong about what he left out.

Linux deserves the place it has. It won because it was ready and truly free in 1992, and because it accepted contributions from whoever showed up while MINIX turned down requests and BSD was in court [6], [30]. Winning that way has merit, and it is how free software won almost everything it has won.

But winning does not turn the project into an architectural reference. The Linux kernel is monolithic, runs 26 million lines of drivers in kernel mode [75], and its own creator called it bloated [46]. Tanenbaum's criticism about reliability still stands, and the strongest answers to it came from outside Linux: seL4 proven correct [84], MINIX 3 reloading drivers [47], L4 in modems [51], Windows's UMDF [74] and Apple's DriverKit [57]. Linux answered the criticism in its own way, with FUSE, VFIO, eBPF and, now, Rust [19], [20], [71], [83]. They are good answers, but they are not the answer Tanenbaum asked for.

The critic who calls Linux a copy of MINIX needs to read what MINIX's author wrote: "the code was his" [6]. The devotee who thinks Linux invented everything needs to read the FreeBSD 4.0 announcement, the DTrace paper and the NT white paper [59], [67], [73]. Both need to read the whole 1992 thread. There, Torvalds agrees that microkernels "are nicer" [1], and Tanenbaum says he is not unhappy with Linux [1].

I like Linux. I use it every day, and I will keep using it. But a kernel is a tool, and a tool is judged by what the documents show, not by the faith of those who use it.

Sources

Each source below was read (full text or relevant excerpt) during the research. Under each reference is what it supports in this article. Quotes are literal, and historical times are in GMT, as they appear in the original headers.

[1]A. S. Tanenbaum and L. Torvalds, “LINUX is obsolete,” messages in the comp.os.minix newsgroup, Jan. 29, 1992, archived by the Linux Information Project. [Online]. Available: https://www.linfo.org/obsolete.html ↩
- Tanenbaum's post of 1992-01-29 (12:12:50 GMT): "a giant step back into the 1970s", "Microkernels have won", "the not-yet-released Windows/NT" as an example of a microkernel, "LINUX is tied fairly closely to the 80x86. Not the way to go", "I think it is a gross error to design an OS for any specific architecture", "Don't get me wrong, I am not unhappy with LINUX", MINIX drivers "in the kernel, but only because the brain-dead nature of the Intel CPUs", citation of Rick Rashid's papers on Mach 3.0.
- Torvalds's reply of 1992-01-29 (23:14:26 GMT): "True, linux is monolithic, and I agree that microkernels are nicer", "linux looses", "If the GNU kernel had been ready last spring...", "Linux wins heavily on points of being available now", "as conformant to standards as I knew how", "non-portability to an extreme", "brain-damages of minix", "doesn't suck like minix does".
- Header "Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam".
[2]ZDNet, “Linux Totally Dominates Supercomputers,” republished by Linux.com, Nov. 15, 2017. [Online]. Available: https://www.linux.com/news/linux-totally-dominates-supercomputers-1/ ↩
- "All 500 of the world's fastest supercomputers are running Linux" on the November 2017 TOP500 list; the last two systems not running Linux ran AIX.
[3]Android Open Source Project, “Kernel overview,” accessed Oct. 4, 2026. [Online]. Available: https://source.android.com/docs/core/architecture/kernel ↩
- "The Android kernel is based on an upstream Linux Long Term Supported (LTS) kernel."
[4]C. DiBona, S. Ockman and M. Stone (Eds.), “Appendix A: The Tanenbaum-Torvalds Debate,” in Open Sources: Voices from the Open Source Revolution. Sebastopol: O'Reilly, 1999. [Online]. Available: https://www.oreilly.com/openbook/opensources/book/appa.html ↩
- Tanenbaum, 1992-01-30 (13:44:34 GMT): "I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful you are not my student...", "5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5", MINIX made to run on a 4.77 MHz PC with no disk; the PC version sold 2 to 1.
- Torvalds, "Apologies (was Re: LINUX is obsolete)", 1992-01-30 (15:38:16 GMT): "Apologies to ast", "I over-reacted", "some of the criticisms are valid", "my first, and hopefully last flamefest".
- O'Reilly's introduction calls the participant "user-hacker Ken Thompson (one of the founders of Unix)"; message header: "kt4@prism.gatech.EDU (Ken Thompson)", "Organization: Georgia Institute of Technology", 1992-02-03; quote "microkernels are probably the wave of the future... easier to implement a monolithic kernel...".
- Tobin: "I find the single-threaded file system a serious pain when using Minix"; Tanenbaum: "A multithreaded file system is only a performance hack".
- Torvalds, 1992-01-31: "you automatically get a multithreaded kernel", "linux API is portable", complete source of about 200 kB against more than 800 kB for Mach's i386.tar.Z, "minix is portable, but you can rewrite that as 'doesn't use any features'"; reply about the Helsinki professor ("the person here at the university that teaches OS design").
- Other participants: Ts'o ("is probably not much more than what is in a Minix implementation", "Linux is here, and GNU isn't", "ipso facto micro kernels must be the right approach"); Hedrick ("availability wins out over technical quality every time", "all they could distribute were diffs", "4.4's release date has a history of extreme slippage"); Graham ("about 12000 lines of code", "adding features is a royal pain"); Foard ("significantly slower"); Tanenbaum ("I AM NOT A THEORIST", QNX with 200,000 systems, "proven technology"); Miller; Haardt ("why I think AST is right"); Burns ("Linux will be obsolete"); Kevin Brown ("years of experience with monolithic kernels").
- "Unhappy campers" (1992-02-03): "10 messages from the 43,000 readers", MINIX at US$169, Coherent at US$99, 4.4BSD at US$800, "100% emotional", "Surely Linus' OS professor pointed this out"; Tanenbaum (02-05): "as easy as herding cats", "has never managed a software project"; Torvalds (02-06): "I won't.", the "linux-kernel" list, Ts'o with "some heavy changes even to 0.10". Appendix with 36 messages.
[5]L. Torvalds, “linux-0.01.tar.gz,” Linux 0.01 source code, Sep. 1991, kernel.org historic archive (file and line counts by the author). [Online]. Available: https://cdn.kernel.org/pub/linux/kernel/Historic/linux-0.01.tar.gz ↩
- My own count on the tarball downloaded on Oct. 4, 2026: 88 files; .c, .h and .s files add up to 9,877 lines; file dates between Jun. 15 and Sep. 17, 1991, 60 of them between Sep. 11 and 17. kernel/ 3,511 lines; mm/memory.c + mm/page.s 298 lines; fs/ 2,771 lines.
- include/linux/sys.h: 67 entries in the syscall table, from sys_setup to sys_setsid; kernel/sys.c: 15 functions that only return -ENOSYS (among them sys_mount, sys_umount, sys_rename, sys_mknod, sys_ptrace).
- include/linux/config.h: LINUS_HD, LASU_HD, "Amount of ram memory (in bytes, 640k-1M not discounted). Currently 8Mb". include/linux/sched.h: NR_TASKS 64, HZ 100, the switch_to macro with an ljmp to the TSS.
- Makefile: "chmem +65000 tools/build" and "If you don't have '-mstring-insns' in your gcc (and nobody but me has :-)". include/linux/fs.h: device numbers "same as minix, so we can use the minix file system", NAME_LEN 14, SUPER_MAGIC 0x137F.
[6]A. S. Tanenbaum, “Some Notes on the 'Who wrote Linux' Kerfuffle,” Vrije Universiteit, May 20, 2004. [Online]. Available: https://www.cs.vu.nl/~ast/brown/ ↩
- Date: May 20, 2004. The book Operating Systems: Design and Implementation with the MINIX code in 1987; floppies for US$69 from Prentice Hall; boilerplate not enforced against universities or students; 40,000 subscribers on comp.os.minix; 200 emails a day, "No."; "everyone was trying to turn MINIX into a production-quality UNIX system...".
- The lawsuit against BSDi "gave Linux the breathing space it needed to catch on"; Brown flew to Amsterdam on 2004-03-23; "AST: Is Microsoft one of them? KB: We have multiple funding sources".
- "He had my book, was running MINIX... But the code was his. The proof of this is that he messed the design up"; "Linus rewrote the whole thing as a big monolithic kernel"; "pretty good proof that it was a redesign"; QNX as a "commercially successful microkernel"; criticism of attribution: "Linus has done this far less than he should have... Ken and Dennis are the real heros"; "I met him once"; "My only regret is that he didn't develop Linux based on the microkernel technology of MINIX".
[7]The Open Group, “UNIX 03: Apple Inc., macOS version 26.0 Tahoe on Apple silicon-based Mac computers,” registered Aug. 29, 2025. [Online]. Available: https://www.opengroup.org/openbrand/register/brand3725.htm ↩
- macOS 26.0 Tahoe registered as UNIX 03 on 29-Aug-2025 (Apple Silicon; there is an equivalent registration for Intel); the register names the macOS product, not the kernel.
[8]Microsoft, “User Mode and Kernel Mode,” Windows drivers, Microsoft Learn, accessed Oct. 4, 2026. [Online]. Available: https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode ↩
- "All code that runs in kernel mode shares a single virtual address space... If a kernel-mode driver crashes, it causes the entire operating system to crash."
[9]FreeBSD Project, “jail(8),” FreeBSD System Manager's Manual, accessed Oct. 4, 2026. [Online]. Available: https://man.freebsd.org/cgi/man.cgi?query=jail&sektion=8 ↩
- "The jail utility appeared in FreeBSD 4.0."
[10]L. Torvalds, “LINUX's History,” Jul. 31, 1992, with the 1991 messages in the comp.os.minix newsgroup (Aug. 25; reply to J. Kuoppala, Aug. 26; announcement of version 0.02, Oct. 5). [Online]. Available: https://www.cs.cmu.edu/~awb/linux.history.html ↩
- Post of 1991-08-25 (20:57:08 GMT), Organization: University of Helsinki: "just a hobby, won't be big and professional like gnu", "my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons)", "it's free of any minix code", "It is NOT protable".
- Reply to Jyrki Kuoppala (1991-08-26): "Simply, I'd say that porting is impossible. It's mostly in C, but most people wouldn't call what I write C. It uses every conceivable feature of the 386 I could find, as it was also a project to teach me about the 386"; 64 MB segments, at most 64 tasks in 4 GB; "almost as much assembler as C"; "a porters nightmare"; "except maybe for the user-mode filesystems".
- Text of July 1992: "0.01 sources weren't actually runnable", "0.01 didn't actually come with any binaries".
- Announcement of 0.02 (1991-10-05), "Free minix-like kernel sources for 386-AT": "Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?", "no minix code has been used", "These sources still need minix-386 to be compiled", "Hurd will be out in a year (or two, or next month, who knows)".
[11]M. Linksvayer, “The Choice of a GNU Generation: An Interview With Linus Torvalds,” Meta Magazine, Nov. 1993. [Online]. Available: https://gondwanaland.com/meta/history/interview.html ↩
- Torvalds: "If 386BSD had been available when I started on Linux, Linux would probably never had happened."
[12]The Open Group, “UNIX 03: Huawei Technology Co., Ltd., Huawei EulerOS 2.0 on Huawei KunLun Mission Critical Server,” registered Sep. 8, 2016. [Online]. Available: https://www.opengroup.org/openbrand/register/brand3622.htm ↩
- Huawei EulerOS 2.0 on Huawei KunLun Mission Critical Server, UNIX 03, "Registered on: 8-Sep-2016"; certificate P1204, with renewal on Sep. 8, 2022. (Huawei's announcement mentions 2019; the article uses the registration date.)
[13]G. Kroah-Hartman, “The Linux Kernel Driver Interface,” Linux kernel documentation, accessed Oct. 4, 2026. [Online]. Available: https://docs.kernel.org/process/stable-api-nonsense.html ↩
- "this article describes the in kernel interfaces, not the kernel to userspace interfaces"; the syscall interface "is very stable over time, and will not break"; pre-0.9 programs running on 2.6; at least three overhauls of the USB stack; "function names may change, structures may grow or shrink"; "trying to keep up with an ever changing kernel interface is also a rough job"; "good luck, you are on your own here, you leech".
[14]J. Liedtke, “Improving IPC by Kernel Design,” in Proc. 14th ACM Symp. on Operating Systems Principles (SOSP 1993), Asheville, 1993. [Online]. Available: https://os.itec.kit.edu/downloads/improving-ipc.pdf ↩
- 486-DX50: theoretical minimum of 172 cycles (3.5 µs), target of 350, result of 250 cycles (5 µs); gain over Mach "from a factor of 22 (8-byte messages) to 3 (4-Kbyte messages)"; mach_thread_self at 18 µs against a minimum round trip to the kernel of 2 µs.
[15]H. Härtig, M. Hohmuth, J. Liedtke et al., “The Performance of µ-Kernel-Based Systems,” 16th ACM Symposium on Operating Systems Principles (SOSP), Saint-Malo, Oct. 1997. [Online]. Available: https://os.inf.tu-dresden.de/pubs/sosp97/ ↩
- SOSP 1997: "For L4Linux, the AIM benchmarks report a maximum throughput which is only 5% lower than that of native Linux. The corresponding penalty is 5 times higher for a co-located in-kernel version of MkLinux, and 7 times higher for a user-level version of MkLinux"; MkLinux on top of a Mach-derived microkernel.
[16]Apple, “Kernel Architecture Overview,” Kernel Programming Guide (documentation archive), accessed Oct. 4, 2026. [Online]. Available: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/Architecture/Architecture.html ↩
- "OS X uses the term kernel somewhat differently than you might expect"; "The OS X kernel environment includes the Mach kernel, BSD, the I/O Kit, file systems, and networking components"; KEXTs loaded "into kernel space"; I/O Kit drivers implemented as KEXTs.
[17]Apple Inc., “Mach Overview,” in Kernel Programming Guide, Documentation Archive, accessed Oct. 4, 2026. [Online]. Available: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/Mach/Mach.html ↩
- Tasks: "units of resource ownership; each task consists of a virtual address space, a port right namespace, and one or more threads"; Ports: "Secure, simplex communication channels, accessible only via send and receive capabilities (known as port rights)"; "At the trap level, the interface to most Mach abstractions consists of messages sent to and from kernel ports"; mach_msg_overwrite_trap; MIG.
- "in OS X, Mach is linked with other kernel components into a single kernel address space. This is primarily for performance; it is much faster to make a direct call between linked components than it is to send messages or do remote procedure calls (RPC) between separate tasks"; "Mach is not primarily a communication hub between clients and servers".
[18]M. Kerrisk (ed.), “cgroups(7),” Linux manual page, accessed Oct. 4, 2026. [Online]. Available: https://man7.org/linux/man-pages/man7/cgroups.7.html ↩
- "The initial release of the cgroups implementation was in Linux 2.6.24."
[19]The Linux Kernel documentation, “FUSE Overview,” accessed Oct. 4, 2026. [Online]. Available: https://docs.kernel.org/filesystems/fuse/fuse.html ↩
- "A filesystem in which data and metadata are provided by an ordinary userspace process"; "FUSE is a userspace filesystem framework. It consists of a kernel module (fuse.ko), a userspace library (libfuse.*) and a mount utility (fusermount)"; "One of the most important features of FUSE is allowing secure, non-privileged mounts [...] A good example is sshfs"; "The filesystem daemon is running with the privileges of the mounting user"; the connection "exists until either the daemon dies, or the filesystem is umounted".
[20]The Linux Kernel documentation, “VFIO - ‘Virtual Function I/O’,” accessed Oct. 4, 2026. [Online]. Available: https://docs.kernel.org/driver-api/vfio.html ↩
- "an IOMMU/device agnostic framework for exposing direct device access to userspace, in a secure, IOMMU protected environment"; "safe, non-privileged, userspace drivers"; "turns the VM into a userspace driver"; UIO "has no notion of IOMMU protection, limited interrupt support, and requires root privileges to access things like PCI configuration space".
[21]The Linux Kernel documentation, “Extensible Scheduler Class,” accessed Oct. 4, 2026. [Online]. Available: https://docs.kernel.org/scheduler/sched-ext.html ↩
- "a scheduler class whose behavior can be defined by a set of BPF programs"; "The system integrity is maintained no matter what the BPF scheduler does. The default scheduling behavior is restored anytime an error is detected, a runnable task stalls, or on invoking the SysRq key sequence SysRq-S".
[22]A. S. Tanenbaum, “An Open Letter to Intel,” Vrije Universiteit, Nov. 2017. [Online]. Available: https://www.cs.vu.nl/~ast/intel/. Internet Archive copy of Nov. 7, 2017: https://web.archive.org/web/20171107134506/http://www.cs.vu.nl/~ast/intel/ ↩
- Letter to "Mr. Krzanich": MINIX "inside the ME-11 management engine chip"; "the most widely used computer operating system in the world"; "The L4 microkernel has been running inside smartphone chips for years"; "apparently an older version of MINIX was used... Military-grade security was never a goal"; "that is Intel's business decision and a separate issue from the code it runs". Oldest copy in the Internet Archive: Nov. 7, 2017.
[23]A. S. Tanenbaum, “MINIX is now available under the BSD license,” message in the comp.os.minix newsgroup, Apr. 7, 2000, reproduced in the MINIX FAQ. [Online]. Available: https://minix1.woodhull.com/faq/mxlicense.html ↩
- Tanenbaum, 2000-04-07: "Better late than never. I finally got permission from Prentice Hall to change the MINIX license to the BSD license. The lawyers sort of sat on this for two years."
[24]kernel.org, “Index of /pub/linux/kernel/v1.0/,” accessed Oct. 4, 2026. [Online]. Available: https://cdn.kernel.org/pub/linux/kernel/v1.0/ ↩
- Linux 1.0 files dated 13-Mar-1994.
[25]A. S. Tanenbaum et al., MINIX 2.0.4 source code (kernel/proc.c, kernel/table.c, include/minix/type.h, fs/const.h), unofficial “Minix QD” redistribution maintained by D. Given. [Online]. Available: https://github.com/davidgiven/minix2 ↩
- kernel/proc.c: "The only system calls that exist in MINIX are sending and receiving messages. These are done by trapping to the kernel with an INT instruction"; mini_send copies directly if the destination is waiting, otherwise it blocks the sender in a queue; deadlock detection with ELOCKED; "User processes are only allowed to send to FS and MM".
- include/minix/type.h: message as a union of mess_1 to mess_6, with m_source and m_type. lib/i386/rts/_sendrec.s: _send, _receive, _sendrec with int SYSVEC (33).
- kernel/table.c: TTY, DP8390, RTL8139, Sound Blaster, printer, disk, floppy, memory, clock and SYSTEM tasks compiled into the kernel; MM, FS and INIT as processes.
- fs/const.h: SUPER_MAGIC 0x137F. commands/simple/chmem.c: "Author: Andy Tanenbaum".
[26]L. Torvalds, “RELEASE NOTES for Linux v0.01,” Sep. 1991. [Online]. Available: https://www.kernel.org/pub/linux/kernel/Historic/old-versions/RELNOTES-0.01 ↩
- "uses no code from minix or other sources"; "you currently need minix to bootstrap the system"; original license: "(C) 1991 Linus Torvalds... Full source must be available (and free)".
[27]R. Card, T. Ts'o and S. Tweedie, “Design and Implementation of the Second Extended Filesystem,” Proceedings of the First Dutch International Symposium on Linux, ISBN 90-367-0385-9. [Online]. Available: https://web.mit.edu/tytso/www/linux/ext2intro.html ↩
- Linux "cross-developed under the Minix operating system"; MINIX FS support to share disks; the MINIX FS "efficient and relatively bug-free"; limits of 64 MB and 14 characters; Extended File System in April 1992 in 0.96c, with 2 GB and 255 characters.
[28]L. Torvalds, “RELEASE NOTES for Linux v0.12,” 1992. [Online]. Available: https://www.kernel.org/pub/linux/kernel/Historic/old-versions/RELNOTES-0.12 ↩
- Switch to the GPL: "make it compatible with the GNU copyleft, removing the 'you may not distribute it for money' condition. I agree"; in effect from February 1.
[29]GNU Project, “History,” GNU Hurd page, Internet Archive copy from 2024. [Online]. Available: https://web.archive.org/web/2024/https://www.gnu.org/software/hurd/history.html ↩
- Hurd on top of Mach as GNU's official kernel from Nov. 1991; GNU Hurd 0.1 on 1996-09-06; GNU 0.2 on 1997-06-16.
[30]M. K. McKusick, “Twenty Years of Berkeley Unix: From AT&T-Owned to Freely Redistributable,” in Open Sources. Sebastopol: O'Reilly, 1999. [Online]. Available: https://www.oreilly.com/openbook/opensources/book/kirkmck.html ↩
- BSDi selling from January 1992 for US$995, phone number 1-800-ITS-Unix; USL's lawsuit against BSDi and then the University of California; injunction hearing in December 1992, denied about six weeks later; settlement in January 1994 (three files removed out of 18,000); 4.4BSD-Lite in June 1994; BSDI, NetBSD and FreeBSD had to start over from it.
[31]L. Jolitz, “386BSD Release 0.1 Released on Bastille Day is Thirty-Three Years Old Today,” Lynne's Take on Tech, Jul. 14, 2025. [Online]. Available: https://lynnesblog.telemuse.net/2025/07/14/386bsd-release-0-1-released-on-bastille-day-is-thirty-three-years-old-today/ ↩
- 386BSD 0.0 in March 1992, after the series in Dr. Dobb's Journal; 386BSD 0.1 on July 14, 1992.
[32]The NetBSD Project, “The History of the NetBSD Project,” accessed Oct. 4, 2026. [Online]. Available: https://www.netbsd.org/about/history.html ↩
- NetBSD 0.8 released on April 20, 1993; project founded in 1993 from 386BSD.
[33]The FreeBSD Documentation Project, “Chapter 1. Introduction,” in FreeBSD Handbook, accessed Oct. 4, 2026. [Online]. Available: https://docs.freebsd.org/en/books/handbook/introduction/ ↩
- Origin in the "Unofficial 386BSD Patchkit" in early 1993; FreeBSD 1.0 in December 1993, on top of Net/2; USL/Novell settlement; deadline of the end of July 1994 to stop distributing the Net/2 product; 4.4BSD-Lite as the new base; FreeBSD 2.0 in December 1994 (November to rebuild the system).
[34]K. Brown and J. Orndorff, “Samizdat: And Other Issues Regarding the 'Source' of Open Source Code,” Alexis de Tocqueville Institution, May 20, 2004. [Online]. Available: https://www.itreview.org/documents/acrobat/040524.pdf ↩
- Report by Kenneth Brown (president of AdTI) and Justin Orndorff, dated May 20, 2004, questioning the origin of the Linux code and the credit given to Torvalds.
[35]A. S. Tanenbaum, “Tanenbaum-Torvalds Debate Part II,” Vrije Universiteit, 2006. [Online]. Available: https://www.cs.vu.nl/~ast/reliable-os/ ↩
- "Tanenbaum-Torvalds Debate Part II" (2006): "I met him once. He is a pleasant fellow and very smart..."; "Microsoft paid a guy named Ken Brown to write a book saying Linus stole Linux from my MINIX 1 system"; Mac OS X "sort of microkernelish... Since all of it runs in kernel mode... it is not a true microkernel"; lists QNX, Integrity, PikeOS, Symbian, L4Linux; "clearly I am not alone in seeing something in microkernels".
[36]A. Toptygin, message to A. S. Tanenbaum published in “Comparison of Linux Code with MINIX Code,” Vrije Universiteit, 2004. [Online]. Available: https://www.cs.vu.nl/~ast/brown/codecomparison/ ↩
- Message from Alexey Toptygin: consulting work for Ken Brown; results sent on May 17; "my analysis found no evidence whatsoever that any code was copied one way or the other"; Brown thought it "clearly impossible for one person to write an OS".
[37]A. Toptygin, “Source comparison of early linux and minix versions,” 2004. [Online]. Available: https://www.cs.vu.nl/~ast/brown/codecomparison/alexey.html ↩
- Compared Linux 0.01, 0.11, 0.12 (and later versions) with MINIX: "Only 4 actual similarities were found"; "the similarity was required by external factors (the C standard, the POSIX standard, the minix filesystem format)".
[38]LinuxWorld News Desk, “Linus Torvalds Isn't the 'Father of Linux',” LinuxWorld, May 17, 2004, Internet Archive copy of Jun. 10, 2004. [Online]. Available: https://web.archive.org/web/20040610132547/http://www.linuxworld.com:80/story/44841.htm ↩
- Torvalds's email to LinuxWorld, May 17, 2004: "Ok, I admit it. I was just a front-man for the real fathers of Linux, the Tooth Fairy and Santa Claus"; a Finnish Santa Claus with contacts at the University of Helsinki.
[39]Association for Computing Machinery, “Andrew S Tanenbaum: ACM Software System Award 2023,” accessed Oct. 4, 2026. [Online]. Available: https://awards.acm.org/award_winners/tanenbaum_1309681 ↩
- ACM Software System Award 2023: "For MINIX, which influenced the teaching of Operating Systems principles to multiple generations of students and contributed to the design of widely used operating systems, including Linux."
[40]J. Kara, “[PATCH v2] reiserfs: Deprecate reiserfs,” message on the reiserfs-devel list, Feb. 2022, archived by LWN. [Online]. Available: https://lwn.net/Articles/886142/ ↩
- Jan Kara (suse address), Feb. 2022: "development has ceased quite some years ago... To reduce maintenance burden... schedule its removal to 2025".
[41]Phoronix, “ReiserFS Has Been Deleted From The Linux Kernel,” accessed Oct. 4, 2026. [Online]. Available: https://www.phoronix.com/news/ReiserFS-Deleted-Linux-6.13 ↩
- ReiserFS removed in Linux 6.13; about 32.8 thousand lines.
[42]A. Chou, J. Yang, B. Chelf, S. Hallem and D. Engler, “An Empirical Study of Operating Systems Errors,” 18th ACM Symposium on Operating Systems Principles (SOSP), 2001. [Online]. Available: https://web.stanford.edu/~engler/metrics-sosp-01.pdf ↩
- Static analysis of Linux and OpenBSD; in Linux 2.4.1 "the vast majority of bugs are in drivers"; drivers with an error rate 3 to 7 times that of the rest of the kernel; "almost seven times higher" for the lock checker.
[43]M. M. Swift, B. N. Bershad and H. M. Levy, “Improving the Reliability of Commodity Operating Systems,” in Proc. 19th ACM Symp. on Operating Systems Principles (SOSP 2003), Bolton Landing, 2003. [Online]. Available: https://swift.sites.cs.wisc.edu/classes/cs736-fa06/papers/nooks.pdf ↩
- "In Windows XP, for example, drivers account for 85% of recently reported failures"; "Nooks recovered automatically from 99% of the faults that caused Linux to crash"; 2,000 injection tests; Nooks with about 22,000 lines against 2.4 million in the kernel; drivers stay in ring 0, isolated by page tables in lightweight protection domains.
[44]A. S. Tanenbaum, J. N. Herder and H. Bos, “Can We Make Operating Systems Reliable and Secure?,” IEEE Computer, vol. 39, no. 5, May 2006. [Online]. Available: https://www.cs.vu.nl/~ast/Publications/Papers/computer-2006a.pdf ↩
- Tanenbaum, Herder and Bos, IEEE Computer, May 2006: 6 to 16 bugs per 1000 lines; "Using a conservative estimate of 6 bugs per 1000 lines of code the Linux kernel probably has something like 15,000 bugs; Windows has at least double that".
- MINIX 3: "The clock driver shares the microkernel's address space, but is scheduled as a separate process. No other drivers run in kernel mode"; a 4,000-line kernel and a 4,500-line file server; "fixed-length messages using the rendezvous principle"; asynchronous notifications through a bitmap.
[45]N. Palix, G. Thomas, S. Saha, C. Calvès, J. Lawall and G. Muller, “Faults in Linux: Ten Years Later,” in Proc. ASPLOS 2011, Newport Beach, 2011, pp. 305–318. [Online]. Available: https://coccinelle.gitlabpages.inria.fr/website/papers/asplos11.pdf ↩
- Study from 2.6.0 to 2.6.33; the kernel more than doubled and the fault rate fell; drivers with staging = 57% of the code since 2.6.30; the drivers' fault rate "is now below that of other directories, such as arch (HAL) and fs (file systems)" and, since 2.6.19, "right at the average".
[46]A. Modine, “Linus calls Linux 'bloated and huge',” The Register, Sep. 22, 2009. [Online]. Available: https://www.theregister.com/2009/09/22/linus_torvalds_linux_bloated_huge/ ↩
- LinuxCon, 2009-09-21 (published 2009-09-22): "We're getting bloated and huge. Yes, it's a problem"; "not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary".
[47]J. N. Herder, H. Bos, B. Gras, P. Homburg and A. S. Tanenbaum, “Failure Resilience for Device Drivers,” in Proc. 37th IEEE/IFIP Int. Conf. on Dependable Systems and Networks (DSN 2007), Edinburgh, 2007, pp. 41–50. [Online]. Available: https://www.few.vu.nl/~ast/Publications/Papers/dsn-2007.pdf ↩
- How the reincarnation server works: the service utility with binary, stable name, privileges, heartbeat period and policy script; detection of exit, panic, CPU or MMU exception, missed heartbeats; replacement requested by the file server; data store publishing the new endpoint; reissue of pending block I/O.
- Experiments: RTL8139 with a 512 MB wget, correct checksums and throughput loss of 25% to 1%; SATA reading 1 GB, loss of 62% to 7%, same SHA-1; DP8390 in Bochs, more than 12,500 injected faults, 347 detectable crashes, "The subsequent recovery was successful in 100% of the induced failures"; over 99% on real hardware; five lines changed in the driver library.
- Limits: Byzantine failures, silent corruption, deterministic bugs, broken hardware; "In general, end-to-end checksums are required to prevent silent" corruption. DMA: "To perform DMA safely a driver should first request the kernel to set up the I/O MMU".
[48]MINIX 3 Wiki, “Frequently Asked Questions,” accessed Oct. 4, 2026. [Online]. Available: https://wiki.minix3.org/doku.php?id=faq ↩
- "MINIX 3 is 5-10% slower" than MINIX 2 (drivers in kernel mode); "our priority has been reliability, not performance"; BSD license.
[49]MINIX 3 Wiki, “Release notes 3.3.0,” accessed Oct. 4, 2026. [Online]. Available: https://wiki.minix3.org/doku.php?id=www:download:releasenotes-3.3.0 ↩
- "In 2008, the European Research Council awarded Prof. Andrew S. Tanenbaum [...] an Advanced Grant of €2.5 million"; BSD license; PC and ARM; "Userland is largely compatible with NetBSD and runs thousands of NetBSD packages".
[50]L. Torvalds, “Hybrid (micro)kernels,” Real World Technologies forum, May 9, 2006. [Online]. Available: https://www.realworldtech.com/forum/?threadid=65915&curpostid=65936 ↩
- Torvalds, 2006-05-09: "The fundamental result of access space separation is that you can't share data structures... All your algorithms basically end up being distributed algorithms"; "As to the whole 'hybrid kernel' thing - it's just marketing".
[51]G. Heiser and K. Elphinstone, “L4 Microkernels: The Lessons from 20 Years of Research and Deployment,” ACM Trans. on Computer Systems, vol. 34, no. 1, art. 1, Apr. 2016. [Online]. Available: https://trustworthy.systems/publications/nicta_full_text/8988.pdf ↩
- "The typical cost for a one-way message was around 100 µs"; "a trend to move core services back into the kernel". IPC table: 1993 L4 at 5 µs; 2013 seL4 on a 3.4 GHz Core i7 Haswell at 0.09 µs (301 cycles); 532 MHz ARM11, 188 cycles.
- Qualcomm: "massive-scale commercial deployment when Qualcomm adopted it as a protected-mode real-time OS for the firmware of their wireless modem processors"; "running on the security processor of all recent Apple iOS devices"; footnote 2: "Total deployment is now in the billions"; PikeOS "certified for use in safety-critical avionics and deployed in aircraft and trains".
- Drivers: "make all device drivers user-level processes", except the timer and the interrupt controller; unverified drivers in the kernel "would obliterate any guarantees"; "even 9,000 SLOC pushed the limits of what was achievable".
[52]J. Liedtke, “On µ-Kernel Construction,” in Proc. 15th ACM Symp. on Operating Systems Principles (SOSP 1995), Copper Mountain, 1995. [Online]. Available: https://os.itec.kit.edu/downloads/publ_1995_liedtke_ukernel-construction.pdf ↩
- Minimality criterion: "only if moving it outside the kernel, i.e. permitting competing implementations, would prevent the implementation of the system's required functionality"; "µ-kernels are inherently not portable. Instead, they are the processor dependent basis for portable operating systems".
[53]A. S. Tanenbaum, “Followup statement on Ken Brown's motivation,” Vrije Universiteit, May 21, 2004. [Online]. Available: https://www.cs.vu.nl/~ast/brown/followup/ ↩
- May 21, 2004: "Microsoft claimed that Windows NT 3.51 was a microkernel. It wasn't. It wasn't even close. Even they dropped the claim with NT 4.0"; "I would easily give up 20% in performance for a system that was robust, reliable".
[54]The Open Group, “UNIX 03: Apple Inc., macOS version 15.0 Sequoia on Apple silicon-based Mac computers,” registered Sep. 12, 2024. [Online]. Available: https://www.opengroup.org/openbrand/register/brand3710.htm ↩
- macOS 15.0 Sequoia registered as UNIX 03 on 12-Sep-2024.
[55]Apple, “Apple Platform Security,” PDF guide, accessed Oct. 4, 2026. [Online]. Available: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf ↩
- "The Secure Enclave Processor runs an Apple-customized version of the L4 microkernel."
[56]Apple Inc., “XNU kernel,” README of the apple-oss-distributions/xnu repository, accessed Oct. 4, 2026. [Online]. Available: https://github.com/apple-oss-distributions/xnu ↩
- "XNU is a hybrid kernel combining the Mach kernel developed at Carnegie Mellon University with components from FreeBSD and a C++ API for writing drivers called IOKit"; "osfmk - Mach kernel based subsystems"; "bsd - BSD subsystems code"; runs on x86_64 and ARM64.
[57]Apple Inc., “DriverKit,” Apple Developer Documentation, accessed Oct. 4, 2026. [Online]. Available: https://developer.apple.com/documentation/driverkit ↩
- "Develop device drivers that run in user space."; "The drivers you build with DriverKit run in user space, rather than as kernel extensions, which improves system stability and security".
[58]Apple Inc., “Deprecated Kernel Extensions and System Extension Alternatives,” Apple Developer Support, accessed Oct. 4, 2026. [Online]. Available: https://developer.apple.com/support/kernel-extensions/ ↩
- Kernel extensions deprecated; "Starting with macOS Big Sur, macOS releases no longer load kernel extensions that use deprecated KPIs by default".
[59]FreeBSD Project, “FreeBSD 4.0 Announcement,” Mar. 14, 2000. [Online]. Available: https://www.freebsd.org/releases/4.0R/announce/ ↩
- Announcement of FreeBSD 4.0-RELEASE, Mar. 14, 2000.
[60]P.-H. Kamp and R. N. M. Watson, “Jails: Confining the omnipotent root,” 2nd International SANE Conference, 2000. [Online]. Available: https://papers.freebsd.org/2000/phk-jails/ ↩
- Kamp and Watson, 2000: jail "provides the ability to partition the operating system environment, while maintaining the simplicity of the UNIX 'root' model"; most popular use "providing virtual machine services in Internet Service Provider environments".
[61]M. Kerrisk (ed.), “mount_namespaces(7),” Linux manual page, accessed Oct. 4, 2026. [Online]. Available: https://man7.org/linux/man-pages/man7/mount_namespaces.7.html ↩
- HISTORY section: mount namespaces in Linux 2.4.19.
[62]kernel.org, “Index of /pub/linux/kernel/v2.6/,” accessed Oct. 4, 2026. [Online]. Available: https://cdn.kernel.org/pub/linux/kernel/v2.6/ ↩
- linux-2.6.24.tar.gz dated 24-Jan-2008.
[63]M. Kerrisk (ed.), “namespaces(7),” Linux manual page, accessed Oct. 4, 2026. [Online]. Available: https://man7.org/linux/man-pages/man7/namespaces.7.html ↩
- "since Linux 3.8, no privilege is required to create a user namespace".
[64]FreeBSD Documentation Project, “Chapter 23. The Z File System (ZFS),” FreeBSD Handbook, accessed Oct. 4, 2026. [Online]. Available: https://docs.freebsd.org/en/books/handbook/zfs/ ↩
- ZFS "Originally developed at Sun Microsystems".
[65]FreeBSD Project, “FreeBSD 7.0-RELEASE Release Notes,” 2008. [Online]. Available: https://www.freebsd.org/releases/7.0R/relnotes/ ↩
- "Support for Sun's ZFS has been added."
[66]FreeBSD Project, “FreeBSD 7.0-RELEASE Announcement,” Feb. 27, 2008. [Online]. Available: https://www.freebsd.org/releases/7.0R/announce/ ↩
- Announcement of FreeBSD 7.0-RELEASE, Feb. 27, 2008.
[67]B. M. Cantrill, M. W. Shapiro and A. H. Leventhal, “Dynamic Instrumentation of Production Systems,” USENIX Annual Technical Conference, Boston, Jun. 2004. [Online]. Available: https://www.usenix.org/legacy/event/usenix04/tech/general/full_papers/cantrill/cantrill.pdf ↩
- Cantrill, Shapiro and Leventhal (Solaris Kernel Development, Sun), USENIX 2004: DTrace instruments user space and the kernel "in a unified and absolutely safe fashion"; "zero probe effect".
[68]FreeBSD Project, “FreeBSD 7.1-RELEASE Release Notes,” 2009. [Online]. Available: https://www.freebsd.org/releases/7.1R/relnotes/ ↩
- DTrace and dtrace(1) "have been imported from OpenSolaris".
[69]FreeBSD Project, “FreeBSD 7.1-RELEASE Announcement,” Jan. 4, 2009. [Online]. Available: https://www.freebsd.org/releases/7.1R/announce/ ↩
- Announcement of FreeBSD 7.1-RELEASE, Jan. 4, 2009.
[70]FreeBSD Documentation Project, “DTrace,” FreeBSD Handbook, accessed Oct. 4, 2026. [Online]. Available: https://docs.freebsd.org/en/books/handbook/dtrace/ ↩
- "DTrace... was developed by Sun™ as a tool for locating performance bottlenecks in production and pre-production systems."
[71]Kernel Newbies, “Linux 3.18,” accessed Oct. 4, 2026. [Online]. Available: https://kernelnewbies.org/Linux_3.18 ↩
- Released on Dec. 7, 2014; bpf() syscall: "eBPF programs are similar to kernel modules. They are loaded by the user process and automatically unloaded when process exits. [...] eBPF verifier statically determines that the program terminates and is safe to execute".
[72]A. S. Tanenbaum, “Rebuttal to Ken Brown,” Vrije Universiteit, Jun. 6, 2004. [Online]. Available: https://www.cs.vu.nl/~ast/brown/rebuttal/ ↩
- June 6, 2004: David Cutler, "one of the principal architects of the operating system for the DEC VAX, VMS", hired by Microsoft to lead Windows NT; "Operating system designers of Cutler's quality are few and far between".
[73]Microsoft, “MS Windows NT Kernel-mode User and GDI White Paper,” TechNet, archived on Microsoft Learn (Previous Versions), accessed Oct. 4, 2026. [Online]. Available: https://learn.microsoft.com/en-us/previous-versions/cc750820(v=technet.10) ↩
- Layers: HAL, "microkernel" (interrupts, DPCs, scheduling, synchronization) and Executive; "From the start the Windows NT architecture has fallen squarely into the modified microkernel or macrokernel camp"; memory manager, cache, file systems, object/security, network protocols and server, and processes in kernel mode since the first version; Win32 as a privileged "application"; USER and GDI in CSRSS.EXE in NT 3.51.
- Reasons for the NT 4.0 change: 64K shared buffer, context switches; client-server transition on a Pentium 100 "in the order of 60-70 m seconds", against "4 to 5 m seconds" into kernel mode (the page renders "µ" as "m"; I read it as microseconds, the only reading consistent with the order of magnitude); savings of 256K to 1 MB of working set; PowerPoint 15 to 20 percent faster; graphics drivers entirely in kernel mode.
- "No commercial operating system is based on a pure microkernel design. The reason is simple: the pure microkernel design is commercially impractical because it is too computationally expensive"; "What is the practical difference [...] between an operating system that crashes from time to time and one that continues running but loses all access to persistent storage?"; NT 3.51 GDI failing: "a system that appears to have crashed".
[74]Microsoft, “Overview of UMDF,” Windows drivers, Microsoft Learn, updated Dec. 15, 2021. [Online]. Available: https://learn.microsoft.com/en-us/windows-hardware/drivers/wdf/overview-of-the-umdf ↩
- "UMDF drivers abstract hardware functionality, run in the user-mode environment"; host process, driver manager and reflector; "File system drivers, display drivers (...), and print drivers cannot be UMDF drivers".
[75]The Linux Kernel Archives, “linux-7.2.tar.xz,” Aug. 17, 2026 (file and line counts by the author). [Online]. Available: https://cdn.kernel.org/pub/linux/kernel/v7.x/ ↩
- My own count on Oct. 4, 2026, on the official tarball (date in the index: 17-Aug-2026): 65,637 .c/.h/.S/.rs files, 37,730,727 lines; drivers/ 26,034,547 lines (69.0%); arch/ 6.7%; sound/ 4.4%; fs/ 4.3%; kernel/ 1.5%; mm/ 0.6%; .rs files 182,584 lines (about 0.5%). On the same date, kernel.org listed 7.2.9 as stable (Oct. 3, 2026) and 7.3-rc6 as mainline.
[76]Kernel Newbies, “Linux 2.6.14,” accessed Oct. 4, 2026. [Online]. Available: https://kernelnewbies.org/Linux_2_6_14 ↩
- Released on Oct. 27, 2005; FUSE: "Allows to implement a fully functional filesystem in a userspace program".
[77]H.-J. Koch, “The Userspace I/O HOWTO,” Linux kernel documentation, 2006. [Online]. Available: https://docs.kernel.org/driver-api/uio-howto.html ↩
- UIO (document of 2006-12-11): "bugs in your driver won't crash the kernel"; "updates of your driver can take place without recompiling the kernel"; network, serial or USB "are no candidates for an UIO driver".
[78]Kernel Newbies, “Linux 3.6,” accessed Oct. 4, 2026. [Online]. Available: https://kernelnewbies.org/Linux_3.6 ↩
- Released on Sep. 30, 2012, with VFIO.
[79]The Linux Kernel documentation, “eBPF verifier,” accessed Oct. 4, 2026. [Online]. Available: https://docs.kernel.org/bpf/verifier.html ↩
- "First step does DAG check to disallow loops and other CFG validation"; "Second step starts from the first insn and descends all possible paths. It simulates execution of every insn and observes the state change of registers and stack".
[80]Kernel Newbies, “Linux 6.12,” accessed Oct. 4, 2026. [Online]. Available: https://kernelnewbies.org/Linux_6.12 ↩
- Released on Nov. 17, 2024, with sched_ext.
[81]J. Corbet, “A first look at Rust in the 6.1 kernel,” LWN.net, Oct. 13, 2022. [Online]. Available: https://lwn.net/Articles/910762/ ↩
- Rust entered 6.1; "No system with a production 6.1 kernel will be running any Rust code".
[82]J. Corbet, “The (successful) end of the kernel Rust experiment,” LWN.net, Dec. 10, 2025. [Online]. Available: https://lwn.net/Articles/1049831/ ↩
- Consensus of the 2025 Maintainers Summit: Rust in the kernel is no longer experimental and becomes a core, permanent part of it; the "experimental" tag will be removed. (The original sentence has an em dash; the article paraphrases it.)
[83]J. Corbet, “The state of the kernel Rust experiment,” LWN.net, Dec. 13, 2025. [Online]. Available: https://lwn.net/Articles/1050174/ ↩
- Ojeda: the Nova driver with parts in mainline; "Android binder driver was merged for 6.18"; Android 16 with kernel 6.12 shipping the ashmem module in Rust: "So there are millions of real devices running kernels with Rust code now".
- Kroah-Hartman: drivers in Rust "are indeed proving to be far safer than those written in C"; "no such CVE has yet been issued". Airlie: DRM "about a year away" from requiring Rust for new drivers. Torvalds: "after nearly five years, the time had come".
[84]G. Klein et al., “seL4: Formal Verification of an OS Kernel,” 22nd ACM Symposium on Operating Systems Principles (SOSP), Oct. 2009. [Online]. Available: https://www.sigops.org/s/conferences/sosp/2009/papers/klein-sosp09.pdf ↩
- seL4 "comprises 8,700 lines of C code and 600 lines of assembler"; "the first formal proof of functional correctness of a complete, general-purpose operating-system kernel"; "With truly small kernels it becomes possible... to guarantee the absence of bugs"; NICTA and UNSW.
- Proof with 200,000 lines of Isabelle script; "We have proved over 150 invariants"; kernel with a total cost of 2.2 py including Haskell; proof "in total about 20 py", seL4-specific "11 py"; the US$10,000-per-line rule for EAL6 would give "$87M for seL4"; bugs found by the second proof "mainly typos, misreading the specification, or failing to update all relevant code parts", enough to "crash the kernel or create security vulnerabilities".
[85]J. Edge, “Replacing x86 firmware with Linux and Go,” LWN.net, Nov. 20, 2017. [Online]. Available: https://lwn.net/Articles/738649/ ↩
- Jake Edge, 2017-11-20, on the talk by Ronald Minnich (Google) at ELCE 2017 in Prague: "Ring -3... It runs MINIX 3 and is where the ME runs"; "year of MINIX 3 on the desktop"; IPv4/IPv6 stacks, file systems, drivers, web servers; "can reimage the system even if the power is turned off".
[86]M. Ermolov and M. Goryachy, “How to Hack a Turned-Off Computer, or Running Unsigned Code in Intel Management Engine,” Black Hat Europe 2017. [Online]. Available: https://www.blackhat.com/eu-17/briefings.html#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine ↩
- Talk by Mark Ermolov and Maxim Goryachy at Black Hat Europe 2017, "How to Hack a Turned-Off Computer, or Running Unsigned Code in Intel Management Engine" (cited only for the existence and title of the talk).
[87]MINIX 3, “What Is MINIX 3?,” accessed Oct. 4, 2026. [Online]. Available: https://www.minix3.org/ ↩
- "designed to be highly reliable, flexible, and secure"; "a tiny microkernel running in kernel mode with the rest of the operating system running as a number of isolated, protected, processes in user mode".
[88]MINIX 3 Wiki, “Features,” accessed Oct. 4, 2026. [Online]. Available: https://wiki.minix3.org/doku.php?id=www:documentation:features ↩
- "Tiny microkernel that runs in kernel mode"; "Each device driver is a separate user-mode process"; "Reincarnation server can reload failed drivers".
[89]Stichting MINIX Research Foundation, “minix: Official MINIX sources,” GitHub repository, tag v3.3.0 and commit 4db99f4 of Nov. 14, 2018, accessed Oct. 4, 2026. [Online]. Available: https://github.com/Stichting-MINIX-Research-Foundation/minix ↩
- Latest tag v3.3.0; last commit on the main branch: 4db99f4, 2018-11-14 07:26 UTC (04:26 BRT), "Remove building with NOCRYPTO option".
[90]The kernel development community, “CPU Architectures,” Linux kernel documentation, accessed Oct. 4, 2026. [Online]. Available: https://docs.kernel.org/arch/index.html ↩
- List of documented architectures: ARC, ARM, ARM64, LoongArch, m68k, MIPS, Nios II, OpenRISC, PA-RISC, powerpc, RISC-V, s390, SuperH, Sparc, x86, Xtensa (16).

Items checked that did not become sources

Samizdat and AdTI's funding: the claim that Microsoft paid Brown appears in the article only as Tanenbaum's claim [35]; I did not use secondary sources (Wikipedia, Linux.com) to state it as fact.
QNX: the official documentation (QNX SDP 8.0, "The Philosophy of the QNX OS") was consulted, but the accessible page does not describe user-space drivers; the article cites QNX only through what Tanenbaum wrote.
GNU Hurd: gnu.org blocked direct access (403); I used the Internet Archive copy.
Just for Fun (L. Torvalds and D. Diamond, 2001): I looked for the text to quote passages about 1991, but the Internet Archive only offers restricted lending and its internal search failed. I did not cite the book. As a first-hand account, I used Torvalds's own text of July 1992 ("LINUX's History") [10].
The line counts for Linux 0.01 and Linux 7.2 are mine, made on the official kernel.org tarballs on Oct. 4, 2026 (.c, .h, .s/.S and .rs files, physical lines, comments included). Other tools (cloc, sloccount) give smaller numbers.
NT white paper: the Microsoft Learn page shows "m seconds" where the original used the µ symbol. I treated it as microseconds.
QNX: I could not download architecture documentation that would support claims of my own; QNX appears only through the words of Tanenbaum and of Heiser and Elphinstone.
osr2006.pdf (Tanenbaum's article in ACM SIGOPS OSR, 2006) is a scanned PDF without a text layer and was not used.

摘要

1992 年 1 月 29 日，阿姆斯特丹自由大學（Vrije Universiteit）教授、MINIX 的作者 Andrew S. Tanenbaum，在 comp.os.minix 新聞群組開了一個名為「LINUX is obsolete」的討論串。他寫道，Linux 是「a giant step back into the 1970s」[1]。三十四年後，Linux 跑在全球最快的全部 500 台超級電腦上 [2]，也是 Android 核心的基礎 [3]。宣布教授落敗、就此結案，是很容易的事。本文回到原始貼文、Linux 0.01 與 MINIX 2 的程式碼，以及量測過錯誤、IPC 與驅動程式復原的論文，把有文件根據的事實和民間傳說分開。說 Linux 是 MINIX 抄本的人錯了。把 Linux 當成一切的發明者、用輕蔑的眼光看待 macOS、BSD 與 Windows 的人，也錯了。Linux 靠授權和在對的時間出現而勝出。在可靠性上，Tanenbaum 的技術論點仍然站得住腳，Linux 自己也一點一點吸收了其中的部分，而許多被歸功於 Linux 的東西，其實更早就出現在其他系統裡。

流傳的迷思

我每天都用 Linux，在家和工作上都用，工作上也會碰 FreeBSD。兩個我都喜歡。正因如此，關於作業系統的討論常常帶著的那種宗派口吻，讓我很不舒服。一邊是批評者，把 Linux 當成 MINIX 拙劣的抄本，還發誓說據稱當過 Linus 老師的 Tanenbaum 從第一天起就和他劃清界線。另一邊是信徒，認為 Linux 發明了容器、macOS 是不會用終端機的人的玩具、BSD 是博物館裡的東西，而 Windows 的每個驅動程式都是定時炸彈。

這兩種看法的共通點，是對文件不感興趣。而文件是存在的。1992 年的論戰逐字存檔 [1], [4]。Linux 第一個版本的程式碼仍在 kernel.org 上 [5]。2004 年，華盛頓的一家研究機構指控 Torvalds 抄襲時，Tanenbaum 長篇寫下了 Linux 的起源 [6]。UNIX 認證記錄在 The Open Group 的公開登錄中 [7]。Microsoft 記載了 Windows 驅動程式如何運作 [8]，FreeBSD 則記載了 jail 從什麼時候開始存在 [9]。

本文檢驗的迷思如下，每一個都附上事實給出的簡短答案：

迷思	文件顯示的事實
「Linux 是 MINIX 的抄本」	就程式碼而言是錯的。Torvalds 在 MINIX 上開發，照搬了檔案系統的布局，也從那本書得到啟發，但程式碼是他自己寫的，這是 Tanenbaum 本人說的 [6]。
「Tanenbaum 是 Linus 的老師」	錯。Torvalds 在赫爾辛基念書；在阿姆斯特丹的 Tanenbaum 說他只見過他一次 [10], [6]。
「Tanenbaum 說 Linux 是一種倒退」	1992 年確有其事。但在同一封訊息中，他說自己對 Linux 並無不滿，2004 年還為它辯護 [1], [6]。
「Torvalds 從來不承認任何事」	錯。他同意微核心「are nicer」，並在隔天公開道歉 [1], [4]。
「Linux 勝出是因為技術上比較優越」	大體上是錯的。主角們自己把勝利歸因於 GNU 的延宕，以及針對 BSD 的訴訟 [1], [11], [6]。
「Linux 根本不是 UNIX」	就商標而言是對的。如果意思是 Linux 系統通過不了認證，那就錯了：已經有一套通過了 [12]。
「Linux 的 ABI 老是壞掉」	對應用程式而言是錯的。對核心內的驅動程式而言是對的，而且是刻意的 [13]。
「微核心天生就慢」	言過其實。Mach 很慢；但 1993 年 L3 傳遞訊息的速度已經快上二十倍，而跑在 L4 上的 Linux 只損失 5% [14], [15]。
「macOS 用了 Mach，所以是微核心」	錯。在 XNU 中，Mach 與 BSD 一起在核心模式下執行 [16], [17]。
「Linux 發明了容器」	錯。FreeBSD 的 jail 在 2000 年推出；cgroups 的第一版在 2008 年才進入 Linux [9], [18]。
「Linux 跟微核心毫無關係」	錯。FUSE、UIO、VFIO 與以 eBPF 寫成的排程器，會把部分功能移出核心或加以隔離，只是不改變架構 [19], [20], [21]。
「微核心就等於安全」	言過其實。Tanenbaum 本人寫過，軍規等級的安全從來不是 MINIX 的目標 [22]。

本文其餘部分會說明這張表的每一列從何而來。

MINIX 是什麼

MINIX 生來就是為了放進教室。Tanenbaum 寫它是為了搭配 1987 年的著作 Operating Systems: Design and Implementation，原始碼由 Prentice Hall 另行販售，售價 69 美元 [6]。在 1992 年的討論中，他解釋這種限制是刻意的：「An explicit design goal was to make it run on cheap hardware so students could afford it. In particular, for years it ran on a regular 4.77 MHZ PC with no hard disk」[4]。在同一封訊息中，他說給原始 PC 的版本，銷量是 286/386 版本的兩倍。

把 MINIX 叫做做工粗糙的玩具，是誤解了它的用意。MINIX 之所以小，是因為目標是教學。但它確實不適合當生產系統，而 Tanenbaum 也不希望它是。2004 年，他說 comp.os.minix 的訂閱者一度達到 40,000 人，而他每天收到 200 封要求增加功能的電子郵件，例如「I need pseudoterminals and I need them by Friday」。他的回答通常是「No.」原因是：「everyone was trying to turn MINIX into a production-quality UNIX system and I didn't want it to get so complicated that it would become useless for my purpose, namely, teaching it to students」[6]。1992 年 2 月，他在群組裡已經說過同樣的話：他拒絕了虛擬記憶體、分頁、符號連結與視窗系統，因為他想要「keep the system simple enough for students to understand」[4]。他認為這個空間很快會被 GNU 或柏克萊的 BSD 填補。

授權也有影響。Prentice Hall 要求商業販售這套系統的人支付權利金，律師們在 MINIX 裡塞滿了「boilerplate」，雖然依 Tanenbaum 的說法，「there was never any intention of really enforcing this against universities or students」[6]。1992 年，一份拷貝售價 169 美元，授權允許兩份備份，教授可以為學生製作無限份拷貝 [4]。然而，改進系統的人只能散布相對於官方版本的差異檔。Rutgers 大學的 Charles Hedrick 在同一場論戰中寫道，他離開了 MINIX 社群，因為這份授權雖然「while amazingly friendly」，卻讓想要 386 版本的人很難辦事：「all they could distribute were diffs」，使得新使用者幾乎無法安裝 [4]。完全開放花了很久。2000 年 4 月 7 日，Tanenbaum 在 comp.os.minix 上宣布：「Better late than never. I finally got permission from Prentice Hall to change the MINIX license to the BSD license. The lawyers sort of sat on this for two years」[23]。那時，Linux 1.0 都已經發布六年了 [24]。

MINIX 的內部：一切都是訊息

MINIX 2.0.4 是 2 系列的最後一個版本，它的程式碼展示了 Tanenbaum 所說的微核心。這份程式碼仍可在非官方的再散布版本中取得，例如 David Given 維護的那一份 [25]。kernel/proc.c 開頭的註解概括了整個架構：「The only system calls that exist in MINIX are sending and receiving messages. These are done by trapping to the kernel with an INT instruction」[25]。在 386 的函式庫中，_send、_receive 與 _sendrec 這幾個函式把目的地和訊息位址放進暫存器、指定操作，然後執行 int 33 [25]。

訊息的大小是固定的。在 include/minix/type.h 中，message 型別是六種格式的聯合（union），從 mess_1 到 mess_6，每一種都是整數、long 與指標的某種組合，再加上來源與類型欄位 [25]。核心不配置緩衝區，也不維護訊息佇列。傳遞遵循會合（rendezvous）原則：如果接收者已經被阻塞、正在等這則訊息，mini_send 就直接把訊息複製給它；否則，傳送者會被阻塞，排進掛在接收者身上的佇列，直到接收者呼叫 receive [25]。同一段程式碼會沿著被阻塞的傳送者鏈走一遍，偵測兩個行程互相傳送給對方的情況，並回傳 ELOCKED，而不是讓系統卡死。

權限已經是最小化的。使用者行程只能使用合併的操作，也就是傳送後等待回覆，而且只能與兩個目的地溝通：「User processes are only allowed to send to FS and MM」[25]。實際上，一次 read() 在函式庫內部會變成一則送給檔案系統（FS）的訊息，而 FS 與磁碟任務之間也是透過訊息溝通。kernel/table.c 中的任務表顯示了分工：TTY、DP8390 與 RTL8139 網路卡、Sound Blaster、印表機、磁碟控制器、軟碟、記憶體、時鐘以及系統任務，都是編譯進核心映像檔的任務；而記憶體管理器（MM）、FS 與 INIT 則是獨立的行程 [25]。

這就是 1992 年的標準。Tanenbaum 在原始貼文中寫道，檔案系統與記憶體管理器以獨立行程執行，I/O 驅動程式也是行程，「in the kernel, but only because the brain-dead nature of the Intel CPUs makes that difficult to do otherwise」[1]。MINIX 1 與 2 的驅動程式和 Linux 的一樣，都在核心模式下執行。差別在於形式：每個驅動程式都是一個擁有自己訊息迴圈的任務，而不是被直接呼叫的函式。

這種設計的代價，在論戰中浮現出來。由於只有一個 FS 行程，一次處理一個請求，讀取慢速軟碟的人會卡住想做其他事的人。愛丁堡大學的 Richard Tobin 抱怨：「I find the single-threaded file system a serious pain when using Minix」[4]。Tanenbaum 回答：「A multithreaded file system is only a performance hack. When there is only one job active, the normal case on a small PC, it buys you nothing」[4]。對教學的人來說，這是枝微末節。對每天使用這套系統的人來說，可不是。

1991 年 8 月：一個不抄程式碼的業餘嗜好

1991 年 8 月 25 日，赫爾辛基大學的學生 Linus Torvalds 在 comp.os.minix 上發文：「I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones」。在同一篇貼文中，他問大家喜歡或不喜歡 MINIX 的哪些地方，「as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things)」。附註說得很直接：「Yes - it's free of any minix code, and it has a multi-threaded fs. It is NOT protable (uses 386 task switching etc)」[10]。

1991 年 9 月 0.01 版的發行說明重申了這一點，並解釋了依賴關係：「Although linux is a complete kernel, and uses no code from minix or other sources, almost none of the support routines have yet been coded. Thus you currently need minix to bootstrap the system」[26]。Linux 誕生在 MINIX 裡面：在其中編譯，也從其中安裝。這種依賴是環境上的，不是程式碼上的。

Jyrki Kuoppala 問這個系統有多少是用 C 寫的，能不能移植到 Amiga。Torvalds 在 8 月 26 日的回答，是對這個專案的誠實寫照：「Simply, I'd say that porting is impossible. It's mostly in C, but most people wouldn't call what I write C. It uses every conceivable feature of the 386 I could find, as it was also a project to teach me about the 386」[10]。他解釋，每個任務有一個 64 MB 的區段，4 GB 中最多 64 個任務；有些 C 檔案「almost as much assembler as C」；結果是「a porters nightmare」。Kuoppala 也要求使用者模式的檔案系統。Torvalds 認為清單上幾乎每一項都可行，「except maybe for the user-mode filesystems」[10]。這個要求要到十四年後才實現，換了個名字。

Linux 0.01 裡面有什麼

原始的 tarball 仍放在 kernel.org 上。檔案的日期介於 1991 年 6 月 15 日到 9 月 17 日之間，其中大多數（60 個）落在 9 月 11 日到 17 日。依我的計算，共有 88 個檔案，C 原始碼、標頭檔與組合語言合計 9,877 行 [5]。這棵目錄樹已經有核心往後幾十年維持的樣貌：boot/ 放開機磁區與進入保護模式的程式碼，還有 kernel/、mm/、fs/、lib/、include/、init/main.c，以及 tools/ 裡一個組出最終映像檔的工具程式。

這種組織方式從第一天起就顯示出單體式的設計。kernel/ 目錄有 3,511 行，裡面有排程器、fork、訊號處理，還有驅動程式：給 AT 硬碟的 hd.c，以及 console.c、serial.c、keyboard.s 與 tty_io.c [5]。沒有驅動程式任務，也沒有訊息。檔案系統呼叫磁碟驅動程式，就像呼叫任何一個函式。整個記憶體管理只有 298 行，分在 mm/memory.c 與 mm/page.s；檔案系統則是 2,771 行 [5]。

系統呼叫表位於 include/linux/sys.h，有 67 個項目，從 sys_setup 到 sys_setsid：1 號是 exit，接著是 fork、read、write、open 與 close [5]。並不是每一個都能用。在 kernel/sys.c 中，有 15 個只會回傳 -ENOSYS，其中包括 sys_mount、sys_umount、sys_rename、sys_mknod 與 sys_ptrace [5]。Linux 0.01 既不能掛載檔案系統，也不能重新命名檔案。

程式碼也透露出它是為誰寫的。include/linux/config.h 有兩組磁碟設定，LINUS_HD 與 LASU_HD，記錄各自機器上磁碟的幾何參數，還有一行註解「Amount of ram memory (in bytes, 640k-1M not discounted). Currently 8Mb」[5]。根裝置直接寫死在程式碼裡。情境切換位於 include/linux/sched.h，是 switch_to 這個巨集，它用一個 ljmp 跳到 386 的任務狀態區段：就是公告裡說的「386 task switching」，一字不差 [5]。64 個任務的上限也在那裡（NR_TASKS 64），時鐘頻率是 100 Hz。

還有 MINIX 的指紋，全都屬於環境或格式。Makefile 會執行 chmem +65000 tools/build [5]；chmem 是 Tanenbaum 寫的 MINIX 工具程式，用來調整為一個執行檔保留的記憶體 [25]。同一個 Makefile 還提醒：「If you don't have '-mstring-insns' in your gcc (and nobody but me has :-)」[5]。在 include/linux/fs.h 中，裝置編號「same as minix, so we can use the minix file system」，檔名最多 14 個字元，超級區塊的魔術數字是 0x137F [5]，和 MINIX 檔案系統中定義的 SUPER_MAGIC 相同 [25]。這些痕跡沒有一個是抄來的程式碼。至於這個版本的狀態，Torvalds 本人在 1992 年 7 月寫道，0.01 的程式碼「weren't actually runnable」，而且這個版本「didn't actually come with any binaries」：那是給表達過興趣的人的一個表示 [10]。

可以用的版本是 0.02。1991 年 10 月 5 日，Torvalds 在 comp.os.minix 上以「Free minix-like kernel sources for 386-AT」為標題發布公告：「Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?」。貼文說明「Full kernel source is provided, as no minix code has been used」，也說「These sources still need minix-386 to be compiled」[10]。關於 Hurd 的那句話，後來成了笑話：「Hurd will be out in a year (or two, or next month, who knows)」。

借來的檔案系統

最具體的遺產是磁碟格式。Rémy Card、Theodore Ts'o 與 Stephen Tweedie 談 ext2 的文章寫道：「In its very early days, Linux was cross-developed under the Minix operating system. It was easier to share disks between the two systems than to design a new filesystem, so Linus Torvalds decided to implement support for the Minix filesystem in Linux」[27]。作者們稱讚 MINIX 檔案系統「efficient and relatively bug-free」，但也指出兩個限制：16 位元的區塊位址把磁碟區限制在 64 MB，檔名最多 14 個字元。

出路經過了 Linux 0.01 所沒有的一層。為了讓新的檔案系統更容易加入，核心多了一個虛擬檔案系統（VFS），「initially written by Chris Provenzano, and later rewritten by Linus Torvalds」[27]。在它之上，Extended File System 於 1992 年 4 月進入 Linux 0.96c，把上限提高到 2 GB 與 255 個字元。它仍有問題：沒有把三種時間戳記分開，而且用鏈結串列管理空閒的區塊與 inode，這些串列隨著使用變得無序，讓磁碟碎片化。1993 年 1 月，兩個後繼者以 alpha 版推出：「heavily based on the Minix filesystem kernel code」的 Xia，以及從 ext 衍生、為成長而設計的 ext2 [27]。Xia 生來比較穩定；ext2 勝出，則是因為它被修正、被擴充。

實作相容的磁碟格式，和抄襲讀取它的程式碼是兩回事。這對 MINIX 成立，對今天 Linux 支援 NTFS 或 FAT 也一樣成立。

改過兩次的授權

Linux 的第一份授權並不是 GPL。0.01 的說明寫著：「This kernel is (C) 1991 Linus Torvalds, but all or part of it may be redistributed provided you do the following: Full source must be available (and free)」[26]。原始版本也禁止為散布收費。在 0.12 的說明中，Torvalds 宣布了改變：「I've had a couple of requests to make it compatible with the GNU copyleft, removing the 'you may not distribute it for money' condition. I agree」[28]。GPL 自 1992 年 2 月 1 日起生效。

1992 年 1 月：「LINUX is obsolete」

Tanenbaum 的貼文發表於 1992 年 1 月 29 日 [1]。他一開頭先介紹自己：MINIX 對他而言是消遣（「something that I do in the evening when I get bored writing books」），真正的工作是研究作業系統。接著，他列出 Linux 的兩個問題。

Tanenbaum 寫了什麼

第一個是架構上的。Tanenbaum 把單體式系統定義為「the whole operating system is a single a.out file that runs in 'kernel mode'」的系統，並舉 UNIX、MS-DOS、VMS 與 MULTICS 為例。微核心的例子，他舉了 Amoeba、Chorus、Mach，以及「the not-yet-released Windows/NT」。他斷言：「among the people who actually design operating systems, the debate is essentially over. Microkernels have won.」關於 Linux：「LINUX is a monolithic style system. This is a giant step back into the 1970s. That is like taking an existing, working C program and rewriting it in BASIC. To me, writing a monolithic system in 1991 is a truly poor idea」[1]。

第二個是可移植性。Tanenbaum 預言 RISC 晶片會「gradually take over from the 80x86 line」，並寫道：「I think it is a gross error to design an OS for any specific architecture, since that is not going to be around all that long.」他的結論是：「LINUX is tied fairly closely to the 80x86. Not the way to go」[1]。

說 Tanenbaum 稱 Linux 是倒退的人說得沒錯，因為那句話確實存在。只是，在同一封訊息中，他也寫了「Don't get me wrong, I am not unhappy with LINUX」[1]。那是在一個技術討論群組裡、針對架構的批評，出現在 8 月那則公告的大約五個月之後。

Torvalds 怎麼回應

Torvalds 在同一天回應，而且毫不客氣。他把 Tanenbaum 歸因於自己教學工作的那些限制稱為「brain-damages of minix」，並寫道「I can only hope (and assume) that Amoeba doesn't suck like minix does」[1]。不過在實質問題上，他讓出了最主要的一點：「True, linux is monolithic, and I agree that microkernels are nicer. [...] From a theoretical (and aesthetical) standpoint linux looses.」

他的論點是另一回事：「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」[1]。關於可移植性，他主張 Linux 在對使用者有意義的層次，也就是 API 層次，比 MINIX 更可移植：「I made linux as conformant to standards as I knew how (without having any POSIX standard in front of me)」。他也承認了其餘部分：「I also agree that linux takes the non-portability to an extreme」[1]。

Tanenbaum 在 30 日回來，留下了整場討論中最常被引用的一句話：「I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful you are not my student. You would not get a high grade for such a design :-)」[4]。在同一封訊息中，他做了一個後來最站不住腳的預言：「5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5」。

道歉

同樣在 1 月 30 日，Torvalds 以「Apologies (was Re: LINUX is obsolete)」為標題發了一則訊息：「And reply I did, with complete abandon, and no thought for good taste and netiquette. Apologies to ast [...] I over-reacted, and am now composing a (much less acerbic) personal letter to ast.」他維持自己的技術立場（「I still think that's not the case, although some of the criticisms are valid」），署名「Linus 'my first, and hopefully last flamefest' Torvalds」[4]。

把 Torvalds 描繪成傲慢、無法自我批評的人，這種形象讀完整個討論串就站不住了。他確實很粗魯。但就在同一天，他道了歉，並承認部分批評是有道理的。

1 月 31 日的技術答辯

Torvalds 的下一則訊息不再有侮辱，是他在 1992 年做出的最佳技術辯護，卻幾乎沒有人引用。關於多執行緒檔案系統，他回答說，這東西只有「on a microkernel」才算是效能上的取巧：「When writing a unix the 'obsolete' way, you automatically get a multithreaded kernel: every process does it's own job, and you don't have to make ugly things like message queues to make it work efficiently」[4]。這就是共享狀態的論點，比他把它完整寫出來早了十四年。

關於可移植性，他把介面和實作分開：「Yes, the /implementation/ is hardware-specific, but there's a HUGE difference [...] linux API is portable (not due to my clever design, but due to the fact that I decided to go for a fairly-well-thought-out and tested OS: unix.)」[4]。他還算了大小：Linux 的完整原始碼壓縮後約 200 kB，而光是 Mach 依賴 386 的部分 i386.tar.Z 就超過 800 kB [4]。他也把指控丟回給 MINIX：如果這個系統之所以可移植，是因為它能在不是為 Unix 打造的機器上執行，那麼「minix is portable, but you can rewrite that as 'doesn't use any features', and still be right」[4]。

討論串的其他部分

O'Reilly 的附錄收錄了 36 則訊息，其中大多數不是兩位主角寫的 [4]。它們顯示，1992 年的社群對這場論戰的理解，比今天很多人都好。

麻省理工學院的 Theodore Ts'o，也就是後來 ext2 的共同作者，在 1 月 31 日回覆了 Tanenbaum。他說 Linux 中 80386 專屬程式碼的數量「is probably not much more than what is in a Minix implementation」，而且遠少於 BSD 4.3 中 VAX 專屬的程式碼。他用一句話總結了許多人的選擇：「the fact remains that Linux is here, and GNU isn't [...] Minix doesn't count because it's not free. :-)」[4]。對於學術界的共識，他也有一個解釋：「since only researchers write papers about operating systems, ipso facto micro kernels must be the right approach」[4]。

Rutgers 的 Charles Hedrick 說得更乾脆：「The history of software shows that availability wins out over technical quality every time. That's Linux' major advantage」[4]。Bell-Northern Research 的 Douglas Graham 問，有什麼公正的文獻能支持「Microkernels have won」，他估計 Linux 有「about 12000 lines of code」，並寫道：「I don't see how splitting that into tasks and blasting messages around would improve it」[4]。對他來說，MINIX 的問題不在效能：「adding features is a royal pain」。

也有人提出折衷方案。Worcester Polytechnic Institute 的 Lawrence Foard 說，他正在為 Linux 寫 IPC 程式碼，讓驅動程式與檔案系統能以使用者行程執行，但他也提醒這樣會「significantly slower」，而且「it would be a mistake to move everything outside the kernel」[4]。他還指責理論家從不測試自己的想法。Tanenbaum 用全大寫回應：「I AM NOT A THEORIST」，並列出他眼中的證據：OSF 把事業押在 Mach 3.0 上，USL 押在 Chorus 上，Amoeba 已經實作完成，而據他所知，QNX 有 200,000 套安裝中的系統。「Microkernels are not a pipe dream. They represent proven technology」[4]。

Tanenbaum 這一邊也有支持者。自稱旁觀者的 David Miller 為兩位作者鼓掌，但也問道：「Why split fundemental os functions, such as memory management, into user processes?」[4]。Michael Haardt 把他的訊息標題定為「why I think AST is right」。Sun 的 Randy Burns 則下了一個當時看似合理的賭注：「It may well be that in 2-3 years when ultra cheap BSD variants and Hurd proliferate, that Linux will be obsolete」[4]。

授權與控制權：沒人記得的部分

2 月 3 日，Tanenbaum 開了另一個討論串「Unhappy campers」，因為他收到了一些惱火的電子郵件（「10 messages from the 43,000 readers」）。他為 MINIX 的價格辯護，拿售價 99 美元的 Coherent 與 800 美元的 4.4BSD 來比較，並寫道自由軟體的問題「100% emotional」[4]。接著他問，Torvalds 會不會讓 Linux 脫離他的掌控，其他人能不能修改它、販售它。

Torvalds 在 2 月 6 日的回答，兩個詞就說完了：「I won't.」他說，他已經在探詢成立一個「linux-kernel」郵件論壇、由它來決定版本，因為他沒有足夠的硬體去支援所有東西，並以 SCSI 為例；他也說 Ts'o 已經做了「some heavy changes even to 0.10」[4]。Tanenbaum 在 2 月 5 日做了相反的預言：協調散布在世界各地的一千名程式設計師，會「as easy as herding cats」，而且「Anyone who says you can have a lot of widely dispersed people hack away on a complicated piece of code and avoid total anarchy has never managed a software project」[4]。從那時起，核心的歷史就是對這句話的一場漫長反駁。

討論串裡的「Ken Thompson」是誰

O'Reilly 出版的 Open Sources 一書收錄了這場論戰，書中的附錄說，討論中出現了「user-hacker Ken Thompson (one of the founders of Unix)」[4]。但同一份附錄裡的訊息標頭說的是另一回事：「From: kt4@prism.gatech.EDU (Ken Thompson)」、「Organization: Georgia Institute of Technology」，日期是 1992 年 2 月 3 日。內容簡短而合理：「I would generally agree that microkernels are probably the wave of the future. However, it is in my opinion easier to implement a monolithic kernel. It is also easier for it to turn into a mess in a hurry as it is modified」[4]。標頭中沒有任何東西把作者和 Unix 的創造者連在一起。休士頓大學的 Kevin Brown 的回覆，像是在對 Unix 的創造者說話（「I figure you've got years of experience with monolithic kernels :-)」），這表示混淆（或玩笑）是從群組本身開始的 [4]。種種跡象都指向一位在 Georgia Tech 有帳號的同名者，而 O'Reilly 的認定，在它自己出版的文件中站不住腳。

Linux 為什麼勝出

神秘化的觀點說，Linux 勝出是因為它比較好。主角們講的是一個更平凡的故事，而且兩人講的是同一個。

Torvalds 在 1992 年 1 月說：如果 GNU 的核心在前一年春天就準備好，他根本不會開始；「Linux wins heavily on points of being available now」[1]。GNU 在 1991 年選定了建立在 Mach 之上的 Hurd 作為官方核心，但第一個測試版 Hurd 0.1 直到 1996 年 9 月 6 日才推出，GNU 0.2 則在 1997 年 6 月 [29]。那時 Linux 1.0 已經推出兩年多了：它在 1994 年 3 月 13 日發布 [24]。

柏克萊的 BSD 是理所當然的候選者，技術上也已經就緒。它被困在法庭裡，而訴訟的細節說明了為什麼這段延宕影響如此之大。

柏克萊、386BSD 與那六個檔案

曾在柏克萊電腦系統研究小組（CSRG）工作的 Kirk McKusick，在同一本 O'Reilly 的書裡講述了這段歷史 [30]。1989 年 6 月，柏克萊推出 Networking Release 1，也就是不依賴 AT&T 授權的網路程式碼與工具程式：「the first freely-redistributable code from Berkeley」。接著，Keith Bostic 提議更進一步。Bostic、Mike Karels 與 McKusick 花了好幾個月，逐一檢查散布版的每個檔案，移除來自 AT&T 32/V 的部分。剩下「only six remaining kernel files that were still contaminated and which could not be trivially rewritten」。柏克萊決定照樣發布其餘部分，命名為 Networking Release 2，於 1991 年 6 月推出，收費 1,000 美元 [30]。

不到六個月，Bill Jolitz 就為那六個檔案寫出替代品，並透過匿名 FTP 發布了一套完整、可開機的 386 PC 系統 386/BSD：「Within weeks he had a huge following」[30]。共同作者 Lynne Jolitz 說，386BSD 0.0 在 1992 年 3 月推出，在此之前，他們花了兩年在 Dr. Dobb's Journal 雜誌上記錄移植過程；386BSD 0.1 則在 1992 年 7 月 14 日推出 [31]。據 McKusick 說，Jolitz 因為有全職工作，跟不上大量湧入的修正，於是一群使用者成立了 NetBSD 來維護這個系統 [30]。NetBSD 的第一個版本 0.8 發布於 1993 年 4 月 20 日 [32]。FreeBSD 在 1993 年初由「Unofficial 386BSD Patchkit」的最後三位協調者發起，FreeBSD 1.0 在 1993 年 12 月推出，仍以 Net/2 為基礎 [33]。

訴訟，一步一步來

與此同時，一家公司 Berkeley Software Design, Inc.（BSDi）把 Jolitz 的六個檔案加進 Net/2，從 1992 年 1 月開始販售附原始碼與二進位檔的系統，售價 995 美元，廣告要人撥打 1-800-ITS-Unix [30]。AT&T 擁有多數股權的子公司 Unix System Laboratories（USL）寄了一封信，要求該公司不得再把產品稱為 Unix，並停用那支電話。BSDi 換了號碼，也改了廣告。USL 還是提告了，主張其中有專有程式碼與營業秘密，並聲請禁制令要求暫停銷售 [30]。

在初步聽證中，法官接受了 BSDi 的論點：它散布的只是加州大學散布的東西，再加上六個檔案；法官要求 USL 只針對這六個檔案重新提出訴狀，否則案件將被駁回。USL 重新對 BSDi 與加州大學提告，並要求一併暫停 Net/2 的散布 [30]。1992 年 12 月，紐澤西州的聯邦法官 Dickinson R. Debevoise 聽取了雙方的辯論。大約六週後，他發布一份四十頁的裁決，駁回禁制令，並撤銷了除兩項之外的所有訴由，建議這個案子先交由州法院審理。加州大學在下一個星期一就在加州提起訴訟，指控 USL 沒有為 System V 中收錄的 BSD 程式碼給予應有的署名 [30]。

不久之後，Novell 從 AT&T 手中買下了 USL。據 McKusick 說，Novell 總裁 Ray Noorda 公開表示，他寧願在市場上競爭，也不願在法庭上競爭。談判從 1993 年夏天開始，到 1994 年 1 月結束：Net/2 的 18,000 個檔案中移除了三個，另有一些做了小幅修改，約 70 個檔案改為標示 USL 的著作權，但仍可自由再散布 [30]。4.4BSD-Lite 在 1994 年 6 月推出，和解協議保證 USL 不會控告以它為基礎的人。FreeBSD 必須在 1994 年 7 月底前停止散布以 Net/2 為基礎的產品，它花到 11 月才在 4.4BSD-Lite 上重建系統，並在 12 月推出 FreeBSD 2.0 [33]。

把日期加起來看。從 BSDi 在 1992 年 1 月商業發布，到 1994 年 12 月的 FreeBSD 2.0，想要一套 PC 上自由 BSD 的人，經歷了將近三年的法律不確定性。這正是 Linux 從 0.12 版走到 1.0 版、並把自訂授權換成 GPL 的那段時間 [28], [24]。Hedrick 早在 1992 年 2 月就預見了這個問題：他理想中的系統是 4.4BSD，但「4.4's release date has a history of extreme slippage」[4]。

雙方事後怎麼說

論戰雙方對這個影響的看法一致。Torvalds 在 1993 年 11 月告訴 Meta 雜誌：「If 386BSD had been available when I started on Linux, Linux would probably never had happened」[11]。Tanenbaum 在 2004 年說：「This delay in getting free BSD out there gave Linux the breathing space it needed to catch on. If it hadn't been for the lawsuit, undoubtedly BSD would have filled the niche for a powerful, free UNIX clone as it was already a stable, mature system with a large following」[6]。

再加上授權。Linux 從 1992 年 2 月起就是 GPL [28]，而 MINIX 直到 2000 年才改用 BSD 授權 [23]。1992 年，想要一套在 386 PC 上執行的自由 Unix 的人，手邊有一個可用的系統，它接受貢獻，也讓任何人都能再散布。那個系統就是 Linux。Torvalds 的功勞很大，不需要誇大：別人還沒準備好的時候，他已經準備好了，而且他懂得接納新來者的程式碼。

2004 年：指控 Linus 抄襲的報告

抄襲的迷思在 2004 年 5 月有了「官方」版本。華盛頓 Alexis de Tocqueville Institution（AdTI）的總裁 Kenneth Brown 發表了 Samizdat，這份文件的日期是 2004 年 5 月 20 日，質疑 Linux 程式碼的來源以及歸給 Torvalds 的功勞 [34]。

Tanenbaum 在同一天，也就是 5 月 20 日，以一個名為「Some Notes on the 'Who wrote Linux' Kerfuffle」的網頁回應。他說，Brown 在 2004 年 3 月 23 日飛到阿姆斯特丹訪問他，被問到資金來源時避而不答。逐字稿很乾脆：「AST: Is Microsoft one of them? KB: We have multiple funding sources」[6]。兩年後，Tanenbaum 直截了當地寫道：「Microsoft paid a guy named Ken Brown to write a book saying Linus stole Linux from my MINIX 1 system」[35]。這是 Tanenbaum 的說法。在 2004 年的訪談中，Brown 只是重複說他有「multiple funding sources」[6]。

2004 年那份回應的核心，比任何 Linux 擁護者都更能拆解這個迷思：

Thus, of course, Linus didn't sit down in a vacuum and suddenly type in the Linux source code. He had my book, was running MINIX, and undoubtedly knew the history (since it is in my book). But the code was his. The proof of this is that he messed the design up. [6]

Tanenbaum 接著說：Linus 沒有在微核心之上寫一個新的檔案系統和新的記憶體管理器，而是「Linus rewrote the whole thing as a big monolithic kernel, complete with inline assembly code :-(」。他的結論是：「producing a system that was fundamentally different from the base he started with seems pretty good proof that it was a redesign」[6]。

抄襲的指控也用程式碼檢驗過。受雇為 Brown 本人擔任顧問的 Alexey Toptygin，比較了 Linux 0.01、0.11、0.12 及之後的版本與 MINIX。他在 2004 年 5 月 17 日把結果交給 Brown：「my analysis found no evidence whatsoever that any code was copied one way or the other」[36]。技術報告只找到「Only 4 actual similarities」，而且每一處都是「the similarity was required by external factors (the C standard, the POSIX standard, the minix filesystem format)」[37]。據 Toptygin 說，Brown 在接下來的談話中一直試圖說服他是他弄錯了，因為「it was clearly impossible for one person to write an OS」[36]。

Torvalds 以反諷回應這份報告。他寄給 LinuxWorld 的電子郵件是這樣開頭的：「Ok, I admit it. I was just a front-man for the real fathers of Linux, the Tooth Fairy and Santa Claus」[38]。玩笑繼續下去：聖誕老人因為是芬蘭人，所以在赫爾辛基大學有人脈。

Tanenbaum 有一個保留意見，Linux 的粉絲通常會跳過。他認為 Torvalds 對前人的功勞歸屬給得太少：「In science it is considered important to credit people for their ideas, and I think Linus has done this far less than he should have. Ken and Dennis are the real heros here. But Linus' sloppiness about attribution is no reason to assert that Linus didn't write Linux」[6]。他也講清楚了自己不同意的地方在哪裡：「My only regret is that he didn't develop Linux based on the microkernel technology of MINIX」[6]。

ACM 在把 2023 年的 Software System Award 頒給 Tanenbaum 時，以持平的方式總結了 MINIX 的遺產：這個獎項是「For MINIX, which influenced the teaching of Operating Systems principles to multiple generations of students and contributed to the design of widely used operating systems, including Linux」[39]。MINIX 影響了 Linux 的設計，但沒有給它程式碼。

師生關係？

這個迷思的另一個版本說，Tanenbaum 是 Torvalds 的老師，而學生背叛了師父。1991 年的貼文來自赫爾辛基大學的帳號 [10]；Tanenbaum 則在阿姆斯特丹的自由大學任教 [1]。他在 2004 年寫道：「Linus and I are not 'enemies' or anything like that. I met him once and he seemed like a nice friendly, smart guy」[6]。2006 年，他又說了一次：「I met him once. He is a pleasant fellow and very smart. We may disagree on some technical issues, but that doesn't make us enemies」[35]。1992 年那句「Be thankful you are not my student」是修辭，正因為 Torvalds 不是他的學生。討論串本身就兩度把這一點說清楚。Torvalds 回答說，他反正也拿不到好成績，因為他和赫爾辛基「the person here at the university that teaches OS design」吵過架。而 Tanenbaum 在 2 月 3 日的「Unhappy campers」中談到可移植性時寫道：「Surely Linus' OS professor pointed this out」[4]。會談起別人的教授的人，不會是那個人的教授。

「Linux 根本不是 UNIX」

這個迷思說對的比說錯的多。UNIX 是 The Open Group 的註冊商標，只有通過規格測試套件、並簽署商標授權合約的產品才能使用。例如，macOS 26 Tahoe 自 2025 年 8 月 29 日起登錄為 UNIX 03，適用於搭載 Apple Silicon 與 Intel 處理器的 Mac [7]。常見的 Linux 發行版不在這份登錄上，所以稱它們為 UNIX，在技術上是錯的。Linux 也不是 BSD：它不是從柏克萊的程式碼衍生而來，而是從零寫起的 [26]。

有兩個細節拆穿了這個論點的誇大版本。第一，認證的對象是完整的產品，不是核心。The Open Group 的登錄寫的是「macOS version 26.0 Tahoe」，不是「XNU」[7]。說某個核心「通過 UNIX 認證」，是把事情混為一談，不論是 XNU 還是 Linux。

第二，已經有一套以 Linux 為基礎的系統通過了認證。在 KunLun 伺服器上執行的 Huawei EulerOS 2.0，出現在 UNIX 03 的登錄中，登錄日期為 2016 年 9 月 8 日，預定於 2022 年 9 月 8 日續約 [12]。它通過的測試套件和 macOS 一樣。因此，「Linux 不遵守 POSIX」這個說法，作為技術上的通則是站不住的。我找不到官方文件解釋為什麼常見的發行版不去認證。我的解讀是，對已經在賣 Linux 支援服務的公司來說，這個商標不值得付出成本，但這只是我的看法。早在 1992 年，Torvalds 就說他把 Linux 做得「as conformant to standards as I knew how」，當時他手邊甚至還沒有 POSIX 標準 [1]。

誠實的總結是：在紙面上，Linux 不是 UNIX，因為它沒有這個商標。實際上，一套通過認證的 Linux 已經證明，這不是因為技術能力不足。

「Linux 的 ABI 老是壞掉」

這個迷思把兩種不同的介面混在一起，而核心文件在第一頁就把兩者分開。Greg Kroah-Hartman 寫了那篇解釋 Linux 為什麼沒有穩定驅動程式介面的文章，開頭就是一個提醒：「Please realize that this article describes the in kernel interfaces, not the kernel to userspace interfaces」[13]。

對於應用程式使用的介面，這篇文章說得毫無模糊空間：「The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is very stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still work just fine on the latest 2.6 kernel release」[13]。說系統呼叫每個版本都會改變的人，是錯的。

內部介面，也就是驅動程式使用的介面，則是刻意會變的。同一份文件提到 USB 堆疊至少經歷了三次改造，並解釋說，當開發者找到更好的做法時，「function names may change, structures may grow or shrink, and function parameters may be reworked」，而主樹內的所有使用者會一次全部修正 [13]。給那些驅動程式在主樹外的人的建議，是把它放進來。至於因為驅動程式是封閉的而辦不到的人：「good luck, you are on your own here, you leech」[13]。

在這一點上，Linux 受到的批評是公平的。這個選擇對購買硬體、而製造商把驅動程式放在主樹外的人，是有實際代價的：內部介面一改，那個驅動程式就得跟著調整，而文件自己也承認，跟上變化「is also a rough job」[13]。專案的論點是，代價由不把程式碼送進主線的人承擔，這是說得通的。但只想讓網路卡能用的使用者，照樣得付帳。說這個問題不存在，就和說系統呼叫會壞掉一樣錯。

當核心移除程式碼時

另一個近來的迷思說，ReiserFS 被移出核心是出於政治動機。紀錄顯示的是另一回事。2022 年 2 月，SUSE 的 Jan Kara 提議將它棄用，理由是：「Reiserfs is relatively old filesystem and its development has ceased quite some years ago. Linux distributions moved away from it towards other filesystems such as btrfs, xfs, or ext4. To reduce maintenance burden on cross filesystem changes [...] let's add a deprecation notice when the filesystem is mounted and schedule its removal to 2025」[40]。移除在 Linux 6.13 中完成，刪掉了大約 32,800 行 [41]。這和介面不穩定是同一個邏輯：主樹裡沒有維護者的程式碼，會成為修改共用介面者的負擔。

微核心對上單體式，用數字說話

撇開辱罵，1992 年的論戰有一個正當的技術問題：把不需要待在核心模式的東西移出去，值不值得？三十年的研究，為雙方都提供了數據。

Tanenbaum 的論點：錯誤住在驅動程式裡

2001 年，史丹佛大學的 Andy Chou、Dawson Engler 與同事，把自動化靜態檢查工具用在 Linux 與 OpenBSD 的程式碼上。對 Linux 2.4.1 的結論是「the vast majority of bugs are in drivers」，而驅動程式碼的錯誤率是核心其餘部分的三到七倍。在鎖的檢查器中，「the error rate for drivers is almost seven times higher than the error rate for the rest of the kernel」[42]。

Windows 也有同樣的問題，只是用另一種方式量測。2003 年，華盛頓大學的 Michael Swift、Brian Bershad 與 Henry Levy 在 Nooks 論文的開頭，引用了 Microsoft 的一個數字：「In Windows XP, for example, drivers account for 85% of recently reported failures」[43]。Nooks 把 Linux 的驅動程式隔離在核心位址空間內的輕量保護域中，並在發生故障時重新啟動它們。在 2,000 次故障注入測試中，「Nooks recovered automatically from 99% of the faults that caused Linux to crash」[43]。這套系統大約有 22,000 行，而當時的核心有 240 萬行。驅動程式仍在 ring 0 執行，與核心其餘部分的權限等級相同，保護來自分頁表 [43]。

Tanenbaum 在 2006 年與 Jorrit Herder、Herbert Bos 合寫、發表於 IEEE Computer 的文章中，用了這些數據。推理是算術：如果每一千行程式碼有 6 到 16 個錯誤，「Using a conservative estimate of 6 bugs per 1000 lines of code the Linux kernel probably has something like 15,000 bugs; Windows has at least double that」[44]。在單體式核心中，有缺陷的驅動程式與其他一切在同一個位址空間裡執行。Microsoft 的文件描述 Windows 的這個問題，清楚到我希望能更常看到：「All code that runs in kernel mode shares a single virtual address space. As a result, a kernel-mode driver isn't isolated from other drivers or the operating system. [...] If a kernel-mode driver crashes, it causes the entire operating system to crash」[8]。

在這裡，Linux 值得一個對它有利、卻很少被批評者引用的數據。2011 年，Nicolas Palix、Julia Lawall 與同事在 2.6.0 到 2.6.33 版上重做了 Chou 的研究。在這段期間，核心的規模增加了一倍多，但每行的故障數下降了。drivers 目錄仍然集中了絕對數量最多的故障，而且連同 drivers/staging，自 2.6.30 起佔了程式碼的 57%。然而，它的故障率「is now below that of other directories, such as arch (HAL) and fs (file systems)」，並且自 2.6.19 起「right at the average」[45]。同儕審查改善了驅動程式。沒有改變的，是殘留錯誤的後果：在 Linux 中，它以完整的權限執行。

在這一點上，Linux 受到的批評是公平的，而且彈藥是 Torvalds 自己提供的。2009 年 9 月，他在 LinuxCon 上說：「We're getting bloated and huge. Yes, it's a problem」。他還補充：「sometimes it's a bit sad that we are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary」[46]。把 Linux 核心當成優雅典範的人，捍衛的是連作者本人都不捍衛的東西。

MINIX 3：驅動程式移出核心，再加一個讓它們復活的伺服器

MINIX 3 是 Tanenbaum 對這些數字的回答，而且比 MINIX 2 走得更遠。在 IEEE Computer 的那篇文章中，架構是分層描述的。微核心處理中斷、行程、排程與 IPC，並為經授權的驅動程式和伺服器提供一小組核心呼叫，例如讀取使用者的位址空間，或寫入允許的 I/O 埠。「The clock driver shares the microkernel's address space, but is scheduled as a separate process. No other drivers run in kernel mode」[44]。磁碟、終端機、網路、印表機或音訊的每一個驅動程式，都在自己的使用者模式行程中執行，受 MMU 保護，要碰硬體必須請核心代勞。檔案伺服器有 4,500 行可執行程式碼，核心則是 4,000 行：用同樣每千行 6 個錯誤的估計，「the total number of bugs in the kernel is probably only about 24 (vs. 15,000 for Linux and far more for Windows)」[44]。

訊息傳遞延續了 MINIX 2 的構想，並多了一項補充。IPC「is done by passing fixed-length messages using the rendezvous principle」，由傳送者直接複製給接收者，再加上一個非同步通知機制：無法遞送的事件，會在行程表中的一個位元圖上標記為待處理。中斷會變成通知，等驅動程式準備好接收時，核心再把它們轉換成一般訊息 [44]。由於核心中沒有訊息佇列或緩衝區，就不可能用訊息耗盡核心記憶體。權限也變得更細：系統針對每個行程限制 IPC 原語、允許的目的地以及通知的使用，而使用者行程只能和 POSIX 伺服器溝通 [44]。

新的元件是轉世伺服器（reincarnation server）。Herder、Bos、Gras、Homburg 與 Tanenbaum 在 DSN 2007 發表的論文描述了它的運作方式 [47]。驅動程式由 service 工具程式啟動，參數包括二進位檔、一個固定的名稱、確切的權限清單、一個 heartbeat 週期，以及可選的復原策略腳本。轉世伺服器是所有系統行程的父行程，任何一個行程結束、恐慌（panic），或因 CPU 或 MMU 例外而死亡時，它會立刻知道。它也會定期要求 heartbeats，在漏掉 N 次回應之後啟動復原，藉此抓出陷入無窮迴圈的行程。檔案伺服器可以要求替換違反協定的磁碟驅動程式，使用者也可以在系統運作中要求重新啟動某個驅動程式，或把它換成修正過的版本 [47]。一個資料伺服器（data store）會公布重新啟動後驅動程式的新 IPC 位址，並通知依賴它的行程。讀取到一半就死掉的磁碟驅動程式會被重新啟動，而檔案伺服器會重新發出待處理的操作，因為區塊 I/O 是冪等的。

論文中的數字很具體。在一項網路測試中，用 wget 下載一個 512 MB 的檔案，同時每隔 1 到 15 秒殺掉 RealTek 8139 驅動程式一次，所有傳輸都以正確的 checksum 完成，吞吐量損失介於 25% 到 1% 之間 [47]。在 SATA 磁碟上，讀取 1 GB 並以類似間隔殺掉驅動程式，損失在 62% 到 7% 之間，同樣沒有損壞資料。在 Bochs 模擬器上對 DP8390 乙太網路驅動程式做故障注入，總共注入了超過 12,500 次故障，出現 347 次可偵測的當機，而「The subsequent recovery was successful in 100% of the induced failures」；在實體硬體上，成功率超過 99% [47]。改寫一個一般驅動程式的成本，是共用驅動程式函式庫中剛好五行程式碼。

作者們自己列出了限制，而這正是這項工作誠實之處。這個設計處理不了拜占庭故障，例如磁碟驅動程式回報已經寫入、實際上寫的卻是垃圾；它偵測不到無聲的資料損毀；治不了重新啟動後又會出現的確定性錯誤；也解決不了壞掉的硬體 [47]。專案的 FAQ 量化了隔離的代價：「MINIX 3 is 5-10% slower」，比較對象是驅動程式在核心模式中執行的 MINIX 2，而「our priority has been reliability, not performance」[48]。2008 年，歐洲研究委員會（European Research Council）給了 Tanenbaum 一筆 250 萬歐元的研究經費，用來打造可靠的系統；MINIX 3.3.0 以 BSD 授權推出，支援 x86 與 ARM Cortex-A8，使用者空間與 NetBSD 相容 [49]。

Torvalds 的論點：共享狀態

Torvalds 在 2006 年 5 月於 Real World Technologies 論壇回應了這場辯論，而他的論點不是效能，是複雜度：

The fundamental result of access space separation is that you can't share data structures. That means that you can't share locking, it means that you must copy any shared data, and that in turn means that you have a much harder time handling coherency. All your algorithms basically end up being distributed algorithms. [50]

在他看來，把位址空間分開，是把記憶體錯誤換成行程之間的協調錯誤，而後者更難理解。在同一則訊息中，他正面攻擊了轉世伺服器的構想：「the argument that you can 'just reload' a failed service and not take the whole system down is equally flawed. Anybody who has ever done distributed programming should know by now that when one node goes down, often the rest comes down too」[50]。他也把時髦的術語打發掉：「As to the whole 'hybrid kernel' thing - it's just marketing」[50]。

這個論點很嚴肅，而 MINIX 3 的數據只回答了其中一部分。對於網路與磁碟驅動程式的暫時性故障，也就是協定容許重試的情況，重新啟動在幾乎所有量測案例中都有效 [47]。對於真正的共享狀態，例如在記憶體中保有中繼資料的檔案系統，MINIX 3 的作者們自己也承認，光重新啟動不夠，還需要加上端到端的 checksum [47]。Torvalds 把重新啟動的論點稱為有缺陷，是言過其實。Tanenbaum 把隔離當成通用解法來推銷，也是言過其實。

效能：問題在 Mach，不在構想

1992 年，Tanenbaum 引用 Rick Rashid 比較 Mach 3.0 與單體式系統的論文，作為效能已不再是問題的證據 [1]。這個斷言言之過早。在 L4 上耕耘了數十年的 Gernot Heiser 與 Kevin Elphinstone，這樣總結 1990 年代初期：「The typical cost for a one-way message was around 100 µs, which was too high for building performant systems」，而業界的回應是「a trend to move core services back into the kernel」[51]。

Jochen Liedtke 在 1993 年證明，代價來自實作。在發表於 SOSP 的論文「Improving IPC by Kernel Design」中，他圍繞著單一目標，也就是 IPC 的速度，從頭重建了 L3 微核心中處理行程與通訊的部分。在一台 486-DX50 上，他算出一則短訊息的理論最小值是 172 個週期，也就是 3.5 µs；他把目標定在 350 個週期，最後做到 250 個週期，5 µs [14]。相較於 Mach，提升幅度是「from a factor of 22 (8-byte messages) to 3 (4-Kbyte messages)」。論文甚至量測了進出核心的成本：在 Mach 上，mach_thread_self 呼叫要花 18 µs，而在那顆處理器上，進出核心一趟的最低成本是 2 µs [14]。

兩年後，在「On µ-Kernel Construction」中，Liedtke 提出了引導 L4 家族的準則：一個概念只有在「only if moving it outside the kernel, i.e. permitting competing implementations, would prevent the implementation of the system's required functionality」的情況下，才被容許留在微核心內 [52]。他還寫了一句話，應該會讓拿 1992 年論戰當武器的人不太舒服：「µ-kernels are inherently not portable. Instead, they are the processor dependent basis for portable operating systems」[52]。當時最快的微核心，和 Linux 0.01 一樣綁死在處理器上。Tanenbaum 在架構上是對的，但他以為可移植性會隨之免費附送，就錯了。

L4 的系譜延續了下去。Heiser 與 Elphinstone 的表格顯示，跨位址空間傳遞一則訊息的成本，從 1993 年原始 L4 的 5 µs，降到 2013 年 seL4 的 0.09 µs，平台是 3.4 GHz 的 Core i7 Haswell，相當於 301 個週期；在 532 MHz 的 ARM11 上，seL4 需要 188 個週期 [51]。1997 年，德勒斯登的 Hermann Härtig、Michael Hohmuth、Liedtke 與同事把 Linux 移植到 L4 之上執行，並量測到：「For L4Linux, the AIM benchmarks report a maximum throughput which is only 5% lower than that of native Linux. The corresponding penalty is 5 times higher for a co-located in-kernel version of MkLinux, and 7 times higher for a user-level version of MkLinux」[15]。MkLinux 是跑在 Mach 上的。設計良好的微核心代價是 5%；Mach 的代價則高得多。

Tanenbaum 在 2004 年說，他願意接受大得多的損失：「I would easily give up 20% in performance for a system that was robust, reliable」[53]。對設計關鍵系統的人來說，這是正當的立場。對經營資料中心的人來說，這是很難推銷的立場。

別人更早、或做得更好的事

這是神秘化的 Linux 觀點最喜歡跳過的部分。稱霸超級電腦與手機 [2], [3]，並不會讓 Linux 成為所有好點子的作者；今天看起來像是「Linux 的東西」的點子，有好幾個更早就出現在其他系統裡。

macOS 與 XNU：通過 UNIX 認證，但不是微核心

macOS 擁有任何常見 Linux 發行版都沒有的東西：UNIX 03 的登錄。macOS 26 Tahoe 在 2025 年 8 月 29 日登錄，涵蓋 Apple Silicon 與 Intel [7]。每個版本都會重新登錄：macOS 15 Sequoia 是在 2024 年 9 月 12 日登錄的 [54]。把 macOS 當成玩具的人，是在輕視一個一版接一版通過 The Open Group 相容性測試套件的大眾桌面系統。Apple 也在風險最高的地方使用微核心：Secure Enclave 處理器「runs an Apple-customized version of the L4 microkernel」[55]。

另一邊的迷思說，macOS 是微核心，因為 XNU 裡面有 Mach。Apple 自己就否認了這一點，而且值得深入看看。XNU 程式碼的 README 把它描述為「a hybrid kernel combining the Mach kernel developed at Carnegie Mellon University with components from FreeBSD and a C++ API for writing drivers called IOKit」；在目錄樹中，osfmk 存放衍生自 Mach 的子系統，bsd 存放 BSD 的子系統 [56]。抽象概念來自 Mach：tasks 是資源擁有權的單位，包含一個位址空間、一個埠權利命名空間，以及一個或多個 threads；還有埠，「Secure, simplex communication channels, accessible only via send and receive capabilities (known as port rights)」[17]。在陷入核心（trap）的層次上，這些抽象大多以送往核心埠的訊息作為介面，而 Mach Interface Generator（MIG）會產生 stubs，替程式設計師隱藏這一切 [17]。

看起來像微核心，但 Apple 隨即解釋：「in OS X, Mach is linked with other kernel components into a single kernel address space. This is primarily for performance; it is much faster to make a direct call between linked components than it is to send messages or do remote procedure calls (RPC) between separate tasks」[17]。Apple 的結論是，在 OS X 中，「Mach is not primarily a communication hub between clients and servers」。架構文件提醒：「OS X uses the term kernel somewhat differently than you might expect」，以及「The OS X kernel environment includes the Mach kernel, BSD, the I/O Kit, file systems, and networking components」[16]。I/O Kit 的驅動程式是載入「into kernel space」的擴充 [16]。Tanenbaum 在 2006 年說得更重：Mac OS X「is sort of microkernelish」，但「Since all of it runs in kernel mode (to get that little extra bit of performance) it is not a true microkernel」[35]。以 1992 年的標準來看，XNU 和 Linux 站在同一邊。因為 macOS 是「Mach」而稱讚它、因為 Linux 是單體式而攻擊它的人，是在用雙重標準。

Apple 超越 Linux 的地方，在第三方驅動程式。DriverKit 的文件寫道：「The drivers you build with DriverKit run in user space, rather than as kernel extensions, which improves system stability and security」[57]。關於核心擴充的頁面說明，它們已被棄用，而且從 macOS Big Sur 開始，系統預設不再載入使用已棄用核心介面的擴充 [58]。實際上，Apple 用平台政策把周邊設備廠商推出核心模式。Linux 對一般驅動程式沒有任何等價的東西，至於它有什麼，我在後面說明。

FreeBSD：2000 年的 jail，比 Linux 早的 ZFS 與 DTrace

容器通常被講成一個 Linux 的故事。但在生產環境中隔離作業系統，更早出現在 FreeBSD。手冊頁寫道：「The jail utility appeared in FreeBSD 4.0」[9]。FreeBSD 4.0 於 2000 年 3 月 14 日發布 [59]。同一年，Poul-Henning Kamp 與 Robert Watson 在 SANE 2000 上發表了這個設計：jail「provides the ability to partition the operating system environment, while maintaining the simplicity of the UNIX 'root' model」，而到當時為止最普遍的用途是「providing virtual machine services in Internet Service Provider environments」[60]。

在 Linux 上，各個部件是陸續到位的。mount namespace 出現在 2.4.19 [61]。cgroups 首度登場於 2.6.24 [18]，該版發布於 2008 年 1 月 24 日 [62]。不需特權就能建立 user namespace，要到 Linux 3.8 才做得到 [63]。Linux 的模式是由使用者空間組合各自獨立的基本元件，最後更有彈性，容器產業也是在它之上成長的。但 jail 比較早。

讓 Linux 管理員羨慕了好多年的兩個工具，也來自外面。ZFS「Originally developed at Sun Microsystems」[64]，而 FreeBSD 7.0 的發行說明記載：「Support for Sun's ZFS has been added」[65]。7.0 版於 2008 年 2 月 27 日推出 [66]。DTrace 由 Sun 的 Solaris 核心團隊成員 Bryan Cantrill、Michael Shapiro 與 Adam Leventhal 在 2004 年的 USENIX 上發表，是一個能「in a unified and absolutely safe fashion」對核心與程式進行插樁的工具，關閉時則是「zero probe effect」[67]。2009 年 1 月 4 日的 FreeBSD 7.1 帶來了「imported from OpenSolaris」的 DTrace [68], [69]。FreeBSD 手冊至今仍這樣開啟這一章：「DTrace [...] was developed by Sun™ as a tool for locating performance bottlenecks in production and pre-production systems」[70]。如今在 Linux 上扮演這個角色的 eBPF，要到 2014 年 12 月 7 日發布的 Linux 3.18 才有 bpf() 系統呼叫 [71]。

Windows NT：回到核心裡的假微核心

Windows 是熱愛 Linux 那群人最喜歡的箭靶，而它確實該被批評：它的核心模式驅動程式會當掉，原因和 Linux 的一樣，Microsoft 自己的文件就這麼寫 [8]。它也該為行銷話術受到批評。1992 年，Tanenbaum 舉「not-yet-released Windows/NT」為微核心的例子 [1]。2004 年，他更正了：「Microsoft claimed that Windows NT 3.51 was a microkernel. It wasn't. It wasn't even close. Even they dropped the claim with NT 4.0」[53]。Torvalds 稱為「just marketing」的那個「混合式核心」，很大程度上指的就是這個 [50]。

NT 也有常被遺忘的血統。Tanenbaum 說，Microsoft 聘請了 DEC 的 VMS 主要架構師之一 David Cutler，來領導開發 Windows NT 的團隊，並補充說「Operating system designers of Cutler's quality are few and far between」[72]。

關於 NT 的設計以及 NT 4.0 的退卻，最好的資料來源是 Microsoft 自己的一份文件：「Windows NT Kernel-mode User and GDI White Paper」，至今仍保存在 Microsoft Learn 上 [73]。它把 NT 3.51 描述成分層的結構：最底層是硬體抽象層（HAL），上面是負責中斷、延遲程序呼叫、執行緒排程與同步的「microkernel」，再上面是 Executive。同一份文件承認，NT「has fallen squarely into the modified microkernel or macrokernel camp」：從第一個版本開始，記憶體管理器、快取、檔案系統、網路協定、網路伺服器與行程管理，就都在核心模式中執行 [73]。留在外面的是環境子系統。原本的計畫是讓 Win32、OS/2 與 POSIX 成為平起平坐的環境；結果 Win32 成了一個特權的「應用程式」，其他一切都依賴它，而視窗管理器（USER）與圖形介面（GDI）在一個使用者行程 CSRSS.EXE 中執行 [73]。

在 NT 4.0 中，Microsoft 把 USER 與 GDI 搬進了核心，文件用數字解釋了原因。主從式模型需要一個 64 KB 的共享記憶體緩衝區，而且每一次圖形呼叫都需要在執行緒與行程之間進行好幾次情境切換。在一台 Pentium 100 上，一次主從式轉換要花 60 到 70 微秒，而轉換到核心模式只要 4 到 5 微秒 [73]。這項改變節省了 256 KB 到 1 MB 的工作記憶體，讓 PowerPoint 快了 15% 到 20%。原本部分在 CSRSS 中執行的圖形驅動程式，改為完全在核心模式中執行 [73]。

Microsoft 不怕這項改變的論點，和 Torvalds 的一樣。文件說「No commercial operating system is based on a pure microkernel design」，因為純粹的設計「is too computationally expensive」，並且問：當使用者模式的檔案系統死掉時，一個當機的系統，和一個繼續執行「but loses all access to persistent storage」的系統，實際上有什麼差別 [73]。關於 GDI，它承認：如果 NT 3.51 的圖形行程失敗，使用者看到的會是「a system that appears to have crashed」[73]。Microsoft 在 NT 4.0 中，以效能之名，做了 Tanenbaum 在 Linux 身上所批評的那種取捨。

多年後，Windows 有了一個 Linux 沒有到同等程度的機制：一套官方的使用者模式驅動程式框架。根據 Microsoft 的說法，「UMDF drivers abstract hardware functionality, run in the user-mode environment, and can access various services」。每個驅動程式都在一個由服務管理的宿主行程中執行，並由一個核心模式元件 reflector 擔任橋梁 [74]。它有其限制：「File system drivers, display drivers (for full display devices, not display-only display devices), and print drivers cannot be UMDF drivers」[74]。即便如此，對許多類別的裝置，Windows 都內建了 Linux 只在小眾場景中提供的驅動程式隔離。

今天的 Linux：單體式，但開了幾扇通往外面的窗

Linux 沒有變成微核心，而數字顯示了留在裡面的東西有多大。我計算了 2026 年 8 月 17 日發布的 Linux 7.2 tarball 中 .c、.h、.S 與 .rs 檔案的行數：65,637 個檔案，共 3,770 萬行。光是 drivers 目錄就有 2,600 萬行，佔總數的 69%；其次是 arch，佔 6.7% [75]。Linux 0.01 只有 9,877 行 [5]。幾乎所有成長的部分都在核心模式、同一個位址空間中執行，而開機後才載入的模組，和一開始就在那裡的程式碼擁有相同的權限，正如 Nooks 的論文早已描述的 [43]。

即便如此，核心還是陸續開了幾扇窗：有的通往核心模式之外，有的則帶著安全網通往核心之內。其中有些，正是對 Tanenbaum 與 MINIX 使用者在 1992 年所提要求的直接回應。

FUSE：1991 年的要求，2005 年實現

1991 年 8 月，Jyrki Kuoppala 要求使用者模式的檔案系統，Torvalds 回答說，這也許是清單上唯一做不到的東西 [10]。FUSE 進入了 2005 年 10 月 27 日發布的 Linux 2.6.14，KernelNewbies 對它的描述是「Allows to implement a fully functional filesystem in a userspace program」[76]。核心文件把使用者空間檔案系統定義為「data and metadata are provided by an ordinary userspace process」的檔案系統，並列出組成部分：一個核心模組（fuse.ko）、一個函式庫（libfuse）以及 fusermount 工具程式 [19]。文件特別強調的功能，是不需特權的掛載：daemon 以掛載者的權限執行，舉的例子是 sshfs。如果 daemon 死掉，它與核心的連線就會結束，檔案系統停止回應；核心則繼續運作 [19]。這就是把 MINIX 的伺服器模型套用到一類檔案系統上。

UIO 與 VFIO：使用者空間的驅動程式，有 IOMMU 與沒有 IOMMU

自 2006 年起在核心中有文件記載的 UIO，讓驅動程式的大部分可以寫在使用者空間。文件坦白地列出優點：「bugs in your driver won't crash the kernel」以及「updates of your driver can take place without recompiling the kernel」[77]。適用範圍有限：已經由網路、序列埠或 USB 等子系統處理的裝置，「are no candidates for an UIO driver」[77]。

VFIO 進入了 2012 年 9 月 30 日發布的 Linux 3.6 [78]，解決了 UIO 留下的問題。一個在使用者空間設定 DMA 的驅動程式，可以寫入記憶體的任何位置，這時隔離就只是裝飾。VFIO 的文件把它描述為「an IOMMU/device agnostic framework for exposing direct device access to userspace, in a secure, IOMMU protected environment」，從而可以有「safe, non-privileged, userspace drivers」[20]。文件批評 UIO「has no notion of IOMMU protection, limited interrupt support, and requires root privileges to access things like PCI configuration space」[20]。主要用途是讓虛擬機器直接存取裝置，用文件的話說，這「turns the VM into a userspace driver」。MINIX 3 提出了同樣的保護：在 DSN 2007 的論文中，想要安全進行 DMA 的驅動程式，要先請核心設定 I/O MMU [47]。

eBPF 與 sched_ext：核心中的程式碼，配上驗證器與逃生計畫

eBPF 走的是相反的路：它把程式碼帶進核心，但要先經過檢查。bpf() 呼叫進入了 Linux 3.18，KernelNewbies 這樣總結：「eBPF programs are similar to kernel modules. [...] eBPF verifier statically determines that the program terminates and is safe to execute」[71]。驗證器的文件詳述了兩個步驟：首先，檢查控制流程圖，禁止迴圈與無法到達的程式碼；接著，逐條指令模擬所有可能的路徑，追蹤每個暫存器與堆疊的型別 [79]。保護來自載入前的檢查，而這個構想離 seL4 比離 MINIX 更近。

進入 2024 年 11 月 17 日發布之 Linux 6.12 的 sched_ext [80]，把這一套帶到了排程器上。它是「a scheduler class whose behavior can be defined by a set of BPF programs」，文件承諾：「The system integrity is maintained no matter what the BPF scheduler does. The default scheduling behavior is restored anytime an error is detected, a runnable task stalls, or on invoking the SysRq key sequence SysRq-S」[21]。有缺陷的排程器會被撤下，核心回到預設行為。把「排程器」換成「驅動程式」，把「預設」換成「新的實例」，這句話就可以出現在轉世伺服器的論文裡。

Rust：同一個問題，另一種答案

最新的一個賭注，是在不把驅動程式移出核心模式的前提下，對付 Chou 在驅動程式中量到的那一類錯誤。Rust 支援在 2022 年進入 Linux 6.1，當時還處於非常初期的狀態，據 LWN 說，「No system with a production 6.1 kernel will be running any Rust code」[81]。三年後，局面改變了。在 2025 年 12 月的 Maintainers Summit 上，維護者們的共識是 Rust 不再是實驗性的，而是核心的永久組成部分，「experimental」標籤將被移除 [82]。在那場會議中，Miguel Ojeda 說，以 Rust 撰寫的 Android Binder 驅動程式已經進入 6.18，而搭載 Android 16 與 6.12 核心的裝置，出貨時已經帶著以 Rust 撰寫的 ashmem 模組：「millions of real devices running kernels with Rust code now」[83]。Greg Kroah-Hartman 說，Rust 驅動程式「are indeed proving to be far safer than those written in C」，而且到那時為止，還沒有任何 CVE 是針對核心的 Rust 程式碼發出的。圖形子系統的維護者 Dave Airlie 說，DRM 拒收以 C 撰寫的新驅動程式，已經是「about a year away」的事了。Torvalds 為這個問題畫下句點，他說，經過將近五年，時候到了 [83]。依我的計算，在 Linux 7.2 中，.rs 檔案合計 182,584 行，不到總數的百分之零點五 [75]。

技術上的重點是，Rust 和微核心用不同的方式回答同一個問題。MINIX 3 接受驅動程式一定會有錯誤，並用 MMU 把損害隔離起來 [44]。Rust 則試圖讓某一類記憶體錯誤根本不會出現，但驅動程式仍在 ring 0，邏輯錯誤仍然可能讓系統當掉。第二條路對專案有一個好處：它保留了 Torvalds 在 2006 年捍衛的東西，也就是子系統之間的共享狀態 [50]。

Linux 仍然是單體式的地方

驅動程式、網路堆疊、主要的檔案系統與記憶體管理，都仍在核心模式、同一個位址空間中 [75]。FUSE、UIO 與 VFIO 是給小眾用途的選擇性出口。eBPF 與 sched_ext 把經過驗證或可丟棄的程式碼放進核心，Rust 則以語言的安全性取代隔離。這些部件沒有一個改變 Tanenbaum 在 1992 年批評的架構。說 Linux「已經有一半是微核心」的人言過其實。說它無視那些批評的人，也一樣。

微核心勝出的地方

Tanenbaum 預言微核心會稱霸桌面與伺服器，這並沒有實現。但有些地方，故障的代價高昂，程式碼必須很小，而在那些地方，微核心贏了。

seL4：一個有數學證明的核心

2009 年，NICTA 與 UNSW 的 Gerwin Klein 及同事在 SOSP 上發表了 seL4 的形式化驗證。seL4 是「a third-generation microkernel of L4 provenance」，「comprises 8,700 lines of C code and 600 lines of assembler」。論文描述的是「the first formal proof of functional correctness of a complete, general-purpose operating-system kernel」，並經過機器驗證 [84]。作者們把這個成果和規模連在一起：「With truly small kernels it becomes possible to take security and robustness further, to the point where it is possible to guarantee the absence of bugs」[84]。這就是 1992 年的論點，如今有了證明。

代價也寫在同一篇論文裡。整個證明連同函式庫與自動產生的部分，共有 200,000 行 Isabelle 腳本，作者們證明了超過 150 個關於核心狀態的不變量 [84]。寫出核心花了 2.2 人年，包括 Haskell 原型在內。證明花了大約 20 人年，其中 11 人年是 seL4 專屬的，其餘是可重複利用的工具與研究。作者們拿業界 Common Criteria EAL6 認證的經驗法則來比較：每行 1 萬美元，套在 seL4 上就是 8,700 萬美元，而保證程度低得多 [84]。證明在 C 程式碼中找到的錯誤，並不是演算法上的缺陷，大多是打字錯誤、對規格的誤讀以及遺漏的檢查，但其中許多仍足以讓核心當掉或打開安全漏洞 [84]。這筆帳對 3,700 萬行的程式碼是算不過來的。Heiser 與 Elphinstone 寫道：「even 9,000 SLOC pushed the limits of what was achievable」[51]。

數十億台裝置裡的 L4

L4 家族走出了實驗室。據 Heiser 與 Elphinstone 說，Pistachio 的一個嵌入式版本有了「massive-scale commercial deployment when Qualcomm adopted it as a protected-mode real-time OS for the firmware of their wireless modem processors」，而且在近期 iOS 裝置的安全處理器上執行；註腳寫著：「Total deployment is now in the billions」[51]。PikeOS 是 L4 第二版的商業複製品，通過了航空電子的認證，在飛機與火車上執行 [51]。在所有 L4 核心中，除了計時器驅動程式與中斷控制器之外，驅動程式都在使用者模式中執行，作者們說，把未經驗證的驅動程式放進核心「would obliterate any guarantees」[51]。Tanenbaum 在 2004 年也指出 QNX 是「An example of commercially successful microkernel」[6]，2006 年又列出 QNX、Integrity、PikeOS、Symbian 與 L4Linux，作為「clearly I am not alone in seeing something in microkernels」的證據 [35]。

幾乎每台 Intel PC 裡都有的 MINIX

這段歷史中最常被提起的諷刺，發生在 2017 年。MINIX 3 在 Intel Management Engine（ME）裡面執行，ME 是在 Intel 機器上、於作業系統之下運作的管理子系統。在 2017 年於布拉格舉行的 Embedded Linux Conference Europe 上，Google 的 Ronald Minnich 描述了核心之下的「環」：「Ring -3 is 'the one that has people really worried'. It runs MINIX 3 and is where the ME runs.」他開玩笑說，這是「year of MINIX 3 on the desktop」，因為有 ME 的機器比裝 Linux、macOS 或 Windows 的機器還多。那裡面跑著 IPv4 與 IPv6 協定堆疊、檔案系統、驅動程式與網頁伺服器。根據 LWN 在 2017 年 11 月 20 日發表的報導，ME「can reimage the system even if the power is turned off as long as it is plugged into the wall and the network」[85]。在同一年的 Black Hat Europe 上，Mark Ermolov 與 Maxim Goryachy 展示了如何在 ME 中執行未簽署的程式碼 [86]。

Tanenbaum 寫了一封給 Intel 的公開信，收件人是「Mr. Krzanich」。Internet Archive 上最早的副本是 2017 年 11 月 7 日的 [22]。語氣是反諷與不悅。他感謝 Intel 把 MINIX 放進「inside the ME-11 management engine chip used on almost all recent desktop and laptop computers in the world」，說這也許讓 MINIX 成了「the most widely used computer operating system in the world」，並抱怨沒有人通知他 [22]。接著是對本文最重要的部分：「I certainly hope Intel did thorough security hardening and testing before deploying the chip, since apparently an older version of MINIX was used. Older versions were primarily for education and newer ones were for high availability. Military-grade security was never a goal」[22]。

認為微核心就等於安全的迷思，在這裡被 MINIX 的作者親手終結。微核心隔離元件、減少特權程式碼，這有助於安全。但它取代不了稽核，而地球上用得最多的 MINIX，就跑在機器主人無法稽核的韌體裡。ME 的問題是治理問題，不是核心架構的問題，而 Tanenbaum 本人也把兩者分開了：「that is Intel's business decision and a separate issue from the code it runs」[22]。

今天的 MINIX 3

專案網站仍把 MINIX 3 描述為「designed to be highly reliable, flexible, and secure」，有「a tiny microkernel running in kernel mode with the rest of the operating system running as a number of isolated, protected, processes in user mode」[87]。功能頁面用三個短句總結架構：「Tiny microkernel that runs in kernel mode」、「Each device driver is a separate user-mode process」與「Reincarnation server can reload failed drivers」[88]。然而，官方儲存庫顯示的是一個停滯的專案：最新的 tag 是 v3.3.0，主分支的最後一個提交是 2018 年 11 月 14 日 [89]。這個構想在 seL4、數據機裡的 L4 以及 QNX 中依然活著。MINIX 本身則主要成了韌體與教室裡的一個零件。

比分

數字並列

量測項目	數據	來源
Linux 0.01 的規模	88 個檔案，9,877 行（我的計算）	[5]
Linux 7.2 的規模	3,770 萬行，69% 在 `drivers`（我的計算）	[75]
Linux 7.2 中的 Rust	182,584 行，約 0.5%（我的計算）	[75]
MINIX 3 的核心	約 4,000 行，只有時鐘驅動程式在核心模式	[44]
seL4 的核心	8,700 行 C 與 600 行組合語言	[84]
Mach 的 IPC，1990 年代初	每則訊息約 100 µs	[51]
L3 的 IPC，50 MHz 的 486	5 µs，比 Mach 快 3 到 22 倍	[14]
seL4 的 IPC，2013 年的 Core i7	0.09 µs（301 個週期）	[51]
NT 3.51，Pentium 100	每次主從式切換 60 到 70 µs，進入核心則是 4 到 5 µs	[73]
在 L4 上執行 Linux 的代價	吞吐量少 5%	[15]
MINIX 3 的隔離代價	比 MINIX 2 慢 5% 到 10%	[48]
驅動程式的錯誤，Linux 2.4.1	錯誤率是核心其餘部分的 3 到 7 倍	[42]
Windows XP 故障中的驅動程式	回報故障的 85%	[43]
Linux 的驅動程式，2.6.19 到 2.6.33	故障率等於核心平均	[45]
MINIX 3 的驅動程式復原	模擬器中 100%，實體硬體上超過 99%	[47]
Nooks（Linux）的復原	原本會讓 Linux 當掉的故障中的 99%	[43]
seL4 證明的成本	約 20 人年，200,000 行 Isabelle	[84]
授權	Linux 在 1992 年採用 GPL；擺脫訴訟的 4.4BSD-Lite 在 1994 年推出；MINIX 在 2000 年改用 BSD	[28], [30], [33], [23]

Tanenbaum 說對的地方

他在可靠性的診斷上是對的。錯誤集中在驅動程式中 [42], [43]，而在單體式核心中，一個糟糕的驅動程式就能讓一切當掉，Microsoft 為 Windows 記載了這一點 [8]，對 Linux 也同樣成立。他說對了：隔離驅動程式的設計，能從在單體式核心中會致命的故障中復原，MINIX 3 量測了這一點 [47]。他說對了：小規模的特權程式碼，才能提供強力的保證；seL4 之所以能被證明正確，正因為它只有 8,700 行 C [84]。他說對了：在故障代價高昂的地方，微核心會有一席之地，從 Qualcomm 的數據機 [51] 到 Secure Enclave [55]。他也說對了 BSD 訴訟對 Linux 成功的影響，這一點連 Torvalds 自己都證實了 [11], [6]。

Tanenbaum 說錯的地方

他在市場上錯得離譜。他說論戰已經「essentially over」，而且「Microkernels have won」[1]；桌面與伺服器仍然是單體式或混合式的，包括他自己歸類為「not a true microkernel」的 XNU [35]，以及正是為了效能而把圖形部分搬進核心的 NT [73]。他說 80x86「is not going to be around all that long」[1]；到了 2025 年，macOS 26 在 Intel Mac 上仍有 UNIX 認證 [7]，Linux 也為 x86 和另外十五種架構各自維護文件 [90]。他預言五年內「everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5」[4]；1997 年，GNU 還在 0.2 版 [29]。他預言協調散布在世界各地的程式設計師會「as easy as herding cats」[4]，而他想像中會陷入無政府狀態的專案，如今跑在前 500 大超級電腦上 [2]。他把可移植性當成微核心的優點，而 Liedtke 在 1995 年會寫道，微核心「are inherently not portable」[52]。他還在 1992 年把 Windows NT 當成微核心的例子 [1]，後來才承認它不是 [53]。

Torvalds 說對的地方

他說對了：能用，比優雅更有價值 [1]。他說對了：對使用者來說，API 的可移植性比核心的可移植性更重要。1992 年改用 GPL [28]，比 MINIX 改用 BSD 授權早了八年 [23]，這讓 Linux 得到了 MINIX 刻意拒絕的貢獻者群 [6]。他早早開放開發，是對的：1992 年 2 月，他已經在探詢成立「linux-kernel」郵件論壇，並從 0.10 版起接受 Ts'o 的大幅修改 [4]。他在 2006 年關於微核心中共享狀態代價的論點是嚴肅的，Microsoft 在 NT 4.0 中也用了同樣的推理 [73]，這有助於理解為什麼很少通用系統走上那條路 [50]。

Torvalds 說錯或讓步的地方

「won't be big and professional」[10] 作為這個討論串中錯得最離譜的預言，留在了歷史上。第二個是 1991 年的「porting is impossible」[10]：今天的核心有十六種處理器架構的文件 [90]。他自己在 1992 年就承認，從理論的角度看，「linux looses」[1]，也承認不可移植性已經走到了「to an extreme」[1]。2006 年，他把重新載入失敗服務的構想稱為「flawed」[50]，而 MINIX 3 與 Nooks 的實驗顯示，在測試的驅動程式故障中，超過 99% 都能復原 [47], [43]。2009 年，他說核心「huge and bloated」[46]。而 Tanenbaum 說 Torvalds 對前人的功勞歸屬給得太少，是有道理的 [6]。

結論：很好，但不神聖

1992 年，一位教授說 Linux 是退回 1970 年代的一步，一個學生回答說，至少它現在就能用。兩人說的都有道理，也各自錯在沒有考慮到的地方。

Linux 配得上它今天的地位。它勝出，是因為它在 1992 年就已就緒、真正自由，也因為在 MINIX 拒絕要求、BSD 困在法庭的時候，它接受任何來者的貢獻 [6], [30]。這樣贏是有功勞的，而自由軟體贏得的幾乎一切，也都是這樣贏來的。

只是，勝出並不會讓這個專案成為架構上的典範。Linux 核心是單體式的，在核心模式中執行 2,600 萬行驅動程式 [75]，連它的創造者都說它臃腫 [46]。Tanenbaum 對可靠性的批評仍然站得住腳，而對它最有力的回應都來自 Linux 之外：經過證明的 seL4 [84]、會重新載入驅動程式的 MINIX 3 [47]、數據機裡的 L4 [51]、Windows 的 UMDF [74]，以及 Apple 的 DriverKit [57]。Linux 用自己的方式回應了這些批評：FUSE、VFIO、eBPF，以及現在的 Rust [19], [20], [71], [83]。這些都是好的回應，但不是 Tanenbaum 要的那種回應。

把 Linux 叫做 MINIX 抄本的批評者，需要讀讀 MINIX 的作者寫了什麼：「the code was his」[6]。以為 Linux 發明了一切的信徒，需要讀讀 FreeBSD 4.0 的發行說明、DTrace 的論文以及 NT 的白皮書 [59], [67], [73]。兩者都需要把 1992 年的討論串從頭讀到尾。在那裡，Torvalds 同意微核心「are nicer」[1]，而 Tanenbaum 說他對 Linux 並無不滿 [1]。

我喜歡 Linux。我每天都用，也會繼續用。但核心是工具，而工具要用文件所顯示的東西來評價，不是用使用者的信仰。

來源

以下每一份來源都在研究期間讀過（全文或相關段落）。每筆參考文獻下方列出它在本文中佐證的內容。引文皆為原文照錄，歷史時間以 GMT 表示，與原始標頭一致。

[1]A. S. Tanenbaum and L. Torvalds, “LINUX is obsolete,” messages in the comp.os.minix newsgroup, Jan. 29, 1992, archived by the Linux Information Project. [Online]. Available: https://www.linfo.org/obsolete.html ↩
- Tanenbaum 1992/01/29（12:12:50 GMT）的貼文：「a giant step back into the 1970s」、「Microkernels have won」、以「the not-yet-released Windows/NT」為微核心的例子、「LINUX is tied fairly closely to the 80x86. Not the way to go」、「I think it is a gross error to design an OS for any specific architecture」、「Don't get me wrong, I am not unhappy with LINUX」、MINIX 的驅動程式「in the kernel, but only because the brain-dead nature of the Intel CPUs」，以及引用 Rick Rashid 關於 Mach 3.0 的論文。
- Torvalds 1992/01/29（23:14:26 GMT）的回覆：「True, linux is monolithic, and I agree that microkernels are nicer」、「linux looses」、「If the GNU kernel had been ready last spring...」、「Linux wins heavily on points of being available now」、「as conformant to standards as I knew how」、「non-portability to an extreme」、「brain-damages of minix」、「doesn't suck like minix does」。
- 標頭「Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam」。
[2]ZDNet, “Linux Totally Dominates Supercomputers,” republished by Linux.com, Nov. 15, 2017. [Online]. Available: https://www.linux.com/news/linux-totally-dominates-supercomputers-1/ ↩
- 2017 年 11 月的 TOP500 榜單：「All 500 of the world's fastest supercomputers are running Linux」；最後兩套不跑 Linux 的系統執行的是 AIX。
[3]Android Open Source Project, “Kernel overview,” accessed Oct. 4, 2026. [Online]. Available: https://source.android.com/docs/core/architecture/kernel ↩
- 「The Android kernel is based on an upstream Linux Long Term Supported (LTS) kernel.」
[4]C. DiBona, S. Ockman and M. Stone (Eds.), “Appendix A: The Tanenbaum-Torvalds Debate,” in Open Sources: Voices from the Open Source Revolution. Sebastopol: O'Reilly, 1999. [Online]. Available: https://www.oreilly.com/openbook/opensources/book/appa.html ↩
- Tanenbaum，1992/01/30（13:44:34 GMT）：「I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful you are not my student...」、「5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5」；MINIX 是為了在沒有硬碟的 4.77 MHz PC 上執行而設計的；PC 版與另一版的銷量是 2 比 1。
- Torvalds，「Apologies (was Re: LINUX is obsolete)」，1992/01/30（15:38:16 GMT）：「Apologies to ast」、「I over-reacted」、「some of the criticisms are valid」、「my first, and hopefully last flamefest」。
- O'Reilly 的導言把這位參與者稱為「user-hacker Ken Thompson (one of the founders of Unix)」；訊息標頭：「kt4@prism.gatech.EDU (Ken Thompson)」、「Organization: Georgia Institute of Technology」，1992/02/03；引文「microkernels are probably the wave of the future... easier to implement a monolithic kernel...」。
- Tobin：「I find the single-threaded file system a serious pain when using Minix」；Tanenbaum：「A multithreaded file system is only a performance hack」。
- Torvalds，1992/01/31：「you automatically get a multithreaded kernel」、「linux API is portable」，完整原始碼約 200 kB，對比 Mach 的 i386.tar.Z 超過 800 kB，「minix is portable, but you can rewrite that as 'doesn't use any features'」；關於赫爾辛基那位教授的回答（「the person here at the university that teaches OS design」）。
- 其他參與者：Ts'o（「is probably not much more than what is in a Minix implementation」、「Linux is here, and GNU isn't」、「ipso facto micro kernels must be the right approach」）；Hedrick（「availability wins out over technical quality every time」、「all they could distribute were diffs」、「4.4's release date has a history of extreme slippage」）；Graham（「about 12000 lines of code」、「adding features is a royal pain」）；Foard（「significantly slower」）；Tanenbaum（「I AM NOT A THEORIST」、QNX 有 200,000 套系統、「proven technology」）；Miller；Haardt（「why I think AST is right」）；Burns（「Linux will be obsolete」）；Kevin Brown（「years of experience with monolithic kernels」）。
- 「Unhappy campers」（1992/02/03）：「10 messages from the 43,000 readers」、MINIX 售價 169 美元、Coherent 99 美元、4.4BSD 800 美元、「100% emotional」、「Surely Linus' OS professor pointed this out」；Tanenbaum（02/05）：「as easy as herding cats」、「has never managed a software project」；Torvalds（02/06）：「I won't.」、「linux-kernel」郵件論壇、Ts'o 做了「some heavy changes even to 0.10」。附錄共收錄 36 則訊息。
[5]L. Torvalds, “linux-0.01.tar.gz,” Linux 0.01 source code, Sep. 1991, kernel.org historic archive (file and line counts by the author). [Online]. Available: https://cdn.kernel.org/pub/linux/kernel/Historic/linux-0.01.tar.gz ↩
- 我在 2026 年 10 月 4 日下載 tarball 後的計算：88 個檔案；.c、.h 與 .s 檔案合計 9,877 行；檔案日期介於 1991 年 6 月 15 日到 9 月 17 日，其中 60 個落在 9 月 11 日到 17 日。kernel/ 3,511 行；mm/memory.c + mm/page.s 298 行；fs/ 2,771 行。
- include/linux/sys.h：系統呼叫表有 67 個項目，從 sys_setup 到 sys_setsid；kernel/sys.c：15 個只回傳 -ENOSYS 的函式（包括 sys_mount、sys_umount、sys_rename、sys_mknod、sys_ptrace）。
- include/linux/config.h：LINUS_HD、LASU_HD、「Amount of ram memory (in bytes, 640k-1M not discounted). Currently 8Mb」。include/linux/sched.h：NR_TASKS 64、HZ 100，以及用 ljmp 跳到 TSS 的 switch_to 巨集。
- Makefile：「chmem +65000 tools/build」與「If you don't have '-mstring-insns' in your gcc (and nobody but me has :-)」。include/linux/fs.h：裝置編號「same as minix, so we can use the minix file system」、NAME_LEN 14、SUPER_MAGIC 0x137F。
[6]A. S. Tanenbaum, “Some Notes on the 'Who wrote Linux' Kerfuffle,” Vrije Universiteit, May 20, 2004. [Online]. Available: https://www.cs.vu.nl/~ast/brown/ ↩
- 日期：2004 年 5 月 20 日。1987 年附有 MINIX 程式碼的 Operating Systems: Design and Implementation 一書；Prentice Hall 的磁碟片售價 69 美元；boilerplate 不對大學與學生執行；comp.os.minix 有 40,000 名訂閱者；每天 200 封電子郵件，「No.」；「everyone was trying to turn MINIX into a production-quality UNIX system...」。
- 針對 BSDi 的訴訟「gave Linux the breathing space it needed to catch on」；Brown 在 2004/03/23 飛到阿姆斯特丹；「AST: Is Microsoft one of them? KB: We have multiple funding sources」。
- 「He had my book, was running MINIX... But the code was his. The proof of this is that he messed the design up」；「Linus rewrote the whole thing as a big monolithic kernel」；「pretty good proof that it was a redesign」；QNX 是「commercially successful microkernel」；對署名的批評：「Linus has done this far less than he should have... Ken and Dennis are the real heros」；「I met him once」；「My only regret is that he didn't develop Linux based on the microkernel technology of MINIX」。
[7]The Open Group, “UNIX 03: Apple Inc., macOS version 26.0 Tahoe on Apple silicon-based Mac computers,” registered Aug. 29, 2025. [Online]. Available: https://www.opengroup.org/openbrand/register/brand3725.htm ↩
- macOS 26.0 Tahoe 於 29-Aug-2025 登錄為 UNIX 03（Apple Silicon；Intel 也有對應的登錄）；登錄上的名稱是 macOS 這個產品，不是核心。
[8]Microsoft, “User Mode and Kernel Mode,” Windows drivers, Microsoft Learn, accessed Oct. 4, 2026. [Online]. Available: https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode ↩
- 「All code that runs in kernel mode shares a single virtual address space... If a kernel-mode driver crashes, it causes the entire operating system to crash.」
[9]FreeBSD Project, “jail(8),” FreeBSD System Manager's Manual, accessed Oct. 4, 2026. [Online]. Available: https://man.freebsd.org/cgi/man.cgi?query=jail&sektion=8 ↩
- 「The jail utility appeared in FreeBSD 4.0.」
[10]L. Torvalds, “LINUX's History,” Jul. 31, 1992, with the 1991 messages in the comp.os.minix newsgroup (Aug. 25; reply to J. Kuoppala, Aug. 26; announcement of version 0.02, Oct. 5). [Online]. Available: https://www.cs.cmu.edu/~awb/linux.history.html ↩
- 1991/08/25（20:57:08 GMT）的貼文，Organization: University of Helsinki：「just a hobby, won't be big and professional like gnu」、「my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons)」、「it's free of any minix code」、「It is NOT protable」。
- 給 Jyrki Kuoppala 的回覆（1991/08/26）：「Simply, I'd say that porting is impossible. It's mostly in C, but most people wouldn't call what I write C. It uses every conceivable feature of the 386 I could find, as it was also a project to teach me about the 386」；64 MB 的區段，4 GB 中最多 64 個任務；「almost as much assembler as C」；「a porters nightmare」；「except maybe for the user-mode filesystems」。
- 1992 年 7 月的文字：「0.01 sources weren't actually runnable」、「0.01 didn't actually come with any binaries」。
- 0.02 的公告（1991/10/05），「Free minix-like kernel sources for 386-AT」：「Do you pine for the nice days of minix-1.1, when men were men and wrote their own device drivers?」、「no minix code has been used」、「These sources still need minix-386 to be compiled」、「Hurd will be out in a year (or two, or next month, who knows)」。
[11]M. Linksvayer, “The Choice of a GNU Generation: An Interview With Linus Torvalds,” Meta Magazine, Nov. 1993. [Online]. Available: https://gondwanaland.com/meta/history/interview.html ↩
- Torvalds：「If 386BSD had been available when I started on Linux, Linux would probably never had happened.」
[12]The Open Group, “UNIX 03: Huawei Technology Co., Ltd., Huawei EulerOS 2.0 on Huawei KunLun Mission Critical Server,” registered Sep. 8, 2016. [Online]. Available: https://www.opengroup.org/openbrand/register/brand3622.htm ↩
- Huawei EulerOS 2.0 on Huawei KunLun Mission Critical Server，UNIX 03，「Registered on: 8-Sep-2016」；證書 P1204，2022 年 9 月 8 日續約。（Huawei 的新聞稿說的是 2019 年；本文採用登錄日期。）
[13]G. Kroah-Hartman, “The Linux Kernel Driver Interface,” Linux kernel documentation, accessed Oct. 4, 2026. [Online]. Available: https://docs.kernel.org/process/stable-api-nonsense.html ↩
- 「this article describes the in kernel interfaces, not the kernel to userspace interfaces」；系統呼叫介面「is very stable over time, and will not break」；0.9 之前的程式在 2.6 上執行；USB 堆疊至少改造了三次；「function names may change, structures may grow or shrink」；「trying to keep up with an ever changing kernel interface is also a rough job」；「good luck, you are on your own here, you leech」。
[14]J. Liedtke, “Improving IPC by Kernel Design,” in Proc. 14th ACM Symp. on Operating Systems Principles (SOSP 1993), Asheville, 1993. [Online]. Available: https://os.itec.kit.edu/downloads/improving-ipc.pdf ↩
- 486-DX50：理論最小值 172 個週期（3.5 µs），目標 350，結果 250 個週期（5 µs）；相對於 Mach 的提升「from a factor of 22 (8-byte messages) to 3 (4-Kbyte messages)」；mach_thread_self 需 18 µs，而進出核心一趟的最低成本是 2 µs。
[15]H. Härtig, M. Hohmuth, J. Liedtke et al., “The Performance of µ-Kernel-Based Systems,” 16th ACM Symposium on Operating Systems Principles (SOSP), Saint-Malo, Oct. 1997. [Online]. Available: https://os.inf.tu-dresden.de/pubs/sosp97/ ↩
- SOSP 1997：「For L4Linux, the AIM benchmarks report a maximum throughput which is only 5% lower than that of native Linux. The corresponding penalty is 5 times higher for a co-located in-kernel version of MkLinux, and 7 times higher for a user-level version of MkLinux」；MkLinux 執行在衍生自 Mach 的微核心上。
[16]Apple, “Kernel Architecture Overview,” Kernel Programming Guide (documentation archive), accessed Oct. 4, 2026. [Online]. Available: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/Architecture/Architecture.html ↩
- 「OS X uses the term kernel somewhat differently than you might expect」；「The OS X kernel environment includes the Mach kernel, BSD, the I/O Kit, file systems, and networking components」；KEXT 載入「into kernel space」；I/O Kit 的驅動程式以 KEXT 的形式實作。
[17]Apple Inc., “Mach Overview,” in Kernel Programming Guide, Documentation Archive, accessed Oct. 4, 2026. [Online]. Available: https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/Mach/Mach.html ↩
- Tasks：「units of resource ownership; each task consists of a virtual address space, a port right namespace, and one or more threads」；Ports：「Secure, simplex communication channels, accessible only via send and receive capabilities (known as port rights)」；「At the trap level, the interface to most Mach abstractions consists of messages sent to and from kernel ports」；mach_msg_overwrite_trap；MIG。
- 「in OS X, Mach is linked with other kernel components into a single kernel address space. This is primarily for performance; it is much faster to make a direct call between linked components than it is to send messages or do remote procedure calls (RPC) between separate tasks」；「Mach is not primarily a communication hub between clients and servers」。
[18]M. Kerrisk (ed.), “cgroups(7),” Linux manual page, accessed Oct. 4, 2026. [Online]. Available: https://man7.org/linux/man-pages/man7/cgroups.7.html ↩
- 「The initial release of the cgroups implementation was in Linux 2.6.24.」
[19]The Linux Kernel documentation, “FUSE Overview,” accessed Oct. 4, 2026. [Online]. Available: https://docs.kernel.org/filesystems/fuse/fuse.html ↩
- 「A filesystem in which data and metadata are provided by an ordinary userspace process」；「FUSE is a userspace filesystem framework. It consists of a kernel module (fuse.ko), a userspace library (libfuse.*) and a mount utility (fusermount)」；「One of the most important features of FUSE is allowing secure, non-privileged mounts [...] A good example is sshfs」；「The filesystem daemon is running with the privileges of the mounting user」；連線「exists until either the daemon dies, or the filesystem is umounted」。
[20]The Linux Kernel documentation, “VFIO - ‘Virtual Function I/O’,” accessed Oct. 4, 2026. [Online]. Available: https://docs.kernel.org/driver-api/vfio.html ↩
- 「an IOMMU/device agnostic framework for exposing direct device access to userspace, in a secure, IOMMU protected environment」；「safe, non-privileged, userspace drivers」；「turns the VM into a userspace driver」；UIO「has no notion of IOMMU protection, limited interrupt support, and requires root privileges to access things like PCI configuration space」。
[21]The Linux Kernel documentation, “Extensible Scheduler Class,” accessed Oct. 4, 2026. [Online]. Available: https://docs.kernel.org/scheduler/sched-ext.html ↩
- 「a scheduler class whose behavior can be defined by a set of BPF programs」；「The system integrity is maintained no matter what the BPF scheduler does. The default scheduling behavior is restored anytime an error is detected, a runnable task stalls, or on invoking the SysRq key sequence SysRq-S」。
[22]A. S. Tanenbaum, “An Open Letter to Intel,” Vrije Universiteit, Nov. 2017. [Online]. Available: https://www.cs.vu.nl/~ast/intel/. Internet Archive copy of Nov. 7, 2017: https://web.archive.org/web/20171107134506/http://www.cs.vu.nl/~ast/intel/ ↩
- 致「Mr. Krzanich」的信：MINIX「inside the ME-11 management engine chip」；「the most widely used computer operating system in the world」；「The L4 microkernel has been running inside smartphone chips for years」；「apparently an older version of MINIX was used... Military-grade security was never a goal」；「that is Intel's business decision and a separate issue from the code it runs」。Internet Archive 上最早的副本：2017 年 11 月 7 日。
[23]A. S. Tanenbaum, “MINIX is now available under the BSD license,” message in the comp.os.minix newsgroup, Apr. 7, 2000, reproduced in the MINIX FAQ. [Online]. Available: https://minix1.woodhull.com/faq/mxlicense.html ↩
- Tanenbaum，2000/04/07：「Better late than never. I finally got permission from Prentice Hall to change the MINIX license to the BSD license. The lawyers sort of sat on this for two years.」
[24]kernel.org, “Index of /pub/linux/kernel/v1.0/,” accessed Oct. 4, 2026. [Online]. Available: https://cdn.kernel.org/pub/linux/kernel/v1.0/ ↩
- Linux 1.0 的檔案日期為 13-Mar-1994。
[25]A. S. Tanenbaum et al., MINIX 2.0.4 source code (kernel/proc.c, kernel/table.c, include/minix/type.h, fs/const.h), unofficial “Minix QD” redistribution maintained by D. Given. [Online]. Available: https://github.com/davidgiven/minix2 ↩
- kernel/proc.c：「The only system calls that exist in MINIX are sending and receiving messages. These are done by trapping to the kernel with an INT instruction」；如果目的地正在等待，mini_send 直接複製，否則把傳送者阻塞在佇列中；以 ELOCKED 偵測死結；「User processes are only allowed to send to FS and MM」。
- include/minix/type.h：message 是從 mess_1 到 mess_6 的聯合，帶有 m_source 與 m_type。lib/i386/rts/_sendrec.s：_send、_receive、_sendrec 使用 int SYSVEC（33）。
- kernel/table.c：TTY、DP8390、RTL8139、Sound Blaster、印表機、磁碟、軟碟、記憶體、時鐘與 SYSTEM 等任務編譯在核心中；MM、FS 與 INIT 是行程。
- fs/const.h：SUPER_MAGIC 0x137F。commands/simple/chmem.c：「Author: Andy Tanenbaum」。
[26]L. Torvalds, “RELEASE NOTES for Linux v0.01,” Sep. 1991. [Online]. Available: https://www.kernel.org/pub/linux/kernel/Historic/old-versions/RELNOTES-0.01 ↩
- 「uses no code from minix or other sources」；「you currently need minix to bootstrap the system」；原始授權：「(C) 1991 Linus Torvalds... Full source must be available (and free)」。
[27]R. Card, T. Ts'o and S. Tweedie, “Design and Implementation of the Second Extended Filesystem,” Proceedings of the First Dutch International Symposium on Linux, ISBN 90-367-0385-9. [Online]. Available: https://web.mit.edu/tytso/www/linux/ext2intro.html ↩
- Linux「cross-developed under the Minix operating system」；為了共用磁碟而支援 MINIX 的檔案系統；MINIX 檔案系統「efficient and relatively bug-free」；64 MB 與 14 個字元的限制；1992 年 4 月在 0.96c 中加入 Extended File System，上限 2 GB 與 255 個字元。
[28]L. Torvalds, “RELEASE NOTES for Linux v0.12,” 1992. [Online]. Available: https://www.kernel.org/pub/linux/kernel/Historic/old-versions/RELNOTES-0.12 ↩
- 改用 GPL：「make it compatible with the GNU copyleft, removing the 'you may not distribute it for money' condition. I agree」；自 2 月 1 日起生效。
[29]GNU Project, “History,” GNU Hurd page, Internet Archive copy from 2024. [Online]. Available: https://web.archive.org/web/2024/https://www.gnu.org/software/hurd/history.html ↩
- 自 1991 年 11 月起，建立在 Mach 上的 Hurd 成為 GNU 的官方核心；GNU Hurd 0.1 於 1996-09-06 推出；GNU 0.2 於 1997-06-16 推出。
[30]M. K. McKusick, “Twenty Years of Berkeley Unix: From AT&T-Owned to Freely Redistributable,” in Open Sources. Sebastopol: O'Reilly, 1999. [Online]. Available: https://www.oreilly.com/openbook/opensources/book/kirkmck.html ↩
- BSDi 自 1992 年 1 月起以 995 美元販售，電話 1-800-ITS-Unix；USL 控告 BSDi，之後也控告加州大學；1992 年 12 月舉行禁制令聽證，約六週後遭駁回；1994 年 1 月和解（18,000 個檔案中移除三個）；1994 年 6 月推出 4.4BSD-Lite；BSDI、NetBSD 與 FreeBSD 都必須以它為基礎重新開始。
[31]L. Jolitz, “386BSD Release 0.1 Released on Bastille Day is Thirty-Three Years Old Today,” Lynne's Take on Tech, Jul. 14, 2025. [Online]. Available: https://lynnesblog.telemuse.net/2025/07/14/386bsd-release-0-1-released-on-bastille-day-is-thirty-three-years-old-today/ ↩
- 386BSD 0.0 於 1992 年 3 月推出，在 Dr. Dobb's Journal 的系列文章之後；386BSD 0.1 於 1992 年 7 月 14 日推出。
[32]The NetBSD Project, “The History of the NetBSD Project,” accessed Oct. 4, 2026. [Online]. Available: https://www.netbsd.org/about/history.html ↩
- NetBSD 0.8 於 1993 年 4 月 20 日發布；專案於 1993 年以 386BSD 為基礎成立。
[33]The FreeBSD Documentation Project, “Chapter 1. Introduction,” in FreeBSD Handbook, accessed Oct. 4, 2026. [Online]. Available: https://docs.freebsd.org/en/books/handbook/introduction/ ↩
- 起源於 1993 年初的「Unofficial 386BSD Patchkit」；1993 年 12 月以 Net/2 為基礎推出 FreeBSD 1.0；USL 與 Novell 的和解；必須在 1994 年 7 月底前停止散布 Net/2 產品；以 4.4BSD-Lite 作為新的基礎；1994 年 12 月推出 FreeBSD 2.0（11 月完成系統重建）。
[34]K. Brown and J. Orndorff, “Samizdat: And Other Issues Regarding the 'Source' of Open Source Code,” Alexis de Tocqueville Institution, May 20, 2004. [Online]. Available: https://www.itreview.org/documents/acrobat/040524.pdf ↩
- Kenneth Brown（AdTI 總裁）與 Justin Orndorff 的報告，日期為 2004 年 5 月 20 日，質疑 Linux 程式碼的來源以及歸給 Torvalds 的功勞。
[35]A. S. Tanenbaum, “Tanenbaum-Torvalds Debate Part II,” Vrije Universiteit, 2006. [Online]. Available: https://www.cs.vu.nl/~ast/reliable-os/ ↩
- 「Tanenbaum-Torvalds Debate Part II」（2006）：「I met him once. He is a pleasant fellow and very smart...」；「Microsoft paid a guy named Ken Brown to write a book saying Linus stole Linux from my MINIX 1 system」；Mac OS X「sort of microkernelish... Since all of it runs in kernel mode... it is not a true microkernel」；列出 QNX、Integrity、PikeOS、Symbian、L4Linux；「clearly I am not alone in seeing something in microkernels」。
[36]A. Toptygin, message to A. S. Tanenbaum published in “Comparison of Linux Code with MINIX Code,” Vrije Universiteit, 2004. [Online]. Available: https://www.cs.vu.nl/~ast/brown/codecomparison/ ↩
- Alexey Toptygin 的訊息：為 Ken Brown 做的顧問工作；結果於 5 月 17 日寄出；「my analysis found no evidence whatsoever that any code was copied one way or the other」；Brown 認為「clearly impossible for one person to write an OS」。
[37]A. Toptygin, “Source comparison of early linux and minix versions,” 2004. [Online]. Available: https://www.cs.vu.nl/~ast/brown/codecomparison/alexey.html ↩
- 比較了 Linux 0.01、0.11、0.12（及之後的版本）與 MINIX：「Only 4 actual similarities were found」；「the similarity was required by external factors (the C standard, the POSIX standard, the minix filesystem format)」。
[38]LinuxWorld News Desk, “Linus Torvalds Isn't the 'Father of Linux',” LinuxWorld, May 17, 2004, Internet Archive copy of Jun. 10, 2004. [Online]. Available: https://web.archive.org/web/20040610132547/http://www.linuxworld.com:80/story/44841.htm ↩
- Torvalds 寄給 LinuxWorld 的電子郵件，2004 年 5 月 17 日：「Ok, I admit it. I was just a front-man for the real fathers of Linux, the Tooth Fairy and Santa Claus」；芬蘭籍的聖誕老人在赫爾辛基大學有人脈。
[39]Association for Computing Machinery, “Andrew S Tanenbaum: ACM Software System Award 2023,” accessed Oct. 4, 2026. [Online]. Available: https://awards.acm.org/award_winners/tanenbaum_1309681 ↩
- ACM Software System Award 2023：「For MINIX, which influenced the teaching of Operating Systems principles to multiple generations of students and contributed to the design of widely used operating systems, including Linux.」
[40]J. Kara, “[PATCH v2] reiserfs: Deprecate reiserfs,” message on the reiserfs-devel list, Feb. 2022, archived by LWN. [Online]. Available: https://lwn.net/Articles/886142/ ↩
- Jan Kara（suse 的信箱），2022 年 2 月：「development has ceased quite some years ago... To reduce maintenance burden... schedule its removal to 2025」。
[41]Phoronix, “ReiserFS Has Been Deleted From The Linux Kernel,” accessed Oct. 4, 2026. [Online]. Available: https://www.phoronix.com/news/ReiserFS-Deleted-Linux-6.13 ↩
- ReiserFS 在 Linux 6.13 中移除；約 32,800 行。
[42]A. Chou, J. Yang, B. Chelf, S. Hallem and D. Engler, “An Empirical Study of Operating Systems Errors,” 18th ACM Symposium on Operating Systems Principles (SOSP), 2001. [Online]. Available: https://web.stanford.edu/~engler/metrics-sosp-01.pdf ↩
- 對 Linux 與 OpenBSD 的靜態分析；在 Linux 2.4.1 中「the vast majority of bugs are in drivers」；驅動程式的錯誤率是核心其餘部分的 3 到 7 倍；鎖檢查器中為「almost seven times higher」。
[43]M. M. Swift, B. N. Bershad and H. M. Levy, “Improving the Reliability of Commodity Operating Systems,” in Proc. 19th ACM Symp. on Operating Systems Principles (SOSP 2003), Bolton Landing, 2003. [Online]. Available: https://swift.sites.cs.wisc.edu/classes/cs736-fa06/papers/nooks.pdf ↩
- 「In Windows XP, for example, drivers account for 85% of recently reported failures」；「Nooks recovered automatically from 99% of the faults that caused Linux to crash」；2,000 次注入測試；Nooks 約 22,000 行，核心則是 240 萬行；驅動程式仍在 ring 0，以分頁表隔離在輕量保護域中。
[44]A. S. Tanenbaum, J. N. Herder and H. Bos, “Can We Make Operating Systems Reliable and Secure?,” IEEE Computer, vol. 39, no. 5, May 2006. [Online]. Available: https://www.cs.vu.nl/~ast/Publications/Papers/computer-2006a.pdf ↩
- Tanenbaum、Herder 與 Bos，IEEE Computer，2006 年 5 月：每 1000 行 6 到 16 個錯誤；「Using a conservative estimate of 6 bugs per 1000 lines of code the Linux kernel probably has something like 15,000 bugs; Windows has at least double that」。
- MINIX 3：「The clock driver shares the microkernel's address space, but is scheduled as a separate process. No other drivers run in kernel mode」；核心 4,000 行，檔案伺服器 4,500 行；「fixed-length messages using the rendezvous principle」；以位元圖實作的非同步通知。
[45]N. Palix, G. Thomas, S. Saha, C. Calvès, J. Lawall and G. Muller, “Faults in Linux: Ten Years Later,” in Proc. ASPLOS 2011, Newport Beach, 2011, pp. 305–318. [Online]. Available: https://coccinelle.gitlabpages.inria.fr/website/papers/asplos11.pdf ↩
- 研究範圍從 2.6.0 到 2.6.33；核心規模增加一倍以上，故障率下降；drivers 加上 staging 自 2.6.30 起佔程式碼的 57%；驅動程式的故障率「is now below that of other directories, such as arch (HAL) and fs (file systems)」，且自 2.6.19 起「right at the average」。
[46]A. Modine, “Linus calls Linux 'bloated and huge',” The Register, Sep. 22, 2009. [Online]. Available: https://www.theregister.com/2009/09/22/linus_torvalds_linux_bloated_huge/ ↩
- LinuxCon，2009/09/21（2009/09/22 刊出）：「We're getting bloated and huge. Yes, it's a problem」；「not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary」。
[47]J. N. Herder, H. Bos, B. Gras, P. Homburg and A. S. Tanenbaum, “Failure Resilience for Device Drivers,” in Proc. 37th IEEE/IFIP Int. Conf. on Dependable Systems and Networks (DSN 2007), Edinburgh, 2007, pp. 41–50. [Online]. Available: https://www.few.vu.nl/~ast/Publications/Papers/dsn-2007.pdf ↩
- 轉世伺服器的運作：service 工具程式帶著二進位檔、固定名稱、權限、heartbeat 週期與策略腳本；偵測結束、恐慌、CPU 或 MMU 例外，以及漏掉的 heartbeat；由檔案伺服器提出替換要求；data store 公布新的端點；重新發出待處理的區塊 I/O。
- 實驗：RTL8139 以 wget 下載 512 MB，checksum 正確，吞吐量損失 25% 到 1%；SATA 讀取 1 GB，損失 62% 到 7%，SHA-1 相同；在 Bochs 上的 DP8390，注入超過 12,500 次故障，347 次可偵測的當機，「The subsequent recovery was successful in 100% of the induced failures」；實體硬體上超過 99%；驅動程式函式庫改了五行。
- 限制：拜占庭故障、無聲的資料損毀、確定性錯誤、壞掉的硬體；「In general, end-to-end checksums are required to prevent silent」損毀。DMA：「To perform DMA safely a driver should first request the kernel to set up the I/O MMU」。
[48]MINIX 3 Wiki, “Frequently Asked Questions,” accessed Oct. 4, 2026. [Online]. Available: https://wiki.minix3.org/doku.php?id=faq ↩
- 「MINIX 3 is 5-10% slower」，比較對象是 MINIX 2（驅動程式在核心模式）；「our priority has been reliability, not performance」；BSD 授權。
[49]MINIX 3 Wiki, “Release notes 3.3.0,” accessed Oct. 4, 2026. [Online]. Available: https://wiki.minix3.org/doku.php?id=www:download:releasenotes-3.3.0 ↩
- 「In 2008, the European Research Council awarded Prof. Andrew S. Tanenbaum [...] an Advanced Grant of €2.5 million」；BSD 授權；PC 與 ARM；「Userland is largely compatible with NetBSD and runs thousands of NetBSD packages」。
[50]L. Torvalds, “Hybrid (micro)kernels,” Real World Technologies forum, May 9, 2006. [Online]. Available: https://www.realworldtech.com/forum/?threadid=65915&curpostid=65936 ↩
- Torvalds，2006/05/09：「The fundamental result of access space separation is that you can't share data structures... All your algorithms basically end up being distributed algorithms」；「As to the whole 'hybrid kernel' thing - it's just marketing」。
[51]G. Heiser and K. Elphinstone, “L4 Microkernels: The Lessons from 20 Years of Research and Deployment,” ACM Trans. on Computer Systems, vol. 34, no. 1, art. 1, Apr. 2016. [Online]. Available: https://trustworthy.systems/publications/nicta_full_text/8988.pdf ↩
- 「The typical cost for a one-way message was around 100 µs」；「a trend to move core services back into the kernel」。IPC 表格：1993 年的 L4 為 5 µs；2013 年的 seL4 在 3.4 GHz 的 Core i7 Haswell 上為 0.09 µs（301 個週期）；532 MHz 的 ARM11 上為 188 個週期。
- Qualcomm：「massive-scale commercial deployment when Qualcomm adopted it as a protected-mode real-time OS for the firmware of their wireless modem processors」；「running on the security processor of all recent Apple iOS devices」；註 2：「Total deployment is now in the billions」；PikeOS「certified for use in safety-critical avionics and deployed in aircraft and trains」。
- 驅動程式：「make all device drivers user-level processes」，計時器與中斷控制器除外；核心中未經驗證的驅動程式「would obliterate any guarantees」；「even 9,000 SLOC pushed the limits of what was achievable」。
[52]J. Liedtke, “On µ-Kernel Construction,” in Proc. 15th ACM Symp. on Operating Systems Principles (SOSP 1995), Copper Mountain, 1995. [Online]. Available: https://os.itec.kit.edu/downloads/publ_1995_liedtke_ukernel-construction.pdf ↩
- 最小化準則：「only if moving it outside the kernel, i.e. permitting competing implementations, would prevent the implementation of the system's required functionality」；「µ-kernels are inherently not portable. Instead, they are the processor dependent basis for portable operating systems」。
[53]A. S. Tanenbaum, “Followup statement on Ken Brown's motivation,” Vrije Universiteit, May 21, 2004. [Online]. Available: https://www.cs.vu.nl/~ast/brown/followup/ ↩
- 2004 年 5 月 21 日：「Microsoft claimed that Windows NT 3.51 was a microkernel. It wasn't. It wasn't even close. Even they dropped the claim with NT 4.0」；「I would easily give up 20% in performance for a system that was robust, reliable」。
[54]The Open Group, “UNIX 03: Apple Inc., macOS version 15.0 Sequoia on Apple silicon-based Mac computers,” registered Sep. 12, 2024. [Online]. Available: https://www.opengroup.org/openbrand/register/brand3710.htm ↩
- macOS 15.0 Sequoia 於 12-Sep-2024 登錄為 UNIX 03。
[55]Apple, “Apple Platform Security,” PDF guide, accessed Oct. 4, 2026. [Online]. Available: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf ↩
- 「The Secure Enclave Processor runs an Apple-customized version of the L4 microkernel.」
[56]Apple Inc., “XNU kernel,” README of the apple-oss-distributions/xnu repository, accessed Oct. 4, 2026. [Online]. Available: https://github.com/apple-oss-distributions/xnu ↩
- 「XNU is a hybrid kernel combining the Mach kernel developed at Carnegie Mellon University with components from FreeBSD and a C++ API for writing drivers called IOKit」；「osfmk - Mach kernel based subsystems」；「bsd - BSD subsystems code」；在 x86_64 與 ARM64 上執行。
[57]Apple Inc., “DriverKit,” Apple Developer Documentation, accessed Oct. 4, 2026. [Online]. Available: https://developer.apple.com/documentation/driverkit ↩
- 「Develop device drivers that run in user space.」；「The drivers you build with DriverKit run in user space, rather than as kernel extensions, which improves system stability and security」。
[58]Apple Inc., “Deprecated Kernel Extensions and System Extension Alternatives,” Apple Developer Support, accessed Oct. 4, 2026. [Online]. Available: https://developer.apple.com/support/kernel-extensions/ ↩
- 核心擴充已被棄用；「Starting with macOS Big Sur, macOS releases no longer load kernel extensions that use deprecated KPIs by default」。
[59]FreeBSD Project, “FreeBSD 4.0 Announcement,” Mar. 14, 2000. [Online]. Available: https://www.freebsd.org/releases/4.0R/announce/ ↩
- FreeBSD 4.0-RELEASE 的公告，2000 年 3 月 14 日。
[60]P.-H. Kamp and R. N. M. Watson, “Jails: Confining the omnipotent root,” 2nd International SANE Conference, 2000. [Online]. Available: https://papers.freebsd.org/2000/phk-jails/ ↩
- Kamp 與 Watson，2000：jail「provides the ability to partition the operating system environment, while maintaining the simplicity of the UNIX 'root' model」；最普遍的用途是「providing virtual machine services in Internet Service Provider environments」。
[61]M. Kerrisk (ed.), “mount_namespaces(7),” Linux manual page, accessed Oct. 4, 2026. [Online]. Available: https://man7.org/linux/man-pages/man7/mount_namespaces.7.html ↩
- HISTORY 一節：mount namespace 出現在 Linux 2.4.19。
[62]kernel.org, “Index of /pub/linux/kernel/v2.6/,” accessed Oct. 4, 2026. [Online]. Available: https://cdn.kernel.org/pub/linux/kernel/v2.6/ ↩
- linux-2.6.24.tar.gz 的日期為 24-Jan-2008。
[63]M. Kerrisk (ed.), “namespaces(7),” Linux manual page, accessed Oct. 4, 2026. [Online]. Available: https://man7.org/linux/man-pages/man7/namespaces.7.html ↩
- 「since Linux 3.8, no privilege is required to create a user namespace」。
[64]FreeBSD Documentation Project, “Chapter 23. The Z File System (ZFS),” FreeBSD Handbook, accessed Oct. 4, 2026. [Online]. Available: https://docs.freebsd.org/en/books/handbook/zfs/ ↩
- ZFS「Originally developed at Sun Microsystems」。
[65]FreeBSD Project, “FreeBSD 7.0-RELEASE Release Notes,” 2008. [Online]. Available: https://www.freebsd.org/releases/7.0R/relnotes/ ↩
- 「Support for Sun's ZFS has been added.」
[66]FreeBSD Project, “FreeBSD 7.0-RELEASE Announcement,” Feb. 27, 2008. [Online]. Available: https://www.freebsd.org/releases/7.0R/announce/ ↩
- FreeBSD 7.0-RELEASE 的公告，2008 年 2 月 27 日。
[67]B. M. Cantrill, M. W. Shapiro and A. H. Leventhal, “Dynamic Instrumentation of Production Systems,” USENIX Annual Technical Conference, Boston, Jun. 2004. [Online]. Available: https://www.usenix.org/legacy/event/usenix04/tech/general/full_papers/cantrill/cantrill.pdf ↩
- Cantrill、Shapiro 與 Leventhal（Sun 的 Solaris Kernel Development），USENIX 2004：DTrace 以「in a unified and absolutely safe fashion」對使用者程式與核心進行插樁；「zero probe effect」。
[68]FreeBSD Project, “FreeBSD 7.1-RELEASE Release Notes,” 2009. [Online]. Available: https://www.freebsd.org/releases/7.1R/relnotes/ ↩
- DTrace 與 dtrace(1)「have been imported from OpenSolaris」。
[69]FreeBSD Project, “FreeBSD 7.1-RELEASE Announcement,” Jan. 4, 2009. [Online]. Available: https://www.freebsd.org/releases/7.1R/announce/ ↩
- FreeBSD 7.1-RELEASE 的公告，2009 年 1 月 4 日。
[70]FreeBSD Documentation Project, “DTrace,” FreeBSD Handbook, accessed Oct. 4, 2026. [Online]. Available: https://docs.freebsd.org/en/books/handbook/dtrace/ ↩
- 「DTrace... was developed by Sun™ as a tool for locating performance bottlenecks in production and pre-production systems.」
[71]Kernel Newbies, “Linux 3.18,” accessed Oct. 4, 2026. [Online]. Available: https://kernelnewbies.org/Linux_3.18 ↩
- 2014 年 12 月 7 日發布；bpf() 系統呼叫：「eBPF programs are similar to kernel modules. They are loaded by the user process and automatically unloaded when process exits. [...] eBPF verifier statically determines that the program terminates and is safe to execute」。
[72]A. S. Tanenbaum, “Rebuttal to Ken Brown,” Vrije Universiteit, Jun. 6, 2004. [Online]. Available: https://www.cs.vu.nl/~ast/brown/rebuttal/ ↩
- 2004 年 6 月 6 日：David Cutler，「one of the principal architects of the operating system for the DEC VAX, VMS」，受 Microsoft 聘請領導 Windows NT；「Operating system designers of Cutler's quality are few and far between」。
[73]Microsoft, “MS Windows NT Kernel-mode User and GDI White Paper,” TechNet, archived on Microsoft Learn (Previous Versions), accessed Oct. 4, 2026. [Online]. Available: https://learn.microsoft.com/en-us/previous-versions/cc750820(v=technet.10) ↩
- 分層：HAL、「microkernel」（中斷、DPC、排程、同步）與 Executive；「From the start the Windows NT architecture has fallen squarely into the modified microkernel or macrokernel camp」；記憶體管理器、快取、檔案系統、物件與安全、網路協定與網路伺服器以及行程，從第一版起就都在核心模式中；Win32 是特權的「application」；NT 3.51 中 USER 與 GDI 在 CSRSS.EXE 中。
- NT 4.0 改變的原因：64K 的共享緩衝區、情境切換；在 Pentium 100 上，主從式轉換「in the order of 60-70 m seconds」，進入核心模式則是「4 to 5 m seconds」（頁面把「µ」顯示成「m」；我把它讀作微秒，這是唯一符合數量級的讀法）；working set 節省 256K 到 1 MB；PowerPoint 快 15% 到 20%；圖形驅動程式完全在核心模式中。
- 「No commercial operating system is based on a pure microkernel design. The reason is simple: the pure microkernel design is commercially impractical because it is too computationally expensive」；「What is the practical difference [...] between an operating system that crashes from time to time and one that continues running but loses all access to persistent storage?」；NT 3.51 的 GDI 失敗時：「a system that appears to have crashed」。
[74]Microsoft, “Overview of UMDF,” Windows drivers, Microsoft Learn, updated Dec. 15, 2021. [Online]. Available: https://learn.microsoft.com/en-us/windows-hardware/drivers/wdf/overview-of-the-umdf ↩
- 「UMDF drivers abstract hardware functionality, run in the user-mode environment」；宿主行程、driver manager 與 reflector；「File system drivers, display drivers (...), and print drivers cannot be UMDF drivers」。
[75]The Linux Kernel Archives, “linux-7.2.tar.xz,” Aug. 17, 2026 (file and line counts by the author). [Online]. Available: https://cdn.kernel.org/pub/linux/kernel/v7.x/ ↩
- 我在 2026 年 10 月 4 日根據官方 tarball 所做的計算（索引上的日期：17-Aug-2026）：65,637 個 .c/.h/.S/.rs 檔案，37,730,727 行；drivers/ 26,034,547 行（69.0%）；arch/ 6.7%；sound/ 4.4%；fs/ 4.3%；kernel/ 1.5%；mm/ 0.6%；.rs 檔案 182,584 行（約 0.5%）。同一天，kernel.org 列出的穩定版是 7.2.9（2026 年 10 月 3 日），主線是 7.3-rc6。
[76]Kernel Newbies, “Linux 2.6.14,” accessed Oct. 4, 2026. [Online]. Available: https://kernelnewbies.org/Linux_2_6_14 ↩
- 2005 年 10 月 27 日發布；FUSE：「Allows to implement a fully functional filesystem in a userspace program」。
[77]H.-J. Koch, “The Userspace I/O HOWTO,” Linux kernel documentation, 2006. [Online]. Available: https://docs.kernel.org/driver-api/uio-howto.html ↩
- UIO（2006-12-11 的文件）：「bugs in your driver won't crash the kernel」；「updates of your driver can take place without recompiling the kernel」；網路、序列埠或 USB「are no candidates for an UIO driver」。
[78]Kernel Newbies, “Linux 3.6,” accessed Oct. 4, 2026. [Online]. Available: https://kernelnewbies.org/Linux_3.6 ↩
- 2012 年 9 月 30 日發布，包含 VFIO。
[79]The Linux Kernel documentation, “eBPF verifier,” accessed Oct. 4, 2026. [Online]. Available: https://docs.kernel.org/bpf/verifier.html ↩
- 「First step does DAG check to disallow loops and other CFG validation」；「Second step starts from the first insn and descends all possible paths. It simulates execution of every insn and observes the state change of registers and stack」。
[80]Kernel Newbies, “Linux 6.12,” accessed Oct. 4, 2026. [Online]. Available: https://kernelnewbies.org/Linux_6.12 ↩
- 2024 年 11 月 17 日發布，包含 sched_ext。
[81]J. Corbet, “A first look at Rust in the 6.1 kernel,” LWN.net, Oct. 13, 2022. [Online]. Available: https://lwn.net/Articles/910762/ ↩
- Rust 進入 6.1；「No system with a production 6.1 kernel will be running any Rust code」。
[82]J. Corbet, “The (successful) end of the kernel Rust experiment,” LWN.net, Dec. 10, 2025. [Online]. Available: https://lwn.net/Articles/1049831/ ↩
- 2025 年 Maintainers Summit 的共識：核心中的 Rust 不再是實驗性的，而是核心且永久的一部分；「experimental」標籤將被移除。（原句含有破折號；本文以轉述呈現。）
[83]J. Corbet, “The state of the kernel Rust experiment,” LWN.net, Dec. 13, 2025. [Online]. Available: https://lwn.net/Articles/1050174/ ↩
- Ojeda：Nova 驅動程式已有部分進入主線；「Android binder driver was merged for 6.18」；搭載 6.12 核心的 Android 16 出貨時帶有以 Rust 撰寫的 ashmem 模組：「So there are millions of real devices running kernels with Rust code now」。
- Kroah-Hartman：Rust 驅動程式「are indeed proving to be far safer than those written in C」；「no such CVE has yet been issued」。Airlie：DRM 要求新驅動程式使用 Rust，是「about a year away」的事。Torvalds：「after nearly five years, the time had come」。
[84]G. Klein et al., “seL4: Formal Verification of an OS Kernel,” 22nd ACM Symposium on Operating Systems Principles (SOSP), Oct. 2009. [Online]. Available: https://www.sigops.org/s/conferences/sosp/2009/papers/klein-sosp09.pdf ↩
- seL4「comprises 8,700 lines of C code and 600 lines of assembler」；「the first formal proof of functional correctness of a complete, general-purpose operating-system kernel」；「With truly small kernels it becomes possible... to guarantee the absence of bugs」；NICTA 與 UNSW。
- 證明有 200,000 行 Isabelle 腳本；「We have proved over 150 invariants」；核心的總成本為 2.2 py，包括 Haskell；證明「in total about 20 py」，seL4 專屬的部分為「11 py」；EAL6 每行 1 萬美元的經驗法則會得出「$87M for seL4」；第二階段證明找到的錯誤「mainly typos, misreading the specification, or failing to update all relevant code parts」，足以「crash the kernel or create security vulnerabilities」。
[85]J. Edge, “Replacing x86 firmware with Linux and Go,” LWN.net, Nov. 20, 2017. [Online]. Available: https://lwn.net/Articles/738649/ ↩
- Jake Edge，2017/11/20，關於 Ronald Minnich（Google）在布拉格 ELCE 2017 的演講：「Ring -3... It runs MINIX 3 and is where the ME runs」；「year of MINIX 3 on the desktop」；IPv4/IPv6 協定堆疊、檔案系統、驅動程式、網頁伺服器；「can reimage the system even if the power is turned off」。
[86]M. Ermolov and M. Goryachy, “How to Hack a Turned-Off Computer, or Running Unsigned Code in Intel Management Engine,” Black Hat Europe 2017. [Online]. Available: https://www.blackhat.com/eu-17/briefings.html#how-to-hack-a-turned-off-computer-or-running-unsigned-code-in-intel-management-engine ↩
- Mark Ermolov 與 Maxim Goryachy 在 Black Hat Europe 2017 的演講「How to Hack a Turned-Off Computer, or Running Unsigned Code in Intel Management Engine」（只用來證明這場演講存在及其標題）。
[87]MINIX 3, “What Is MINIX 3?,” accessed Oct. 4, 2026. [Online]. Available: https://www.minix3.org/ ↩
- 「designed to be highly reliable, flexible, and secure」；「a tiny microkernel running in kernel mode with the rest of the operating system running as a number of isolated, protected, processes in user mode」。
[88]MINIX 3 Wiki, “Features,” accessed Oct. 4, 2026. [Online]. Available: https://wiki.minix3.org/doku.php?id=www:documentation:features ↩
- 「Tiny microkernel that runs in kernel mode」；「Each device driver is a separate user-mode process」；「Reincarnation server can reload failed drivers」。
[89]Stichting MINIX Research Foundation, “minix: Official MINIX sources,” GitHub repository, tag v3.3.0 and commit 4db99f4 of Nov. 14, 2018, accessed Oct. 4, 2026. [Online]. Available: https://github.com/Stichting-MINIX-Research-Foundation/minix ↩
- 最新的 tag 是 v3.3.0；主分支的最後一個提交：4db99f4，2018/11/14 07:26 UTC（BRT 04:26），「Remove building with NOCRYPTO option」。
[90]The kernel development community, “CPU Architectures,” Linux kernel documentation, accessed Oct. 4, 2026. [Online]. Available: https://docs.kernel.org/arch/index.html ↩
- 有文件的架構清單：ARC、ARM、ARM64、LoongArch、m68k、MIPS、Nios II、OpenRISC、PA-RISC、powerpc、RISC-V、s390、SuperH、Sparc、x86、Xtensa（16 種）。

經查證但未採用的資料

Samizdat 與 AdTI 的資金來源：微軟付錢給 Brown 的說法，在本文中只作為 Tanenbaum 的主張出現 [35]；我沒有使用次級來源（Wikipedia、Linux.com）把它當作事實陳述。
QNX：查閱了官方文件（QNX SDP 8.0，「The Philosophy of the QNX OS」），但可存取的頁面沒有描述使用者空間的驅動程式；本文只引用 Tanenbaum 對 QNX 的說法。
GNU Hurd：gnu.org 封鎖了直接存取（403）；我使用 Internet Archive 的副本。
Just for Fun（L. Torvalds 與 D. Diamond，2001）：我找過這本書，想引用關於 1991 年的段落，但 Internet Archive 只提供限制借閱，站內搜尋也失敗了。我沒有引用這本書。作為第一手的回憶，我使用的是 Torvalds 本人在 1992 年 7 月寫的文字（「LINUX's History」）[10]。
Linux 0.01 與 Linux 7.2 的行數是我自己算的，於 2026 年 10 月 4 日根據 kernel.org 的官方 tarball 計算（.c、.h、.s/.S 與 .rs 檔案，實體行數，不扣除註解）。其他工具（cloc、sloccount）得出的數字較小。
NT 白皮書：Microsoft Learn 的頁面在原文使用 µ 符號的地方顯示為「m seconds」。我把它當作微秒處理。
QNX：我無法下載能支持獨立論斷的架構文件；QNX 只透過 Tanenbaum 以及 Heiser 與 Elphinstone 的話出現。
osr2006.pdf（Tanenbaum 發表於 ACM SIGOPS OSR 的文章，2006）是沒有文字層的掃描 PDF，沒有使用。