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."

Comments

live-CD

[DreamerFi]

And you can try it out on your current PC - the download is a live-cd!

Phew

[Anonymous Coward]

Now we can all switch over from Linux, at least until Hurd ships.

*pummeling ensues*

GNU/Hurd!! I meant GNU/Hurd!!!

Love this quote

[strider44]

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.

Re:Love this quote

[strider44]

In the meantime, RISC chips happened, and some of them are running at over 100 MIPS. Speeds of 200 MIPS and more are likely in the coming years. These things are not going to suddenly vanish. What is going to happen is that they will gradually take over from the 80x86 line. They will run old MS-DOS programs by interpreting the 80386 in software. (I even wrote my own IBM PC simulator in C, which you can get by FTP from ftp.cs.vu.nl = 192.31.231.42 in dir minix/simulator.) I think it is a gross error to design an OS for any specific architecture, since that is not going to be around all that long. Another one. Reading predictions from fifteen years ago is really quite entertaining, showing that even the smartest people can get things slightly wrong.

Re:Love this quote

[E1ven]

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.

And while it's not 15 years out, IIRC, the IA-64 architecture did actually use a software translator. (Although to be fair, I think that was more of a VLIW style chip)

While I don't claim to understand the entire 15 year history of chip production perfectly, I wouldn't be so quick to dismiss his comments. He was more right than he was wrong.

Re:Love this quote

[MikeFM]

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).

Re:Love this quote

[Sentry21]

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).

The OS X kernel is a different situation. Darwin is a mixture of microkernel and monolithic, as is (for example) Linux. In Linux, a lot of things (like device configuration, etc.) get done in userspace by daemons using a kernel interface, which means the kernel need only contain the code necessary to initialize the device. Darwin's kernel (xnu), however, is a more complex design in terms of overall design (though the internals may be less complex - I'm not a kernel developer), and is derived from Mach 3.0 and FreeBSD 5.0.

Mach provides xnu with kernel threads, message-passing (for IPC), memory management (including protected memory and VM), kernel debugging, realtimeness, and console I/O. It also enables the use of the Mach-O binary format, which allows one binary to contain code for multiple architectures (e.g. x86 and PPC). In fact, when I installed OpenDarwin quite a while ago, all the binaries that came with it were dual-architecture-enabled, meaning I could mount the same drive on PPC or x86 and execute them (which is kind of neat).

The BSD kernel provides (obviously) the BSD layer, as well as POSIX, the process model, security policies, UIDs, networking, VFS (with filesystem-independant journalling), permissions, SysV IPC, the crypto framework, and some primitives.

On top of all that is IOKit, the driver framework. It uses a subset of C++, and the OO design allows faster development with less code, and easier debugging as well. It is multi-threaded, SMP-safe, and allows for hot-plugging and dynamic configuration, and most interestingly of all, some drivers can be written to run in userspace, providing stability in the case of a crash.

Now, as to your comment about performance, it is possible you are referring to the tests done using MySQL a while back, which shows MySQL performance as being (as I recall) abysmal compared to Linux on the same hardware. The problem with that test is that MySQL uses functions that tell the kernel to flush writes to disk. These functions are supposed to block so that the program can't continue until the writes are done and the data is stored on the platter. On OS X, this is exactly what happens, and every time MySQL requests data be flushed, the thread doing the flushing has to wait until the data is on the platter (or at the very least, in the drive's write cache). On Linux, this function returns instantly, as Linux (apparently) assumes that hard drives and power supplies are infallible, and obviously if you're that concerned about your data, get a UPS.

It should be noted that MySQL, in the online manual, strongly recommend turning that feature off for production systems, forcing Linux to block until the write is completed, and lowering performance. I would be interested to see a benchmark comparing the two with this configuration.

This discrepancy in the way Linux handles flush requests vs. the way OS X handles them gives a noticable drop in performance in a standard MySQL situation. I am told that the version that ships with OS X Server 10.4 is modified so as to increase performance while keeping reliability. Unfortunately, I cannot confirm this at this point.

Honest question

[Frogbert]

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?

Re:Honest question

[TheMMaster]

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 :"more like your BSD's in comparision to Linux"

Re:Honest question

[shadowknot]

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.

Re:Honest question

[/ASCII]

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.

Re:Honest question

[TDRighteo]

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:

I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful you are not my student. You would not get a high grade for such a design :-)
--- Andy Tanenbaum

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.

for those that don't know

[Anonymous Coward]

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.

Re:Minix on a modern machine?

[Inominate]

It's not relevant as an actual operating system. It's relevance lies in it's use in teaching operating system design. Minix is a very simple, yet complete OS.

Re:Thank you, Dr. Tanenbaum.

[TrappedByMyself]

Your contributions have been much appreciated.

Yes, thank you. My sadistic operating systems professor used your textbook. Your name still gives me nightmares to this day.

Re:This guy told linus

[LizardKing]

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.

The code is nice

[DavidNWelton]

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

Re:Minix on a modern machine?

[E1ven]

Historically, that's been true, but the 3.0 version seems to be re-targetted toward being a more functional OS as well.
While I'm sure it's still primarily intended for Teaching, He's focusing on reliability as the selling point of the new version-
It's got an advantage over Linux in that all drivers run in user-space. That means drivers can't bring down the whole kernel. Given that most kernel bugs come from driver implementations, this is a very nice feature.

"MINIX 1 and 2 were intended as teaching tools; MINIX 3 adds the new goal of being usable as a serious system on resource-limited and embedded computers and for applications requiring high reliability."

Tanenbaum gets a failing grade

[idlake]

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.

Re:Tanenbaum gets a failing grade

[0xABADC0DA]

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.

Re:Tanenbaum gets a failing grade

[Salamander]

Experience with Mach, Hurd, Darwin, and Minix shows that this is clearly not the case: many common microkernels have proven to be more difficult to extend and maintain, to be less robust, and to perform worse than monolithic kernels.

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.

Microkernels are an attempt to overcome the problems with unsafe, static runtimes and languages by putting components into separate address spaces

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.

If you have a safe, dynamic runtime, you don't need a microkernel architecture.

And how is that "safe, dynamic runtime" not itself a microkernel?

Among software developers, people like you are among the last holdouts that think it's OK to write millions of lines of C code with ad-hoc self-invented object-like dispatch tables and manual storage management.

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.

Instead of making it easier for people to modify the kernel, they try to keep it some obscure art form.

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

Recollections

[awol]

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 ;-)

Re:Old laptops

[Vo0k]

NetBSD.
I've found myself in similar situation once, Linux or Solaris wouldn't fit with reasonable amount of useful stuff on a 200M harddrive of an old SUN. Then I managed to fit most of the NetBSD distro, with 2 desktop managers, Netscape Navigator (pre-Moz times), bunch of servers for running a remote diskless workstation and still managed to cut 40M of diskspace for swap memory for that remote workstation :)

Tannenbaum still ahead!

[Vo0k]

See? It's Minix 3 already, while Linux is still in 2.x! ;)

VMware image. Was :live-CD

[JanMark]

Not only that, there is also a VMware image!

Educational standards on Slashdot...

[MosesJones]

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?

It's all BSD licensed

[david.given]

It's worth pointing out that one of Minix's great selling-points is that it's all BSD licensed --- including the tool chain. It doesn't use gcc by default; its native compiler is the BSD licensed Amsterdam Compiler Kit.

This makes it, as far as I know, the only completely BSD licensed Unix-like operating system in the world. Even the big BSDs can't claim that, as they all rely on gcc.

I was in on the Minix beta testing. It's actually extremely impressive. It's quite minimalist; most of the shell commands are pared down to their bare minimum --- for example, tar doesn't support the j or z flags --- and it tends towards SysV rather than BSD with things like options to ps. It runs happily on a 4MB 486 with 1GB of hard drive, with no virtual memory, and will contentedly churn through a complete rebuild without any trouble whatsoever. Slackware users will probably like it.

Driver support isn't particularly great; apart from the usual communications port drivers, there's a small selection of supported network cards, a FDD driver, an IDE-ATA driver that supports CDROMs, and a BIOS hard disk driver for when you're using SCSI or USB or some other exotic storage. The VFS only supports a single filesystem, MinixFS (surprise, suprise!) but allows you multiple mountpoints. In order to read CDs or DOS floppies you need external commands.

There's no GUI, of course.

As a test, as part of the beta program, I did manage to get ipkg working on it. This required a fair bit of hacking, mostly due to ipkg assuming it was running on a gcc/Linux system, but it did work, and I found myself able to construct and install .ipk packages --- rather impressive. Now the real thing's been released, I need to revisit it.

Oh, yeah, it has one of the nicest boot loaders I've ever seen --- it's programmable!

Device drivers: Andrew is living on denial.

[MROD]

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.

Re:Answer from someone who was there

[kl76]

  It started off as Linus's weekend hack to build a 386-specific replacement kernel

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.

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.

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).

  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.

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.

Re:System Requirements

[argent]

16MB ram in the requirements... all I can say is WOW.

What hardware do I need to run MINIX 3?<br>
You need an Intel 386 or higher with 4 MB of RAM, an IDE hard disk with 100 MB of free disk space, and an IDE CD-ROM for booting.

Globule?

[Thuktun]

Disclaimer: I am the chief architect of Globule, the experimental content-distribution network used to host www.minix3.org.

Translation: "Please load-test my network."