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."
I just want to thank you, Andy, for your decades of effort towards advancing the field of computing. Your contributions have been much appreciated. After all, if it were not for Minix we would not have Linux today. Thanks, Andy!
Cyric Zndovzny at your service.
That's because Minix is an academic operating system, meant to be used for teaching and perhaps research purposes. It's not supposed to be taking over the world of operating systems. That was part of the motivation for Linus and friends to go off and make Linux because Tannenbaum didn't want Minix to be made overly complex and riddled with real-world inconsistencies and hacks (thus it could remain an effective teaching tool).
...which is exactly what everything post Pentium Pro does... So yes, he got it exactly right...
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.
That stiff breeze you just felt was from the sarcasm of the OP going over your head at mach 1...
Keep in mind, that modern CPU architectures tend to translate to a much more RISC like set of instructions internally. It wouldn't be horribly wrong to argue that they are translating, although using dedicated Hardware, instead of software.
Also keep in mind that the difference between RISC and CISC is that CISC has a translation layer between the user-visible instruction set and the native hardware instruction set (microcode), where as RISC does not.
"This Guy"
Is a TEACHER
Is an AUTHOR
Ia a HACKER
Now shut the $^#( up before I hunt you down and stuff that minix formatted floppy up your A$$.
Tanenbaum rightly criticized Linus for creating a big monolithic operating system kernel, but at least Linus was copying something that was successful and he made it a success himself.
But, geez, how often do microkernels have to fail before Tanenbaum will admit that there must be something fundamentally wrong with his approach, too? Microkernels attempt to address the right problem (kernel fault isolation), just in such an idiotic way that they keep failing in the real world. But instead of a detailed criticial analysis of previous failures, Tanenbaum and Herder just go on merrily implementing Minix3, apparently on the assumption that all previous failures of microkernels were just due to programmer incompetence, an incompetence that they themselves naturally don't suffer from.
Both Linux-style monolithic kernels and Tanenbaum-style microkernels are dead ends. But at least Linux gets the job done more or less in the short term. In the long term, we'll probably have to wait for dinosaurs like Tanenbaum to die out before a new generation of computer science students can approach the problem of operating system design with a fresh perspective.
That'd be more convincing if I could see a microkernel OS that didn't suck. The theory is great.. sort of like object oriented programming.. but doesn't always work out. The biggest problem seems to be that that extra layer of abstraction slows things down (which makes sense really). Then you have to weigh the benefits of running faster and leaner or easier programming. From a programmers point of view most will like the abstracted and easier option because you can spend more time writing code and less time debugging and fixing but real world usgae doesn't always work well with that.
Still.. as fast as modern computers are I think we may be reaching a point where raw speed is less important and well designed microkernels can probably run almost as fast as monolithic kernels. If heavy usage servers can be run as virtual machines in Xen then why not use a microkernel too?
So. Any examples of microkernel OS's that handle heavy server load, function well as a desktop, and can handle multimedia tasks like gaming? OS X uses BSD under a microkernel I think but my experience is that it is slow and the tests I've seen have shown that Linux performs a lot better on it than OS X (no idea if that was due to microkernel use). I'd find it hard to believe that with solid numbers showing that microkernel is just as fast and without additional overhead that someone like Linus wouldn't use it since it's an easier programming model (better for security, stability, etc).
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
But how mature and how usable this OS is?
What about software for Minix?
On website there is info about packages - gcc, vim/emacs, old Python, no ncurses, no X... What can I install (by compiling) on Minix and what is not possible and why?
``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.''
Perhaps, but it's true as stated. The consensus among OS designers really was that microkernels were superior. Linus opted for a monolithic kernel, because he didn't believe in Microkernels, but he was the odd one out. Linux's success also doesn't demonstrate superiority of monolithic kernels over microkernels. Linux's success is due to the enormous mindshare among developers and users, not the design.
Also, Linux isn't a pure monolithic kernel. Almost everything is loaded as a module these days, and modules can communicate through message passing, and can even be implemented is userspace in some cases (e.g. filesystem drivers with FUSE). Even the direct function calling that modules do can be seen as just an optimization of what MINIX does with message passing.
Please correct me if I got my facts wrong.
GNU/Hurd!! I meant GNU/Hurd!!!
No, you meant GNU. Just GNU. The only reason we say "GNU/Linux" is that that involves adding a non-GNU kernel (Linux) to the GNU operating system. But when you're using the Hurd as your kernel, you are just using the GNU operating system, the way Stallman intended it, and the proper name for the system is "GNU".
This is, of course, all moot, given that the Hurd has about 5 users...
If you read Linus' book he basically says he started writing Linux because he thought Minix was terrible. That is why Linux original used ext2 (same fs as minix). So in reality, Minix and they have similar sounding names because they are both trying to be like unix.
To be really fair, RISC was made obsolete by superscalar architectures.
I'm sorry, but, HUH? Superscalar architectures were really only made possible by RISC platforms. In traditional CISC, the variety of instruction structure made it very difficult to order the instructions for multi-execution. Not to mention that the silicon was already rather convoluted in CISC structures, thus making it even more difficult to fit superscalar execution.
The truth is that RISC won out. And so did CISC. Make sense? Allow me to explain:
The key concept behind RISC was that it simplified the silicon sufficiently to ramp up the clock speed in exchange for requiring more instructions to perform the same task as CISC. Since a higher clock speed can more than make up for any per-instruction performance differences, the early 90's was ruled by high speed chips such as Alphas.
However, CISC chips retained several features, not the least of which was the ability to build a far simpler compiler. Thus a compromise was reached. Microcode was added to RISC chips, thus making them appear to be CISC chips. All the improvements in clock speed were retained, but the chip had an extra pipeline stage to convert a short CISC instruction into a long (and hopefully Superscalar!) set of RISC instructions.
And now you know why nearly every RISC chip in existence had Superscalar execution prior to it being added to the Pentium. (Sorry, but Intel was REALLY late to the game on most of this high-performance stuff. Fortunate for them, Intel has a rather massive R&D department that was able to develop combinations of experimental chip technology far faster than any of their competitors.)
Javascript + Nintendo DSi = DSiCade
Of course he does. Everyone does. The old argument between Linus and Andy was never about reliability. It was about *practicality* and *efficiency*. Microkernels usually incur a lot of overhead. Andy thought the overhead was worth it; Linus didn't.
Where does it list the hardware it supports? I'm not talking about CPU or HD or CD. I'm talking about network card, video card, DVD, printer, etc. In my opinion the biggest problem with UNIX/LINUX/MINIX type OS's is the problem of hardware support. Since most hardware shops don't have the resources to create and test drivers for multiple OS's, they concentrate on Windows and let someone else come up with drivers for other OS's. That leaves the UNIX/LINUX/MINIX type OS's constantly behind the curve since they have to have someone create drivers after the hardware is released and by the time the driver is tested and stable, the hardware is obsolete.
What the hey are you talking about? Minix is still a very popular operating system for teaching OS design principles. Why would you ever get the idea that Minix is supposed to be a Linux/UNIX/Windows/whatever killer? It was never designed to be anything bigger than an academic excercise. Never. Period.
Your little case study of Intel only proves that Intel is incapable of creating a long-term-worthy CPU core. And that might not even be true ... The Pentium M is built on the line of P-Pro/P3, not the all-new P4. I dont think that there is a sufficently large pool of modern RISC processors around that one can make any general statements on the R&D cycle of RISC processors.
What could be stated is that by having a CISC-on-RISC processor one can persue multipe RISC cores and allow them to flourish, die, and be revived on entirely unpredictable market demands, and long term developement costs of a paticular core. This isnt unique to CPU design, nor is it a new concept. Brooks covers multiple implementations in Mythical Man-Month.. Virtual machines be it software ala Java, Smalltalk, Lisp, or the virtual-to-the-exteeem AS/400 platform.
No new lessons to be learnt here.
Coca Cola is far more popular than much healthier drinks. The marketplace is governed by economic and political considerations that should not mean what fails it is inferior.