You are here

MINIX: what is it, and why is it still relevant?

MINIX, as originated by Andy Tanenbaum, is an operating system that has its roots and heart in academia as a tool that teaches you how kernels really should work. Recently, however, with the advent of version three of this rock solid OS, the focus is on making a production ripe embedded distribution. Being POSIX compatible with a Kernel of 3800 lines of code and a unique approach to handling drivers, MINIX 3 is well worth the effort to review for readiness.

A very brief history

Andy Tanenbaum first released MINIX 1 in 1987 as an appendix to the book, Operating Systems: Design and Implementation. MINIX rapidly became very popular, with a USENET newsgroup being formed with 40,000 readers within 3 months. One of these readers was Linus Torvalds, who went out and bought a PC just to run and study MINIX. He wanted some improvements, so he made them himself. Then he made some more, and eventually he realized that he had gradually converted MINIX into his own operating system, entirely free of the original code.

MINIX 2 was released in 1997 with the next edition of Andy Tanenbaum and Albert S Woodhull’s book.

MINIX 3 (current stable version 3.1.2) is now out and by no coincidence the book’s third edition. The OS has been released under a BSD license, which should, in theory, suit both commercial and educational markets. For the first time, there is a clearly stated emphasis on an industrial ripe Kernel for embedded applications. Hence, my motivation for writing this article.

There is a clearly stated emphasis on an industrial ripe Kernel for embedded applications

Trivia: the MINIX mascot is a Raccoon (figure 1), which, to me, seems to be a nice positive figure that can compete with Penguins in terms of cuddliness.

Currently the MINIX website is quite active with 1400 visitors a day on weekdays. Better still: expect version 3.1.3 of MINIX released around the time you read this article. The new release will focus on greatly increasing the reliability (e.g., being able to survive and replace device driver crashes without the user even noticing).

Figure 1: MINIX Raccoon logo

A little technology

For the most up to date technical information please visit the document section of the MINIX home.

MINIX 3 is POSIX compatible, which implies that the OS has a set of standard interfaces. Practically speaking, this implies that porting a large swathe of software from other POSIX compatible systems, such as Linux, is straightforward. MINIX has already had 400 packages ported including X windows.

MINIX 3 runs on 386, 486, or Pentiums or compatible CPUs, and can be installed on a system with as little as 50MB of disk space and 8MB of ram. Therefore, the distribution should run nicely on the laptop I first used ten years ago.

Architecturally, MINIX is based on the concept of a microkernel where the device drivers live in user land. This is advantageous, as processes in user land do not have direct access to resources without first going through the Kernel and should not be able to crash the Kernel through misbehavior. This very strong toughening catches many failure paths that are present in the much larger monolithic kernels such as Windows or Linux. Further, this allows the Kernel to remain small and understandable by any experienced kernel programmer, the fewer lines of code that exist in the Kernel the less likely that bugs, security, or maintainability issues occur.

Designed into the OS is a reincarnation server to restart device drivers if they have stalled or crashed. This feature is a rather nice self-healing process that you may want in your satellites and nuclear reactors.

The main performance trade off is extra effort required for context switching from the Kernel to user land for device drivers, which decreases the performance when compared to monolithic Kernels. The question to answer then is whether the performance overhead of 5-10% is made up for by the elegant design’s enhanced reliability, readability, and maintainability. I personally suspect it is.

The performance overhead of 5-10% is made up for by the elegant design’s enhanced reliability, readability, and maintainability

Interview with Andy Tanenbaum

Andy Tanenbaum has many achievements (see his Wikipedia entry) including writing some excellent textbooks, teaching, and being the design guru behind MINIX.

Questions

AB: Can you give a little background context of your role within the development process of MINIX3.

AT: I am the guiding light and occasional disciplinarian. I try to keep our goal in focus—building a highly reliable system. My Ph.D students, Masters students, and professional programmers do the actual work.

AB: MINIX has had a traditional role as a learning tool within University environments; do you have any idea about how widely MINIX is currently deployed?

AT: I don’t think the book sales of the hardcover text version in English have ever dipped below 10,000 copies a year for 20 years, and it has been published in places like India in runs of 100,000. And the book has been translated into a dozen languages. The number of students who have studied MINIX in detail is surely north of half a million and still going strong. The www.minix3.org Website currently gets about 1100 to 1400 hits a day and there have been over 100,000 downloads of the CD-ROM image in the past year. Because it comes with the Berkeley license, industrial users who modify it for products don’t have to report back to us, so I don’t know much about use in embedded systems.

AB: MINIX3 has been designed to be a production ripe OS for embedded and low resource computers. Is MINIX being taken up in industry at present?

AT: MINIX 3 hasn’t been out there long enough to have acquired much of an industrial user base, and companies don’t have to tell us they are using it, so I don’t really know.

AB: What do you see as the near future development goals of MINIX?

AT: Making it self-healing, I think with version 3.1.3 it should be possible to start a long file transfer over the network, then repeatedly kill the disk driver and Ethernet driver to simulate driver crashes and have the transfer complete correctly with no errors, despite the drivers being automatically replaced on the fly during operation multiple times. Other systems don’t do quite as well when drivers crash (or are killed to simulate crashes). They go belly up instantly.

There you have it, an interview with Andy Tanenbaum and an OS built on the KISS principle. Now to install MINIX 3.

Installation

MINIX 3 is downloadable as source and as a Live CD. After booting from the CD, the process of installing a disk is straightforward. However, the installation requires an extra partition. For demonstration purposes, I have, therefore, chosen to use a virtual machine QEMU and a pseudo partition contained within a specially formatted file. If you are as pleased as I am with the outcome, then you can always later repartition your real hard disk and perform the setup properly.

A second advantage of having a partition stored within a file is that you can copy the file to other machines and use the virtualization player to run; thus allowing different setups, browsers, and test configurations. Further, as we move from a single process paradigm to multiple cores—where the cores reside not only traditionally in the CPU, but also in the graphics card and perhaps even the sound card—we can expect that, for Service Providers, multiple virtualizations may be the most efficient approach to consuming the maximum amount of resources with useful work per customer.

The following instructions require 1GB of hard disk and 160MB of free memory. Note: I am spoiling myself here. It is viable to perform a setup with less resources; however, I am installing on a typical, if not slightly old PC, and am not trying to push forward a resource lean embedded environment. I have based the instructions on Ubuntu Linux 6.06; however, QEMU, being virtualization software, also runs stably on other OSes (MAC, Windows and, of course, other Linux and UNIX distributions). On the other OSes, after installing QEMU, the instructions shouldn’t change.

The two virtual machines I considered for use were QEMU and Bochs, both excellent free software tools of the trade. First, I tried QEMU out and the process worked first time without any errors or hassles; therefore, I never got around to trying out Bochs.

I tried QEMU out and the process worked first time without any errors or hassles

The QEMU emulator is GPLed under the circumstances that we are using it. However, there is a proprietary license associated with the accelerator pack. Without the accelerator pack the emulator runs between 5-10 times slower than the system that is being emulated. This slow down is not an issue for MINIX3 which is fast and has a small footprint.

The approach I am taking is to download the bootable disc image from the official MINIX 3 website, create an empty virtual partition, boot up the image within the emulator, and populate the virtual disc via a standard setup. Finally, I’ll boot off the virtual disc via QEMU and play "Dungeons" a rather nice text based adventure, which I had much fun with as a student (and yes I am that old!).

Note: At the time of writing the download links were working. If, in the meantime, the links fail, please visit www.minix3.org to get the CD image.

In Ubuntu, with system administrator rights, you can install QEMU via the command line with the following command:

sudo apt-get install qemu
Do you want to continue [Y/n]?

The result of your action should be similar to:

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
bochsbios vgabios
Recommended packages:
debootstrap sharutils proll openhackware
The following NEW packages will be installed:
bochsbios qemu vgabios
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 3861kB of archives.
After unpacking 10.4MB of additional disk space will be used.
Do you want to continue [Y/n]?

If this approach fails then please visit the homepage of QEMU.

After checking that you have enough disk space for the 1GB pseudo file system and the 250MB CD image, create a directory in your home directory.

cd ~
mkdir minix3

Download the CDROM image, either via your web browser or via wget, from the MINIX 3 website and expand it into the minix3 directory.

Make an empty virtual image with 1GB free. I chose 1GB so that I’d have room to install lots of packages and their sources. However, you maybe able to get away with around 100MB if you restrict yourself to an elite set of packages and no sources.

qemu-img create minix3_1_2_a.img 1024M

The output should be similar to:

Formating 'minix3_1_2_a.img', fmt=raw, size=1048552 kB

In addition, the file minix3_1_2_a.img should now exist and it should be of the correct file size.

Login as root and create a root password from the command line via passwd. Type less from the command line. Oh no! the tool is not installed:

less: No such file or directory

Okay, now we need to install some applications. The CD image contains 40 such packages. Your next action should be to type packman to run the package manager, and then press ‘3’ to list the packages on the CD. A list should appear similar to that shown in figure 3.

Figure 3: List of installable packages found on the CD Rom image

Press ‘q’ to return to the original menu. Select ‘4’ to choose a package and ‘21’ for the less package.

For some homework, install dungeons (package 11) and run it from the command line, within the game type info. The game was fun when I was a student all those long and wasted years ago. Perhaps, you will find it as fun.

Figure 4: Time to play in the dungeons

What to do next

MINIX is fast, reliable (well I have never seen it crash or freeze) and, with a small footprint, is ideal for your old Pentiums or even 386s and 486s that might still be hanging around in your loft somewhere.

MINIX is fast, reliable and, with a small footprint, is ideal for your old Pentiums or even 386s and 486s

I would respectfully suggest that you try to get yourself onto the network and start using it. If you find any issues, report them back to the hard working development community via comp.os.minix.

If you think that your favorite free software package or a device driver is missing, then why not join the development community and volunteer your time to build this lean-mean-operating-system-machine’s vocabulary of packages to a higher level? I suspect that you will learn some good practices on the way.

Finally, if you wish to brush up on the theoretical constructs behind OS design with a MINIX 3 practical bias, then you may be interested in reading the updated classic Operating Systems Design and Implementation 3 edition by Andrew S. Tanenbaum and Albert S. Woodhull.

Impressions

Personally, I found MINIX 3 fun to play with. Installing it on an old PC was quick and painless. Boot up time is dramatically less than for Windows or Linux, partially because the Kernel is so lean and only a few servers are running. Being POSIX compatible and being able to run X Windows makes porting of GNOME or KDE (or Window managers, in general), viable and potentially straightforward. Though intended for the embedded marketplace, I don’t see any reason to not position MINIX as a viable OS that will later stand alongside Linux, FreeBSD and OpenBSD, etc., in audience recognition. I even positively contemplate the possibility of an ergonomic fit with embedded Apache, Tomcat and Java as an efficient internet application host. However, no doubt, that would depend on the performance hit of context switches from kernel space to user land due to the deliberate reliability design feature of placing drivers in user land.

I don’t see any reason to not position MINIX as a viable OS that will later stand alongside Linux, FreeBSD and OpenBSD, etc., in audience recognition

Finally, it is clear that the design of MINIX 3 brings new competitive ideas for enhancing reliability and maintainability to the fore. I hope MINIX 3 will stimulate the next generation of OS designers in the same way it has the previous.

Acknowledgments

I wish to acknowledge the input of Andy Tanenbaum and the historically-seen rippling effects of his innovative design concepts on others.

You're putting words in the mouths of "GNU/Linux" advocates that they do not say. Read the real argument.

http://www.gnu.org/gnu/why-gnu-linux.html

GNU was a project to create a free replacement of the operating system Unix. Unix was not a shell, it was not a hardware manager (kernel), it was not a C library, it was not a set of core commands, it was not a C compiler... Unix was an operating system that consisted of *all* of these things.

GNU succeeded in creating free replacements for most of these pieces of Unix by 1991. One piece that was not yet complete was a hardware manager. (a kernel)

At that time Linus Torvalds started writing his own Unix like hardware manager (a kernel) called Linux. This project is what Linux *is* and has always been. It still bears that name, look of the project name part of the source tarball's file name:
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.20.tar.gz

With all the major pieces of a Unix like operating system complete, people were able to combine GNU and Linux to make a Unix like operating system. They said to the world, "look, we have a Unix like operating system here, it is called Linux!".

Free software advocates could just ignore this accident of history. After all, what really matters is the freedom of users right? But ignoring the situation fails to address a problem that giving GNU fair due helps address. Many people believe that idealism and radical views are inconsistent with the achievement of tangible results. GNU, a project born of extreme idealism and a very radical viewpoint is a significant counter example. In a world where free software users are constantly being tempted to give up their freedom, it is worth the hassle to point out that the most significant contribution to the world's most popular free software operating system was successfully built by radical idealists who were told they would never succeed in doing so.

Copyright law gives people the POWER to control who can and can not copy information. Non-copyleft free software licenses are neutral, they leave this power intact. Copyleft free software licenses revoke this POWER so that all people can have the FREEDOM to make copies.

Compilers give people the POWER to hide what a computer program does and to prevent changes. Non-copyleft free software licenses are neutral, they leave this power intact. Copyleft free software licenses revoke this POWER so that all people can have the FREEDOM to control and improve the instructions that process the information that is an important part of their lives.

Minix doesn't require the GNU operating system to operate. Minix has its own operating system. Just because the GCC can run on the Minix OS doesn't mean that GNU OS is running on it. Since the GNU OS isn't running on the Minix OS, it doesn't require the name GNU/Minix

Linux requires an operating system. Without this operating system, Linux doesn't do much of anything. Linux works very well with the GNU operating system. The combination operating system platform should be known as GNU/Linux.

License too free? It doesn't matter which license is used, all that matters is that a free license is used. GPL is better at ensuring the user's freedom but the BSD license is much more preferable to any non-Free license.

One thing the desktop world can use is more reliability. Minix aims to be a very reliable, self-healing operating system. For me, this reliability is worth the extra overhead of operating a microkernel based operating system.

More work on Minix still needs to be done. Things like Minix 3's memory management is incomplete. AFAIK, Minix still doesn't have dynamic linking support.

Linus wrote Linux from scratch, he may have been inspired by MINIX and other Unix OS but he did not convert minix into his own OS. MINIX and Linux are fundamentally different. Linux is a monolithic kernel and MINIX is a microkernel

It's worth pointing out that Linus Torvalds started Linux because he wasn't happy with the original licensing conditions on MINIX. In the early days, Prentice-Hall claimed copyright on it, and would not allow it to be redistributed separately from the Tanenbaum book. That meant that all (legitimate) users of MINIX had to buy a copy of the book!

I believe this is no longer true with MINIX 3, but the damage has been done. Linux was able to prosper because it was Free Software from its early days, MINIX was not.

Let's set things straight:
UNIX was the basis for the GNU operating system: Richard M. Stallman wrote down the POSIX specifications and set out to write the GNU OS following those specs. Around that time, due to the sources of UNIX being locked down and costing a bundle to get, Alex Tanenbaum set out to write MINIX 1, due to his intimate knowledge of the original UNIX. By that time, the GNU OS was on the way and BSD Unix was too.
Here come Linus Torvalds; he had a 386, was running MINIX on it and then wanted it to support pseudoterminals - something that the MINIX kernel couldn't support. So he set out to write his own, using MINIX as a base but rewriting the kernel from scratch - ending up with a new kernel running with the other MINIX tools.
Having freed the code (and gotten, because of the syadmin at the Helsinki U, a name for it), Linus had now Linux ready to go; due to Tanenbaum's unwillingness to make MINIX into something it wasn't (a production OS), people started using Linux on MINIX an then, due to it feeling too constricted, started porting GNU (and some MIT and BSD) tools to it and adapting Linux (the kernel) to those more advanced tools (MINIX is, initially, a very small system).
As such, very early Linux systems should have been called Minix/Linux, and current systems should be called GNU/Linux.
What's best about this, is that starting with MINIX 2, all those free systems were POSIX compliant - meaning the hassle to port an application from one to another is actually quite low.

Now, why is Linux more advanced than MINIX? Simply put, there was much more work done on it. Why are the two so opposed? Because Linus T and Alex T disagree on a few key points. In MINIX initially, the memory manager itself was run in user space (!) which led to a 25% performance hit. On the other hand, Linux integrates everything in kernel space - which make it potentially unstable.
On desktop or low-load systems, the two are pretty much equivalent. On high-performance systems or very tightly integrated systems though, Linux wins. Why? Because its integration allow it to go faster and save on resources, its modular design allows big chunks of unneeded stuff to be removed, and as such it can run by itself. Minix needs to create a user space, then switch stuff back and forth. While stability is here, on very tight (I mean, only a few Kb of RAM here - Linux can run from ROM) systems it won't work.
Ideally, MINIX is indeed more stable than Linux; however, the latter has the edge on development (this can be corrected), is modular enough for today's applications (meaning it is in practice as good as MINIX), faster than MINIX (even Alex T agrees) and actually quite robust already.
Of course, if Linux offered more user space drivers (there are only a few available now) and restricted kernel space to high performance drivers (memory manager, accelerated graphics and real-time I/O), then we'd have the best of both worlds.
Ironically enough, considering how several modules are now made (NTFS-3G comes to mind), it may actully become true when emphasis won't be on added features and improved performance anymore.
---
A computer is like air conditioning: it becomes useless when you open windows.

First I think Minix 3 is still a research system ...
Mitch - thanks for the history lesson - some of us remember GNU when it was followed by a string of invectives! In a lot of ways Linus' kernel pulled GNU out of the "research" phase into the real world where things are expected to actually work. GNU software has come a long way in the last ten or so years. Seriously, I think we can thank all those people using the Linux kernel. I have tried MINIX 3 - and despite all the hoopla it still won't run X-windows on any of my old machines (no virtual memory). Supposedly they are working on that - but. I don't know what they are using with it to run X, but it ain't the 100 dollar laptop. I will re-evaluate when 3.1.3 comes out, but till then it is not robust enough to call industrial strength. When I can start it and use X on my old pentium systems (which have actually run X pre kernel-2.4.24) - I and a few other people will be most seriously interested. To get to the "beyond research" phase they need to add a memory server to the mix - yes the swap / pageable / virtual / whatever memory should run on one of those resurrectable device drivers. My experience suggests virtual memory screw-ups cause more crashes than device drivers. And no I won't buy the mythology that device drivers cause those virtual memory problems. If they did your PC would never finish the IPL. When Minix-3 can actually fix that, it should be ready for prime time. There are some great ideas involved in MINIX-3, and they will effect how future kernels work. This should become more evident as we move into multi-core processors and highly threaded systems. Think how much could be done with chips having 100 cores each running a minix like micro os using a highly integrated virtual interface. Think how the Linux kernel will need to evolve to manage this. Now, imagine what the mix will look like after 100 development cycles. Ok, Scotty Beam us up!

Author information

Biography

Alan Berg Bsc. MSc. PGCE, has been a lead developer at the Central Computer Services at the University of Amsterdam since 1998. In his spare time, he writes articles, book reviews and has authored three books. He has a degree, two masters and a teaching qualification. In previous incarnations, he was a technical writer, an Internet/Linux course writer, and a science teacher. He likes to get his hands dirty with the building and gluing of systems. He remains agile by playing computer games with his sons who (sadly) consistently beat him physically, mentally and morally at least twice in any given day.