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!
Tannenbaum's home page:
http://www.cs.vu.nl/~ast/
Yes, it's the same guy who wrote the book for your networking course.
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.
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.
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."
Colin Davis
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.
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
Anagram("United States of America") == "Dine out, taste a Mac, fries"
Not only that, there is also a VMware image!
-- (:> jms cs.vu.nl (_) --"---
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!
QNX Neutrino is an example of a microkernel which doesn't suck. In fact QNX sees heavy use in realtime environments, where both space and performance matter a great deal. Some applications of QNX put considerable importance on the thing not collapsing in a heap after a failure of some part.
The original Windows NT architecture might have been a microkernel. But ever since the 4.0 version where Microsoft pulled the video subsystem into kernel space, there is no way you can still call that a microkernal. And they have only been pulling more and more into kernal space (for example, large portions of the IIS 6.0 HTTP processor actually run in kernel space on Windows Server 2003).
The real problem is not whether machines think but whether men do. - B.F. Skinner
The biggest problem seems to be that that extra layer of abstraction slows things down (which makes sense really). [...] If heavy usage servers can be run as virtual machines in Xen then why not use a microkernel too?
Funny you should mention Xen, because it's essentially a microkernel running other kernels as protected processes.
So. Any examples of microkernel OS's that handle heavy server load, function well as a desktop, and can handle multimedia tasks like gaming?
Other posts mention QNX, so I won't bother.
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).
You'd be surprised. There's a lot of vested interest in the current programming paradigms and existing codebase. A principled microkernel architecture might just be incompatible with POSIX, which eliminates a large swath of portable and useful software.
If you want performance, you need look no further than L4, EROS (and it's successor CapROS). For a principled design, I'd go with EROS/CapROS or the next generation capability system Coyotos (who's designers are trying very hard to implement POSIX while maintaining capability security).
Something useful right now, doesn't exist as far as I know.
Higher Logics: where programming meets science.
True, but you overlooked the fact that I said, "I meant switch over from GNU/Linux!" [emphasis added]. You think you're contradicting me, but you're not.
Linus Torvalds -- then a student of Tanenbaum
Torvalds was never a student of Tanenbaum. Like many computing students the world over, myself included, he learned something about OS hacking using Minix, which is Tanenbaum's baby, but he wasn't a student of Tanenbaum. Tanenbaum teaches at Vrije Universiteit in the Netherlands; Torvalds went to Helsinki University in Finland.
Linux really was first created just to prove a point: that a monolithic kernel could sometimes outperform a microkernel
No, that's not right either. Presumably this fiction follows from your earlier fiction about Linus being a student of Tanenbaum. Tanenbaum's take on the matter is as follows.
Go brush up on your research skills. We can work on your stylistic elements after you get your facts straight.
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.
Actually, the bigger problem with microkernel is debugging. When passing messages around inside an OS, there is a potential for lots of race states and the like. The trick to microkernel is getting the messages to run around as fast as possible without adding synchronization points. Every synchronization point slows the system a little, but makes the system a little more stable. Once you've optimized the system for performance, and small change to any module the kernel talks to can throw the whole thing out of balance, and you need to go back and debug the race states and retune the code.
In short, a kernel can be fast, flexible, or reliable. You can have two, but it is really difficult to have three. Macro-kernels are generally fast and reliable. Micro-kernels can be fast and flexible, flexible and reliable, but rarely are they fast and reliable.