Slashdot Mirror
Andy Tanenbaum Releases Minix 3
Guillaume Pierre writes "Andy Tanenbaum announced the availability of the next version of the Minix operating
system. "MINIX 3 is a new open-source operating system
designed to be highly reliable and secure. This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code. The parts that run in user mode are divided into small modules, well insulated from one another. For example, each device driver runs as a separate user-mode process so a bug in a driver (by far the biggest source of bugs in any operating system), cannot bring down the entire OS. In fact, most of the time when a driver crashes it is automatically replaced without requiring any user intervention, without requiring rebooting, and without affecting running programs. These features, the tiny amount of kernel code, and other aspects greatly enhance system reliability."In case anyone wonders: yes, he still thinks that
micro-kernels
are more reliable than monolithic kernels ;-) Disclaimer: I am the chief architect of Globule, the experimental content-distribution network used to host www.minix3.org."
And you can try it out on your current PC - the download is a live-cd!
Now we can all switch over from Linux, at least until Hurd ships.
*pummeling ensues*
GNU/Hurd!! I meant GNU/Hurd!!!
While I could go into a long story here about the relative merits of the two designs, suffice it to say that among the people who actually design operating systems, the debate is essentially over. Microkernels have won.
In retrospect that might have been a bit overconfident.
In case you don't know, Andy was the professor who originally suggested to Linus that he create a kernel, and then provided all the support and positive encouragement that would obviously be needed to successfully complete such an undertaking. He knew from the outset that Linux was going to be a massive hit. He is truely one of Computer Science's great visionaries.
more like your BSD's in comparision to Linux :)
:"more like your BSD's in comparision to Linux"
all three are more or less posix compliant operating systems, which means that most software should run on both.
Some software that requires some functionality not found in posix will need to be ported sperately. Like xorg for instance, but, most of the gnu tools will probably run (probably) and there is the question what c library it uses, if it uses its own, there are going to be a whole myrad of other interesting problems, if it uses glibc or bsd's libc, then it's easier.
in other words
Fighting for peace is like fucking for virginity
Linus Torvalds was kind of inspired by minix to create a more useable and extensible Open Source OS and the original source for the Linux Kernel was written using a minix install. Check out the DVD of RevolutionOS for a detailed history.
Linus would have deserved that "F" in operating system design, but he wasn't writing his kernel to get grades on a computer course. If he had been then he probably wouldn't have written a crude, monolithic kernel that was totally unportable. Apart from the crudity of it, those were his explicit goals - to write a monolithic kernel that would run optimally on his 80386. (Bear in mind that the Linux kernel we know today is pretty far removed from that early version in design and implementation).
As for AT, he's a very smart guy. He writes books on operating system deign and networking that clearly describe quite complex topics. Even if you don't like the idea of microkernels, the "Operating Systems ..." book that describes the Minix kernel is an excellent read.
Linus was never Tannenbaums student. They met online in a classic flamewar where Tannenbaum delivered such classic comments as 'If you where my student, you wouldn't get a very high grade'. But Linux was born out of gripes Linus had with Minix.
Try out fish, the friendly interactive shell.
Ah, no, Linus was definately not Tanenbaum's student. Quite aside from the fact that Tanenbaum taught in the Netherlands and Linus studied in Finland, we couldn't have this quote if he was:
However, Linus did admit that at least one academic from his own university shared Tanenbaum's opinions, and thus he was unlikely to be getting high marks anyway. ;-)
As has been pointed to before, you can find an abstract of the famous "Linus vs Tanenbaum" posts to comp.os.minix here.
His bio so in terms of why he gets to grade Linux as an F (IMO he was right, its improved since but it was poor, SMP, size of kernel, modularity, the only advantage was that NT and Windows scored a "Not Classified") its because he managed to understand Operating system design to such a level that his work was the BASIS from which Linus was "inspired".
Minix and his work are key reference works in writing pretty much any OS and his work in computer networking and distribution in paticular are top notch. His stuff is very much NOT Ivory Tower (I speak as someone who has had to do bespoke OS work) and very practical way to build operating systems and overcome networking challenges. Heard of the OSI model for networking? Most of the rest of us have heard of it thanks to Andy's work, because we couldn't afford the official reference from ANSI/ISO.
Out of interest what is you have done?
An Eye for an Eye will make the whole world blind - Gandhi
For example, each device driver runs as a separate user-mode process so a bug in a driver (by far the biggest source of bugs in any operating system), cannot bring down the entire OS. In fact, most of the time when a driver crashes it is automatically replaced without requiring any user intervention, without requiring rebooting, and without affecting running programs.
This is all well and good until the crashing device driver locks the system bus or grams an NMI etc. And what if the device driver in qestion is the one accessing the disk? How does the microkernel recover from that one when it can't access the drive the device driver is sitting upon?
I can see where his thought processes are coming from, but I still think he lives in Computer Science Heaven, I'm afraid, where all hardware is mathematically perfect and I/O never happens (as it's not mathematically provable).
In the real world device drivers hardly ever crash the system 'cos they're kernel mode, they crash it because the hard-hang the system or denigh the kernel the resources to dig itself out of the hole. Neither of these change by moving the code into user space.
Agrajag: "Oh no, not again!"
It's because traditional microkernels solve the wrong problem. The goal is reliability and flexibility (user-space drivers and whatnot). The wrong problem is using separate memory spaces to achieve the goals. They are just too clumsy... they are ridiculously slow, are coarse grained (4k page is the smallest unit), and you cannot apply a filter to memory accesses.
If the microkernel was combined with a safe language, like Java or C#, then the problems would go away. You wouldn't need to change the page table, so that massive penalty is not there. Accessing memory through a memory object would allow any arbitrary range (down to single bits). You could also apply a filter, so the driver could implement the commands to the disk but the hardware access object would only allow valid use of the bus; this wouldn't be perfect but would greatly increase reliability over microkernels, which are already much more reliable than monolithic.
And speed? It could be faster than C-based code for various reasons (using the dirty bit to accellerate garbage collection, no context switches, etc). It's not like there isn't precendent: the berkely packet filter is actually an interpreted bytecode that is run inside the kernel. It has a number of restrictions to ensure safety (like only branching forwards), but basically in all unix operating systems it is a giant switch statement that interprets the bytecode. This is plenty fast enough to handle the packets, orders of magnitude faster than sending the packets into user-space.
If Tanenbaum really cared about reliability or safety or simplicity he would make a managed microkernel, not more of this C/asm based crap.