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?
Um, how relevant is Minix these days? Is it honestly intended to be used on a PC or is it aimed squarely at embedded devices? I'll admit, I really enjoyed Minix back in the old days, on a single 360k on an 8088.. It was quite an amazing trick. But NOW?
Each processor would proceed sequentially as if it had been better for them not to rise against Saul.
That'd be cool to give this a bash with our shiny new VMWare players!
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!"
I have done my share of kernel programming and I have always thought that it is pretty horrible that simple device driver bugs can take down the system. Almost all of Windows' Blue Screens are from bad third party drivers. Almost all of the oopses I have seen on linux are from device drivers for extra hardware (I mean drivers not for core common O/S features). On linux device driver debug still seems to be horrible; on Windows it is considerably better but still not as good as application debug.
With common user systems as cheap and fast as they are now, do user mode device drivers make sense? Is the performance worth giving up for the stability? Check out Microsoft's User-mode Driver Framework approach. Here is an old linux journal article on the subject. Does anyone know of other interesting examples of user mode device drivers on any operating systems?
-- soldack
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.
I agree 100%. And there has been excellent prior work in that area, with fault isolation in single-address space kernels; experiments suggest that single-address space approaches are significantly faster. And it doesn't even have to be Java or C#; languages like Modula-3 or Object Pascal are far safer than C and can get by with a tiny runtime. Heck, even consistent use of C++ for writing kernels would be better than what people are doing now, despite the numerous problems that C++ has.
It is just astounding to me that while anybody else would be laughed at if they tried to write a modern, complex application in ANSI C, operating system designers are somehow considered special, as if concepts like "abstraction", "error handling", and "runtime safety" didn't matter for kernels that are millions of lines big.
Well, since nobody else has posted a very informative answer...
Linux is based on MINIX. It was built on MINIX, using MINIX. It started off as Linus's weekend hack to build a 386-specific replacement kernel, so he could have MINIX with pre-emptive multi-tasking and memory protection. Andy Tanenbaum didn't want to make MINIX 386-specific because, like the NetBSD and Debian folks, he was trying to make something that would be portable to lots of different hardware. (Like the Atari ST I was running it on.)
Then there was the big flamewar over monolithic kernels vs modular microkernels. Linus went off in a huff and turned Linux into a complete OS by ripping out all the MINIX and adding all the GNU stuff instead. Then over the years he introduced a modular kernel and made it portable to multiple architectures, basically admitting he was wrong but never saying so.
At that point, Linux started to become usable as an OS. And in the mean time, MINIX had been killed by toxic licensing policies of the copyright owner (not Andy Tanenbaum). That, and the x86 architecture had expanded to 90% of the market. So, we arrived at the situation we have today, where MINIX is largely forgotten, and we have a MINIX-like Linux with all the mindshare.
And now, ironically, Andy Tanenbaum has made MINIX 3 only run on the x86. So perhaps he and Linus can now both admit they were wrong in major respects, and make friends?
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
All else equal, the faster code is better.
Sure, but all things are not equal, and an improvement that obviously improves performance, often doesn't. OS programming isn't quite the same as pure user-level programming, so optimizations aren't so clear-cut.
People often assume that monolithic kernels are faster than properly designed microkernels due to less supervisor-user context switching, but this often isn't the largest cost in modern systems. For instance, monolithic kernels can't/don't schedule their interrupt handling through the common scheduler, so they're nearly impossible to use for realtime.
Reliability, flexibility and security is also dramatically improved in decomposed microkernel designs, so really, suffering a 5-10% performance penalty to gain an extra few 9's in reliability (99.99% uptime as opposed to 99%) is often worth it IMO.
Higher Logics: where programming meets science.
16MB ram in the requirements... all I can say is WOW.
This is supposed to be a simple OS, much simpler than the first version of Linux.
ucLinux can run on 1MB. Older versions can be trimmed enough to run in 200kb even but thats pushing it. Minix now requires 16MB!!! Thats more than ANY BSD out there.
I was interested in running it on MCUs with small ram and flash. Trimming down uCLinux to the extreme uses 200kb of ram by the kernel and one shell. eCos requires under 64kb for simple compilations. eCos is POSIX for the most part, but theres hardly any schedulers in there, and no real filesystem drivers or calls.
Minix is a full OS, but being that simple, I expected the kernel to fit in 64kb ram. I guess I'll use NetBSD as a simpler OS to study before graduating on to Minix 3.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
Tanenbaum is unscientific: he focuses on a single variable and ignores all the others; he fails to even state his claims properly, let alone support them with data; and he fails to justify a novel approach with a detailed empirical analysis of prior work.
Even if what you say is true, there are plenty of others making very detailed analyses of microkernel architectures, and they have reached many of the same conclusions: that microkernels are feasible, useful, and practical, if done correctly. The real problem is that microkernels have a stigma attached to them, and because they are hard to properly design and implement. As such, only researchers have traditionally worked on them, and we all know researchers are not going to develop a full-featured system like Linux. Hopefully, that will change with CapROS.
See my other posts in this thread:
Performance
Examples of microkernel sytems
Higher Logics: where programming meets science.
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.