MINIX 3: a Modular, Self-Healing POSIX-compatible Operating System

MINIX 3: a Modular, Self-Healing POSIX-compatible Operating System — FOSDEM

FOSDEM

AI-assisted summary of MINIX 3: a Modular, Self-Healing POSIX-compatible Operating System — original source. Check the original for full context.

Source published:

Key ideas

  • Andrew Tanenbaum highlights that 85% of Windows crashes stem from third-party drivers, which represent about 70% of typical operating system codebases and suffer from bug densities three to seven times higher than core kernel code. (8:04)
  • MINIX 3 achieves high reliability by shrinking its microkernel to roughly 6,000 lines of code, isolating drivers, file systems, and virtual memory into unprivileged user-space processes. (9:58)
  • In fault-injection benchmarks modifying binary instructions in real time, MINIX 3 survived 2.5 million test iterations and 18,000 driver crashes without a single operating system failure. (30:53)
  • Microkernel message-passing overhead incurs roughly 500 nanoseconds per message, translating to a modest 5% to 10% performance penalty that Tanenbaum argues average consumers would gladly trade for complete system stability. (44:48)

Detailed notes

## Background Published on YouTube by FOSDEM on February 14, 2010, this keynote features Andrew Tanenbaum presenting the architecture and goals of MINIX 3. The video description highlights MINIX's history since 1987, its relation to offshoots like Linux, and MINIX 3's focus on achieving appliance-grade reliability by automatically detecting and replacing crashed device drivers and servers without human intervention.

## TL;DR Andrew Tanenbaum introduces MINIX 3, a modular, POSIX-compliant microkernel operating system engineered to make computers as dependable as everyday appliances. He contrasts modern bloated monolithic kernels—where bug-dense third-party device drivers account for the majority of crashes—against MINIX 3's compact, 6,000-line microkernel that confines drivers, servers, and file systems to isolated user-space processes governed by the principle of least authority. Leveraging components like the Reincarnation Server, Data Store, and fine-grained memory grants, the system detects failures via heartbeats and transparently restarts crashed drivers without affecting running user programs or bringing down the kernel. Tanenbaum also presents empirical fault-injection testing results, reviews MINIX 3's growing software catalog, and discusses ongoing research in live patching, multicore scaling, and the deliberate trade-off of modest IPC latency for crash-proof stability.

## Atmosphere & style Tanenbaum delivers a sharp, dryly humorous, and accessible talk that balances rigorous computer science with wry, seasoned observations on the state of commercial software. His delivery is conversational yet authoritative, poking fun at industry tolerance for constant reboots and software bloat while drawing steady chuckles and knowing nods from the audience of open-source developers. Watching the lecture feels like attending an engaging masterclass with a computing pioneer who is completely unapologetic about challenging entrenched monolithic design dogma in pursuit of genuine fault tolerance.

## Bulletin - [08:04](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=484s) Andrew Tanenbaum highlights that 85% of Windows crashes stem from third-party drivers, which represent about 70% of typical operating system codebases and suffer from bug densities three to seven times higher than core kernel code. - [09:58](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=598s) MINIX 3 achieves high reliability by shrinking its microkernel to roughly 6,000 lines of code, isolating drivers, file systems, and virtual memory into unprivileged user-space processes. - [30:53](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1853s) In fault-injection benchmarks modifying binary instructions in real time, MINIX 3 survived 2.5 million test iterations and 18,000 driver crashes without a single operating system failure. - [44:48](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2688s) Microkernel message-passing overhead incurs roughly 500 nanoseconds per message, translating to a modest 5% to 10% performance penalty that Tanenbaum argues average consumers would gladly trade for complete system stability.

## Key takeaways - [05:33](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=333s) Monolithic operating systems like Linux and Windows have grown excessively bloated, leading to high bug rates that make whole-system crashes inevitable. - [04:15](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=255s) The computer industry has normalized routine crashes, whereas consumer appliance engineering and automotive standards demand near-zero defect rates. - [08:04](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=484s) Device drivers are responsible for the vast majority of operating system failures, exhibiting significantly higher defect densities than core kernel subsystems. - [09:58](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=598s) MINIX 3 isolates device drivers, memory management, and file systems as unprivileged user-space processes running under strict hardware MMU protection. - [11:57](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=717s) The Principle of Least Authority is enforced through fine-grained kernel capability bitmaps controlling permitted IPC calls, target processes, and I/O port ranges. - [14:54](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=894s) Microkernel IPC overhead adds only microseconds to operations, which is functionally negligible compared to mechanical disk seek latencies. - [18:56](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1136s) The Reincarnation Server periodically pings child servers and drivers, killing hung processes and transparently spawning replacements to enable self-healing. - [21:19](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1279s) To prevent deadlocks during storage failures, MINIX 3 caches the disk driver binary in RAM and seamlessly replays in-flight requests to recovered instances. - [24:16](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1456s) Dynamic memory allocation is excluded from the microkernel in favor of compile-time static arrays, eliminating memory leaks and dangling pointer vulnerabilities. - [28:59](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1739s) A grant table mechanism enables fine-grained, kernel-validated memory copies between isolated user-space processes without supervisor privilege escalation. - [30:53](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1853s) Fault-injection testing with over 800,000 injected faults per driver proved that MINIX 3 can reliably survive driver crashes and infinite loops without dropping the OS. - [33:11](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1991s) Despite running microkernel infrastructure, MINIX 3 provides an established Unix ecosystem supporting over 600 packages including X11, GCC, Apache, and standard shells. - [40:26](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2426s) Active research focuses on hot-swapping running OS components via live updates and mapping decoupled system servers directly onto dedicated multicore processors. - [48:19](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2899s) The minimal Trusted Computing Base of MINIX 3 spans roughly 20,000 lines of code across the microkernel, Reincarnation Server, and Data Store. - [53:00](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=3180s) Automated recovery relies on the observation that the vast majority of driver bugs are transient race conditions rather than deterministic algorithmic failures.

## Detailed walkthrough ### [00:20](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=20s) Introduction and the Strange History of MINIX

Andrew Tanenbaum opens his address by warning the audience that he has a chronic tendency to talk too long, which has forced him to take preventative measures. He mentions that he is feeling “as sick as a dog,” but leaning on his theater background, he insists that “the show must go on” and promises to give it his best shot. While he introduces himself as the head of the project, he makes sure to acknowledge that MINIX 3 is the work of an entire team of contributors whose names could not all fit onto his introductory slide.

```mermaid flowchart TD accTitle: Evolution of UNIX and MINIX accDescr: Chronological timeline of UNIX licensing and the creation of MINIX editions. subgraph UNIX["UNIX Lineage"] V6["1975: Bell Labs releases UNIX V6"] --> Lions["John Lions Commentary Book"] Lions --> V7["1979: AT&T UNIX V7<br>(Strict license forbids teaching)"] end subgraph MINIX["MINIX Lineage"] V7 -.->|"Tanenbaum writes clone (1984)"| M1["1987: MINIX 1 released + textbook"] M1 --> M2["1997: MINIX 2nd Edition"] M2 --> M3["2004-2008: MINIX 3 research & ERC grant"] end ```

Turning to what he characterizes as the “somewhat strange history” of MINIX, Tanenbaum recounts how the system was born out of corporate licensing decisions. In 1975, Bell Labs released UNIX Version 6, the first version widely distributed outside the laboratories. It became an instant hit, largely popularized in academia through a classic explanatory book written by Professor John Lions of the University of New South Wales. However, when AT&T rolled out Version 7 in 1979, the company included a restrictive clause in the licensing contract that explicitly banned teaching the code in university courses. Reflecting sarcastically on AT&T’s effort to keep its software entirely secret, Tanenbaum remarks, “That was a brilliant move on AT&T’s marketing department, that’s why UNIX rules the world now.”

Faced with this contractual ban while teaching an operating systems course in 1984, Tanenbaum decided to write his own clone of UNIX from scratch. He acknowledged that building an entire operating system was probably a crazy undertaking, but he finished the project in 1987, published a textbook covering its internals, and released the code publicly to bypass AT&T’s restrictions. A second edition followed a decade later. Around 2004, the focus shifted toward serious research on building highly dependable, reliable operating systems, ultimately laying the foundation for MINIX 3.

[02:40](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=160s) The ERC Grant and Software Product Liability

The trajectory of the MINIX project shifted fundamentally in 2008 when Tanenbaum received an Advanced Grant from the European Research Council (ERC) worth 2.5 million euros. Tanenbaum notes that securing that sum of money indicated the European Union recognized that modern software reliability is severely lacking and considered building a genuinely dependable alternative a problem worth substantial funding.

The grant arrived alongside broader legal discussions taking place within the EU throughout 2009 concerning whether commercial software ought to be held accountable under conventional product liability laws. Tanenbaum illustrates the double standard software enjoys by comparing it to manufacturing. If an automaker or a tire manufacturer produces ten million tires and a single tire explodes, the company cannot simply dismiss the failure by telling customers that tires explode occasionally and they should just learn to live with it. Yet when software fails, vendors routinely shrug it off as normal behavior.

Tanenbaum frequently addressed this point in media interviews, noting how legal frameworks could force a radical change across the entire industry. As he frames the regulatory confrontation: “Suppose they go to Microsoft and say you know, ‘By law your software has to work,’ and they say, ‘It can’t be done, you know, you can’t make a law saying pigs can fly,’ and if the EU could say, ‘Well, Tanenbaum did it, why don’t you do it that way?’ then they would say, ‘Well, we don’t want to.’ That’s not as strong as ‘It can’t be done,’ and so you know, that’s sort of direction we’re going.”

- The European Research Council awarded €2.5 million specifically to fund research into highly reliable operating system design. - Physical manufacturing standards (such as tire safety) require near-zero defect rates under liability laws, whereas commercial software is legally exempt from failure liabilities.

[04:15](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=255s) Software Reliability: The Reset Button vs. The TV and Car Analogy

Tanenbaum contrasts the engineer’s complacency with software defects against the reasonable expectations of ordinary consumers. Inside hacker culture, crashes are accepted with flippant resignation, rooted in the prevailing attitude that “if God had wanted software to be reliable he wouldn’t have created reset buttons.” To an everyday user like one's grandmother, this mindset makes no sense; she expects a computer to operate like a television set, where you buy it, plug it into the wall, and count on it working flawlessly for the next ten years. While technical users justify instabilities because software environments churn and change every 45 nanoseconds, the average user just wants a dependable appliance.

To expose the absurdity of accepting quarterly reboots, Tanenbaum offers an analogy involving an automobile. If a driver’s car suddenly died on the road once every three months for no apparent reason, forcing them to turn off the ignition, pull out the key, step out, pop the hood, slam it shut, and get back behind the wheel to start moving again, nobody would accept the manufacturer dismissing the defect as a minor ten-second inconvenience. Yet computer users routinely treat a computer that crashes only once every three months as remarkably reliable. Tanenbaum emphasizes that while tech-savvy users have grown numb to software failure, normal users have not, raising the central research question: can systems software be built to satisfy grandma's expectations?

[05:33](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=333s) Software Bloat, Modern Hardware, and Aircraft Carrier Modularity

The primary source of system instability, Tanenbaum argues, is unchecked software bloat across Windows, Linux, and other mainstream environments. To illustrate that this is not partisan critique, he cites an interview in PC Pro magazine featuring Linus Torvalds admitting that the Linux kernel had become bloated and huge. Tanenbaum highlights the irony: “This is Linus saying this, this is not Bill Gates, okay? So you know, Bill Gates said Linux is bloated and huge, I, you know, okay, but Linus is saying—if Linus had said Windows is bloated and huge, okay, but even Linus thinks that, you know, Linux has got out of hand.” He observes that while nobody on Earth understands the entirety of Windows, Linus might be the only person who still understands the entire Linux kernel, if even he does.

```mermaid flowchart TD accTitle: System Separation Comparison accDescr: Comparing an unisolated monolithic kernel with the fault isolation of an aircraft carrier. subgraph Monolithic["Monolithic Kernel Fault Propagation"] D1["Obscure Printer Driver Fault"] -->|"Memory Corruption"| K1["Entire Kernel Panics / BSOD"] end subgraph Modular["Aircraft Carrier Modularity"] T["Sanitation System (Toilets)"] M["Weapons System (Missiles)"] T -.-x|"Fully Isolated<br>(No cross-system interference)"| M end ```

The growth of software size directly contradicts the explosion of hardware power. Tanenbaum points to his lightweight notebook, which possesses 5,000 times the computing power, 1,000 times the RAM, 1,000 times the disk capacity, and 1/50th the price of the PDP-11 he originally worked on. Despite this monumental hardware leap, the ancient machine booted in five seconds flat, whereas the notebook takes roughly four minutes. In his view, developers have squandered endless CPU cycles, RAM, and bandwidth by piling on layers of bloated, useless code.

To break this cycle, future operating systems must embrace the structural modularity seen in other complex engineering disciplines. Complex human artifacts like aircraft carriers dwarf operating systems in physical complexity, yet their subsystems are strictly compartmentalized: - Designers guarantee that plumbing failures remain strictly isolated from defense systems: “If a toilet gets clogged on the aircraft carrier, it doesn’t begin firing missiles, okay? Because the toilet system and the aircraft system, the missile system, are separated very much.” - Conversely, an alert for an incoming hostile missile does not trigger involuntary flushing in the ship's restrooms. - Because systems have grown too complicated for single individuals to trace, operating systems must incorporate self-healing mechanisms that can automatically repair damaged components without human intervention.

[08:04](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=484s) Microkernels vs. Monolithic Kernels: Bug Density and Driver Faults

Tanenbaum restates his longstanding architectural commitment to microkernels over monolithic designs. While industrial microkernel systems like L4, QNX, PikeOS, and Green Hills Software keep their trusted computing base between 5,000 and 10,000 lines of code—with MINIX 3 standing at roughly 6,000 lines—monolithic operating systems have ballooned out of proportion. The Linux kernel spans over 6 million lines of code, and Microsoft Windows exceeds 100 million lines across its entire stack.

Software engineering studies within commercial industries reveal an inevitable baseline error rate ranging from 5 to 10 bugs per thousand lines of code (KLOC), even under strict automated bug tracking and quality-assurance regimens. High-quality open-source projects, such as FreeBSD, achieve an exceptional standard of roughly 3 bugs per KLOC. Applied across different codebases, the resulting difference in raw defect counts is staggering: - A 6,000-line MINIX 3 kernel would mathematically harbor around 18 bugs. - A 6-million-line monolithic kernel like Linux would contain an estimated 18,000 bugs.

Even granting that many bugs represent non-critical defects like minor message typos, Tanenbaum argues that a pool of 18,000 defects inevitably contains severe vulnerabilities and crash-inducing errors. The danger is magnified heavily by device drivers. He cites a study conducted at Stanford University demonstrating that Linux device drivers have bug rates 3 to 7 times higher than the core kernel code. Developers eagerly scrutinize high-profile subsystems like core virtual memory management algorithms, but virtually nobody wants to review "100 pages of yuck" inside an obscure printer driver. Because drivers constitute roughly 70 percent of an operating system's codebase, running them in kernel space guarantees chronic instability. Microsoft's internal telemetry confirms this exact hazard, showing that 85 percent of all Windows crashes stem from third-party drivers written by external hardware vendors rushing components to market rather than errors in Microsoft’s core kernel code.

[09:58](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=598s) Modular User-Mode Architecture and the Microkernel

To isolate failures, an operating system must adopt a modular design surrounded by strong protective barriers. In MINIX 3, the operating system executes almost entirely as a collection of independent user-level processes rather than a monolithic supervisor blob. At the very foundation sits the microkernel, comprising merely about 6,000 lines of code. The microkernel’s scope is intentionally stripped down: it handles raw hardware interrupts, low-level inter-process communication (IPC), CPU scheduling, the system clock, and an internal facility called the system task (which has progressively been decoupled from the kernel proper). The microkernel possesses only a rudimentary understanding of processes; it does not implement high-level process policy, acting only when an external manager instructs it to execute a specific task.

Directly above the microkernel, device drivers—including the disk, terminal, network, and printer drivers—run as independent user-mode processes under hardware memory protection with the MMU active. Above the drivers sits another tier of user-mode system servers containing the file system, process manager, and virtual memory manager. At the highest level run standard application binaries like the shell or the `make` utility. From the microkernel's point of view, system components are completely indistinguishable from ordinary user programs. As Andrew Tanenbaum observes regarding system abstractions: “It's that way for many Unix people how could the file system be a user program but it is and the virtual memory manager is a user program and so on.”

```mermaid flowchart TD accTitle: MINIX 3 Layered Architecture accDescr: Architectural layers of MINIX 3 showing user programs, servers, drivers, and the microkernel.

subgraph UserSpace["User Mode (Protected / Non-privileged)"] direction TB subgraph Apps["Applications"] Shell["Shell / User Programs / make"] end subgraph Servers["System Servers"] FS["File Server"] PM["Process Manager"] VM["VM Server"] DS["Data Store / Reincarnation"] end subgraph Drivers["Device Drivers"] Disk["Disk Driver"] Net["Network Driver"] Audio["Audio Driver"] end end

subgraph KernelSpace["Kernel Mode"] MK["Microkernel (~6,000 LOC)\nInterrupts • Scheduling • IPC • Clock"] end

Apps -->|"POSIX calls"| Servers Servers <-->|"IPC Messages"| Drivers Servers -->|"Kernel calls"| MK Drivers -->|"Kernel calls"| MK ```

- The MINIX 3 microkernel consists of roughly 6,000 lines of C and assembler. - Device drivers run entirely unprivileged in protected mode with active memory management hardware. - Unlike traditional monolithic kernels, critical subsystems such as virtual memory and the file system are strictly isolated user-space processes.

---

[11:57](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=717s) Principle of Least Authority and Driver Isolation

Interaction between system components and the core relies on roughly 35 specialized internal kernel calls, which are entirely separate from standard POSIX library calls exposed to user applications. Because drivers and servers live in isolated address spaces, they are completely barred from executing privileged CPU instructions, modifying hardware registers, or touching I/O ports directly. If a storage driver needs to read or write an I/O port, or if a file server needs to deliver a cached data block across memory boundaries into a client application's address space, it cannot perform the transfer itself; it must explicitly petition the kernel to do the work on its behalf.

Every component is governed by the Principle of Least Authority (POLA). The kernel enforces fine-grained capability bitmaps for each driver and server, dictating precisely which kernel calls may be invoked, which target processes may receive IPC messages, and which specific I/O ports may be accessed. Furthermore, all driver processes are time-sliced, ensuring that a driver caught in an infinite loop cannot freeze the computer. Tanenbaum notes the dramatic change in status for hardware drivers: “It's a humbling experience for the disc driver not to be able to touch the disc that's life.”

This strict partitioning produces substantial security advantages. For example, if an attacker exploits a software bug or injects malicious code into the audio driver, the breach is completely contained. The compromised audio driver can produce bizarre noises through the sound hardware, but it cannot touch the disk controller, alter kernel memory, or tamper with foreign address spaces because the microkernel instantly rejects any unauthorized I/O requests.

- The system implements approximately 35 low-level internal kernel calls for administrative tasks such as DMA mapping, copying across address spaces, and setting interrupt vectors. - Per-process permission bitmaps specify authorized kernel calls, permitted IPC destination processes, and accessible physical I/O port ranges. - Time-slicing prevents rogue or malfunctioning drivers from starving the system of CPU resources.

---

[14:54](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=894s) System Servers and File System Message Flow

User-mode servers provide standard operating system facilities: one or more file servers, a process manager, a virtual memory manager, an X server, network servers, an information server, a data store, and a reincarnation server. The operation of the file system illustrates how message-passing IPC replaces traditional monolithic in-kernel function calls. When a user process executes a POSIX `read(fd, buffer, nbytes)` request, the C library formats and transmits an IPC message to the file server. In a cache-hit scenario, the file server finds the data block in its local cache, requests the kernel's system task to copy the bytes into the user's buffer, and transmits an IPC reply back to the user application—a four-message round trip taking approximately 500 nanoseconds per message.

When a cache miss occurs, the file server messages the disk driver to retrieve the missing sector. The disk driver asks the kernel's system task to issue commands to the physical I/O ports, blocks awaiting an interrupt notification, checks the hardware controller's status registers via another kernel request, and replies to the file server once the transfer finishes. Finally, the file server instructs the system task to copy the block into the application's address space and answers the user process. While this missing-block sequence requires about nine distinct IPC messages—incurring roughly 4.5 microseconds of IPC overhead—Tanenbaum points out that spinning hardware latencies dwarf this microkernel cost: “we've actually read a block from the disc that takes several milliseconds okay so another five microseconds more or less really isn't a central issue here.”

- IPC message exchange overhead is approximately 500 nanoseconds per message. - A cached file read completes within four IPC messages. - An uncached read involves around nine messages, adding roughly 4.5 microseconds of processing overhead to a disk access that inherently takes multiple milliseconds.

---

[17:24](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1044s) Process Management, Virtual Memory, and the Data Store

MINIX 3 strictly separates high-level system policy from low-level execution mechanisms across its core servers:

- **Process Manager (PM):** Retains all high-level logic for creating, scheduling, maintaining, and terminating processes, as well as handling POSIX signal routing and process hierarchy accounting. - **Virtual Memory (VM) Manager:** Runs as an ordinary user process that contains all paging policies, replacement algorithms, free page accounting, and page fault resolution logic. When a process experiences a page fault, the event is redirected to the VM server to decide which physical page frame to map. Once the page tables are assembled, the VM server simply hands the memory map to the microkernel: the kernel unconditionally installs the map into the hardware MMU without needing to understand virtual memory policies or memory management heuristics. - **Data Store (DS):** Operates as an internal name server and state-storage registry where components can store and retrieve structured runtime data.

The Data Store plays an indispensable role in enabling self-healing, recoverable device drivers. Even simple drivers maintain operational state—such as hardware volume levels, current mixer settings, or serial line parameters. If a driver crashes unexpectedly, it can be terminated and transparently rebooted by the reincarnation server, pulling its historical configuration state directly from the Data Store without disturbing active user programs.

[18:56](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1136s) Supporting Servers and the Reincarnation Server

Beyond device drivers, MINIX 3 organizes auxiliary system functionality into dedicated user-space servers. The data store maintains configuration data and runtime state; for instance, it holds the volume levels for audio devices so that if an audio driver crashes, its replacement can retrieve the previous settings and apply them seamlessly. An information server handles debugging tasks, generating status and memory dumps bound to function keys (the F-keys in MINIX) to let developers inspect what is happening inside the operating system. Networking is implemented through a dedicated network server containing a complete TCP/IP stack running entirely in user space.

The central component for fault tolerance is the reincarnation server, whose primary purpose is reviving dead processes. As the parent process of all system drivers and servers, it maintains an internal table specifying policies and actions for every component. It continuously monitors these processes by sending periodic pings. In a comedic routine illustrating this polling loop, Andrew Tanenbaum demonstrates how the reincarnation server checks in on a component:

> “The reincarnation server will go to a driver and say, ‘Hey disk driver, how you doing?’ and a disk driver will say, ‘Fantastic! I did 57 megabytes a second in the last second, the disk is really humming, we're going great, you know.’ And then three seconds later it'll ping the disk driver again: ‘How you doing?’”

If a driver falls silent, the reincarnation server waits, checks again, and warns: “Now either you answer or you're toast.” A child process is given exactly three chances. If it fails to respond on the third attempt, the reincarnation server terminates the dead or hung process, spawns a fresh instance, and helps it re-establish its environment via the data store.

[21:19](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1279s) Self-Healing in Action: Transparent Disk Recovery

Replacing a failed driver while system calls are ongoing presents subtle dependency challenges, particularly when recovering the storage stack itself. If the disk driver crashes while processing a read request from the file server, the reincarnation server cannot simply load a new binary from disk. MINIX 3 solves this bootstrap paradox by maintaining a shadowed copy of the disk driver executable permanently cached in memory.

```mermaid flowchart TD accTitle: Disk Driver Crash and Recovery Flow accDescr: Step-by-step interaction showing file server and reincarnation server handling a disk driver crash and recovery.

subgraph Failure["Crash Event"] FS1["File Server"] -->|"1. Read block request"| DD1["Disk Driver (Old)"] DD1 -.->|"Crashes / Unresponsive"| RS1["Reincarnation Server"] end

subgraph Spawning["Reincarnation"] RS1 -->|"2. Pings fail (3 attempts)"| KILL["Kill Old Driver"] KILL -->|"3. Spawn from shadowed RAM copy"| DD2["Disk Driver (New)"] DD2 -->|"4. Register location"| DS["Data Store"] end

subgraph Rebinding["Re-binding & Execution"] RS1 -->|"5. Notify failure"| FS2["File Server"] FS2 -->|"6. Query new driver address"| DS FS2 -->|"7. Re-issue block request"| DD2 end ```

Once the root disk driver is running from RAM, the file server queries the data store for the new driver's communication endpoint and transparently replays the unfulfilled read or write command. Tanenbaum remarks that when the file server asks the new driver to take over the block operation, the new driver responds enthusiastically:

> “The file system says, ‘Oh new disk driver, I'm trying to write a block here, you think you could do it for me?’ and a disk driver says, ‘I'd love to write blocks, it's my favorite activity in the whole world—besides reading blocks is writing blocks—so yes, I'll do that.’”

The user process that originated the read call experiences no crash or error return code; the replacement happens entirely on the fly. Tanenbaum notes that full transparent recovery for heavily stateful core servers (such as a crashed file system with complex in-flight buffers) remains an active research topic, but the architecture already delivers self-healing execution for memory-light drivers and stateless services.

[23:18](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1398s) Handling Failures Across Different Driver Types

The consequences and recovery strategies for a driver crash vary substantially depending on the hardware semantics: - **Ethernet Drivers:** Network failures are the simplest to absorb because network stacks are inherently designed for unreliable delivery. Tanenbaum points out that “nobody ever guaranteed that packets were going to be delivered.” Lost UDP packets conform to the best-effort nature of the protocol, while TCP stacks automatically time out and retransmit dropped frames once the new driver binds to the interface. - **Printer Drivers:** Printers present an inherently physical, non-transactional state. If the printer daemon loses its driver midway through a page, it cannot easily inspect where the print head stopped. The pragmatic fallback is for the daemon to restart the print job from the beginning. - **Audio Drivers:** If an audio driver crashes mid-stream, the hardware position is lost. The player process can simply restart the track from the beginning. While not seamless, Tanenbaum argues this is vastly preferable to an unrecoverable system halt: “If the audio driver goes down and the result is there's a small glitch and then the song plays again from the beginning, that's better than an operating system crash.”

[24:16](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1456s) Kernel Minimization, Sandboxing, and Static Allocation

MINIX 3 achieves high reliability by minimizing the Trusted Computing Base (TCB)—the critical software layer whose failure compromises the entire machine. Because defect density correlates directly with code volume (roughly three bugs per thousand lines of code), stripping drivers and file systems out of the kernel drastically reduces the defect surface of the privileged core.

Tanenbaum contrasts this design with monolithic operating systems like Windows and Linux, where peripheral expansion routinely pollutes ring 0:

> “If you go out on your Linux or Windows, whatever PC, and you buy a FireWire card, it comes with a CD-ROM and you put the CD-ROM in the drive and guess what happens: random code written by somebody in Taiwan gets installed in your kernel.”

In MINIX 3, third-party code runs strictly as an isolated user-space process. Moving defects out of supervisor mode does not change the aggregate number of bugs in the codebase, but it defangs them. Tanenbaum jokes that these user-space bugs are effectively “castrated” or “emasculated”—they remain flawed, but they lack the machine privileges required to panic the kernel or trash neighbor memory.

To further protect the kernel from corruption: - Dynamic kernel allocation is banned: there is no `malloc` and no `free` inside the microkernel, eliminating memory leaks, dangling pointers, and heap exhaustion bugs. - Kernel data structures are fixed-size arrays dimensioned at compile time. For example, process capacity is capped by a header constant (such as 256 processes). - Tanenbaum defends this trade-off by pointing out that modern machines have gigabytes of memory, making the few thousand bytes sacrificed to over-dimensioned static tables completely negligible compared to the architectural stability gained.

[26:20](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1580s) IPC Semantics, Interrupts, and Untrusted Drivers

Inter-process communication (IPC) in MINIX 3 is engineered for predictability. Hardware interrupts and IPC messaging are unified: when a device triggers an interrupt, the low-level microkernel converts it directly into a standard IPC message delivered to the relevant driver's mailbox.

Communication originally relied on a synchronous rendezvous model with fixed-length messages. While fixed-size payloads prevent buffer overflow vulnerabilities, synchronous handshakes exposed an unexpected failure mode: if a client process crashes or halts while a server is processing its request, the server hangs indefinitely when attempting to execute its blocking reply. To prevent rogue or dying clients from hanging vital system servers, the MINIX team began introducing asynchronous messaging mechanics.

Tanenbaum emphasizes that treating device drivers as untrusted code by default is the only sensible stance for a secure system:

> “In every other system the drivers are regarded as trusted code, and experience shows that we're right: they are, it is untrusted code.”

Because drivers possess no memory access to kernel tables or foreign address spaces, standard C pitfalls like wild pointers are confined to their own sandbox. A bad memory write crashes only the errant driver process itself, leaving the rest of the operating system completely intact.

[27:56](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1676s) Driver Recovery and Reincarnation

When a device driver crashes, its parent—the Reincarnation Server—is immediately informed via a signal that one of its child processes has died. The server consults an internal table to determine the corrective procedure for that component and triggers an automated shell script. That script handles the administrative cleanup: logging the incident, preserving the core dump or binary image for post-mortem debugging, and optionally alerting a system administrator or sending an error report to the hardware manufacturer. Once this sequence finishes, the Reincarnation Server launches a fresh instance of the driver.

```mermaid flowchart TD accTitle: Reincarnation Server Failure Recovery Flow accDescr: Shows how the Reincarnation Server detects a driver crash or hang, takes diagnostics, and restarts it.

subgraph Failure["Driver Failure Modes"] CRASH["Driver Crashes"] LOOP["Infinite Loop Detected\n(Periodic heartbeat fails N times)"] end

subgraph RS["Reincarnation Server"] SIG["Receive Signal / Timeout"] SCRIPT["Run Recovery Shell Script\n- Save core dump\n- Log event / Send email"] KILL["Kill Hung Driver"] RESTART["Start Fresh Driver Instance"] end

CRASH --> SIG LOOP --> KILL KILL --> SIG SIG --> SCRIPT SCRIPT --> RESTART ```

The system is similarly equipped to handle infinite loops or unresponsive components. The Reincarnation Server periodically polls servers and drivers with a status query. If a driver is trapped in an infinite loop and fails to reply after a predefined threshold of attempts, the Reincarnation Server terminates the stalled process and spawns a replacement. Because all MINIX 3 drivers execute as ordinary user processes at the lowest hardware privilege tier rather than as superuser, a rogue or stalled driver cannot corrupt the rest of the running system. As Andrew Tanenbaum points out:

> “And so we can survive infinite loops inside critical components of the operating system I mean nobody else can do that.”

---

[28:59](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1739s) Fine-Grained Memory Grants

Because servers and drivers execute in isolated user address spaces without supervisor privileges, they cannot directly read or write into an application’s address space. For example, when a user program asks the file server to fetch a block of data, the file server must direct the disk driver to place that data directly into the caller's memory buffer. MINIX 3 resolves this by requiring processes to construct an in-memory Grant Table. A process registers this table by issuing a kernel call specifying the table's base address and the number of valid entries, ensuring the kernel tracks authorization state system-wide.

```mermaid flowchart LR accTitle: Memory Grant Architecture Flow accDescr: Demonstrates how user memory grants allow drivers to write directly to caller buffers via the kernel.

subgraph UserSpace["User Address Space"] APP["Application Process\n(Builds Grant Table)"] FS["File Server"] DD["Disk Driver Process"] end

subgraph KernelSpace["Kernel Space"] MGT["Kernel-Tracked\nGrant Table Entry"] COPY["Kernel Memory Copy\n(Byte-accurate bounds check)"] end

APP -->|"1. Grants access range\n(e.g., bytes 1400-1499)"| MGT APP -->|"2. Passes grant index"| FS FS -->|"3. Delegates grant index"| DD DD -->|"4. Requests transfer via grant"| COPY COPY -.->|"5. Enforces bounds & writes"| APP ```

A grant entry explicitly authorizes a target process to access an exact span of bytes (for example, allowing process 9 to write only into bytes 1400 through 1499). The access requires no page alignment. When initiating the transfer, the caller passes the corresponding grant index to the intermediate server and disk driver. The driver then invokes the kernel, referencing the grant token. The kernel verifies whether the caller is authorized, confirms the requested byte boundaries, and performs the copy itself. While routing copies through the kernel introduces minor overhead, it guarantees protection down to byte granularity. Once the operation finishes, the owner invalidates the grant so the memory cannot be touched again.

---

[30:53](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1853s) Fault Injection Testing

To rigorously evaluate the system's resilience, the MINIX team subjected drivers to sustained binary-level fault injection testing. Using an external tool running concurrently via `ptrace`-style tracing calls, the test framework modified the binary instructions of running network drivers in real time. Rather than injecting random garbage data, the harness parses machine instructions to emulate typical human programmer errors:

- Swapping register operands in instructions like `mov` to replicate variable inversion (such as writing `i = j` instead of `j = i`). - Altering conditional branch instructions (such as swapping a "branch less than" into a "branch less than or equal to") to emulate off-by-one loop conditions (`for (i = 0; i < n; i++)` versus `for (i = 0; i <= n; i++)`).

```mermaid flowchart TD accTitle: Fault Injection Test Loop accDescr: Shows the 100-fault injection batch loop and outcomes on network drivers.

START["Select Ethernet Driver Binary"] --> INJECT["Inject 100 Semantic Faults"] INJECT --> WAIT["Wait 1 Second"] WAIT --> STATUS{"Did Driver Crash?"} STATUS -- No --> INJECT STATUS -- Yes --> LOG["Record Crash & Recover Driver"] LOG --> NEXT{"Reached Trial Limit?"} NEXT -- No --> INJECT NEXT -- Yes --> RESULTS["Results:\n- 2,500,000 trials\n- 800,000 faults / driver\n- 18,000 driver crashes\n- 0 OS crashes"] ```

The experiment injected 800,000 faults into each of three distinct Ethernet drivers, applying alterations in batches of 100 instructions and pausing for one second to monitor stability. In many instances, the driver survived the one-second window because the modified code path was never executed or the mutation proved harmless; in those cases, another 100 mutations were introduced until a crash occurred. Over 2.5 million test iterations, the injection harness caused 18,000 driver crashes.

The experiments also exposed buggy peripheral hardware and uncovered edge cases that froze the PCI bus so severely that only unplugging the machine could clear them. Throughout the entire suite of 18,000 driver crashes and 2.5 million trials, the MINIX 3 operating system itself never crashed.

---

[33:11](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1991s) Software Ecosystem and Unix Usability

Tanenbaum emphasizes that MINIX 3 was deliberately designed to escape the trap of toy academic systems:

> “You know there's a lot of academic projects where they build a little tiny kernel and it it does something you know to do whatever but it only works when the grad student is there and it can't actually run anything you know because it's too much work to do all the rest of the stuff but we've actually made a real effort maybe too much of an effort to make it an actual sort of usable Unix system.”

While lacking kernel threads—which currently rules out heavy desktop environments like GNOME or KDE and complicated browsers like Mozilla Firefox—MINIX 3 provides an X11 graphical environment paired with the lightweight EDE desktop, though most programmers rely on X11 with multiple `xterm` windows.

```mermaid flowchart TD accTitle: Path-Based Userland Selection in MINIX 3 accDescr: Shows how modifying PATH selects between GNU, BSD, and Version 7 utilities.

PATH["User PATH Configuration"] PATH -->|"/usr/gnu first"| GNU["GNU Coreutils\n(gls, gcp, etc.)"] PATH -->|"/usr/bsd first"| BSD["BSD Utilities"] PATH -->|"Default / unset"| V7["Version 7 AT&T Unix Utilities"] ```

The software catalog includes approximately 600 packages: - **Shells & Utilities:** Bash, `pdksh`, and Zsh. Users can customize their environment by ordering their `PATH` variable to prefer GNU core utilities, BSD tools, or the default Version 7 AT&T Unix tools stored in separate directories. - **Compilers & Languages:** Perl, Python, PHP, C, and C++. The system includes GCC, as well as the Amsterdam Compiler Kit (ACK). While ACK only adheres strictly to ANSI C, it builds the entire MINIX 3 system—including the kernel, user-space drivers, and system servers (125 source files compiled and 11 links)—in under 10 seconds. - **Editors & Productivity:** Emacs, Vim, Nvi, Vile, and Nedit; image tools like ImageMagick and `xv`. - **Daemons & Databases:** Apache, Lynx, Dillo, PostgreSQL, SQLite, MySQL client, Pine, Subversion, MPlayer, and NetHack. - **Emulation:** MINIX 3 runs QEMU to host legacy operating systems. Because Windows 98 originally targeted 60 MHz Pentium processors, running it inside QEMU on a modern host—even with a 10× software emulation slowdown—outperforms the original hardware era.

---

[36:53](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2213s) Community Adoption and Website Traffic

To assess community adoption, the project tracks traffic on its primary distribution site, `minix3.org`. By early 2010, the project averaged approximately 25,000 visits per month and around 12,000 downloads per month over the preceding year. Since the site launched at the end of 2005, it accumulated over 1.6 million cumulative visits. Tanenbaum notes that while these metrics are modest compared to Linux, they represent a significant level of real-world interest for a low-budget academic open-source operating system.

[37:37](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2257s) Project Traction, Team Composition, and the Frustration with Porting

Andrew Tanenbaum shares that MINIX 3 has reached 610,000 downloads over roughly four years. He puts this in perspective with typical modesty: “Compared to Linux this is nothing, but compared to other open source projects of other, you know, kinds of things, 600,000 downloads, just you know, there's some interest in there in the world.”

```mermaid flowchart TD accTitle: MINIX 3 Project Team Structure accDescr: Organizational breakdown of the MINIX 3 development group led by Andrew Tanenbaum.

subgraph Core["Core Research & Staff"] PI["Andrew Tanenbaum"] Postdoc["1 Postdoc"] PhD["5 PhD Students"] PaidDev["3 Full-Time Paid Programmers"] OpenRoles["2 Paid Openings (Amsterdam)"] end

subgraph Academic["Students & Contributors"] SA["2 Student Assistants"] MSc["Master's Students"] GSoC["4 Google Summer of Code Students"] Volunteers["Global Community Volunteers"] end

PI --> Core PI --> Academic ```

He then outlines the roster behind the system: - Tanenbaum himself as project lead - 5 PhD students and 1 postdoc - 2 student assistants and several Master's students - 3 paid, full-time programmers funded via an EU grant - 4 Google Summer of Code students from the past year, alongside global community volunteers

Using the FOSDEM platform as an overt recruitment drive, he invites volunteers to contribute in several areas. He notes that the project wiki needs better documentation and translation into other languages, and porting software libraries remains a major bottleneck.

Tanenbaum launches into a humorous critique of the state of open-source portability and modern build systems:

> “I don't know, everybody here has probably taken a course in software engineering somewhere along the line, and all of you forgot it the day after the exam, that it's just amazing how much free software is so crappy, it's not portable.”

He illustrates the absurdity with autotools scripts, noting that you run `./configure` and it routinely fails because it cannot locate an esoteric version like Perl 5.2.326.94b—even when the target program does not use Perl at all. He derides these build scripts as “20,000 lines of incomprehensible code generated by a program which itself was generated by a program.” While fixing them usually requires deleting only one or two offending lines, tracking those lines down is tedious work.

Finally, he advertises two open full-time paid programming positions based in Amsterdam funded by his EU grant. Pitching directly to developers trapped in mundane jobs, he jokes that if you are currently stuck doing web design for a bathroom equipment manufacturer and would rather get paid to hack kernels in a lovely city like Amsterdam, you should Google his homepage and submit a CV.

---

[40:26](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2426s) Active Research: Live Updates, Multicore Architecture, and Modern File Systems

Turning to active research, Tanenbaum highlights the transition from reactive crash recovery to proactive live updates. While MINIX 3 can already resurrect components after a crash, replacing them intentionally without downtime presents both simpler and more demanding challenges. In mainstream operating systems, a minor patch from version 6.2.4.3 to 6.2.4.4 inevitably demands a reboot. Tanenbaum points out the absurdity of this in an era where appliances are software-driven. A modern television running 40 MB of software shouldn't suddenly disrupt the final two minutes of the Super Bowl with a seven-minute reboot message. The goal is to hot-swap components while all user processes remain fully operational, accepting perhaps a minor delay of a few seconds during the cutover rather than downtime.

```mermaid flowchart LR accTitle: Areas of Active Research in MINIX 3 accDescr: Key technical directions being explored by the MINIX 3 team.

LU["Live Updates"] -->|"Hot-swap modules"| ZeroReboot["Zero Reboot Downtime"] MC["Multiserver Meets Multicore"] -->|"Map OS servers"| Cores["Dedicated CPU Cores"] FS["Rethinking File Systems"] -->|"Move beyond"| Multics["1965 Multics Paradigm"] State["Stateful Recovery"] -->|"Preserve driver state"| Reliability["Continuous Execution"] ```

The team is focusing on several fundamental architectural areas: - **Multiserver meets Multicore:** With CPU core counts scaling upward alongside MINIX's decoupled multiserver architecture, Tanenbaum is investigating how to map individual OS server processes directly onto dedicated physical cores. - **Rethinking File Systems:** Tanenbaum notes that contemporary file systems are essentially the 1965 Multics file system, where the only substantive shift has been cosmetic delimiters—Multics used `>`, Unix adopted `/`, and Windows switched to `\`. The project intends to explore fresh file system paradigms fit for modern workloads. - **Stateful Service Recovery:** Developing mechanisms to seamlessly restore and migrate services that hold persistent, in-flight state without data corruption.

---

[42:24](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2544s) Licensing, Identity, and the FOSDEM Summary

Tanenbaum addresses the project's licensing, noting that MINIX 3 uses the permissive BSD license, which he summarizes as: “Do whatever you want except sue us, but other than that, do whatever you want.” He recalls speaking at a Linux conference in Australia where an audience member asked about the license; expecting angry backlash or flying tomatoes from the Linux faithful, he was instead met with a huge cheer. While MINIX bundles various GPL packages as add-ons, Tanenbaum notes they could easily be isolated onto a separate CD-ROM if licensing friction ever arose.

In terms of positioning, the project seeks to prove that multiserver architectures—rather than the broader, generic concept of microkernels—are practical and reliable. Key targets include high-reliability systems, embedded devices, and low-cost $50 single-chip laptops for initiatives like One Laptop per Child (OLPC). MINIX 3's mascot is the wild raccoon—selected because, like the OS, it is small, cute, agile, clever, and most importantly, it eats bugs.

Tanenbaum summarizes the talk by reiterating that modern operating systems are bloated and unreliable. MINIX 3 addresses this with an ultra-compact microkernel, user-mode drivers with strictly restricted privileges, isolated operating system components, and on-the-fly failure replacement. He directs attendees to `minix3.org`, their Google Newsgroup, and the project wiki, mentioning he brought a limited number of official physical CD-ROMs to hand out, before opening the floor to audience questions.

---

[44:48](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2688s) Q&A: Comparison with Chrome OS and the Microkernel Latency Debate

The question-and-answer session begins with an inquiry about whether MINIX 3 shares design principles with Google Chrome OS. Tanenbaum notes that he has not examined Chrome OS's source code, but observes that Chrome OS appears oriented toward running a single central application—the web browser. While that might satisfy users who only need a web portal, MINIX 3 is engineered as a fully fledged, POSIX-compliant Unix operating system capable of running standard command-line tools and software suites.

A second audience member brings up latency. Referring to Tanenbaum's earlier statement that message passing incurs roughly a 500-nanosecond overhead, the questioner notes that developers in specialized fields—such as pro audio—routinely agitate over 5-microsecond latencies and push hard for 1 to 2 microseconds.

Tanenbaum responds with dry humor:

> “Grandma doesn't know what a microsecond is, but I mean if you're the, you know, the guy who wants to get every drop of performance out of it, you know, no, this is not for you.”

Reflecting on his computing history, he recalls that his first 60 MHz Pentium was 100 times faster than his old PDP-11, yet there will always be users for whom raw performance is never enough. For users obsessing over every cycle, MINIX 3 is the wrong tool; the architecture is unapologetically designed for fault tolerance and reliability rather than peak throughput. He notes that while the MINIX team has not rigorously benchmarked raw overhead, the L4 microkernel project extensively optimized their IPC and demonstrated that a pure microkernel design incurs approximately a 5% to 10% performance penalty overall. If a 5% to 10% overhead is unacceptable to a developer's constraints, a microkernel system simply is not the right fit. A third questioner then steps up to pursue the performance implications of pure microkernel designs further.

[47:15](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2835s) Trading Clock Speed for Stability: The 2 GHz vs. 3 GHz Dilemma

When an audience member asks about the hybrid approach and where MINIX 3 positions itself regarding raw performance, Andrew Tanenbaum makes it immediately clear that squeezing out maximum benchmarks has never been the project's priority. Instead, he frames the tradeoff through a down-to-earth consumer thought experiment involving a computer vendor and an everyday user. If a regular customer or grandmother called Dell to order a PC and was offered a choice between a 3 GHz machine that crashes occasionally and a 2 GHz system guaranteed never to crash, Tanenbaum contends that the stable 2 GHz model would easily dominate sales.

Tanenbaum emphasizes that mainstream users have long reached a threshold where hardware is fast enough for everyday tasks, making resilience far more valuable than raw processing power. While high-performance computing enthusiasts seeking every last drop of throughput might look elsewhere, everyday computer users would eagerly accept lower clock speeds if it meant total reliability. Underlining his own conviction, Tanenbaum states: “I mean I don't have an actual data but I have a just a very strong feeling there's an awful lot of people who'd give up a third of their performance or maybe if I'd give up personally 50% of my performance if you could guarantee it would never crash right off the bat.”

- Dell hypothetical scenario: 3 GHz with occasional crashes versus 2 GHz with zero crashes. - Target audience: Everyday end users prioritized over power users needing maximum benchmark speed. - Personal tradeoff: Tanenbaum would personally surrender up to 50% of machine performance in exchange for an absolute crash-free guarantee.

[48:19](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2899s) TCB Vulnerabilities and Boot Speed: Reincarnation Server and Data Store

Responding to a question regarding what happens if the Reincarnation Server itself dies, Tanenbaum offers a blunt assessment of single-point failures: “No, we're dead in the water.” However, he outlines that well-understood fault-tolerant computing techniques could resolve this if needed. MINIX 3 could adopt triple modular redundancy (TMR), running three synchronized copies of the Reincarnation Server that continually inspect one another. If one instance misbehaves or halts, the remaining two would outvote it, terminate it, and instantiate a fresh replica. In practice, MINIX 3 has not required TMR because the Reincarnation Server is so small—amounting to roughly ten pages of code—that it rarely if ever fails.

A similar logic applies to the Data Store, which, alongside the Reincarnation Server and the microkernel, constitutes the system's core Trusted Computing Base (TCB) of roughly 20,000 lines of code. Because the Data Store handles light traffic and is only a few pages of code, it has proven highly dependable, though it too could run three voting replicas if absolute fault immunity were mandated. Shifting to system responsiveness, an attendee asks about boot times. Tanenbaum clarifies that on typical hardware, the total machine boot takes around 30 seconds, but 20 to 25 seconds of that duration are consumed by BIOS hardware routines and memory diagnostics; once the hardware handoff occurs, the MINIX 3 operating system itself initializes in only a couple of seconds.

```mermaid flowchart TD accTitle: Triple Modular Redundancy Scheme for Core Servers accDescr: Three identical server instances vote on operational state to detect and replace a malfunctioning instance. subgraph TMR["Triple Modular Redundancy (TMR) Concept"] S1["Server Instance A"] S2["Server Instance B"] S3["Server Instance C (Failed)"] VOTE{"Majority Vote (2 vs 1)"} S1 --> VOTE S2 --> VOTE S3 -.->|"Fault / Desync"| VOTE VOTE -->|"Outvote & Terminate"| KILL["Kill Instance C"] KILL -->|"Spawn Replacement"| S3NEW["New Server Instance C"] end ```

- Total TCB size: Approximately 20,000 lines of code (including microkernel, Reincarnation Server, and Data Store). - Reincarnation Server code footprint: Around 10 pages of code. - Data Store code footprint: A couple of pages of code. - Boot breakdown: ~30 seconds total, where 20–25 seconds are motherboard/BIOS memory tests and only a few seconds belong to the MINIX 3 OS startup.

[49:49](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2989s) Permission Bitmaps and Architecture Scalability

An audience member asks about kernel scalability, specifically whether the bitmapped permission masks used to govern inter-process communication restrict the system to 32 drivers or servers at compile time. Tanenbaum explains that the system currently uses a 32-bit bitmap because it is more than sufficient for the existing footprint of the OS. In typical installations, the total count of active servers and drivers sits around 15 to 20, meaning the 32-slot boundary has not been exhausted in everyday operation.

If an installation were to require more components, scaling the structure would be straightforward. The kernel could expand the bitmap to a 64-bit integer or chain multiple words together to support 30, 40, or more drivers. Tanenbaum makes sure to differentiate between system components and normal applications: user processes operate strictly on standard POSIX interfaces. They cannot transmit raw IPC messages to arbitrary system servers or one another, and they exchange data via conventional Unix pipes, meaning application process counts are not constrained by the 32-bit IPC permission mask.

- Bitmap restriction: Currently 32 bits, sufficient for systems running 15–20 core drivers and servers. - Expansion path: Switching to a 64-bit word or multiple-word arrays can accommodate larger driver fleets. - Process isolation: User applications are bound by POSIX and pipe semantics, completely outside driver IPC bitmaps.

[51:51](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=3111s) Embedded Systems, the ARM Port, and Paid vs. Volunteer Developers

When an attendee asks whether MINIX 3 supports non-x86 architectures like ARM to fulfill the vision of consumer electronics such as smart TVs, Tanenbaum acknowledges that an ARM port is essential for serious adoption in the embedded space, but progress has stalled due to the unpredictable nature of open-source volunteer efforts. The project has seen two separate developers initiate an ARM port, only for both to lose interest, get distracted by life commitments, and drift away before completing the code.

This experience prompts Tanenbaum to reflect frankly on the broader economics of open-source software maintenance. He challenges the romanticized myth of independent hobbyists building critical infrastructure, noting that modern open-source ecosystems rely heavily on corporate investment. Tanenbaum observes: “I read somewhere recently that more than 75% of all the Linux code was written by paid programmers working for IBM, Red Hat, and a couple of other companies that the story of the users contribute stuff that is you know it's a nice story, but it isn't actually the reality and you know so if somebody wants to work on the ARM port for us we'd be very very grateful.” To break the cycle of abandoned volunteer branches, he explains that he is actively seeking funds to hire dedicated, paid developers to complete the ARM architecture port.

- Target domain: Consumer electronics, television sets, and low-power embedded platforms. - ARM port status: Unfinished after two separate volunteer developers abandoned the task halfway through. - Industry workforce reality: Cites statistics showing >75% of modern Linux contributions stem from corporate-backed salaried engineers at vendors like IBM and Red Hat.

[53:00](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=3180s) Runaway Failures, Missile Launches, and Transient vs. Algorithmic Bugs

The session concludes with a series of questions addressing corner cases in automated failure recovery. One attendee poses a safety-critical scenario: if an aircraft carrier launches a missile and the driver or kernel process crashes mid-action, could the Reincarnation Server inadvertently cause a catastrophic double-fire by automatically relaunching the process? Tanenbaum clarifies that the recovery mechanism is fully programmable. When a component dies, the Reincarnation Server consults a policy table and executes an associated shell script. That script does not have to issue a restart; it can be programmed to halt execution, raise alarms, or log an incident rather than blindly retrying dangerous hardware actions.

A software developer follows up with a classic QA dilemma: what prevents the system from entering an infinite crash loop if an application triggers an identical algorithmic bug, such as a disk driver crashing on the exact same linear block address calculation every time a request is retried? Tanenbaum concedes that software cannot magically repair broken logic on the fly, explaining: “If the failure is a true algorithmic failure and it is incapable itself of converting the linear block address to the correct head sector and track and cylinder, then there's no way we can fix it you know on the fly by starting it, but our experience and everybody else's experience is that most errors that you run into are transient errors caused by weird timing or two things happen at the same moment or something like that that the true algorithmic bugs that it never works you know typically get checked you know before they ship the thing.” Because race conditions and transient states cause the vast majority of real-world crashes, simply restarting the driver clears the state and works.

Finally, addressing concerns about faulty DMA controllers or drivers programming DMA wrong, Tanenbaum reiterates that broken physical silicon cannot be repaired by an OS. However, the driver recovery harness allows the Reincarnation Server script to step down through alternative software implementations. If the primary driver fails, the recovery script can automatically launch a fallback driver or roll back to a known-stable older version, providing multi-tiered software survivability without manual intervention.

- Policy-based recovery: Reincarnation Server actions are driven by customizable shell scripts that can halt, alert, or retry based on specific component profiles. - Transient vs. deterministic bugs: Restarting primarily remedies transient timing bugs, races, and corrupted runtime state, which represent the bulk of production crashes. - Algorithmic fallback: While on-the-fly patching is impossible, the harness supports N-version programming or fallback to legacy drivers if an active driver experiences repeated failures.

## Notable quotes > [23:18](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1398s) If the audio driver goes down and the result is there's a small glitch and then the song plays again from the beginning, that's better than an operating system crash. — Andrew Tanenbaum

## Mentioned Andrew Tanenbaum, MINIX 3, UNIX Version 6, UNIX Version 7, AT&T, Bell Labs, John Lions, University of New South Wales, European Research Council (ERC), European Union, Microsoft, Microsoft Windows, Linus Torvalds, Linux, Bill Gates, PC Pro, PDP-11, L4, QNX, PikeOS, Green Hills Software, FreeBSD, Stanford University, FOSDEM, Amsterdam Compiler Kit, GCC, X11, EDE, GNOME, KDE, Mozilla Firefox, QEMU, Windows 98, Apache, PostgreSQL, SQLite, MySQL, Google Summer of Code, Multics, Chrome OS, Dell, IBM, Red Hat, ARM, One Laptop per Child

## Video description By Andrew Tanenbaum

MINIX started in 1987 and led to several offshoots, the best known being Linux. MINIX 3 is the third major version of MINIX and is now focused on very high-reliability and security.

MINIX started in 1987 and led to several offshoots, the best known being Linux. MINIX 3 is the third major version of MINIX and is now focused on very high-reliability and security. When you buy a TV set, you just plug it in and it works perfectly for the next 10 year. We are trying to make operating systems as good as that. The current version of MINIX 3 can detect device driver crashes and some server crashes and automatically replace the failed component without user intervention and without affecting running processes. The talk will discuss these aspects as well as new work.

FOSDEM (Free and Open Source Development European Meeting) is a European event centered around Free and Open Source software development. It is aimed at developers and all interested in the Free and Open Source news in the world. Its goals are to enable developers to meet and to promote the awareness and use of free and open source software. More info at http://fosdem.org

[Source](https://www.youtube.com/watch?v=bx3KuE7UjGA)

中文简报

MINIX 3:模块化、自愈型且兼容POSIX的操作系统 Andrew Tanenbaum介绍了MINIX 3,这是一款遵循POSIX标准的模块化微内核操作系统,旨在让计算机像日常家电一样可靠。他将现代庞大臃肿的单体内核(其中缺陷密集的第三方设备驱动程序导致了绝大多数崩溃)与MINIX 3紧凑的6000行微内核进行了对比,后者基于最小权限原则将驱动程序、服务器和文件系统限制在隔离的用户空间进程中。借助转生服务器(Reincarnation Server)、数据存储(Data Store)和细粒度内存授权等组件,系统通过心跳检测故障,并能无缝重启发生崩溃的驱动程序,而不会影响正在运行的用户程序或导致内核崩溃。Tanenbaum还展示了经验性的故障注入测试结果,回顾了MINIX 3不断扩充的软件目录,并讨论了在热补丁、多核扩展方面的持续研究,以及为了获得防崩溃的稳定性而有意牺牲适度IPC延迟的权衡取舍。 Andrew Tanenbaum强调,85%的Windows崩溃源于第三方驱动程序,这些驱动约占典型操作系统代码库的70%,且其缺陷密度是内核核心代码的3到7倍。 (8:04) MINIX 3通过将微内核缩减至约6000行代码,并将驱动程序、文件系统和虚拟内存隔离到无特权的用户空间进程中,从而实现了高可靠性。 (9:58) 在实时修改二进制指令的故障注入基准测试中,MINIX 3经受住了250万次测试迭代和18000次驱动程序崩溃,操作系统未出现过一次故障。 (30:53) 微内核的消息传递开销大约为每条消息500纳秒,折算下来仅带来5%至10%的适度性能损失,Tanenbaum认为普通消费者会非常乐意用这点损失换取系统的完全稳定。 (44:48)

Reading summary

Andrew Tanenbaum argues that modern operating systems are plagued by bloat and frequent crashes, advocating for a modular microkernel design like MINIX 3 that treats drivers as untrusted user-space processes to achieve self-healing reliability. Software Bloat and the Microkernel Alternative (5:33) Tanenbaum highlights that commercial and open-source monolithic operating systems have ballooned, with Linux surpassing 6 million lines of code and Windows exceeding 100 million lines. With standard software error rates averaging 5 to 10 bugs per thousand lines of code, large codebases harbor tens of thousands of potential defects. Device drivers account for roughly 70 percent of an operating system's codebase and have bug densities three to seven times higher than core code, causing an estimated 85 percent of Windows crashes. In contrast, MINIX 3 confines its microkernel to roughly 6,000 lines of code, reducing the privileged defect surface. Driver Isolation and Least Authority (9:58) Rather than running drivers in supervisor mode, MINIX 3 executes device drivers and core system servers—such as the file system and virtual memory manager—as separate user-space processes protected by memory management hardware. Components interact through approximately 35 low-level internal kernel calls and inter-process communication (IPC) messages, adding about 500 nanoseconds of overhead per message. Governed by the Principle of Least Authority, drivers cannot directly touch hardware registers or foreign memory; instead, they operate through kernel-enforced permission bitmaps and byte-bounded memory grant tables. Automated Recovery and Fault-Injection Testing (18:56) Self-healing in MINIX 3 is managed by the Reincarnation Server, which periodically polls system drivers and servers. If a driver hangs, enters an infinite loop, or crashes, the Reincarnation Server terminates it and spawns a fresh copy, pulling saved runtime configurations from an internal Data Store without bringing down the OS. For the disk driver, a shadowed RAM copy enables transparent recovery during active I/O. In fault-injection experiments that altered binary instructions to mimic human coding errors, three network drivers suffered 18,000 crashes over 2.5 million test iterations, yet the underlying operating system never crashed. Performance Tradeoffs and Usability (33:11) MINIX 3 functions as a POSIX-compliant system supporting around 600 packages, including shells, compilers, and editors, though it lacks kernel threads needed for modern web browsers or full desktop environments. Tanenbaum defends the minor performance penalty of microkernel IPC—noting L4 achieved overheads of roughly 5% to 10%—by arguing everyday consumers prioritize stability over raw speed. He contends most users would readily trade clock speed for a system guaranteed not to crash, while noting the core Trusted Computing Base comprises about 20,000 lines of code across the microkernel, Reincarnation Server, and Data Store. While MINIX 3 demonstrates robust recovery against transient timing errors and driver failures, Tanenbaum acknowledges limits: persistent algorithmic bugs cannot be repaired on the fly, single-point failures in the Reincarnation Server would require triple modular redundancy, and broader embedded adoption remains constrained by incomplete ports like ARM due to reliance on paid development.

精炼阅读摘要

Andrew Tanenbaum在演讲中指出,现代主流操作系统因代码库膨胀与宏内核架构导致崩溃频发,而MINIX 3通过将代码基最小化、设备驱动完全用户态化以及引入自我修复机制,能够构建出极高可靠性且兼容POSIX的微内核系统。 软件膨胀与宏内核的可靠性危机 (2:40) 现代操作系统在硬件性能成千倍提升的同时,启动速度与稳定性反而恶化,核心原因在于软件代码急剧膨胀。以工业界千行代码缺陷率(KLOC)计算,商业软件常态为5至10个缺陷,高质量开源项目如FreeBSD约为3个。Linux内核代码超过600万行,预估潜藏18,000个缺陷;Windows整体技术栈超1亿行。此外,斯坦福大学研究表明Linux设备驱动的缺陷率是核心内核代码的3至7倍,微软遥测数据亦显示85%的Windows系统崩溃源自第三方硬件厂商的驱动程序。将占代码库70%的驱动程序置于特权内核态,导致系统时刻面临单点崩溃威胁。 面对这种工程现状,行业对软件缺陷产生了与传统制造业截然不同的双重标准。汽车与轮胎制造受严格产品责任法约束,极低缺陷率是底线,而商业软件却长期享有免责特权。为探索根治之道,欧盟ERC在2008年向Tanenbaum授予250万欧元高级研究基金,专项资助高可靠性操作系统设计。Tanenbaum主张操作系统应效仿航母等复杂工程的物理隔离机制:卫生间管道堵塞不应导致导弹误射,系统的故障隔离必须在架构底层得到绝对保证。 微内核极小化与最小特权沙盒架构 (8:04) MINIX 3将可信计算基(TCB)极限压缩至约20,000行代码,其中纯微内核仅约6,000行C与汇编,排除了malloc与free等动态内存分配,全部采用编译期确定的静态数组以杜绝内存泄漏和堆耗尽。微内核仅负责原始硬件中断、进程间通信(IPC)、CPU调度、系统时钟和底层系统任务,完全不涉及高级进程策略。文件系统、虚拟内存管理器、网络协议栈以及磁盘、网卡、声卡等所有驱动程序,均作为完全独立的用户态进程运行在非特权保护模式下,并受到硬件内存管理单元(MMU)的严格隔离。 系统严格推行最小特权原则(POLA),各组件通过约35个专用内部内核调用与微内核交互,且受到细粒度能力位图的约束。位图严格限定每个驱动可访问的I/O端口范围、可发起的内核调用以及允许通信的目标进程。所有驱动均参与时间片轮转调度,即便陷入死循环也不会挂起整机。由于驱动缺乏修改内核表或跨地址空间操作的特权,由指针错误或恶意利用造成的内存破坏被严格限制在其自身的沙盒内,从而剥夺了用户态缺陷引发整机崩溃的能力。 透明自我修复机制与故障注入验证 (18:56) 为实现无人值守的自我修复,MINIX 3引入了转生服务器(Reincarnation Server)与数据存储器(Data Store)。转生服务器作为所有系统驱动和服务器的父进程,通过周期性心跳探测监控各组件运行状态;若某个驱动程序在三次尝试后仍未响应,或被信号通知意外终止,转生服务器将立即终结死锁组件,并通过预设的自动化脚本生成核心转储和日志,随后拉起新实例。组件的配置与运行时状态由数据存储器集中维护,重启后的驱动能无缝恢复历史参数。以关键的磁盘驱动崩溃为例,由于内存中驻留有磁盘驱动二进制镜像,转生服务器无需访问磁盘即可在内存中重启新实例,文件系统进而重新绑定端点并重发读写请求,上层用户进程完全察觉不到底层中断。 团队通过动态注入语义缺陷对该架构的韧性进行了严格测试。测试框架实时修改网卡驱动的机器指令,针对性模拟操作数互换(如i=j颠倒)及分支条件偏置(循环边界越界)等常见人为编程失误。在对三个独立以太网驱动实施的250万次测试中,共累计注入80万次故障并引发了18,000次驱动程序崩溃。测试结果显示,尽管边缘硬件曾出现冻结PCI总线的极端情况,但MINIX 3操作系统本身在全部18,000次驱动崩溃中实现了零次死机。 系统开销权衡与现实工程生态局限 (14:54) 在通信与内存交互层面,MINIX 3采用固定长度IPC消息传递机制,单条消息通信开销约500纳秒。针对跨进程直接传输,系统设计了基于内核授权表(Grant Table)的内存授权机制,赋予目标进程字节级精度的读写权限,无需页面对齐。虽然微内核调用增加了一定处理周期(例如未命中缓存的文件读取约需9条IPC消息,耗时约4.5微秒),但在磁盘毫秒级物理延迟面前,微秒级开销占比极小。根据L4微内核的优化先例,纯微内核架构的整体性能损耗通常落在5%至10%之间。Tanenbaum坦言,MINIX 3面向的是追求绝对稳定的大众用户与嵌入式设备,而非压榨每一点极限吞吐的高性能计算场景,甚至普通用户若能在“3 GHz但偶尔崩溃”与“2 GHz绝不崩溃”之间选择,理应倾向于后者。 在生态构建上,MINIX 3虽提供X11图形界面、轻量级EDE桌面,并通过软件库适配了GCC、ACK、Bash、Python及Apache等约600个软件包,但因暂无内核级线程支持,目前无法运行Firefox、GNOME或KDE等大型桌面软件。此外,关键的ARM架构移植由于依赖社区业余贡献者,先后经历两任开发者中途放弃而停滞。Tanenbaum指出,现代开源基建高度倚赖企业资助(如Linux超过75%代码由红帽、IBM等企业付费员工撰写),MINIX 3在缺乏全职商业人力投入的情况下,跨平台移植与深层库适配仍面临显著的现实瓶颈。 MINIX 3证实了通过多服务器微内核架构与自动化故障恢复可以构建出抗崩溃的POSIX操作系统,但该体系主要解决的是偶发竞态与临时状态异常,无法在运行时动态纠正固有的算法设计缺陷。未来该项目将进一步向多核资源直接映射、无感知热更新以及摆脱传统Multics范式的新型文件系统方向探索。

Detailed notes — zh

## Background 本内容由 FOSDEM 于 2010 年 2 月 14 日在 YouTube 平台发布,记录了著名计算机科学家 Andrew Tanenbaum 关于 MINIX 3 操作系统的精彩演讲。视频简介指出,始于 1987 年的 MINIX 曾催生了包括 Linux 在内的诸多衍生系统,而第三代主要聚焦于极高的可靠性与安全性,旨在打造像家用电视一样插电即可稳定工作十年的操作系统,能够在无需人工干预且不影响运行进程的情况下自动检测并替换崩溃的驱动或服务。 ## TL;DR Andrew Tanenbaum 在演讲中尖锐抨击了现代单体操作系统因代码恶性膨胀与劣质驱动导致的高崩溃率现状,并展示了 MINIX 3 彻底的微内核与多服务器自愈架构。系统将仅约 6,000 行的核心特权代码与运行在非特权用户态的设备驱动、文件系统及内存管理严格隔离,结合细粒度权限位图与内存授权机制切断故障蔓延。通过转世服务器的心跳探测、内存阴影副本以及数据存储服务,MINIX 3 实现了无响应驱动的透明重启与状态无缝还原,并在 250 万次故障注入测试中保持了核心零崩溃的卓越表现。此外,演讲还介绍了该系统完备的 POSIX 生态、向多核及动态热更新演进的研究方向,并坦诚探讨了在极致性能与绝对可靠性之间的架构取舍。 ## Atmosphere & style Tanenbaum 尽管自嘲“病得像条狗”,却依然展现出老派戏剧演员般活力充沛、妙语连珠的主持台风,开场便以剧院式的幽默彻底点燃了全场技术黑客的气氛。他善用生活化的犀利比喻——从航母马桶不影响防空导弹,到老奶奶买戴尔电脑时宁要稳定不要主频——将晦涩深奥的操作系统架构理论讲得既辛辣讽刺又通俗生动。整场演讲洋溢着纯粹的学术理想主义与脚踏实地的工程硬核风格,不仅有对软件工业现状的无情针砭,亦有在面对观众尖锐提问时从容不迫、坦荡直率的宗师气度。 ## Bulletin - [02:41](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=161s) MINIX 3 获得欧盟欧洲研究委员会(ERC)250 万欧元科研经费支持,旨在通过微内核与强模块化架构打造像家用电视般稳定、能够自动自愈的高可靠操作系统。 - [08:05](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=485s) 统计显示操作系统 70% 的代码为设备驱动且缺陷率是核心算法的 3 至 7 倍;MINIX 3 将微内核缩减至约 6,000 行代码,并把所有驱动和文件系统置于独立非特权用户空间运行。 - [30:53](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1853s) 在 250 万次包含真实代码语义缺陷的故障注入测试中,驱动程序累计崩溃 18,000 次,但 MINIX 3 操作系统内核保持了零崩溃记录。 - [18:56](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1136s) 针对驱动崩溃与死循环,MINIX 3 依靠转生服务器(Reincarnation Server)、内存阴影副本与数据存储(DS)实现透明自愈,并能通过 Shell 脚本自定义恢复或回滚策略。 ## Key takeaways - [04:19](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=259s) 软件行业长期对低可靠性采取病态容忍,而 MINIX 3 试图用工程实践证明操作系统可以像家用电视一样实现多年免维护与高可靠运行。 - [06:18](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=378s) 借鉴工业产品责任法与复杂工程(如航母)的隔离哲学,通用操作系统必须打破宏内核的全局特权模式,防止局部马桶故障误发导弹。 - [08:05](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=485s) 代码行数与缺陷率成正比,微内核将受信任计算基(TCB)压缩到极限,从而在数学概率上大幅削减了内核潜藏缺陷的基数。 - [24:18](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1458s) 设备驱动占据操作系统 70% 的体积且缺陷率最高;将其移出内核空间虽未消灭缺陷数量,但彻底剥夺了其破坏内核核心数据结构的能力。 - [09:58](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=598s) 微内核仅保留约 6,000 行代码负责中断、极简调度与 IPC,虚拟内存管理与文件系统均以用户态进程实现,严格践行机制与策略分离。 - [27:56](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1676s) 系统通过内存授权(Memory Grants)实现字节级跨空间安全拷贝,且内核完全抛弃动态 malloc/free,通过静态分配彻底规避内存泄漏与碎片。 - [14:56](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=896s) 微内核约 500 纳秒的 IPC 通信延迟相比物理 I/O 毫秒级寻道微不足道,整体性能损耗通常仅在 5% 到 10% 左右,换取了极高稳定性。 - [21:22](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1282s) 转生服务器(RS)通过周期性心跳探测防范驱动挂起与死循环,配合内存阴影副本可实现磁盘驱动在崩溃瞬间对上层完全无感的透明重拉。 - [17:24](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1044s) 数据存储服务器(Data Store)作为键值中心解耦并持久化外设驱动状态,为崩溃后的平滑状态复原奠定了基石。 - [48:19](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2899s) 针对转生服务器自身的潜在单点故障,理论与工程上可采用经典的三重模块冗余(TMR)机制通过二对一投票仲裁解决。 - [53:50](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=3230s) 绝大多数系统故障属于并发或时序竞争引起的瞬态故障,快速清空状态重启能解决绝大多数问题,不可逆操作则可通过脚本策略阻止盲目重试。 - [33:11](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1991s) MINIX 3 拥有包括 ACK 与 GCC 双编译器在内的完备 POSIX 开发环境,自研编译器只需不到 10 秒即可完整构建包含内核与驱动的整套系统。 - [51:01](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=3061s) 开源核心基础设施难以完全依赖纯业余志愿者驱动,维持长周期核心攻坚(如 ARM 端口开发)必须依靠全职带薪工程师。 ## Detailed walkthrough ### [00:20](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=20s) 开场与 MINIX 的诞生背景 Andrew Tanenbaum 在演讲伊始便坦言自己虽然“病得像条狗一样(sick as a dog)”,但出于戏剧舞台的职业背景与信条,他坚持“演出必须继续(the show must go on)”。他介绍自己负责主持 MINIX 3 项目,背后还有庞大的团队协作。随后,他回顾了 MINIX 诞生的曲折历史。1975 年贝尔实验室发布了 UNIX Version 6,这是首个走出实验室的版本并取得了巨大成功。新南威尔士大学的 John Lions 教授为此撰写了一本讲解系统源码的经典小册子,全球许多大学都将其用作教材。 转折发生在 1979 年,AT&T 发布 Version 7 时在许可合同中加入了一条严苛条款:“尔等不得在课程中讲授本系统(Thou shalt not teach this in courses)”。AT&T 试图将源码作为商业机密据为己有,Tanenbaum 语带讽刺地称这是 AT&T 市场部门的“天才之举”,也正是 UNIX 最终错失统治世界良机的原因。由于法律限制,1984 年在讲授操作系统课程的 Tanenbaum 决定另辟蹊径,自己亲手编写一个 UNIX 克隆版本。他自嘲这在当时可能是一个疯狂的想法,但最终在 1987 年完成并公开发布,同时出版了配套教科书,专门用来绕过 AT&T 的限制。 - 1975 年贝尔实验室推出 UNIX V6;John Lions 撰写了解读源码的经典教材。 - 1979 年 UNIX V7 合同禁止高校用于教学目的。 - 1984 年 Tanenbaum 开始编写兼容克隆版,1987 年正式发布 MINIX 1.0 及教材。 - 1997 年发布第二版教材,2004 年前后研究重心转向高可靠性操作系统并推出第三版。 --- ### [02:41](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=161s) 欧盟研究资助与软件产品责任法想构 到了 2008 年,项目迎来了根本性转机:Tanenbaum 获得了来自欧盟欧洲研究委员会(ERC)的高达 250 万欧元的科研资助。这笔巨额资助的目标非常明确——研发一款极高可靠性的操作系统。Tanenbaum 直言,这说明官方也意识到当今软件的可靠性已经匮乏到了值得投入真金白银去改变的地步。 在谈到外部监管环境时,Tanenbaum 提到 2009 年欧盟曾探讨将软件纳入常规的“产品责任法”进行监管。他以工业制造为例指出,如果一家轮胎制造商生产的轮胎每一千万条中爆胎一条,厂家绝不能对顾客说“轮胎偶尔就是会爆炸,现实就是这样,习惯就好”;任何实体商品都必须在绝大多数情况下保持正常工作。然而对于软件,大众却普遍接受“它坏了就是坏了”的荒谬现状。Tanenbaum 强调,一旦法律要求软件必须承担与实体商品同等的质量保证,科技巨头就再也无法以“客观上做不到”为由推卸责任。 > Tanenbaum 针对软件监管提出:“And if the EU could say well Tanenbaum did it, why don't you do it that way? Then they would say, 'Well, we don't want to' — that's not as strong as 'It can't be done'.” - 2008 年获得欧洲研究委员会(ERC)250 万欧元科研经费,主攻操作系统的高可靠性。 - 2009 年欧盟内部曾讨论将软件纳入普通商品的产品质量责任法管辖范畴。 - 传统的质量抗辩逻辑认为要求软件不崩溃就像“立法让猪飞起来一样不可能”,而 MINIX 3 试图用工程实践证明高可靠性切实可行。 --- ### [04:19](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=259s) 软件可靠性的现实与“像电视一样”的期望 Tanenbaum 幽默地剖析了黑客与普通大众对可靠性认知的巨大鸿沟。对于程序员与黑客而言,大家的态度往往是:“如果上帝希望软件可靠,他就不会发明复位按钮了(If God had wanted software to be reliable, he wouldn't have created reset buttons)。”如果一台电脑每三个月崩溃一次,用户按下重启键就能恢复,大家甚至会觉得这个系统相当可靠。 但 Tanenbaum 用汽车和家用电视进行了对比:如果一辆汽车每三个月在路上无缘无故熄火一次,车主必须熄火、拔钥匙、下车、掀开发动机盖再合上、重新坐回车内打火才能继续开,哪怕车厂声称“每三个月只需耽误你 10 秒钟”,绝对没有任何消费者会容忍这种缺陷。老奶奶眼中的电子产品应该是电视机:买回家插上电,未来 10 年里它就应该完美无瑕地工作。Tanenbaum 认为,现代软件之所以陷入频频崩溃的泥潭,核心根源在于严重的“软件膨胀(bloat)”。代码规模越来越庞大失控,连 Linus Torvalds 自己都在《PC Pro》杂志上公开发表看法承认这一点。 > Tanenbaum 援引行业言论强调代码规模的失控:“And the headline is, 'Linus Torvalds says Linux is bloated and huge' — this is Linus saying this, this is not Bill Gates.” - 黑客文化习惯了依靠复位键解决问题,而普通消费者期望软件具备像家用电视一样长达 10 年免维护的可靠性。 - 汽车的比喻生动揭示了软件行业长期以来对低可靠性的病态容忍。 - Linus Torvalds 公开承认 Linux 内核变得庞大而臃肿,复杂性正在逼近无人能全局理解的极限。 --- ### [06:18](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=378s) 硬件激增与重新思考操作系统:模块化与自愈 从硬件演进的角度看,Tanenbaum 拿自己桌上的便携笔记本与早年使用的 PDP-11 进行了讽刺性的对比:现在的笔记本算力是 PDP-11 的 5000 倍,价格只有后者的五十分之一,内存与磁盘容量增长了上千倍,体积也小得多;然而,PDP-11 引导系统仅需 5 秒,当今的笔记本开机却需要耗费整整 4 分钟。他痛斥当今的技术环境虽然拥有近乎“无限的时钟周期、无限的内存与无限的带宽”,但却充斥着“无限膨胀、无用且垃圾的软件”。 要让操作系统重获电视机般的坚固性,未来系统必须走向微型化、极简主义与强模块化。Tanenbaum 举了航空母舰的例子来说明模块隔离的重要性:航空母舰远比操作系统复杂得多,但设计者深谙模块化原则——如果航母上的某个马桶堵塞了,系统绝对不会因此误发导弹;反之,当雷达探测到敌方导弹来袭时,马桶也不会自动开始冲水。现代宏内核操作系统恰恰缺乏这种严格的故障隔离。因此,MINIX 3 的研究核心正是通过模块化架构实现“自愈(self-healing)”,在组件发生错误时自动修复,不再依赖人工干预。 ```mermaid flowchart TD accTitle: 复杂系统故障隔离与传统操作系统缺陷对比 accDescr: 对比航空母舰的强隔离模块化设计与传统单体操作系统的故障蔓延问题 subgraph Carrier["航空母舰设计模式(强模块化隔离)"] Toilet["卫生设施模块 (马桶系统)"] -. 严格隔离.- Missiles["防御武器模块 (导弹系统)"] ToiletFail["马桶堵塞故障"] --> ToiletState["仅限局部受损,不触发武器响应"] MissileAlert["雷达告警"] --> WeaponState["仅限防空激活,不影响生活设施"] end subgraph Monolithic["传统宏内核模式(缺乏隔离)"] Driver["第三方设备驱动 (70%代码)"] --> KernelSpace["统一运行在最高内核特权级"] KernelSpace --> FatalCrash["单个驱动内存越界/死锁 -> 全局蓝屏/崩溃"] end ``` > Tanenbaum 指出工程系统隔离的核心价值:“Because the toilet system and the aircraft system, the missile system, are separated very much — they understand you don't want problems in one part going over to another part.” - 硬件性能呈数千倍增长,操作系统冷启动时间反而从 5 秒恶化至数分钟。 - 传统工程领域(如航空母舰)依靠严格的子系统隔离避免连锁灾难,而通用操作系统未能贯彻这一原则。 - 未来的操作系统设计必须依托模块化与自愈机制,在无需用户介入的前提下自动修复崩溃组件。 --- ### [08:05](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=485s) 微内核架构与代码缺陷率的数学现实 Tanenbaum 再次阐述了他长期捍卫的微内核(Microkernel)理念。他列举了工业界广泛应用的高可靠实时微内核系统,如 QNX、Green Hills(INTEGRITY)以及 PikeOS,它们在航空电子和汽车工业中占据核心地位。从代码体量来看,MINIX 3 内核仅有约 6,000 行代码,L4 大约 10,000 行;而 Linux 内核则膨胀至约 600 万行代码,Windows 整体更是超过 1 亿行。 根据软件工程界对工业级代码缺陷率的大量统计,即使是质量控制极严的企业级项目,每千行代码(KLOC)通常也会潜藏 5 到 10 个缺陷。在以高质量著称的 FreeBSD 项目中,缺陷率约为 3 个 / KLOC。如果按这一最优水平推算,MINIX 内核总共大约只有 18 个缺陷,而拥有 600 万行内核代码的 Linux 则可能潜藏 18,000 个缺陷。尽管其中许多并非致命错误,但在 18,000 个缺陷的庞大基数下,致命故障的发生不可避免。 更严峻的问题在于设备驱动程序。斯坦福大学针对 Linux 驱动的研究显示,驱动代码的缺陷率是内核其余核心算法的 3 到 7 倍。开发者热衷于钻研精妙的内存管理算法,却没人愿意耐心审查晦涩打印机长达百页的丑陋硬件驱动。雪上加霜的是,设备驱动占到了整个操作系统代码量的 70%。在 Windows 生态中,官方统计表明 85% 的系统崩溃都是由非微软编写的第三方驱动引起的,系统崩溃往往只是因为台湾某家赶工发布硬件的厂商写出了劣质驱动。 | 操作系统 / 组件 | 代码行数 (LOC) | 预估缺陷基数 (按 3 bugs/KLOC 测算) | 架构运行特权 | |:--- |:--- |:--- |:--- | | **MINIX 3 内核** | 约 6,000 行 | 约 18 个 | 核心特权态 (微内核) | | **L4 微内核** | 约 10,000 行 | 约 30 个 | 核心特权态 (微内核) | | **Linux 内核** | 约 6,000,000 行 | 约 18,000 个 | 核心特权态 (宏内核,含驱动) | | **Windows 整体** | > 100,000,000 行 | 超过 300,000 个 | 核心特权态/混合态 (含驱动) | > Tanenbaum 强调代码规模决定软件质量:“At that rate, MINIX would have maybe 18 bugs in the kernel, and Linux would have 18,000.” - 工业界平均缺陷率为 5-10 bugs/KLOC;FreeBSD 高质量样本为 3 bugs/KLOC。 - 斯坦福大学的研究证实:驱动程序缺陷率是核心算法的 3 至 7 倍,且驱动代码占据了操作系统总体规模的 70%。 - 微软官方统计显示,Windows 平台 85% 的蓝屏崩溃是由第三方驱动缺陷直接造成的。 ### [09:58](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=598s) MINIX 3 的分层微内核架构 Andrew Tanenbaum 解释了应对操作系统故障的根本思路:故障既然难以完全避免,就必须采用模块化设计,在各个组件之间筑起“高墙”。为此,MINIX 3 绝大部分操作系统组件都作为独立的用户空间进程运行。处于最底层的是一个极其精简的微内核,仅包含约 6,000 行代码。它的职责被严格压缩到极限:仅处理硬件中断、进程间通信(IPC)、最底层的时钟以及极原始的进程抽象与调度。Tanenbaum 幽默地指出,内核甚至不理解进程管理的真正含义——“有人对它说:‘这里有个进程,去运行它’,它就跑起来,根本不知道自己在做什么”,甚至原先驻留在内核中的系统服务(System Task)也在逐步往外剥离。 在微内核之上,系统通过开启内存管理单元(MMU)的保护模式划分出多层用户空间进程。驱动程序层位于微内核的正上方,每一个硬件驱动都是一个毫无特权的独立进程,终端、网络适配器、打印机以及磁盘驱动均彼此隔绝。再往上一层是系统服务层,包括文件系统、进程管理器(PM)以及虚拟内存管理器(VM)等。最顶层则是普通的应用程序。在微内核眼里,这些层级并没有本质差别,文件系统和普通工具(如 `make` 或 Shell)享有完全相同的地位。Tanenbaum 对比了各系统的观念差异:在 Unix 世界中,Shell 作为用户程序早已深入人心(如 sh、bash、csh 等),但 Windows 用户很难想象这一点;而对许多 Unix 程序员而言,连文件系统和虚拟内存都能做成纯粹的用户态程序,同样令人难以置信。 ```mermaid flowchart TD accTitle: MINIX 3 架构分层图 accDescr: 展示 MINIX 3 从顶层用户程序到底层微内核的四层隔离架构 subgraph UserSpace ["用户模式 (User Mode - MMU 保护开启)"] direction TB subgraph L3 ["用户程序层"] Apps["用户程序 (Shell, make, POSIX 应用)"] end subgraph L2 ["系统服务层"] Servers["服务器集群 (VFS, PM, VM, DS, RS)"] end subgraph L1 ["设备驱动层"] Drivers["设备驱动 (磁盘, 网卡, 音频, 终端)"] end end subgraph KernelSpace ["内核模式 (Kernel Mode)"] Microkernel["微内核 (约 6,000 行代码)<br/>中断处理 / 基础调度 / IPC / 原始进程抽象"] end Apps --> L2 Servers --> L1 L1 -->|"系统调用 (~35个)"| Microkernel ``` - 微内核代码量仅约 6,000 行,大幅缩减了核心代码引入缺陷的概率。 - 驱动程序与核心服务器全部运行在非特权用户模式下,无法直接执行任何特权 CPU 指令。 ### [11:57](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=717s) 最小权限原则与内核调用机制 为了约束用户态运行的系统组件,MINIX 3 严格践行了“最小权限原则”(Principle of Least Authority, POLA)。这些组件不能调用给普通用户准备的标准 POSIX 接口,而是使用一组专用的内部内核调用(约 35 个)。Tanenbaum 阐述道,所有涉及特权硬件的操作都被彻底剥夺:用户态驱动完全无法访问 I/O 端口。如果驱动想要读取或写入端口,必须向内核发出请求并附带目标端口列表,由内核检查权限后代为执行;由于各服务运行在完全独立的地址空间中,文件服务器即便准备好了磁盘数据块,也没有权限直接拷贝进请求者的内存空间,必须请求内核的系统任务协助搬运。 系统为每个服务分配了细粒度的权限位图。Tanenbaum 举例说明,系统内部有两张关键位图:一张规定了允许执行的内核调用集合(例如一个无需派生进程的音频驱动,其调用 fork 原语的权限会被直接封死);另一张位图规定了 IPC 的通信目标白名单(音频驱动若试图给网卡驱动发消息,内核会立即拦截并返回权限错误)。最形象的体现是硬件端口隔离:磁盘驱动根本不能直接摸到磁盘控制器,必须低声下气向内核申请:“我能往磁盘上写数据吗?”Tanenbaum 调侃道:“对磁盘驱动来说,摸不到磁盘是一次让人学会谦逊的体验,但这就是现实。”针对这种机制的安全优势,Andrew Tanenbaum 强调:“如果病毒或恶意程序攻破了你的系统并控制了音频驱动,它最多只能发出非常怪异的声音,却根本无法接管磁盘,因为当它试图访问磁盘时,系统会直接告知无权访问。” - 系统不提供直接 I/O 操作能力,所有的寄存器读写、DMA 映射、中断向量挂载均须经由内核鉴权。 - 驱动与服务器采用时间片轮转调度;一旦某组件陷入死循环,仅消耗自身配额,绝不会导致整机冻结。 - 服务间无法相互篡改内存,更无法越权修改内核内存空间,彻底消除了驱动 Bug 踩踏内核的隐患。 ### [14:56](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=896s) 用户态文件系统的消息流转与开销分析 Tanenbaum 随后深入剖析了系统内部各核心服务的协作细节,重点展示了文件系统(File Server)在处理一次 `read()` 系统调用时的端到端流程。当应用程序调用库函数 `read(fd, buf, 512)` 时,该请求被封装为一条标准 IPC 消息并发送至文件服务器。文件系统首先检索其内部缓存,如果发生缓存命中(Cache Hit),流程非常轻量: 1. 文件系统检查内部 Cache,命中目标数据块; 2. 文件系统向内核系统任务(System Task)发送请求,请求将其缓冲区跨进程复制到用户应用程序的内存空间中; 3. 系统任务执行拷贝并应答; 4. 文件系统向应用程序回复读取成功,整个命中链路大约只需要 4 条消息交互。 ```mermaid flowchart LR accTitle: 缓存未命中时的磁盘读取消息流 accDescr: 展示文件未命中缓存时在应用程序、文件系统、驱动和微内核之间的多步消息流转 subgraph AppLayer ["应用层"] App["用户程序"] end subgraph ServerLayer ["服务层"] FS["文件系统 (FS)"] end subgraph DriverLayer ["驱动层"] DD["磁盘驱动"] end subgraph CoreKernel ["微内核"] ST["系统任务 / 内核"] end App -->|"1. read()"| FS FS -->|"2. 请求数据块"| DD DD -->|"3. 请求写 I/O 端口"| ST ST -->|"4. 硬件中断通知"| DD DD -->|"5. I/O 完成确认"| FS FS -->|"6. 跨空间复制请求"| ST ST -->|"7. 内存写入"| App FS -->|"8. 响应完成"| App ``` 在缓存未命中的复杂场景下,消息链条会延长:文件系统发现缺页后通知磁盘驱动,驱动请求微内核写入端口启动磁盘读取,并在硬件完成产生中断通知后,读取端口确认状态。随后磁盘驱动通知文件系统读取完毕,文件系统再指示微内核将数据拷贝至应用内存,最后通知应用返回。这整套未命中的调用链大约需要 9 条消息。针对微内核性能经常饱受诟病的质疑,Tanenbaum 列举了量化数据:在现代 CPU 上,单条 IPC 消息的耗时大约在 500 纳秒左右,9 条消息累计产生的通信开销约为 4.5 微秒。然而,一次真正的物理磁盘寻道与读取需要数毫秒(几个 Milliseconds)时间;在数毫秒的机械延迟面前,这 4.5 微秒的微内核开销根本微不足道,绝非系统的瓶颈所在。 - 单次内核消息传递耗时约 500 纳秒,纯内存命中的调用仅需 4 次消息通信。 - 物理 I/O 带来的毫秒级延迟远远掩盖了用户态切换与 IPC 所带来的微秒级开销。 ### [17:24](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1044s) 机制与策略分离:核心服务器与自愈数据存储 Tanenbaum 接着盘点了操作系统其他核心模块的设计哲学。进程管理器(Process Manager)全权负责进程的生命周期逻辑(创建、终止以及信号机制的流转),而微内核本身只保留最底层的调度。这一思想在虚拟内存管理器(Virtual Memory Manager, VM)中体现得尤为彻底:系统贯彻了“机制与策略严格分离”的原则。VM 作为独立的用户态程序,封装了所有的算法与策略,它掌握系统的全局空闲物理页表,处理所有重定向过来的缺页异常(Page Fault),并构建进程映射表。一旦计算完成,VM 仅需调用内核接口下达指令:“这是 6 号进程的内存映射页表,拿去执行。”内核本身不带任何虚拟内存启发式算法,只是盲目服从配置。 在服务器集群中,还有两个特别关键的系统服务:信息服务器、数据存储服务器(Data Store, DS)以及复活服务器(Reincarnation Server, RS)。其中数据存储服务器是一个小型的专职键值/名字服务,各组件可以向其暂存关键数据,随后按需检索。Tanenbaum 透露,DS 的核心价值在于实现“可恢复驱动”(Recoverable Drivers)。要让操作系统在驱动程序发生严重崩溃时具备自愈(Self-Healing)能力,驱动的状态处理是关键痛点。有些驱动拥有的内部状态很少,有些则状态复杂。Tanenbaum 以音频驱动举例:音频驱动通常记录着用户当前的输出音量等微量状态,如果能够把这些状态解耦并持久化保存在 DS 中,一旦音频驱动异常终止被复活服务器重新拉起,系统便能在用户毫无察觉的情况下无缝还原现场并继续服务。 - 虚拟内存管理器(VM)以纯用户态形式实现,内核仅负责载入其计算好的页表,二者完全解耦。 - 数据存储服务器(DS)充当运行时状态的中继站,为驱动程序挂掉后的平滑自愈与状态恢复奠定了技术底座。 ### [18:56](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1136s) 用户空间服务与死而复生的“转生服务器” 在 MINIX 3 中,各种系统服务都被解耦为独立的用户空间进程。例如数据存储服务(Data Store),它保存着音频设备等组件的状态;一旦音频驱动崩溃并被重启,新驱动只需向数据存储索取之前保存的音频音量等数据,就能将设备无缝恢复到崩溃前的状态。此外,信息服务器(Information Server)主要用于调试,用户在键盘上按下各种 F 功能键即可触发转储信息,清晰查看系统当前运行状态;网络服务器则将完整的 TCP/IP 协议栈彻底放在用户空间运行。 在这套体系中,最引人注目的当属“转生服务器”(Reincarnation Server)。正如 Andrew Tanenbaum 所幽默形容的,它的职责就是“让死者复活”(reviving the dead)。作为所有驱动程序与系统服务的父进程,当子进程崩溃挂掉时,转生服务器会负责回收残骸并修复系统。它不仅根据内部规则表处理异常,还会频繁对各个驱动进行心跳探测(Ping)。 Tanenbaum 绘声绘色地模拟了心跳检测的过程:转生服务器询问磁盘驱动最近怎么样,磁盘驱动一开始还得意洋洋地汇报“棒极了!刚才这一秒我跑了 57MB,磁盘转得飞快!”但过了三秒,转生服务器再次探测时,磁盘驱动却一片死寂。转生服务器自言自语道:“唔,情况不妙。”它会继续追问一次,如果仍没有动静,转生服务器便给出最后通牒:“好吧,再给你最后一次机会,要是再不回答,你就完蛋了(you're toast)!”当三次机会耗尽,转生服务器果断出手“大义灭亲”,杀掉这个假死的子进程并重新拉起一个全新实例。 ```mermaid flowchart TD accTitle: Reincarnation Server Heartbeat Check accDescr: 转生服务器对驱动程序进行周期性心跳探测并在三次无响应后执行杀死与重启。 subgraph PingLoop["心跳检测机制"] A["转生服务器 (Reincarnation Server)"] -->|"Ping: 运行状态如何?"| B["磁盘驱动 (Disk Driver)"] B -.->|"正常回应: '每秒处理57MB,运行良好'"| A B -.->|"无响应 (超时计数: 1... 2... 3)"| C{"达到 3 次重试?"} end subgraph Recovery["故障恢复"] C -->|"是"| D["杀死无响应驱动进程"] D --> E["从内存阴影副本启动新驱动"] E --> F["新驱动从 Data Store 恢复状态"] end ``` - **信息服务器(Information Server)**:绑定各 F 键(F1~F12 等),按键即可打印系统内部数据结构的调试转储(Debug Dumps)。 - **网络服务**:TCP/IP 协议栈全量运行于用户态,内核完全不参与网络协议解析。 - **故障判定机制**:转生服务器采取严格的“三次不回应即认定死亡”策略,超限后强制终止并重启。 --- ### [21:22](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1282s) 磁盘驱动透明恢复:内存“阴影副本”与自愈系统 当磁盘驱动正在处理请求时崩溃,MINIX 3 展现出极其精妙的自愈能力。传统系统面临的一个死锁悖论是:如果磁盘驱动已经崩溃,转生服务器该如何从磁盘读取新的驱动可执行文件?Tanenbaum 指出,MINIX 3 的解决方案是在物理内存中始终保留一份磁盘驱动的“阴影副本”(Shadowed Copy)。因此,转生服务器无需访问磁盘即可在内存中直接重新激活根设备驱动;一旦根设备恢复工作,磁盘上的其他所有驱动程序便可以按需重新加载。 整个恢复过程对用户态应用程序是完全透明的。文件服务器(File Server)向磁盘驱动发出读写数据块的请求后,旧驱动突发崩溃。转生服务器发现其超时后迅速启动新驱动,并通告文件服务器旧驱动“不幸离世”。文件服务器转头向数据存储查询是否有新驱动接班,数据存储回应:“你的运气真好,几微秒前刚上线了一个新的,这是它的地址。”当文件服务器将未完成的写块请求交给新驱动时,新驱动欣然领命,声称“除了读块,写块就是我这辈子最喜欢的活动!”用户进程丝毫察觉不到底层发生过一次组件崩溃与重启。 Tanenbaum 坦承,目前的自愈机制在无状态或状态简单的驱动(如磁盘驱动、轻量音频驱动)上表现完美,但在文件服务器这种自身携带复杂内存状态的核心服务上,完全平滑恢复依然是正在攻关的研究课题。正如 Andrew Tanenbaum 所总结的: > “系统具备自我修复能力,它能自行检测问题并在一定程度上自我修复。”(“The system is self-healing it detects its own problems and it can fix itself to some extent.”) ```mermaid flowchart LR accTitle: Transparent Disk Driver Crash Recovery accDescr: 文件服务器在磁盘驱动崩溃后通过数据存储与新驱动对接并完成未竟请求。 subgraph UserSpace["用户与文件服务"] U["用户进程"] -->|"1. read() 请求"| FS["文件服务器 (File Server)"] FS -->|"5. 寻找可用驱动"| DS["数据存储 (Data Store)"] DS -->|"6. 返回新驱动地址"| FS FS -->|"7. 重发读写请求"| D2["新磁盘驱动"] end subgraph DriverManagement["故障接管"] FS -.->|"2. 发送请求"| D1["旧磁盘驱动 (崩溃)"] RS["转生服务器"] -->|"3. 检测死亡并杀死"| D1 RS -->|"4. 内存阴影副本拉起"| D2 end ``` --- ### [23:18](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1398s) 外设驱动崩溃的容错哲学与微内核安全优势 对于其他外设驱动的崩溃,系统采取了务实的容错策略。以以太网驱动为例,以太网本身就是不可靠的尽力而为(Best-effort)传输机制,驱动崩溃导致丢包本就在协议预期之内;如果是 UDP 丢包,上层协议并不保证可靠投递,如果是 TCP 丢包,TCP 自带的重传机制会自动超时重发。打印机驱动如果中途崩溃,由于难以获知断点位置,打印守护进程只需检测到故障后重新打印整篇文件即可;音频驱动若发生异常,最坏情况也无非是声音短暂停顿后从头播放。Tanenbaum 强调,虽然有时无法做到百分之百的无缝平滑,但比起整个操作系统蓝屏死机,播放歌曲打个微小的嗝显然是好得多的结果。 微内核的设计不仅大幅压缩了受信任计算基(Trusted Computing Base, TCB),更阻断了外部不可信代码的侵蚀。Tanenbaum 尖锐地批评了宏内核操作系统的现状:如果在 Linux 或 Windows 上购买一张 FireWire(火线)扩展卡,附带的光盘里装的代码“可能由台湾的某个人随手写成”,直接作为内核模块加载进核心空间。这名开发者当时可能急于交差,公司管理层可能根本不在意质量,但这段粗制滥造的代码却堂而皇之地获得了内核最高权限。 而在 MINIX 3 中,这套驱动只能作为一个普通的用户空间进程启动,即便代码崩溃,遭殃的也仅仅是 FireWire 功能本身,绝不会拖垮整个操作系统。Tanenbaum 总结说,把代码移出内核并没有消灭 Bug 的绝对数量,但它改变了 Bug 的破坏力: > “当然,把 Bug 移到用户空间并不会减少 Bug 的数量……它只是让它们变得威力大减——用户空间进程里的 Bug 能造成的破坏要小得多。”(“Of course moving bugs to user space doesn't reduce the number of bugs… it just makes them less powerful a bug in a user space process can do less damage.”) - **TCB 极度精简**:内核代码行数越少,潜藏的缺陷就越少(按千行代码含 3 个 Bug 的行业均值计算,代码量小意味着总体绝对 Bug 极少)。 - **静态内存分配哲学**:MINIX 3 内核彻底移除了 `malloc` 和 `free` 调用,所有内核表项均采用静态常量固定(如进程数上限直接在头文件定义为 256)。Tanenbaum 指出在现代计算机动辄拥有数吉字节(GB)内存的背景下,为固定表项预留几千字节以彻底消除内存泄漏和碎片,是一笔极其划算的架构权衡。 - **驱动去信任化**:在 MINIX 3 哲学中,所有驱动程序一律被视作“不可信任的代码”(Untrusted Code),并剥夺其修改内核数据结构的权限。 --- ### [26:24](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1584s) IPC 设计演进:从同步汇合到异步消息 在进程间通信(IPC)的实现上,MINIX 3 最初采用了固定长度消息配合汇合机制(Rendezvous System)。发送方发出消息,接收方执行接收,双方握手即完成拷贝,这种机制既不会发生缓冲区溢出,也无需繁琐的内存缓冲区管理。同时,内核将硬件中断统一转化为普通的系统消息发送给对应的驱动程序,驱动收到“来自磁盘硬件的消息”后自行处理,架构极为简洁一致。 然而,纯同步汇合机制在现实中遭遇了严峻的可靠性瓶颈——“生病的客户端”(Sick Client)问题。如果客户端向服务端发送请求后突然意外死亡,服务端处理完毕尝试回复时就会因为找不到接收方而被永久挂起阻塞。业内通常只防备失效的服务端,但客户端失效同样会瓦解微内核的流动性。 为了消除这种导致服务器挂起的隐患,设计团队不得不做出妥协,开始引入部分异步消息机制。尽管 Tanenbaum 本人坦言自己并不喜欢异步消息带来的复杂性,但为了杜绝服务端被死客户端拖累挂死,这一妥协势在必行。通过严格的内存沙箱与消息隔离,C 语言中屡见不鲜的野指针错误在 MINIX 3 中最多只会破坏出错驱动自身的进程空间,既无法跨模块扩散,更不可能触碰到内核的核心数据结构。 ### [27:56](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1676s) 驱动崩溃自动恢复与内存授权机制(Memory Grants) Andrew Tanenbaum 阐述了 MINIX 3 是如何应对驱动程序崩溃与死循环的。当某个驱动程序崩溃时,作为其父进程的转世服务器(Reincarnation Server, RS)会收到一个子进程终止的信号。转世服务器随即查表确认该如何处置,并执行一个 Shell 脚本。该脚本不仅可以记录事件日志、抓取 core dump 保存以供后续调试,还能配置为向系统管理员或硬件厂商发送警报邮件;待一切处理就绪后,脚本会重新拉起该驱动。即便驱动程序或系统服务陷入死循环,转世服务器周期性发起“心跳检测”而连续三次(或设定的阈值)无应答时,也会果断将其杀死并重启。Tanenbaum 自豪地表示:“And so we can survive infinite loops inside critical components of the operating system I mean nobody else can do that.”(“因此我们能够在操作系统核心组件发生死循环时幸存下来,据我所知没有其他人能做到这一点。”)由于驱动均运行在非特权的普通用户态,即使失控也无法造成灾难性破坏。 针对微内核架构下跨进程安全数据传输的需求,MINIX 3 引入了“内存授权”(Memory Grants)机制。例如,当文件服务器需要将磁盘读取的数据块写入用户空间,或者磁盘驱动需要向文件服务器写入数据时,由于双方都是无特权的用户态进程,彼此无法直接触碰对方的地址空间。 ```mermaid flowchart TD accTitle: MINIX 3 内存授权访问控制流程 accDescr: 展示接收方进程向内核注册内存授权表,再通过授权号由内核代为进行字节级安全拷贝的过程。 subgraph UserSpace["用户空间 (User Space)"] Receiver["数据接收方进程<br/>(构建 Memory Grant Table)"] Caller["数据写入方驱动/服务<br/>(持有 Grant Index)"] end subgraph KernelSpace["内核空间 (Kernel Space)"] KTable["内核管理各进程授权表<br/>(记录进程ID、起始地址、字节范围)"] KCopy["内核执行字节级安全拷贝<br/>(Kernel Copy to Address Space)"] end Receiver -->|"1. 系统调用注册授权表"| KTable Receiver -.->|"2. 传递 Grant Index (如 Grant #1)"| Caller Caller -->|"3. 请求内核代写: Grant Index + Buffer"| KCopy KTable -->|"4. 校验权限与字节范围"| KCopy KCopy -->|"5. 写入目标地址并精确到字节"| Receiver ``` 任何希望被写入内存的进程都会构建一张内存授权表,并通过内核调用向内核注册其起始地址和表项数量。授权表项可以精确指定:“允许磁盘驱动程序进程 9 写入本进程从第 1400 字节到 1499 字节的内存”。该机制具有以下关键特征: - **精确到字节级**:完全无需页面对齐(Page Alignment),精确限制到单一字节的范围。 - **内核代为拷贝**:发送方将授权索引(如 Memory Grant #1)传递给驱动,驱动请求内核执行写入,由内核核验权限与边界后代为复制。 - **开销极小且用完即废**:尽管内核介入增加了一点开销,但实现了极致的内存隔离;传输完成后即可抹除授权项,避免后续非法访问。 --- ### [30:53](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1853s) 硬件故障注入实验:250 万次测试与系统的坚韧表现 为了验证 MINIX 3 架构的健壮性,团队进行了大规模的故障注入(Fault Injection)实验。他们使用专门的二进制代码故障生成工具,在 3 个不同的以太网驱动程序中注入真实代码缺陷。该工具并不是随意填充垃圾数据,而是深入分析机器指令和语义,专门模拟程序员最常犯的代码错误: - **寄存器反转**:互换数据传输指令中的寄存器操作数,模拟将 `i = j` 笔误写成 `j = i`。 - **条件分支改写**:将小于分支指令(BLT)篡改为小于等于分支指令(BLE),模拟将 `for (i = 0; i < n; i++)` 错写成 `for (i = 0; i <= n; i++)` 的边界越界缺陷。 实验测试逻辑采取批量渐进方式:每次向驱动注入 100 处缺陷并等待 1 秒观察是否崩溃;如果未崩溃(可能是该秒内未执行到受损代码,或改动无致命影响),则再注入 100 处,直至驱动崩溃为止。最终实验跑了整整 250 万次测试,导致驱动程序崩溃了 18,000 次。 在经历这 18,000 次驱动崩溃的过程中,测试暴露出了各种硬件层面的毛病,甚至发现某些操作能将 PCI 总线彻底卡死,导致除了拔掉物理电源线外无法恢复。然而,MINIX 3 操作系统内核本身在全部 250 万次测试中从未崩溃过一次。Tanenbaum 指出,驱动程序可以被玩弄到反复挂掉,但操作系统依然坚挺,这充分证实了微内核架构的高可靠性。 --- ### [33:11](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=1991s) 从学术玩具到可用 UNIX:完备的用户态生态与构建速度 Tanenbaum 强调,许多学术操作系统的微内核项目往往只能在特定研究生在场时勉强跑通,根本无法真正运行实际软件。而 MINIX 3 则投入了巨大精力,打造成了一个完全可用、符合 UNIX 规范的操作系统。尽管它不如现代主流 Linux 或 BSD 那么复杂华丽,但已经具备完整且熟悉的 UNIX 开发与运行环境: - **图形界面与桌面**:支持 X11 窗口系统以及轻量级桌面环境 EDE(Equinox Desktop Environment)。虽然暂无内核线程导致还无法运行 GNOME 或 KDE,但大多数开发者需要的仅是 X11 配上一堆 xterm 终端。 - **Shell 环境**:提供了 Bash、PD-KSH(Public Domain Korn Shell)、Zsh 等多种 Shell。 - **编程语言与双 C 编译器**:支持 C、C++、Python、Perl、PHP 等。系统同时自带两种 C 编译器:一种是功能庞大且令人头疼的 GCC,另一种是作者团队自主研发的 ACK(Amsterdam Compiler Kit)。ACK 严格遵循 ANSI C 标准,Tanenbaum 甚至吐槽道:“I wish GCC implemented ANSI standard C, but it doesn't.”。ACK 的编译速度极其惊人,构建包含 MINIX 微内核、所有用户态驱动与服务器在内的整套操作系统(总共 125 次编译和 11 次链接),仅耗时 8 到 9 秒,全程不到 10 秒。 - **编辑器与常用工具**:涵盖 Emacs、nvi、Vim、Vile、mg 等编辑器;图像工具包含 ImageMagick、JPEG 工具包及 XV。 - **三套工具包并存**:系统同时内置了 Version 7 经典 UNIX 工具包、GNU 工具包以及 BSD 工具包,分别存放在不同目录下。用户只需调整 `PATH` 环境变量的前后顺序(如将 `/usr/gnu` 或 BSD 目录置于最前),就能自由决定优先使用哪一派别的工具套件。 - **网络、数据库与应用生态**:支持 Apache、Dillo、Links、Lynx 等网络应用(缺少 Firefox 主要是因为其依赖内核线程且移植难度极大);邮件客户端支持 Pine 等;数据库支持 PostgreSQL、SQLite 及 MySQL Client;还移植了 MPlayer、NetHack、Subversion 等,整体收录了大约 600 个应用软件包。 - **虚拟机运行 Windows 98**:系统移植了 QEMU。由于 Windows 98 当年运行在 60MHz 的奔腾处理器上,即使 QEMU 带来约 10 倍的软件模拟损耗,在现代机器上仍相当于一台 300MHz 的奔腾 II,使得 Windows 98 在 MINIX 3 之上流畅运行,实际体验甚至快于当年的原生硬件。 关于系统的关注度,Tanenbaum 列举了官方网站(minix3.org)的实际流量数据: - 过去一年中,网站月访问量稳定在约 25,000 次。 - 自 2005 年底网站上线至 2010 年约 4 年间,累计独立访问量已达 160 万次。Tanenbaum 评价道,这个数字虽然无法同 Linux 相提并论,但对于低预算的学术开源项目来说已相当可观。 - 过去一年中,MINIX 3 系统的安装镜像每月下载量稳定在 12,000 次左右。 ### [37:37](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2257s) 社区规模与招聘:招募阿姆斯特丹的全职内核黑客 MINIX 3 在过去大约四年时间里累计获得了 610,000 次下载。Andrew Tanenbaum 坦率地指出,尽管这与 Linux 相比不值一提,但与其他同类开源项目相比,60 万的下载量足以证明外界对它的浓厚兴趣。当前的核心团队由 Tanenbaum 本人领导,包括 5 名博士生、1 名博士后、2 名学生助教、3 名全职受薪程序员、数名硕士生,以及去年加入的 4 名 Google Summer of Code(GSoC)学生和全球各地的志愿者。 现场演讲兼具公开招募的目的。Tanenbaum 吐槽了大量开源软件在移植性上的拙劣表现:“几乎每个人都在某个阶段上过软件工程课,但所有人都在考完试的第二天把内容忘得一干二净,那么多自由软件居然写得如此差劲,毫无可移植性。”他调侃道,运行 `./configure` 几乎总是失败,往往只因找不到像 `Perl 5.2.3.26.94b` 这样的特定版本就直接报错退出,哪怕待编译的软件根本不用 Perl;那些由生成器自动生成出来的 20,000 行复杂脚本完全是一团乱麻。团队迫切需要志愿者协助将程序和库移植到 MINIX 3,并参与维护和翻译 Wiki 文档。此外,得益于欧盟的科研资助(EU Grant),Tanenbaum 正在招募第 4 位全职程序员,同时为另一关联项目招募第 5 位程序员,工作地点均在荷兰阿姆斯特丹。他向台下打趣:“如果你正在给卫浴设备公司做网页设计且并不喜欢这份工作,不如来阿姆斯特丹拿全职薪水做内核黑客(Kernel Hacking)。” - **下载数据**:约 4 年内实现 610,000 次下载。 - **团队构成**:Tanenbaum 本人、5 名博士生、1 名博士后、2 名助教、3 名全职程序员、数名硕士生、4 名 GSoC 学生及外部志愿者。 - **开源招聘岗位**:2 个全职受薪程序员名额(工作地点:荷兰阿姆斯特丹,需通过邮件投递简历)。 --- ### [40:26](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2426s) 当前研发方向:热更新、多核与重构文件系统 在研发进展方面,MINIX 团队的首要目标是实现热更新(Live Update),即在系统保持运行且所有进程不受干扰的情况下动态替换组件。Tanenbaum 以智能电视举例:现代电视不再是单纯的硬件,内部运行着包含约 40MB 代码的软件系统;如果在“超级碗(Super Bowl)”比赛进入最后几分钟的关键时刻,电视屏幕突然弹出“正在重启”并耗时 7 分钟升级系统,观众就会错过最后的进球,这对于用户或银行等不能停机的机构来说是无法接受的。因此,MINIX 3 力求实现逐个组件的动态在线替换,哪怕在更新过程中系统可能仅会出现数秒轻微卡顿,也绝不重启。 面对多核处理器的普及,团队正探索“多服务器遇上多核(multiserver meets multicore)”架构。MINIX 3 本身由大量独立的用户空间进程(服务器)构成,这与多核芯片拥有众多硬件核心的特性天然契合,团队正研究如何将不同的系统服务绑定到各自的独立核心上运行。同时,团队还在着手重构文件系统。Tanenbaum 尖锐地指出,现存的文件系统本质上依然是 1965 年 Multics 系统的产物,过去半个世纪唯一的改动仅仅是路径分隔符——Multics 用大于号(`>`),Unix 改用正斜杠(`/`),Windows 则用反斜杠(`\`)。来到 2010 年,理应从零构思面向未来的全新文件系统,并重点攻克有状态服务(Stateful Services)的崩溃恢复难题。 ```mermaid flowchart TD accTitle: MINIX 3 当前重点研发方向 accDescr: 展示 MINIX 3 正在进行的四大技术革新:热更新、多服务器多核结合、文件系统重构及有状态服务恢复。 subgraph Research["MINIX 3 当前前沿工作"] LU["动态热更新 (Live Update)<br/>在线替换组件,消灭系统重启"] MC["多服务器与多核结合<br/>各系统进程独立调度至物理核"] FS["重构文件系统<br/>跳出 1965 年 Multics 的传统架构"] SR["有状态服务恢复<br/>解决状态保持型组件的故障自愈"] end LU --> Target["构建高可靠、不宕机的现代操作系统"] MC --> Target FS --> Target SR --> Target ``` - **热更新目标**:无缝在线更新系统组件,杜绝补丁重启导致的服务中断。 - **硬件适配**:探索多服务器架构在多核 CPU 上的映射,让多进程与多计算核心一一匹配。 - **文件系统**:打破 1965 年 Multics 以来 45 年未曾发生根本变革的传统文件系统设计。 --- ### [42:25](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2545s) 软件授权、市场定位与浣熊吉祥物 MINIX 3 采用 BSD 许可证,Tanenbaum 戏称其条款极其简单:“除了起诉我们之外,你想干什么就干什么。”谈及开源许可证之争,他回忆自己在澳大利亚 Linux 大会(linux.conf.au)做主题演讲时,台下有人询问 MINIX 的授权方式,他本以为说出 BSD 会招来观众扔西红柿,没想到却迎来了全场 Linux 爱好者的大声喝彩。虽然 MINIX 3 系统中也包含大量 GPL 软件包,但它们均作为外部扩展附加件提供,在必要时甚至可以单独拆分刻录在第二张 CD 上。 在定位上,Tanenbaum 重申系统的本质在于“多服务器系统”,微内核只是其实现手段,其核心理念是证明设备驱动应当运行在用户空间。MINIX 3 的目标场景涵盖超高可靠与容错应用、嵌入式系统,以及未来面向发展中国家的 50 美元单芯片小内存笔记本(如 OLPC “每个孩子一台笔记本”的下一代产品)。MINIX 3 还选用了野生浣熊作为官方吉祥物。Tanenbaum 笑着解释道:“每个人都得选个动物当标志。浣熊体型小巧、聪明机敏,而最重要的一点是——它吃虫子(Bugs)。”在总结发言中,他指出当前主流操作系统臃肿且不可靠,MINIX 3 凭借微小内核、受限权限和动态驱动恢复,为高可靠操作系统开辟了新道路。 --- ### [44:48](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2688s) 现场问答:对比 Chrome OS 与微内核性能损耗 在提问环节,一名观众询问 MINIX 3 与谷歌的 Chrome OS 是否在设计哲学上有相似之处。Tanenbaum 回应称,Chrome OS 本质上只致力于运行一个程序,那就是浏览器本身,对于只需要稳定浏览器的普通用户而言这或许足够,但 MINIX 3 是一套完整的操作系统,能够运行标准 Unix 生态下的所有常规软件。 随后,另一位开发者针对进程间消息传递带来了约 500 纳秒的延迟提出质疑,指出音频处理领域的开发者对哪怕 5 微秒的延迟都非常敏感,甚至极力追求降至 1 到 2 微秒。Tanenbaum 直率地回答:“老奶奶根本不知道什么是微秒;如果你是一个想榨干硬件最后一滴性能的人,那很遗憾,这个系统不是为你准备的。”他回忆自己当年拿到第一台 60MHz 的奔腾 1(Pentium 1)处理器时觉得不可思议,因为它比他早年使用的 PDP-11 快了整整 100 倍,然而总有人觉得硬件速度永远不够用。Tanenbaum 坦承 MINIX 3 追求的是极端可靠性而非极限性能,虽然团队自身未精确测量整体损耗,但同样采用微内核架构并进行过深度优化的 L4 团队测得,微内核机制带来的整体性能损耗大约在 5% 到 10% 之间,“如果 5% 到 10% 的损耗对你来说实在太高,那这个系统确实不适合你。” - **Chrome OS 异同**:Chrome OS 核心服务于单一浏览器应用,而 MINIX 3 支持完整的 POSIX/Unix 环境。 - **微内核开销**:消息传递存在约 500 纳秒延迟;参考 L4 的优化数据,微内核总性能损耗通常在 5% 至 10% 左右。 - **设计取舍**:在绝对的极致性能与系统的自我修复高可靠性之间,MINIX 3 明确选择后者。 ### [47:15](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2835s) 性能与可靠性的权衡:祖母与戴尔电脑的类比 有观众提问,在采用微内核与混合设计时,MINIX 3 如何定位自身所能达到的性能水平。安德鲁·塔能鲍姆(Andrew Tanenbaum)坦诚地回应道,追求极致性能从来都不在他们的首要议程上。他生动地举了一个普通消费者购买电脑的假想例子:如果一位普通的老奶奶打电话给戴尔公司购买新电脑,销售人员向她提供两种选择——一款是运行在 3 GHz 但偶尔会崩溃的高性能机型,另一款则是运行在 2 GHz 但承诺永远不会死机崩溃的机型,那么绝大多数普通用户肯定会毫不犹豫地选择后者。 塔能鲍姆指出,虽然计算机科学界经常执着于微小的性能开销,但日常用户的核心诉求是稳定可靠。对于那些极度渴求极限速度的游戏玩家或特定专业人员来说,MINIX 3 目前的设计或许不合适;但对于普通大众而言,现代硬件早已足够快速。安德鲁·塔能鲍姆明确表达了他对系统稳定性的执着追求:“我敢打赌他们能卖出很多 2 GHz 的型号;虽然我没有实际数据,但我有一种非常强烈的直觉,那就是有极多的人愿意牺牲三分之一的性能,甚至我个人愿意放弃 50% 的性能,只要你能保证它从一开始就永远不崩溃。” - 现代处理器的计算能力对普通应用已绰绰有余,追求 100% 稳定的价值远高于压榨最后一点主频性能。 - 极速发烧友不是当前 MINIX 3 的目标用户,该系统旨在解决系统崩溃给普通人带来的挫败感。 ### [48:19](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2899s) 重生服务器自身的单点故障与三重模块冗余(TMR) 现场观众紧接着提出了一个尖锐的架构问题:既然驱动和服务都由重生服务器(Reincarnation Server)进行监控与拉起,那如果重生服务器本身崩溃了该怎么办?塔能鲍姆非常坦率地承认:“如果不采取额外措施,那我们就会直接陷入瘫痪(dead in the water)。”但他随即解释了在理论与工程上可行的解决方案,即引入容错计算中经典的“三重模块冗余”(Triple Modular Redundancy, 简称 TMR)机制。 在 TMR 方案下,系统可以同时并行运行三个独立的重生服务器副本,彼此之间相互监控并对决策进行二对一投票表决。一旦其中某一个副本崩溃或表现异常,另外两个正常的副本就可以立即将其终止并重新创建新副本。塔能鲍姆补充说明,之所以目前没有在 MINIX 3 中直接引入 TMR,是因为重生服务器的代码极其简短,总共只有大约 10 页纸的代码量;由于其逻辑极为简单清晰,在实际运行中从未遇到过崩溃问题。如果未来对极端关键任务有需求,完全可以随时切入 TMR 机制。 ```mermaid flowchart TD accTitle: 重生服务器的三重模块冗余架构 accDescr: 展示三个对等的重生服务器副本通过表决机制相互监控与修复 subgraph TMR["三重模块冗余 (TMR) 监控层"] RS1["重生服务器 A"] RS2["重生服务器 B"] RS3["重生服务器 C"] end VOTE{"多数表决仲裁 (2/3 多数)"} ACTION["剔除异常副本 / 重启新副本"] RS1 --- VOTE RS2 --- VOTE RS3 --- VOTE VOTE -->|"检测到不一致或失效"| ACTION ``` ### [49:03](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2943s) 启动速度与权限位图的可扩展性 关于系统的启动速度,观众询问 MINIX 3 究竟比传统操作系统快多少。塔能鲍姆澄清,计算机开机时绝大部分时间实际上消耗在主板固件与硬件自检阶段(例如 BIOS 检查内存设备),通常需要 20 到 25 秒左右。一旦底层硬件自检完毕并将控制权移交给操作系统,MINIX 3 基础系统的实际加载与启动仅仅需要两三秒的时间,整体开机流程大约在 10 到 15 秒左右。 随后观众就系统内核的权限管理位图提出了可扩展性疑问:内核使用位图限制服务通信,目前是否限制在 32 个驱动或服务。塔能鲍姆解释说,当前内核确实使用的是 32 位的整型位图,但这完全能够满足目前系统的需求,因为常驻的核心服务器和驱动程序总共只有 15 到 20 个左右。如果未来系统接入的外设驱动超过 32 个,只需将位图数据类型从 32 位扩展为 64 位或使用多字数组即可,这在工程实现上毫无难度。他特别强调,这个位图仅仅约束特权服务之间的 IPC 通信权限,而海量的普通用户进程是完全不受此限制的;用户进程遵循标准 POSIX 接口,彼此之间只能通过管道(pipes)通信,不能随意向驱动发送内核消息。 - **启动时间分解**:开机大部分耗时发生在硬件检测与 BIOS 阶段;MINIX 3 系统核心初始化仅需两到三秒。 - **IPC 权限位图**:当前采用 32 位位图,覆盖系统内 15~20 个驱动与核心服务已绰绰有余。 - **用户进程隔离**:用户层程序无法直接向驱动程序发送原始 IPC 消息,权限隔离不会限制用户进程数量。 ### [51:01](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=3061s) 数据存储服务崩溃应对与 ARM 移植的现实困境 针对“数据存储服务(Data Store)崩溃后连带导致驱动无法恢复”的顾虑,塔能鲍姆将讨论引向了可信计算基(Trusted Computing Base, TCB)的概念。他强调,MINIX 3 的核心设计哲学之一就是尽可能缩减 TCB 的规模。目前包括微内核、重生服务器和数据存储在内的核心关键代码总量只有大约 20,000 行。数据存储服务因为逻辑简单、吞吐交互频率低,发生故障的几率极低,同样也可以在需要时应用 TMR 冗余技术来保障绝对可用。 谈及将 MINIX 3 应用于电视机等嵌入式系统时,塔能鲍姆无奈地分享了向 ARM 架构移植的波折历程。尽管团队一直渴望推进 ARM 移植以进军嵌入式领域,但纯粹依赖志愿者的模式遇到了严峻挑战。前后有两位开源志愿者启动了 ARM 分支的移植工作,但都在半途因为“失去兴趣或移情别恋”而放弃离开,导致 ARM 端口迟迟未能完工。 安德鲁·塔能鲍姆在此处打破了开源社区普遍存在的某种浪漫幻觉,直言不讳地指出:“我最近在某处读到,超过 75% 的 Linux 代码都是由 IBM、Red Hat 和其他几家公司雇佣的带薪程序员编写的;那种全靠普通用户自发贡献代码的故事虽然听上去很美好,但其实并不是现实情况。”正因如此,他正积极筹措资金以聘请全职受薪程序员来攻坚 ARM 端口,因为志愿者在现实生活中往往有其他优先事项要处理,业余编程往往只能退居其次。 ### [53:00](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=3180s) 致命不可逆操作(导弹发射)与崩溃自愈的策略控制 一位观众提出了一个极具戏剧性的场景:“如果一艘航空母舰正在发射导弹,此时负责该指令的内核进程崩溃了,重生服务器自动将其重启,这会不会导致系统再次发射一枚新导弹?我们能否对特定进程进行编程,禁止这种无休止的自动重试?” 塔能鲍姆确认这完全处于系统策略的掌控之中。他解释道,当任何驱动或服务崩溃时,重生服务器并不是机械盲目地立刻重启它,而是会先检索内部的配置表,并触发执行一段可编程的 Shell 脚本。系统管理员完全可以在脚本中自定义特定策略——例如指示系统:“立即停止并告警,不要重启该服务,向管理员发送通知邮件”,或者执行特定的安全回滚,而不是简单粗暴地重复执行未完成的任务。因此,对于具有物理危险性或不可逆副作用的敏感任务,完全可以通过配置策略来精准规避二次触发。 - 重生动作不是硬编码的盲目重启,而是由外部 Shell 脚本和策略表驱动。 - 关键不可逆业务可以配置为“崩溃即冻结”,防止在物理世界造成重复执行的灾难。 ### [53:50](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=3230s) 瞬态故障与算法缺陷的区别,以及 DMA 硬件失效处理 最后,一位具备软件开发与测试背景的观众提到了一个典型现象:QA 测试人员经常会提交数个一模一样的 Bug,内容全是“点击此按钮导致崩溃,再次点击依然崩溃”。如果磁盘驱动由于算法缺陷导致崩溃,文件系统重发完全相同的损坏请求,系统会不会陷入死循环?针对不可靠硬件或驱动错误配置 DMA(直接内存访问)的情况,MINIX 又能做什么? 塔能鲍姆深入剖析了软件工程中“瞬态错误”(transient errors)与“算法致命缺陷”(algorithmic bugs)的根本差异。如果磁盘驱动存在纯粹的数学或逻辑错误(例如无法正确将线性逻辑块地址 LBA 转换为柱面、磁头和扇区),那么重启无论多少次都无法修复代码本身的缺陷。但软件工程的大量统计数据与实践经验表明,操作系统与驱动中绝大多数导致崩溃的严重故障都是由细微的时序竞争(race conditions)或罕见的并发冲突引起的瞬态故障。对于这些问题,状态清零并重启往往能立刻恢复正常服务。 针对确实存在代码设计缺陷或硬件损坏的情况,塔能鲍姆提出了多版本驱动容错设想: - **算法缺陷与瞬态故障**:绝大多数驱动崩溃属于时序交织导致的偶然瞬态故障,重启能解决绝大部分实际问题;如果是发布前未被测试出来的硬性算法 Bug,运行时重置无法自动修复逻辑。 - **多版本平滑降级(N-Version Programming)**:系统可以准备由不同人员编写的两个独立实现,或保留已知稳定的历史旧版本;Shell 脚本在检测到第一代驱动崩溃后,可无缝激活备用驱动或老版本驱动接管硬件。 - **硬件损坏与 DMA 错误**:如果硬件 DMA 控制器本身在物理层面损毁,任何软件都无能为力,必须更换硬件设备;但如果是驱动程序写错了 DMA 寄存器控制字,系统同样可以通过切换回上一版正常驱动来暂时恢复运行。 ## Notable quotes > [47:15](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2835s) 有极多的人愿意牺牲三分之一的性能,甚至我个人愿意放弃 50% 的性能,只要你能保证它从一开始就永远不崩溃。 — Andrew Tanenbaum > [37:37](https://www.youtube.com/watch?v=bx3KuE7UjGA&t=2257s) 几乎每个人都在某个阶段上过软件工程课,但所有人都在考完试的第二天把内容忘得一干二净,那么多自由软件居然写得如此差劲,毫无可移植性。 — Andrew Tanenbaum ## Mentioned MINIX 3, Andrew Tanenbaum, Linux, Linus Torvalds, AT&T, Bell Labs, John Lions, European Research Council, FreeBSD, QNX, Green Hills Software, PikeOS, L4, Windows, Amsterdam Compiler Kit, GCC, Multics, Chrome OS, IBM, Red Hat, QEMU, FOSDEM ## Video description By Andrew Tanenbaum MINIX started in 1987 and led to several offshoots, the best known being Linux. MINIX 3 is the third major version of MINIX and is now focused on very high-reliability and security. MINIX started in 1987 and led to several offshoots, the best known being Linux. MINIX 3 is the third major version of MINIX and is now focused on very high-reliability and security. When you buy a TV set, you just plug it in and it works perfectly for the next 10 year. We are trying to make operating systems as good as that. The current version of MINIX 3 can detect device driver crashes and some server crashes and automatically replace the failed component without user intervention and without affecting running processes. The talk will discuss these aspects as well as new work. FOSDEM (Free and Open Source Development European Meeting) is a European event centered around Free and Open Source software development. It is aimed at developers and all interested in the Free and Open Source news in the world. Its goals are to enable developers to meet and to promote the awareness and use of free and open source software. More info at http://fosdem.org [Source](https://www.youtube.com/watch?v=bx3KuE7UjGA)

Source quotes

[47:15] Andrew Tanenbaum: 有极多的人愿意牺牲三分之一的性能,甚至我个人愿意放弃 50% 的性能,只要你能保证它从一开始就永远不崩溃。 [37:37] Andrew Tanenbaum: 几乎每个人都在某个阶段上过软件工程课,但所有人都在考完试的第二天把内容忘得一干二净,那么多自由软件居然写得如此差劲,毫无可移植性。

Source quotes

[23:18] Andrew Tanenbaum: If the audio driver goes down and the result is there's a small glitch and then the song plays again from the beginning, that's better than an operating system crash.

Original transcript

[0:20] okay wait I haven't given the talk yet [0:23] um and I have a tendency to talk too [0:26] long so I have taken measures [0:30] preventative measures um unfortunately I [0:33] am as sick as a dog but I have a [0:36] background in theater and as we say the [0:39] show must go on and so I'll give it my [0:42] best shot here um I hope you can [0:44] understand me though [0:46] hello [0:48] hello hello am yeah it's okay okay um [0:54] I'm I'm Andy Tanner Bal and I'm going to [0:56] talk about Minix 3 and I'm sort of [0:59] running the project but there's a whole [1:01] bunch of other people too and I didn't [1:02] have enough space to list everybody but [1:05] I sort of take my word for it there's a [1:06] whole bunch of other [1:08] people um now what uh oh no do do [1:12] something here we go okay let let me um [1:15] start with a A Brief History of Minix [1:18] it's got a somewhat strange history and [1:20] and uh it's confused a lot of people in [1:23] 1975 Bell ABS released Unix version 6 [1:26] that was the first one that got out of [1:28] bell ABS okay it was a huge success John [1:31] Lions a professor at the University of [1:32] New South Wales wrote a book describing [1:35] uh version six a little booklet it's [1:36] become a real classic um describing it [1:39] it was people taught that at university [1:41] courses for a number of years and then [1:43] um AT&T in its wisdom when it released [1:46] version 7 1979 put in a clause in the [1:50] Conta saying Thou shalt not teach this [1:52] in courses okay you know it's our [1:54] product we want to keep it secret we [1:55] don't want anybody to know about it and [1:57] so that was a a brilliant move on AT&T's [1:59] marketing Department that's why Unix [2:01] rules the world now um in 1984 you know [2:04] I was teaching an operating systems [2:06] course and since we were forbidden you [2:08] know by contract from teaching and I [2:09] decided to write a clone of this myself [2:12] which is probably a crazy idea but um I [2:15] did in 1987 I actually finished it and I [2:18] released it and I wrote a book about it [2:21] and so it sort of got out there it was [2:23] mostly for teaching purposes to get [2:24] around the stupid contract from AT&T [2:27] okay then there was a second edition of [2:28] the book 10 years later and then we sort [2:31] of got interested in doing research on [2:33] reliable operating systems in about 2004 [2:37] there's another version book came out [2:38] and then in 2008 everything sort of [2:41] changed I got a grant from the European [2:44] Union from the European research Council [2:47] okay and a couple of words about the [2:49] grant um Grant was2 and a half million [2:51] euro okay so it's just a fair amount of [2:52] money and the goal was to develop a [2:55] highly reliable operating system so you [2:58] know apparently they think that [2:59] liability is lacking now if they're [3:02] willing to give me2 and5 million EUR to [3:03] try to make one so they at least thought [3:07] you know this is worth some real money [3:08] to make one um in 2009 there was a [3:12] discussion within the EU which didn't [3:14] come to fruition but there was a [3:17] discussion of having softer fall under [3:18] the standard product liability laws if [3:21] you're a tire manufacturer and one tire [3:23] in 10 million explodes you can't say [3:26] tires explode sometimes that's the way [3:28] it is you know get used to it it doesn't [3:30] work okay you know it's got to actually [3:33] work all the time with software if it [3:35] doesn't work people say it doesn't work [3:37] that's the way it is you know if [3:38] software fell under liability laws like [3:41] everything else does all of a sudden [3:43] companies would be liable for selling [3:45] software doesn't work that really [3:47] changes the situation and um you know i' [3:50] I've been interviewed a number of times [3:51] with this people say you know well what [3:53] difference it make I said you know [3:54] suppose they go to Microsoft and say you [3:56] know um by law your software has to work [3:59] and they say it can't be done you know [4:01] you can't make a law saying pigs can fly [4:03] and if the EU could say well tanam did [4:05] it why don't you do it that way then [4:07] they would say well we don't want to um [4:10] that's not as strong as it can't be done [4:12] and so you know that's sort of direction [4:14] we're [4:15] going couple of words about software [4:19] reliability um hackers like all of us [4:22] have very much the view you know if God [4:25] had wanted software to be reliable he [4:27] wouldn't have created reset buttons okay [4:30] you know [4:33] so you [4:35] know your grandma however thinks why [4:39] isn't it like a TV you know you buy it [4:41] you plug it in and it works perfectly [4:43] for the next 10 years you know why [4:45] aren't computers and software like TVs [4:47] now because we all know you know because [4:49] the software is changing every 45 Nan [4:51] seconds you know and so on but a lot of [4:53] people kind of you know want it to be [4:56] like that and so I think you know like [4:58] if your soft if your computer crashes [5:00] once every 3 months you hit the reset [5:01] button you think it's really reliable [5:03] suppose your car stopped working once [5:05] every 3 months at random for no [5:07] particular reason and you knew from [5:09] experience you get out of the car take [5:10] the key out you know open the hood close [5:12] the hood again get back in the car put [5:13] it it works you know you said no big [5:15] deal you know I think most people [5:16] wouldn't like that from their car even [5:18] though the car manufacturer said what's [5:20] the big deal it cost you 10 seconds [5:21] every three months no big deal I people [5:23] wouldn't like that but we're used to [5:25] software not working but grandma isn't [5:27] so the question is can we make soft that [5:30] Grandma actually might think is pretty [5:31] good um I think the main cause of the [5:34] problems is bloat in software there's [5:36] all that code and it's getting bigger [5:38] and bigger and so on um you know windows [5:41] and Linux and everything else growing [5:43] like crazy um I saw this article in PC [5:46] Pro magazine just a couple of months ago [5:49] and the headline is lenus tval says [5:51] Linux Linux is bloated and huge this is [5:54] Lena saying this this is not Bill Gates [5:57] okay so you know Bill Gates said Linux [5:59] is blooded and huge I you know okay but [6:01] lenus is say lenus had said Windows is [6:03] bloed and huge okay but even lenus [6:05] thinks that you know Linux has got out [6:07] of hand that there's certainly nobody [6:08] who understands all of Windows maybe [6:11] lenus understands all of the Linux [6:12] kernel maybe but you know things have [6:15] just gotten I think out of hand so I I [6:17] have the [6:18] feeling that there's a need to rethink [6:20] operating systems and the research that [6:22] we're doing is in that direction we have [6:24] basically infinite Hardware my little [6:26] notebook here has 5,000 times the [6:28] computing power of the PDP 11 I sort of [6:30] started with you know it's smaller also [6:33] at to mention it's you know 150th the [6:35] price and has you know a thousand times [6:37] more memory and a disc a thousand times [6:39] the bigger nevertheless booting The [6:41] Notebook takes about four minutes and [6:43] beating booting the pdp11 took 5 seconds [6:45] and a machine 5,000 times slower what's [6:48] wrong with this picture Okay um there's [6:51] infinite Cycles there's infinite Ram [6:53] there's infinite bandwidth and there's [6:55] infinite bloated useless crappy software [6:57] okay and so you got all this bad [7:00] software and to become more like a TV [7:03] you know I think future operating system [7:05] has to become smaller simpler more [7:07] modular which is very important um the [7:09] modularity is I mean people have built [7:11] more complicated things than operating [7:13] systems an aircraft carrier is much more [7:15] complicated than an operating system but [7:17] aircraft carriers are very very modular [7:19] the designers understand that so like if [7:22] a toilet gets clogged on the aircraft [7:23] carrier it doesn't begin firing missiles [7:26] okay because the toilet system and the [7:29] aircraft system the the missile system [7:31] are separated very much they understand [7:34] you don't want problems in one part [7:36] going over to another part you know and [7:38] likewise if an incoming missile is [7:40] detected the toilets don't start [7:41] flushing it's you know they really [7:44] understood about building modular [7:45] systems in most other worlds and we [7:48] don't okay and make it reliable and [7:50] secure and I think self-healing is a [7:53] major part of this it has to fix itself [7:55] people don't understand it anymore so [7:56] that's where our stuff is going I'm not [7:58] talk about intelligence design at least [8:01] that's applied to operating [8:03] systems [8:05] um I'm I'm well known for espousing micr [8:08] kernels and I I still believe that um [8:11] you know ARS is about 6,000 lines L4 I [8:13] think is about 10,000 lines it's Q andx [8:16] Industrial Systems you know greenh Hills [8:18] and and Pike and Q andx there's lots of [8:20] Industrial Systems in avionics and [8:22] automotives that are micr kernels and [8:23] they're all in the order of you know 5 [8:25] 10,000 lines of code versus 6 million [8:27] for Linux and I think Windows is up [8:29] probably above 100 million now [8:30] altogether um been a lot of studies [8:33] about how many bugs there are per line [8:34] of code okay um you know if you find a [8:37] bug you just fix it you know done in [8:39] Industry that's not the way it works [8:40] many companies have careful bug tracking [8:42] systems you find a bug you have to [8:44] report it using some automated bug [8:45] reporting system and they get a log of [8:47] um you know how many bugs they found and [8:50] experience is there about 5 to 10 bugs [8:52] per thousand lines of code in industrial [8:55] projects where they're really careful [8:56] about quality control there's a study in [8:58] FreeBSD which is very very good quality [9:00] control three bugs per thousand lines of [9:02] code that's considered very very good [9:04] okay at that rate Minix would have maybe [9:06] 18 bugs in the kernel and Linux would [9:08] have 18,000 now of course not all the [9:10] bugs are fatal so maybe you know [9:11] spelling errors on messages and you know [9:13] minor stuff but if you got 18,000 errors [9:16] they're going to be some that are going [9:17] to be important even though many [9:20] aren't um also there was a study at [9:22] Stanford of the Linux drivers and they [9:24] have about three to seven times more [9:26] bugs than the rest of the kernel because [9:28] everybody wants to look at the memory [9:29] algorithm that's really cool and neat [9:31] and fun but nobody wants to look at the [9:33] driver for some obscure printer okay [9:35] because it's no fun at all it's a real [9:37] mess it's you know 100 pages of yuck [9:39] okay and unfortunately 70% of the code [9:41] is the drivers they have an error rate [9:43] of three to seven times you know I mean [9:45] that's where the problems come in um in [9:47] Windows it's known that 85% of all [9:49] crashes are due to drivers not written [9:51] by Microsoft and they get the blame for [9:53] it but it's some random guy in Taiwan [9:55] who was in a big hurry to get his driver [9:57] out who wasn't very careful and that's [9:58] where the trouble comes from [9:59] so in a modular design with sort of [10:02] walls around the pieces you got a chance [10:03] to to do this so R OS runs as multiple [10:07] user level processes so the operating [10:09] system runs basically in user mode so [10:12] here's um the basic architecture of of [10:14] Minix 3 the um the micr kernel at the [10:17] bottom it's about 6,000 lines of code [10:19] and it handles the interrupts very basic [10:22] notion of a process scheduling IPC and [10:25] the clock and this thing called system [10:27] but we've already moved that out of the [10:28] kernel so basic just handling the [10:30] interrupts and the inter process [10:31] communication and a very primitive [10:33] notion of a process okay it doesn't [10:36] really manage the processes somebody [10:38] tells it you know there's a process go [10:40] run them and it runs it without really [10:42] understanding what it's doing one level [10:44] up in user mode are the driver processes [10:47] and each one is a separate process so [10:48] the dis driver is running as a user mode [10:51] user mode process and protected mode [10:54] with the mmu turned on you know just all [10:56] by itself as an un non-privileged [10:59] process and the terminal and the network [11:00] and the printers and all these things [11:02] running a separate user mode processes [11:04] with relatively little power on top of [11:07] that is another layer of user mode [11:10] processes with the file systems and and [11:12] process manager and virtual memory [11:14] manager and all other stuff again [11:15] running as user mode processes in the [11:18] top layer are the regular user programs [11:20] okay but from the Kernel's point of view [11:21] they're just user processes the file [11:23] system is no different than than make or [11:25] the shell it's just another user process [11:27] right in in in you know all uni systems [11:29] the shell is just another user program [11:31] and there's you know many shells the [11:33] born shell and the Born Again shell and [11:35] ksh and a whole bunch of shells C shell [11:37] um in Windows and many other programs [11:40] shell is sort of built into the [11:41] operating system it's hard for them to [11:42] understand how could the shell be a user [11:44] program you know it's that way for many [11:47] Unix people how could the file system be [11:48] a user program but it is and the virtual [11:50] memory manager is a user program and so [11:52] on that's sort of the basic design that [11:54] makes it very modular and it has a [11:56] number of interesting [11:57] properties um first of all uh you can [12:00] call the curle has some calls that these [12:02] drivers and servers can make and these [12:05] calls are different than the posix calls [12:06] these are internal calls for the benefit [12:09] of drivers and servers we also have the [12:11] posic interface for user programs but [12:13] the kernel calls are low-level things [12:15] like um a user process can't read or [12:17] write an IO Port they have no access to [12:18] the io system so if you want to read or [12:20] write an IO Port you got to ask the [12:22] colonel hey here's a bunch of I ports go [12:23] read them for me and it'll check to see [12:26] if you're authorized to do that and if [12:28] you are it'll go read them for you and [12:29] so on um you know the stuff for setting [12:32] interrupt vectors there's things copying [12:34] between address spaces because a file [12:36] server runs in its own address space it [12:38] can't talk to anybody else's address [12:40] space so if somebody says to it give me [12:42] a block it can't actually deliver the [12:44] block it doesn't have the authority to [12:46] get outside of its address page it has [12:47] to ask the colonel go give him give him [12:49] the block there's all kinds of checks [12:51] which I'll describe later you know dma [12:54] mapping uh assigning memory Maps uh [12:56] setting up privileges I know all these [12:58] things that are internal kernel calls [13:00] about 35 or so of these kernel calls for [13:03] the benefit of the kernel the drivers [13:05] and the servers everything uses the [13:07] principle of leas authority so they're [13:10] running as user mode processes [13:12] everybody's got very carefully granted [13:14] Powers so they don't they can't just do [13:17] U anything for example nobody can [13:19] execute privilege instructions they [13:21] can't touch the privilege registers [13:22] they're time sliced so if one of these [13:25] things gets into an infinite Loop it [13:26] doesn't hang the system it simply you [13:28] know Wast a certain fraction of the time [13:30] but not all of it none of them can touch [13:32] kernel memory so they can't corrupt [13:33] kernel memory due to a bug um they can't [13:36] touch other address spaces there's a bit [13:38] map per kernel call saying which kernel [13:40] call you're allowed to do so if you're [13:42] an audio driver for example and there's [13:44] no reason for you to Fork you can't do [13:46] the kernel call that's s of the [13:47] Primitive for [13:49] fork there's also a bit map saying who [13:51] you can send to so again if you're the [13:53] audio driver and you've got no business [13:55] talking to you know the the network [13:56] driver you can't do it you'll try to [13:58] send to the network driver and a colonel [14:00] return an error saying you know not [14:02] authorized there's no direct IO you [14:04] can't touch IO ports so the disc driver [14:06] can't get to the disc it has to ask the [14:08] kernel it's a humbling experience for [14:10] the disc driver not to be able to touch [14:12] the disc that's life um it says can I [14:14] use please write on the disc and it says [14:16] yes you know but if you're the audio [14:18] driver and you say can I ride on the [14:20] disc the answer is no that has the [14:22] consequence for example if a virus or [14:23] something should get into your system [14:25] and take over the audio driver it can [14:27] make really weird noises but it can't [14:29] take over the disc cuz when it tries to [14:31] use the disc it's told sorry no [14:33] permission so there's a lot of security [14:35] value in this too okay so drivers user [14:38] mode they run a separate processes they [14:39] don't have any kind of super user power [14:41] the mmu is turned on so there no special [14:43] protection they don't have access to the [14:45] io ports um to do anything they got to [14:47] ask the colonel which checks um to copy [14:50] to other address spaces they got to ask [14:51] they're really not very powerful which [14:54] is intentional okay there's a bunch of [14:56] user mode servers there's one or more [14:58] file servers there's a process manager [15:00] there's a virtual memory server data [15:02] store information server Network server [15:05] um X server of course which always a [15:07] user process and re reincarnation server [15:10] and I'll I'll talk a bit more about [15:11] these things in a couple of minutes [15:14] let's start with the file server that's [15:15] one of the more interesting ones here's [15:17] a picture of the file server so here's a [15:19] user program and it wants to read you [15:21] know it does a read okay so read is a [15:23] little Library routine and the library [15:25] routine sends a message to the file [15:27] server saying I want you know to read [15:29] you know 512 bytes from file descript 6 [15:32] or whatever okay and here's the file [15:34] system's little cache the little colored [15:35] thingies if we're lucky then the file [15:39] system will have the Block in the cachee [15:41] and it'll call the cyst task in the [15:43] kernel to say please copy the block to [15:46] the user space because it's not allowed [15:47] to do that the file the system task will [15:50] say okay done it and then the file [15:52] system replies to the user saying you [15:53] know read completed with you know error [15:55] code if you know or no error code and um [15:59] you know so there there's like four [16:00] messages needed to do this you might say [16:02] how long is a message it's about I don't [16:04] know 500 NCS and without order of [16:06] magnitude so there's a little bit of [16:07] overhead but it's not immense now let's [16:10] look at a more complicated case when the [16:12] block isn't in the cache the user say to [16:15] to file some copy block the file system [16:17] looks in the cache can't find the block [16:19] sends a message to the disc driver [16:20] saying go get the block the dis driver [16:23] you know sends a message to the system T [16:25] saying here some IO ports please write [16:27] these values on the io ports so you know [16:30] get the block um then it waits then [16:33] there's a notification from the hardw [16:35] into the disc driver which is like a [16:36] message which says basically okay you [16:38] know disc you know has finished activity [16:41] wants something from you and so then it [16:43] goes and checks the you know does some [16:45] reads from IO ports finds out the St [16:46] whoops finds out what the status is and [16:48] if all is well the dis driver notifies [16:51] the file system [16:52] saying you know I got um you know I did [16:55] I did the io for you and so on and then [16:57] the file system calls the system task to [16:59] say copy it the user space and it copies [17:02] the user space and then he tells the [17:03] user it's done okay so um it's there's [17:06] like nine messages in here at 500 NS [17:08] each so we're talking about burning up 4 [17:10] and a half micros seconds in this kind [17:12] of overhead plus a bit more but we've [17:15] actually read a block from the disc that [17:17] takes several milliseconds okay so [17:19] another five microsc more or less really [17:21] isn't a central issue here okay on the [17:24] process manager it manages processes um [17:28] it contains the L IC for starting and [17:29] terminating processes I think signals [17:32] are in there too they had to go [17:33] somewhere [17:35] um but you know the basic logic for [17:38] keeping track of things is in this [17:40] process called the process manager okay [17:43] it's a virtual memory manager it has the [17:45] the logic of the virtual memory but not [17:47] the mechanism so the kernel you know the [17:50] virtual memory manager T the konel here [17:51] is the memory map for this process and [17:54] the colonel just says yes sir and just [17:56] takes it and doesn't you know if it's [17:57] stupid well it'll C crash it doesn't [17:59] know it just follows instructions all [18:01] the logic for keeping track of the pages [18:03] and setting up the maps and so on that's [18:05] all done in this user level virtual [18:07] memory manager okay so it knows where [18:09] the free pages are it knows you know [18:10] who's got what you know page falls all [18:12] get redirected to it it figures out what [18:14] the do about the page fault so all the [18:16] smarts and all the algorithms are in the [18:18] virtual memory manager as a user process [18:20] when it's all done it builds the [18:22] appropriate page map just tells the [18:23] colonel here's the page map from number [18:26] six okay the data store is a little name [18:29] server where you can say here save this [18:31] and then you can ask for it later and [18:33] there are reasons for that which I'll [18:34] come to in a minute um it could be used [18:37] in fact is being used for recoverable [18:39] drivers okay um very briefly what that [18:42] means is if you want a driver you want [18:44] the system to uh be reliable and be able [18:47] to survive a failure in a driver some of [18:50] the drivers have a small amount of State [18:51] some have a large amount of state but [18:53] for example an audio driver knows what [18:54] the volume levels are for the You Know [18:56] audio devices and it stores those in the [18:59] data store and if the audio driver ever [19:00] crashes it's replaced by a new audio [19:02] driver which goes to the data store and [19:04] says you know give give me the you know [19:06] the appropriate data for me and then it [19:08] gives it back the audio levels and the [19:10] new driver can set the audio levels to [19:12] whatever the old driver had had set [19:14] them the information server is basic for [19:17] debugging all the F buttons and [19:19] Minix display various debugging dumps so [19:22] you can see what's going on um there's a [19:25] network server it's a complete ttcp IP [19:27] stack runs entirely user space whole [19:29] thing runs there and um then there's the [19:32] reincarnation server which is kind of a [19:33] fun thing which most systems don't have [19:36] um The Reincarnation server is about [19:38] Reviving The Dead okay um it's um the [19:42] parent of all the drivers and the [19:44] servers okay whenever a driver or server [19:47] dies The Reincarnation server collects [19:49] it and sort of fixes things okay and [19:52] there's a table which it looks at and [19:54] that tells it what to do and it also [19:57] pings the drivers and the servers [19:58] frequently so The Reincarnation Servo [20:00] will go to a driver and say hey disc [20:02] driver how you doing and a disc driver [20:04] will say fantastic I did 57 megabytes a [20:07] second in the last second the disc is [20:09] really humming we're going great you [20:11] know and then 3 seconds later it'll ping [20:13] the disc driver again say how you [20:19] doing and The Reincarnation server says [20:21] hm not good okay disc driver how you [20:27] doing hm okay I'll give you one more [20:31] chance okay now either you answer or [20:33] you're [20:36] toast and so at this point The [20:39] Reincarnation of you get three chances [20:40] sorry about that okay I'm killing you so [20:42] it kills its child goes and fetches a [20:44] new one starts it up again the new one [20:47] you know goes to the data store and says [20:49] do I have any state which we haven't [20:51] really got for complicated state but for [20:53] simple State this driver doesn't have [20:54] any state so it's easy um it starts up a [20:57] new one new one you know tries to patch [20:59] up the pieces and it may be depending on [21:02] you know the nature of the driver you [21:04] know you may or may not screw up one or [21:06] more processes but you don't screw up [21:07] the whole system and in most cases you [21:09] don't screw up anything or in some cases [21:11] you don't that's It's Tricky that's what [21:13] the research is for example the file [21:14] server knows it gave a command to the [21:16] disc driver and didn't get an answer so [21:18] we have to deal with that I'll show that [21:19] in a second so here's the recovery for [21:22] example for dis drivers so the user [21:24] sends a message to the file server [21:25] saying read read from a file okay and [21:28] file server sends a message to the dis [21:29] driver saying read block and the dis [21:32] driver Now crashes okay so what happens [21:34] next The Reincarnation server detects [21:36] this because it doesn't answer its pings [21:38] and it goes and fetches a new driver you [21:41] might ask how does The Reincarnation [21:43] server fetch the disc driver from the [21:45] disc when there's no disc driver and the [21:47] answer is it has a shadowed copy of the [21:49] disc driver in memory all the time so it [21:51] can always get to the root device you [21:53] know from its memory copy and once [21:55] you've got a working root device you can [21:57] keep all the other dri on the root [21:59] device so you can always fetch the rest [22:00] of them so there's you know even a [22:02] failure of the disc driver isn't fatal [22:04] and then um a message is sent to the [22:07] file server saying um I have some bad [22:09] news for you um your your friend the [22:11] disc driver um um is passed away we're [22:13] really sorry about that um the file [22:15] server says all right um I wonder if [22:17] there's a new one so it goes to the data [22:18] store and says by any chance is there a [22:20] dis driver and the dist the data store [22:24] says you're in luck a new one just [22:26] appeared a couple of micros seconds ago [22:27] here's its address addess go for it then [22:30] the final system says oh new disc driver [22:33] I'm I'm trying to write a block here you [22:34] think you could do it for me and a dis [22:35] driver says I'd love to write blocks [22:37] it's my favorite activity in the whole [22:38] world besides reading blocks is writing [22:40] blocks so yes I'll do that so you're [22:42] back in business and the user process [22:44] doesn't notice this so it's all [22:45] transparent so you're replacing parts of [22:47] the operating system on the Fly while [22:49] it's running you know without user [22:51] process being disturbed that's sort of [22:52] the whole idea now we're not finished [22:54] with all of this yet we can only do the [22:55] simple parts now but we're working on [22:57] like if the file server goes down with [22:59] all that state that's much more [23:00] complicated we're not really dealing [23:02] with stateful things yet except for [23:04] small amounts of State Like You Know [23:06] audio drivers but this is a basic idea [23:08] in where we're going okay so the system [23:10] is self-healing it detects its own [23:12] problems and it conficts itself to some [23:15] uh extent okay what about crashes of [23:18] other drivers well ethernet is very easy [23:20] because ethernet is unreliable to start [23:22] with that is its best efforts if it goes [23:24] down you lose some packets but you know [23:26] nobody ever guaranteed that packets were [23:28] going to be delivered so the higher [23:29] level protocols you know if it was a UDP [23:31] packet you lost well nobody ever [23:33] guaranteed that UDP packets were going [23:34] to be delivered so nothing's wrong if [23:36] it's TCP packet you lost TCP itself [23:38] times out and tries again so that's [23:40] really easy um the printer goes down you [23:43] don't know where you were you sort of [23:44] halfway in the middle of a file or [23:46] something so all all you can do is the [23:47] printer demon detects the problem just [23:49] prints the file again there's really no [23:51] way out you know it's theoretically [23:53] impossible and audio it doesn't know [23:55] where it was so it could play the song [23:56] again I mean so sometimes you can [23:59] recover completely gracefully and [24:00] sometimes it's hard to do but still if [24:02] the audio driver goes down and the [24:04] result is there's a small glitch and [24:05] then the song plays again from the [24:07] beginning that's better than an [24:08] operating system crash okay so no it's [24:10] not totally transparent it's very hard [24:12] to make it totally transparent but we're [24:14] trying to get as close as we reasonably [24:16] can the Kel has many reliability and [24:19] security features [24:22] um um there's less codes the few bugs [24:25] you know if you're talking three bugs [24:27] per thousand lines of code and there you [24:29] know thousands of lines of code less [24:31] there's going to be bug fewer bugs you [24:32] know um it also means The Trusted [24:34] Computing base the stuff that actually [24:37] has to work is much smaller than in [24:39] conventional systems there's no foreign [24:42] code in the driver you know if you go [24:43] out on your you know Linux or Windows [24:45] whatever PC and you buy a FireWire card [24:48] it comes with a CD ROM and you put the [24:50] CD ROM in the drive and guess what [24:52] happens random code written by somebody [24:54] in Taiwan gets installed in your kernel [24:57] you know it may or may not work work the [24:58] kid may or may not have been in a hurry [25:00] management may or may not have cared [25:01] about the quality of any of this stuff [25:03] and there's this foreign code sitting in [25:04] your kernel now you really don't want [25:06] that it's a very very bad design in Min [25:09] design you know youd have a new user [25:11] process started with the Fireware code [25:12] in it which might or might not work but [25:15] if it didn't work it wouldn't take the [25:16] system down it would just take fire wire [25:18] down I think it's a much that's the [25:19] modularity principle it's I think a much [25:21] in principle a better [25:23] designs we also have made an effort to [25:25] have static data structures you know Ram [25:27] is cheap and so there's no malok in the [25:29] kernel tables are all fixed size the [25:32] number of processes that you can have is [25:34] fixed by a constant in some header file [25:36] so I think it's I know 256 processes if [25:38] you ever run above that it says you know [25:40] full um but that means no malok and no [25:43] free and no memory leaks and you know so [25:45] we waste a little bit of ram by over [25:47] dimensioning you know various tables it [25:49] seems in this day and age with memories [25:51] you know G you can't buy a computer with [25:54] less than a gigabyte so you know so we [25:56] waste a couple of thousand bytes on [25:58] bigger tables you know it's really not a [25:59] bad trade-off um of course moving bugs [26:02] to user space doesn't reduce the number [26:04] of bugs right got the same amount of [26:05] code it just makes them less powerful a [26:08] bug in a user space process can do less [26:10] damage so we have the same number of [26:12] bugs everybody else does it just these [26:14] bugs are sort of emasculated you know [26:16] with these you know castrated bugs up [26:18] there which you know can't do very [26:20] much okay IPC reliability and security [26:24] we have fixed length messages although [26:25] we're having to rethink that a little [26:26] bit now says no buffer overrun [26:29] initially we had a rondevo system you [26:31] know you sent somebody a message he did [26:33] a receive the message was transferred [26:35] and everybody's happy we're we're having [26:37] to move away from that for reasons I'll [26:38] say in a second um this had no loss [26:40] messages there's no buffer management uh [26:43] it was a very simple scheme interrupts [26:45] and messages are unified so if an [26:47] interrupt happens it's turned into a [26:49] message by the low-level Colonel and the [26:51] driver just gets a message saying you [26:53] know message from disc hardware and then [26:55] it's up to the disc Hardware to you know [26:57] to figure out what to do next [26:59] um there's one problem we've run into [27:00] reliability if the client sends a [27:02] message to the server and the server [27:04] tries to respond but the client has died [27:06] that hangs the server because it can't [27:08] do the respond okay and so we're having [27:10] to go over to asynchronous messages a [27:13] little bit which I don't like but it's [27:15] really necessary in case to avoid [27:18] hanging servers you know everybody [27:20] worries about you know you know six [27:22] servers but we also are worrying about [27:23] sick clients and so we may have to go [27:25] over to that anyway um the drivers are [27:27] are we regard drivers as untrusted code [27:31] in every other system the drivers are [27:32] regarded as trusted code and experience [27:34] shows that we're right they are it is [27:36] untrusted code um and bugs and viruses [27:39] and stuff can't spread from module to [27:41] module easily because they're they're so [27:44] isolated um none of the drivers or [27:46] operating system processes can touch the [27:48] kernel data structur so they can't mess [27:50] them up okay if a bad pointer occurs you [27:52] know in C bad pointer errors are very [27:54] common it it wipes out one driver it [27:56] crashes it's parent the re Incarnation [27:58] server is informed via a signal that one [28:00] of its children has died it says oh you [28:02] know the disc driver has died look up in [28:04] the table what am I supposed to do it [28:05] runs a shell script the shell script is [28:07] likely to you know log the event [28:09] somewhere possibly take the corpse you [28:11] know the the a. out you know the core [28:12] dump and save it somewhere for future [28:14] debugging it might send an email to [28:16] administrator uh you could set it up to [28:18] send an email to the manufacturer [28:19] there's all kinds of things you could do [28:20] it's running a shell script when it's [28:22] all done it starts the driver again okay [28:25] um if a driver or a server gets into an [28:28] inite Loop then when the you know The [28:30] Reincarnation service is how you doing [28:32] there's no answer because it's in this [28:34] infinite Loop and after three or [28:36] whatever the the constant is number of [28:37] tries then it kills it and starts a new [28:39] one and so we can survive infinite Loops [28:42] inside critical components of the [28:44] operating system I mean nobody else can [28:46] do that and again because these things [28:49] do not run a super user there just [28:50] regular user processes running at the [28:52] lowest possible privilege level they [28:54] can't do a lot of damage if something [28:56] goes wrong okay um let me describe [28:59] memory grants which is an important uh [29:01] concept that we [29:05] have um you know file server and some [29:09] other processes need to access memory [29:11] from another process so if you say to [29:13] the file server read a block it's got to [29:15] write the block into your address space [29:17] but it can't touch your address space [29:18] because it's just a humble user process [29:20] so how do we do this we every process [29:23] that wants to have somebody else write [29:25] into its address space builds a memory [29:27] Grant table okay and it makes a colonel [29:30] call saying here is my memory Grant [29:32] table here's the starting address and [29:33] it's got so many entries in it okay so [29:35] the colel knows where everybody's memory [29:37] Grand table is and it could make in its [29:39] memory Grand table an entry saying the [29:42] disc driver process you know nine May [29:44] write in my memory from bytes 1400 to [29:47] 1499 so it puts in the exact [29:50] amount accurate to the bite there's no [29:53] page alignment required okay and then um [29:56] when when it wants to when when the user [29:58] wants to talk to the FI the file server [30:00] the file server wants to talk to dis [30:02] driver it passes an index saying you [30:04] have the authority to write in my [30:06] address space using memory Grant number [30:08] one okay and then when the disc driver [30:12] you know wants to write into the um file [30:14] server address bace it says to the [30:15] colonel I want to use this you know um [30:19] memory Grant to write into his address [30:21] bace and then Colonel checks the table [30:24] to see is this guy authorized and which [30:26] bytes is he authorized and if the kernel [30:28] does the copy accurate to the bite so we [30:30] can protect memory down to the bite [30:32] granularity but having the kernel do the [30:34] copying instead of the other guy doing [30:35] the copying now this introduces a little [30:37] bit of overhead it's true but it [30:38] protects the address space so you can [30:40] say to somebody you can only write in [30:42] this little piece of my memory and no [30:43] more and after the operation is [30:45] completed you know normally you'd erase [30:47] the grant so he can't use it again okay [30:50] so this protects memory down to the bite [30:52] level [30:53] granularity fault injection um [30:59] we ran experiments injecting false into [31:01] drivers to see how good it was and so [31:03] there's a program you can get which uh [31:05] generates fals in binary code to um to [31:09] test it and we injected 800,000 faults [31:12] in each of three different I think it [31:13] was Network ethernet drivers [31:16] okay and so this fault injection program [31:19] runs in real time another process like [31:21] you know using p Trace kind of calls it [31:23] generates um bugs in your code it [31:26] doesn't just generate junk what it does [31:28] is it analyzes the code understands the [31:30] machine architecture and then it does [31:32] things like if you said um you know um [31:36] move you know one register to another [31:38] register it will swap those so it [31:41] simulates the error if you wrote you [31:42] know I equals J and you meant J equals I [31:46] so it's a very you know simulating [31:48] semantic errors that programmers might [31:50] make it looks for conditional branches [31:52] and changes the condition so it finds a [31:54] branch less than it turns into a branch [31:56] less than or equal to this simulates the [31:58] error you know for I equal 0 I less than [32:00] n you know I ++ to you know for I equal [32:03] 0 I less than or equal to you know n i++ [32:07] a typical error programmer makes this [32:09] program generates errors that are common [32:12] programming errors and we injected like [32:14] you know 800,000 faults in these things [32:16] the way we did it was injected 100 at a [32:18] time so we took the driver put 100 [32:20] faults in it changed 100 pieces of code [32:22] and we waited one second to see if it [32:24] crashed now many times it didn't crash [32:26] because it never executed the code we [32:28] messed up in that one second or the way [32:31] we messed it up wasn't really [32:33] important if it didn't crash we injected [32:36] another 100 Falls and repeated the [32:38] process and then we waited until it [32:40] crashed okay well we eventually got [32:42] 18,000 crashes out of this stuff but the [32:45] operating system never crashed despite [32:48] running two and a half million trials we [32:49] found a lot of things we found bad [32:51] Hardware sometimes in the 18,000 crashes [32:53] we found ways to hang the PCI bus that [32:56] couldn't be recovered other than pulling [32:57] the plug out um we found all kinds of [32:59] wonderful things mostly crappy Hardware [33:01] but the operating system never crashed [33:03] in all these trials so we think it's [33:05] relatively robust because we crash the [33:07] drivers all the time but not the [33:09] operating system okay so that's sort of [33:11] the um the basic technical story um you [33:16] know there's a lot of academic projects [33:18] where they build a little tiny kernel [33:19] and it it does something you know to do [33:23] whatever but it only works when the grad [33:25] student is there and it can't actually [33:27] run anything you know because it's too [33:28] much work to do all the rest of the [33:29] stuff but we've actually made a real [33:31] effort maybe too much of an effort to [33:33] make it an actual sort of usable Unix [33:36] system okay it's not state-of-the-art [33:38] it's not nearly as fancy as not as Unix [33:40] or as Linux or BSD or any of those [33:42] things but it's a usable recognizable uh [33:45] Unix system so you could actually [33:47] believe it could work you know for the [33:49] screen there's X11 and we have a simple [33:51] desktop um program Ed we don't have [33:54] kernel threads yet that's on our agenda [33:56] so we can't run things like like and KDE [33:58] but Ed gives you a desktop if you want [34:00] but it's our experience that a lot of [34:02] programmers just want X11 and a bunch of [34:03] xterms and that we have um we have you [34:07] know a bunch of shells bash and the [34:08] public domain corn shell and zshell and [34:11] I know other shells we've got compilers [34:13] for C and C++ and Python and Pearl and [34:16] PHP and number of the other sort of [34:17] standard languages we actually have two [34:19] c compilers we have GCC which is a big [34:22] pain and we have a our own compiler [34:24] which is in some way it's not you know [34:26] it's not as fancy and it only implements [34:29] only implements an standard C I wish GCC [34:32] implemented an standard C but it doesn't [34:34] um and it's much much faster like we can [34:36] build the entire operating system you [34:38] know all of Minix the kernel all the [34:40] drivers in user space all the uh servers [34:43] in about eight or nine seconds with act [34:46] so that's a relatively fast fast build [34:49] for 125 compiles and 11 links about less [34:53] than 10 [34:54] seconds editors we have emac we have nvi [34:57] Vim vile nit you know standard editors [35:00] uh photos with have image magic jpeg [35:02] package XV utilities we got all of the [35:05] version 7 you know standard real Unix [35:08] utilities we also have all the G [35:10] utilities we also have the BSD utilities [35:12] we put them in different directories so [35:14] if in your path you put user G as the [35:16] first thing in the path then it'll find [35:18] the G utilities first and you're getting [35:20] G copy and G LS and G everything if you [35:24] put you know the BSD path the BSD [35:26] directory in the front of your pan math [35:28] then you get the BSD utilities as first [35:30] choice if you don't put either of these [35:31] you get our utilities as the First [35:33] Choice the version 7 utilties so you can [35:34] sort of choose which environment you [35:36] want by setting up your path with the [35:38] appropriate directory in the [35:39] beginning we have some stuff at the web [35:42] Apache Dow links links we don't have [35:44] Firefox we'd like that but I think it [35:46] needs kernel threads and it's a very big [35:48] hairy program and I I don't think it's [35:50] very portable but we' like to have it [35:52] somebody wants to support Firefox that' [35:53] be wonderful um we really love it mail [35:55] programs Pine poptart X Sim Sim and so [35:58] on uh database post grass SQL light my [36:01] SQL client we don't have the server um [36:04] qmu which is nice you can emulate the [36:06] you can run Windows 98 you know on top [36:08] of um of Minx and it runs at the same [36:11] speed Windows 98 ran on the hardware you [36:14] know we can't run wind 7 it's too big [36:16] and complicated barely runs on current [36:18] Hardware but Windows 98 ran on you know [36:20] 60 mahz you know Pentium 1es and qmu [36:25] slows you down by a factor of 10 you [36:26] take a modern machine it's like you know [36:28] a 300 MHz you know penium 2 and Windows [36:33] 98 wents perfectly on that so running at [36:35] a better speed than Windows 98 ran on [36:38] the hardware it was designed for and we [36:40] have M player and net hack and we have [36:42] subversion so this there's about 600 [36:44] programs available for it so it's not [36:46] you know a full-blown system with [36:47] thousands of packages but it's enough to [36:49] prove the point that it's doable you [36:51] could actually use it um does anybody [36:53] care does anybody use this stuff well we [36:55] have you know of course we log the [36:56] traffic to the we it Minix [36:59] 3.org here are the um number of visits [37:02] per month we've had for the last year [37:04] it's running about 25,000 visits a month [37:08] okay we've had 1.6 million visits since [37:11] the site went up in 2005 about about [37:13] four years ago actually at the end of [37:15] 2005 um compared to Linux this probably [37:19] isn't very much but for those of you who [37:21] work on other open source or academic [37:23] projects you know 1.6 million visits is [37:26] probably a fair number compared to other [37:28] comparable open- Source you know [37:29] lowbudget you know kind of projects um [37:31] downloads per month it looks like we're [37:34] running I don't know 12,000 downloads a [37:35] month for the last year so we've had [37:37] 610,000 downloads since you know like [37:40] about four four years so again I mean [37:42] compared to Linux this is nothing but [37:44] compared to um other open source [37:46] projects of other you know kinds of [37:48] things 600,000 downloads just you know [37:50] there's some interest in there the world [37:52] okay the the current team is me uh I got [37:56] five PhD students working on there it's [37:58] one Poston I've got two student [38:00] assistants I've got three paid full-time [38:03] programmers a couple of Master students [38:05] doing work on it we had four Google [38:07] summer of code students last year and [38:09] there's various volunteers around the [38:11] world working on all kinds of things so [38:13] this is sort of the the group um this is [38:15] an ad which is why I came here of course [38:18] um we're always looking for help to work [38:20] on new things volunteers for example to [38:24] Port programs porting programs you know [38:27] I don't know everybody here has probably [38:29] taking a course in software engineering [38:30] somewhere along the line and all of you [38:32] forgot it the day after the exam that [38:34] it's just amazing how much free software [38:36] is so crappy it's not portable you know [38:39] you run/ configure and it always fails [38:44] always you know um you know what happens [38:47] it was looking for I don't know Pearl [38:49] 5.2.3 [38:51] 26.94 B and if that wasn't there it [38:55] gives up even though the application [38:57] you're trying install doesn't use Pearl [38:58] at all okay you know these configure [39:03] scripts of configure strips of 20,000 [39:07] lines of incomprehensible code generated [39:09] by a program which itself was generated [39:11] by our program it's just not the way to [39:13] do things when the application in [39:15] question didn't even need this facility [39:17] so porting programs you know it's [39:19] typically it's one or two lines have to [39:20] be removed from it but it takes some [39:22] effort to figure them out so that's a [39:23] problem porting libraries of all kinds [39:25] would be useful we have a Wiki [39:27] documentation to the wiki would be you [39:29] know fantastic all kinds of things are [39:31] not well documented translating the wiki [39:33] into other languages is very welcome uh [39:36] and now the the real thing I'm I [39:38] actually have money from this EU Grant [39:39] to hire more people I've got I spent [39:42] most of the money on the PhD students so [39:43] on but I'm looking for a fourth [39:45] full-time paid programmer so if you're [39:47] looking for a job or you have a job now [39:49] you don't like you're you know you're [39:50] doing web design for a company making [39:52] bathroom equipment or something and you [39:54] don't really like the job much and you'd [39:56] rather do kernel hacking and be paid for [39:58] it this is your chance so get a hold of [40:00] me you know so I'm looking for a fifth [40:02] program for another related project but [40:05] so basic on I have two openings for paid [40:07] programmers in [40:08] Amsterdam so if you're interested try to [40:10] see me later or at least mail me your [40:12] your CV you can find my just type my [40:14] name to Google you can find my homepage [40:15] pretty easily my my uh things on there [40:18] so you can do o hacking is a a full-time [40:20] paid job am is a lovely city and so on [40:23] um this is more on my homepage or just [40:24] just Google me and find the homepage [40:26] okay what's the current [40:27] work working on live update we want able [40:30] to replace pieces of the system while [40:32] it's running so you know if you can [40:33] replace it after a crash um doing it [40:36] intentionally is you know easier in some [40:39] sense or in some ways it's harder um [40:41] like in most operating systems if you're [40:43] using you know version you know 6.2.4 [40:46] point3 and there's now A4 that's come [40:49] out they tell you reboot the system we [40:51] don't want to reboot the system we want [40:52] to go over to the new version while it's [40:54] still running and while all the [40:55] processes are running that you know [40:58] there you are you know your TV used to [41:00] be you know Hardware now your TV is [41:01] software it's got a little box you know [41:03] which is you know 40 megabytes of code [41:04] running in there and there it's the [41:06] Super Bowl and it's the last couple of [41:07] minutes and you get this message [41:09] rebooting and it takes seven minutes and [41:12] it reboots with the new version of the [41:13] operating system and you've missed you [41:15] know the final you know couple of goals [41:16] you know um you sort of want to replace [41:18] the system you know while it's running [41:20] Banks don't like going down and so on so [41:23] we we think it's important to try to be [41:24] able to update the system component for [41:26] component while it's running and while [41:28] things are going on and during the [41:30] update process it might slow down a [41:32] little bit for a couple of seconds but [41:34] not have to have a reboot um multi core [41:37] has become very common now we've had a [41:38] multi- server operating system the [41:40] operating system itself runs as many [41:41] processes suppose you had a lot of cores [41:44] and you had a lot of processes well you [41:46] know it might occur to you gee we have a [41:48] lot of processes and we have a lot of [41:49] cores can't we sort of make that match [41:51] together somehow like run each process [41:53] on its own core for example so but it's [41:55] not not so easy but we're looking at [41:57] that whole area of sort of multiserver [41:59] meets [42:00] multicore we're rethinking the file [42:02] system the current file system is [42:04] basically the multic file system from [42:06] 1965 the only major change really is in [42:09] multic they use the greater than sign as [42:10] the separator and now we use the slash [42:12] Windows uses the backslash but other [42:14] than that it's the multics file system [42:15] essentially it's now 2010 let's rethink [42:18] the file system you know so we're [42:20] looking at that and we're trying to [42:22] recover stateful Services which is a bit [42:23] tricky okay the license which is always [42:26] you know issue um it's the BSD license [42:28] which be do whatever you want except Su [42:31] us but other than that do whatever you [42:34] want um I know there are religious wars [42:37] I was speaker a keynote speaker at the [42:39] Linux conference in Australia a couple [42:41] of years ago and I didn't have the slide [42:43] then and somebody asked me the question [42:44] time like what's the license and I said [42:46] it's the BSD license I was expecting [42:48] tomatoes to be you know headed my [42:49] direction there was a huge cheer from [42:50] the audience Linux group cheering the [42:53] BSD license on anyway but for better or [42:55] worse it's the BSD license we have a lot [42:56] of GP packages but they're all sort of [42:58] add-ons you know and in theory if they [43:00] got annoyed at us we could put all the [43:02] packages on a separate CD ROM and you [43:03] have to have two CD ROMs but um whatever [43:06] okay positioning of Minix um we're [43:08] trying to show that multi-server systems [43:10] it's not about microc it's about [43:11] multiserver systems show they're [43:12] reliable demonstrate the drivers belong [43:14] in user mode uh High reliable in Fall [43:17] tolerant applications possibly future [43:19] $50 single chip small Ram laptops for [43:22] the third world you know the one laptop [43:23] per child the next generation of that [43:26] and embedded systems we have a logo [43:28] that's a raccoon wild raccoon well [43:30] everybody has to have an animal you know [43:32] logo small it's cute it's clever it's [43:34] agile and most importantly e [43:39] [Music] [43:43] bugs okay conclusion current systems are [43:47] bloated and unreliable it's an attempt [43:49] to build a reliable operating system the [43:51] konel is quite small the OS runs as a [43:53] collection of user processes each driver [43:55] is a separate process the operating [43:57] system components have have restricted [43:59] privileges we can replace the drivers on [44:01] the Fly we have a website Minix 3.org go [44:03] there and find all kinds of stuff we [44:05] have a Google News Group you know you [44:06] can talk to us and you answer questions [44:08] and the whole thing we have a Wiki [44:09] please contribute to it um I also have [44:11] cd ROMs I didn't realize the scale of [44:13] this meeting so I didn't bring very many [44:17] uh they Feeding Frenzy but you can [44:20] download it make your own cdrom only [44:21] these are the official ones with you [44:22] know our a little thing on it but it's [44:24] the same thing on the website so I have [44:25] the CD ROMs uh and whatnot uh okay [44:31] [Applause] [44:46] questions [44:48] hello are there any similarities between [44:51] what you're trying to achieve with um [44:53] what Chrome OS is trying to achieve with [44:56] with which she trying to achieve with is [44:58] there are there any similarities between [45:00] the design philosophies that you're [45:01] taking and the ones that Chrome are [45:03] taking are they completely different [45:04] which Chrome OS Google Chrome [45:07] OS chrome chrome chrome Chrome OS chrome [45:11] chrome Google um Chrome I think is [45:14] trying to run basically only one program [45:17] that's their own browser and for many [45:20] people that may be enough all they want [45:22] is a reliable browser I mean internally [45:24] I don't know I haven't seen the source [45:25] yet of that but it's a similar kind of [45:28] idea only this is a real operating [45:30] system you can run all of the Unix stuff [45:31] on it and not just the browser so there [45:34] philosophically a c certain difference [45:37] but you know so I don't know what their [45:38] architecture is of chrome so it may or [45:40] may not be technically similar but the [45:42] idea of not so big you know I think [45:44] that's probably in there [45:46] yeah um you said that per message you [45:49] have a delay of about 500 NS saying that [45:53] it's not much delay but we have people [45:55] especially from the audio [45:57] guys that neg us that we have a delay of [46:00] five micros seconds and would like to [46:02] get it to two micros or one microc [46:05] grandma doesn't know what a microsc is [46:07] but I mean if this if you're the you [46:08] know the guy who wants to get every drop [46:10] of performance out of it you know no [46:13] this is not for you but I used to have [46:16] um when I got my first 60 megahertz [46:19] Pentium 1 I thought that was fantastic [46:21] because it was still 100 times faster [46:23] than my old pdp1 and you know there's [46:26] some people would whatever you have it's [46:27] not enough you know this isn't for that [46:30] crowd I'm afraid but if you want a [46:31] reliable system that's sort of our [46:33] Direction but no the last drop of [46:35] performance this is not going to be it I [46:36] don't know how much the performance loss [46:38] is we've never measured it The L4 guys [46:40] who have a similar kind of system have [46:41] actually measured they've really done a [46:43] lot of work to optimize it and they say [46:45] that the the micr kernel approach cost [46:47] them about 5 to 10% in total performance [46:50] and so if 5 to 10% is much too much for [46:52] you then this is no good [47:00] uh first thanks for the the presentation [47:02] because it was very really really [47:03] interesting and well quite funny [47:05] actually uh I have a question in the [47:07] line of the the previous question uh [47:10] regarding the performance uh you go for [47:12] a pure micr kernel approach but uh how [47:15] about the hybrid approach and how do you [47:18] actually um Place yourself with respect [47:21] to the level of performance that you can [47:23] achieve using a hybrid approach again [47:26] performance is not been on on our agenda [47:28] that you know if you have a 3 gz machine [47:31] and it behaves I mean I I I've never [47:33] seen this experiment but um if you went [47:36] to the average grandma or regular user [47:39] and the grandma called up D and say I [47:41] want a new computer and Dell said we [47:43] have two models we have you know the the [47:46] high high-speed model runs at 3 [47:47] gigahertz and so on and it crashes once [47:49] in a while and we have the 2 gz model [47:51] which never crashes I bet they'd sell a [47:53] lot of the 2 gz models I mean I I don't [47:56] have an ual data but I have a just a [47:58] very strong feeling there's an awful lot [48:00] of people who'd give up a third of their [48:02] performance or maybe if i' give up [48:03] personally 50% of my performance if you [48:05] could guarantee it would never crash [48:08] right off the B so the people who want [48:09] highest performance this is not your [48:11] thing but I think an awful lot of [48:12] regular people don't you know don't care [48:15] about that just things are fast enough [48:19] now yes also thanks for the presentation [48:23] um what happens when the reincarnation [48:27] um service goes down can you recover [48:29] from that no we're dead in the water in [48:32] theory we could have three copies of it [48:34] running and have a triple modular [48:35] redundancy scheme where all three copies [48:38] were checking on each other and if any [48:40] one of them you any two could vote [48:41] outvote the other one so if one of them [48:43] failed or began acting weird the other [48:45] two could kill it and then start a new [48:48] one so that the techniques for doing [48:50] that triple module of redundancy are [48:52] well understood but the re reincarnation [48:54] server is so simple in terms of its Cod [48:56] it's only like 10 p of code that we [48:57] haven't had any problems with it but we [48:59] could go to TMR if that became an [49:03] issue so you compared to U Standard [49:07] Operating Systems you said you want to [49:08] boot faster how fast does Minix 3 boot I [49:13] know the actual booting of the the basic [49:15] operating systems on know maybe 10 or 15 [49:20] seconds you know most of the boot time [49:23] have to you know normally when computer [49:25] boots it starts starts up doing the BIOS [49:28] you know checks of the hardware and for [49:30] Minix nearly all the time is the [49:32] hardware checks me the time the hardware [49:34] is actually finished and starts booting [49:36] minut it's only a couple of seconds so [49:38] it might be you know 30 seconds to boot [49:40] of which you know 22 seconds or 25 [49:42] seconds are the hardware checks of the [49:43] memory and so on but the actual booting [49:45] the operating system um is is is fairly [49:47] short a couple of [49:49] seconds a question about scalability um [49:54] you mentioned that a lot of permission [49:55] checks are done with Maps um can you on [49:58] compile time for your kernel system uh [50:01] uh go beyond 32 servers devices or just [50:04] limited of 32 bit uh 32 devices are [50:07] enough for the world at the moment it's [50:09] in fact a bit map with 32 although [50:11] there's no reason we couldn't make it a [50:12] bit map of 64 but it has to do with the [50:15] you know uh which servers you can talk [50:17] to and the number of servers is limited [50:18] number of servers and drivers is on the [50:20] order of I know 15 or 20 something like [50:22] that so so far we haven't run into that [50:23] limit but if we ever ran into the limit [50:25] we'd have to change something from being [50:27] a 32-bit number to a 64-bit number but [50:30] it's not you know if you have lots of [50:31] user processes that's not an issue that [50:33] user processes see the posix interface [50:36] they can't send messages to each other [50:37] they just have the normal posix [50:38] interface if they want to talk they use [50:40] pipes it's only the [50:43] question no but I mean you know if you [50:45] had more than you know 30 or 40 drivers [50:48] running then we'd have to have more bits [50:50] in the bit map but it wouldn't be very [50:52] hard I mean if words were 64 bits which [50:55] that we don't support you'd have more [50:56] bits but you could have two words so [50:58] it's a small point but it could be dealt [51:01] with what happens when a data server [51:03] goes down and maybe afterwards a driver [51:06] the data store the data store the data [51:08] store is in you know I talked about a [51:10] smaller TCB and smaller TCB means we're [51:13] trying to get the amount of trusted [51:14] stuff as small as possible okay the TCB [51:17] includes The Reincarnation server the [51:19] data store the kernel itself there a [51:21] certain amount maybe 20,000 lines of [51:23] code that's absolutely crucial to have [51:25] the system work and the data store is [51:27] indeed part of that again because the [51:28] data store doesn't have a lot of traffic [51:30] going to it you know then you could have [51:32] again triple module of redundancy having [51:34] three data stores and they could vote [51:36] and so on so at the cost of a little bit [51:38] more overhead you could make that [51:40] reliable if that were really important [51:42] but we don't currently because the [51:43] amount of code in there is only a couple [51:44] of pages and it's fairly simple and [51:46] Fairly reliable but what one could do [51:48] that you know for even more [51:51] reliability yep uh given you're talking [51:53] about TVs and things they work on nonex [51:57] X6 ports say arm for example we've tried [52:01] to get an arm Port but you know one of [52:02] the problems unfortunately with with [52:04] volunteers is we've had two people start [52:06] the armp port and both sort of get bored [52:08] you know and then drift off and so our [52:10] armp Port isn't finished yet and so [52:12] someone do an arm Port we're really [52:13] happy to do that so to get into the [52:15] embedded world in the serious way we'd [52:16] probably have to get the arm Port [52:17] actually finished and you know um it [52:21] just you know my I I read somewhere [52:22] recently that more than 75% of all the [52:25] Linux code was written by paid [52:27] programmers working for IBM red hat and [52:30] a couple of other companies that the [52:31] story of the users contribute stuff that [52:34] is you know it's a nice story but it [52:35] isn't actually the reality and you know [52:38] so if somebody wants to work on the armp [52:40] for us we' be very very grateful um you [52:43] know uh so we're trying to that's why [52:45] I'm trying to hire another paid [52:46] programmer which the [52:48] volunteers they have other things in [52:50] their Liv sometimes and you know the [52:51] programming sort of become second choice [52:53] so I think we need the arm port to get [52:55] to the TV world and embedded world we [52:57] don't have it yet although we've [53:00] tried um if an aircraft carrier launches [53:04] a missile and The Reincarnation server [53:07] uh is going to restart the process of [53:09] the kernel then it's going to launch a [53:11] new missile so can I avoid this from [53:13] happening and is this programmable in a [53:16] way that I can say for this specific [53:18] kernel process I do not want this to [53:21] happen that it will Tre try all the time [53:23] yeah yes that as I said when a process [53:25] when a colonel driver or server dies The [53:28] Reincarnation server gets a message that [53:30] it died it then looks up in a table what [53:32] it's supposed to do and what it normally [53:33] does is it runs a shell script and that [53:35] shell script could be set up to say stop [53:38] don't start it again just send a message [53:40] to so and so or an email or whatever or [53:42] it could restart it so it could easily [53:44] put into the script don't restart this [53:46] one you know take some other [53:49] action [53:50] hello okay so most people that write [53:53] software have the experience of having a [53:55] QA Department that files five identical [53:57] bugs of the form I clicked this button [53:58] and it crashed then I clicked it again [54:00] and it crashed and then I clicked it [54:02] again and it crashed and it seems great [54:04] to restart for example the dis driver [54:07] but then the file system is told to send [54:09] the same request that crashed the last [54:11] one so what are you doing to sort of [54:13] make sure that these Ripple failures [54:15] don't you know if the failure is a true [54:18] algorithmic failure and it is UN [54:20] incapable itself of converting the [54:22] linear block address to the correct head [54:24] sector and track and cylinder then [54:26] there's no way we can fix it you know on [54:28] the Fly by starting it but our [54:29] experience and everybody else's [54:31] experience is that most areas that you [54:33] run into are trangent errors caused by [54:35] weird timing or two things happen at the [54:37] same moment or something like that that [54:39] the true algorithmic bugs that it never [54:42] works you know typically get checked you [54:44] know before they ship the thing but you [54:46] know so we mostly can recover from what [54:48] are effectively Trent errors and that [54:50] works most of the time what is possible [54:52] we don't have but wouldn't be hard to do [54:54] is if you had two copies of the disc [54:55] driver or three cop I that were actually [54:57] different code different algorithms [54:59] written differently The Reincarnation [55:01] Cod after after number one crashes then [55:03] run run number two next so the mechanism [55:06] is there to if you have a backup we [55:08] can't fix the code debug the code and [55:10] fix it on the fly but we do have a way [55:12] to run a different one if one wanted to [55:14] do that but in practice that isn't [55:17] needed what is uh Min or can doing or [55:21] can do to protect against like a [55:23] hardware that does does a bad dma or a [55:25] driver Maybe maybe that programs dma [55:27] incorrectly I mean if the programmer has [55:30] you know if the code in the driver is [55:31] incorrect and it's programming the dma [55:33] wrong all the time nothing we can do [55:35] about that I mean somebody's going to [55:36] fix the code if there's another driver [55:37] available maybe an older one you know we [55:39] could run the older one or something um [55:41] so we can't fix program program bugs on [55:43] the Fly Hardware errors of course we [55:46] can't do anything about if the the dma [55:47] controller is actually broken well [55:49] nobody can fix that I mean that requires [55:51] putting a new controller in the best we [55:53] could do is we conceivably could have a [55:55] series of drivers but you know run this [55:57] one if that one fails second choice is [55:59] to run an older version that we can set [56:01] up easily just the cell script says on [56:03] the first failure run this driver and [56:05] the second failure run that driver and [56:06] so on so that mechanism is [56:10] easy okay