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.
Ahh, I used to run Minix 1.X on an Atari ST ages ago, maybe it's time to take a nostalgia trip.
However, while I agree that microkernels are conceptually smarter, Linux has clearly won the "unix on a PC hardware" contest. But then again, as far as I could tell, that contest was never on AST's agenda anyway. For him the Minix system was a teaching tool.
> They will run old MS-DOS programs by interpreting the 80386 in software.
:-) I use Dosbox quite often for playing old games, tinkering with TASM, etc.
Well, this is partly true
Please don't, as this is also a nice gathering tool for measuring the slashdot effect and see if our replicated web server is holding out. We are using a dozen machines over the world to host the content.
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.
Why, yes, yes it does.
When you're afraid to download music illegally in your own home, then the terrorists have won!
GNU/Linux is somehow compatible with minux.
They both run most of the gnu toolset. Note that minux has more of a bsd like license. "Redistributions in binary form must reproduce the above copyright notice...". Note that the minux distirbution contains a lot of the (GPL) gnu tool.
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!
http://www.mklinux.org/
Not sure how current it is, and it might be for 68000-based CPUs if I'm not confusing it with another project.
I tried it about 8 years ago so my experience is probably way outdated. Then it wouldn't even boot on about 7 of 10 of my PCs and the ones that did boot were pretty limited. I think it was QNX that had one feature I did find interesting though.. the ability to move your logged in GUI session from client machine to client machine without shutting apps down or logging out. It was a pretty cool feature similar to what we can do with VNC today but smoother. I'd love to see that work in X. (If that wasn't QNX then I have no idea what it was!)
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
At issue isn't whether Tanenbaum is right or whether he is wrong, at issue is his methdology. 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. Tanenbaum just tinkers and makes grand claims. That's why he should receive a failing grade.
As for microkernels being new, they are not. They have been around for at least a quarter of a century (arguably longer), and they have received more than their fair share of attention and study. There have been many other ideas in OS design since then; if anything deserves attention, it is them.
Perhaps the most obvious and straightforward idea for how to improve reliability and decrease development costs for operating systems is to start applying modern, proven software development technologies: object-oriented programming languages, tools, design methodologies, safe runtimes, reflection, garbage collection, etc. The hypothesis that doing so improves reliability is far more plausible than Tanenbaum's hypothesis that we can stick with using ANSI C if we only use some hare-brained scheme of dividing everything up into separate address spaces. And, in fact, there is actual experimental evidence that using safe runtimes with monolithic kernels is more efficient for fault isolation than using unsafe runtimes with microkernels.
How about Mac OS X and Windows NT/2000/XP? Those are microkernel-based architectures. OS X uses Mach under the hood. Some BSD variants also support running on otop of Mach.
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.
Actually, you could modify it. You just couldn't distribute modified versions of it. You could, however, distribute patches against the original code as much as you wanted.
As to the reason for this, Andy T. had wanted to make the source widely available, but at that time (1990) there wasn't wide-spread access to the Internet (you had to be at a university that was on it, which many weren't, or you had to work for at a government shop). So the only choice was to have it published in the traditional maner (in this case, through Prentice Hall). But the publisher's at that time would only publish something if, and only if, they were exclusive. Andy fought hard to even get the publisher to allow "shadow copies" of the software (i.e., an instructor could give out copies to his students, or you could give out up to around 5 copies from a purchased copy).
If the Internet was more in full swing at the time, where you didn't need a traditional publisher, then I'm sure that things would have been different.
No. You would be switching the kernel from Linux to Minix {or The Hurd}, whilst retaining a GNU userland. So you would be switching over to GNU/Minix, or GNU/Hurd.
..... often having PID=1 and capable to bring down a system if inelegantly terminated] and sends back the output generated from the command}, the "ls" command is invoked. The kernel checks to see if there is an undamaged copy of "ls" in memory already, and if not loads one. The "ls" command passes a call to the kernel to read the directory listing from the disk, then generates some human-readable output from this data. The shell calls the kernel to write this information to the screen.
There are two parts to an operating system; the kernel {which provides a very low level interface to the computer's hardware} and the userland {which provides an interface to people}. The GNU project has created a viable userland, but is still having difficulty producing a kernel. Linus Torvalds -- then a student of Tanenbaum -- created Linux, originally a simple kernel which has now grown into something much bigger.
When you type "ls" {which is a userland command} into the shell {another userland process, which accepts commands from users [by means of a call to the kernel], passes them to the process sheduler [another userland process
It was when hackers wrapped a GNU userland around the Linux kernel that the magic really began to happen. Of course, you could just as easily wrap a GNU userland around the FreeBSD kernel, or a BSD userland around Linux, but GNU and Linux just hit it off the best.
The delicious irony of all this is that Linux really was first created just to prove a point: that a monolithic kernel could sometimes outperform a microkernel {which Tanenbaum disputed}. Though apparently counter-intuitive, this is not really all that surprising when you think about it a little harder: certain Typical Real Life Operations are predictable enough to optimise very hard, and a monolithic kernel naturally supports harder optimisation than a microkernel at the expense of some flexibility. If the operations you optimise hardest happen commonly enough, then the performance gain can be significant. {Cf. if you live in an area with plenty of sunshine, waste disposal by landfill, and your water heater runs on almost any fuel besides electricity, then terry nappies will definitely be greener; whereas if your household waste is burned in a reasonably modern power plant, your water heater is electric and prevailing weather conditions are such that you need to use a tumble drier for the majority of your washing loads, disposables might work out better.}
Je fume. Tu fumes. Nous fûmes!
That is why Linux original used ext2 (same fs as minix)
No, Minix used (uses? not sure what the "new" minix uses) the minix filesystem, which was only able to address I think it was 32mb of space.
Linux had the EXT2 filesystem at a later date, migrating away from the Minix filesystem. If you compile your kernel, you'll still see the option to have the minix filesystem functionality compiled in. (or modularized)
I still remember having to decide if I wanted to go with the "new" ext2 filesystem, which will not be compatible with older kernels. *g* Back then, that was a big deal, or so it seemed.
Btw, saying that Minix and Linux are "trying" to be like Unix is about like saying that Hyundai and Acura are alot like Toyota because they are trying to be cars.
-- This space for lease, low setup fee, inquire within!
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.
Good point. Both OS X and NT+ do violate the microkernel philosophy in the name of performance (Wikipedia calls them Hybrid kernels). However, they differ significantly from monolithic kernels like Linux in that third party drivers are by default outside of the kernel instead of inside.
:-)
So perhaps they're millikernels?
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.
Yes, it is --- it's on a Minix filesystem tucked away at the top of the ISO filesystem. If you boot the CD, you'll get a complete Minix LiveCD based system, with all the source on it.
If you want to access it from Linux you'll need to persuade Linux to parse the partition table on the CD, which it normally won't do --- the easiest way to do this is to dd the whole lot off the CD and onto a scratch drive. Linux will then see the partition table, and you'll be able to find and mount the Minix filesystem.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Oh, I get it. I'm supposed to distinguish microkernels from other things only in terms of aspects you dislike, allowing you to appropriate anything you do like for "your side" of the debate? Sorry, not falling for it. As I said earlier, both microkernels and OOP are variants of the same basic concept: modularity. Like one, like both. Hate one, hate both. Making arbitrary distinctions for the sole sake of hyping one and dissing the other is dishonest.
Then such a kernel's not very monolithic, is it? Idiot. What do you call that piece of code that takes care of loading classes and dealing with reflection and garbage collection and other forms of inter-component mediation and safety enforcement in your microkernel-less utopia, Mr. Smartass? Oh, right. It's a microkernel. Sheesh.
Oh, so Java objects can't exchange messages, or implement trivial getter/setter methods? Yeah, right. The kind of twiddling you mention is trivially possible in any language or environment, whether it be C or Java or Linux or QNX. I've even written about that problem. . .twice, and both before you showed up to be educated. Attributing a problem only to one paradigm when it applies to both is, again, dishonest.
You're just lucky I'm not charging you my usual hourly rate for being your own private tutor. You couldn't afford it, and will never be able to while you have more attitude than knowledge.
Slashdot - News for Herds. Stuff that Splatters.
Ah, I think I understand this kernel/userland distinction. What you are saying is that Linux is just a kernel, and the GNU people make X11 and KDE, which is how people actually interact with the system. Oh, wait, no they didn't. They made ls and whatnot. Oooooh, they makes it surely worth noting loudly everytime I talk about my OS.
To be fair, I do prefer the GNU userland to the BSD stuff. None of it would exst without gcc, which is probably the single most important Open Source project in existence. But, even so, I find the "GNU/Linux" issue to be just a bunch of whiny pedantry.
Cheriton's V System didn't suck. I used it in a commercial project in the late 1980s and loved it; it met all of your criteria. If Cheriton had open-sourced it, I think it would have had a huge impact. But he didn't, and for whatever reason it hasn't.