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."
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.
Honest question, is Minix compatable with Linux or something? Or do they just sound the same by coincidence? Or is it more like your BSD's in comparision to Linux?
A couple of years ago, I was doing some hacking with the eCos embedded operating system and decided that I wanted to load data off the floppy before running the application, and so needed a floppy driver. Of course, I looked at Linux and BSD systems first, but they had big, hairy drivers. To be fair this is true partially because they try and support all kinds of weird hardware, but they also contain calls into lots of other parts of the system. On a whim, I got out my minix book, looked at the source code, and found the port was a lot easier, and finished it up in a few days (at least reading, I didn't need to write). In any case, the results are here:
"Scivoli": http://www.dedasys.com/freesoftware/ecos.html
and an article (in Italian): http://www.dedasys.com/articles/ecos.html
http://www.welton.it/davidw/
I was "there" when Andy and Linus had their first "ding dong". I was doing an OS/Design undergraduate (300 level) course at the time using the AT book and MINIX as the tool through which we had to implement changes to the scheduler. The book was excellent, MINIX was pretty cool but more importantly it was an educational tool to allow us to delve into the guts of an operating system and play around with it. It was so accessible and relatively easy to do, certainly compared to anything else available at the time.
;-)
Cruising the newsgroups was pretty much the done thing at the time and comp.os.minux was pretty high on my list for obvious reasons. Saw this stuff happening at the time and, knowing that AST was always pretty direct was entertained by the whole flame war thing. Anyway my point is that AST saw MINIX as a OS theory educational tool and Linus saw it as too defective to be even that and as such Linux was better. Funny, I agree with them both, kinda. I could never have kernel hacked Linux like I did MINIX at the time and MINIX could never have become my primary desktop at home like it is now. I guess they were just talking at crossed purposes even then. Pretty much standard flamewar
"The first thing to do when you find yourself in a hole is stop digging."
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.
There was already a 386-specific 32-bit version of the MINIX kernel around at the time; it was called MINIX-386, unsurprisingly enough, and was widely used in the MINIX hacker community.
There wasn't ever any MINIX code in Linux - there couldn't have been, as MINIX was a commercial product at the time. What there was, was plenty of minor MINIX influences on the design (lack of raw disk devices, "kernel", "fs" and "mm" subdirectories in the kernel source, Minix-compatible on-disk filesystem format, major/minor device numbers etc.) but no major ones (ie. the microkernel paradigm).
Well, yes, you had to pay for MINIX, but there were no free OSs to speak of in those days. The reason MINIX seemed to disappear was that most of the MINIX hacker types were using MINIX because it was the closest thing to real UNIX they could afford. Once Linux appeared, as open source, with its simple goal of being a UNIX clone (rather than a model OS for teaching purposes, as MINIX was meant to be), it was inevitable that most of the MINIX hacker community would migrate en masse.
How unscientific of you, to draw such an unrelated conclusion from that data. The operating systems you have mentioned have been less prevalent in the marketplace. They have had smaller numbers of users and, more importantly, engineers working on them than, say, Linux. That does not in any way demonstrate that they are more difficult to extend and maintain, as there are plenty of other reasons for what has happened in the market. How do you know that they wouldn't be even more marginal than they are had they been designed as monolithic kernels, or that Linux wouldn't be even more successful if it had been designed as a microkernel? What actual evidence do you have to say otherwise? None.
Wrong. Shared vs. separate address space is an implementation choice; microkernel vs. monolithic is a design choice. That microkernels are typically implemented using separate address spaces is irrelevant. If you had actually worked in operating systems you'd also know that totally shared vs. totally separate are not the only options for address-space relationships. Linux's process/thread/address-space model is based (without attribution, naturally) on something called nUnix, which Dave Mitchell implemented and I inherited at Encore before Linux existed. One of its key ideas is/was that parts of a process could be shared without having to share everything. SysV's shared memory goes back even further than that. Even within the kernel one can implement some forms of inter-component memory protection without resorting to completely separate address spaces. Been there, done that. I was the one who wrote code at Encore to let two operating systems run side by side in the same box, on separate sets of processors with separate memory and exception vectors and - most importantly - so that a memory fault in one wouldn't take the other down. That was done in a slightly different context (one was an RTOS and the other a GPOS) but the same techniques could just as easily be applied to a microkernel.
And how is that "safe, dynamic runtime" not itself a microkernel?
Yeah, I'm such a dinosaur, working here in what is acknowledged as one of the leading-edge areas of the storage industry, implementing a highly available distributed system. Riiight. What do you do that anyone should remember you for, Mr. Expert? In actual fact I don't think it's a good idea to write "millions of lines of C..." when one has a choice. If I were to design another microkernel it would be every bit as current in terms of software-engineering methodology as anything you've ever done, but that doesn't mean it would be implemented as a "managed code" environment. I understand the concept of informed tradeoffs as opposed to mere uninformed dogma. I produce working and shipping systems based on that. Come back when you've done likewise.
OS development doesn't need to be made hard; it's inherently hard. In an OS, everything you do has to be done with an eye toward reentrancy and concurrency, performance and minimal resource consum
Slashdot - News for Herds. Stuff that Splatters.