6 ms·

MINIX 3: a Modular, Self-Healing POSIX-compatible Operating System

51 points by axman6 16y ago

rbanffy 16y ago
Absolutely fascinating lecture. Very much worth watching.
strlen 16y ago
After watching the lecture, just download Minix, setup it up in VMWare/Virtualbox/Bochs and hack something in it. Really, do it. It's amazingly cool OS and fun to play with.
switch007 16y ago
His book, "Modern Operating Systems", is a fascinating read for any geek. He discusses MINIX a fair bit (unsurprisingly!)
- michael_dorfman 16y ago
  Or, just get his "Operating Systems: Design and Implementation", which is a great read, and contains the full MINIX3 source code (printed and on CD).
  - rbanffy 16y ago
    Wow... I remember having read that in 88 or 89... It's a bit sad MINIX 1 would still be considered pretty modern.
yan 16y ago
MINIX is a fantastic kernel to practice kernel hacking on and see how operating systems function without the real world cruft of performance and portability hacks.
- ori_b 16y ago
  Personally, I found the code relatively painful to follow through. I'm not even talking about how the parts communicated - the code was difficult for me to trace through in the small. Even when compared to Linux or the BSDs, let alone Plan 9. K&R prototypes, overly decorative comments that just echo the name of the function, defining macros like 'PUBLIC' and FUNCTION_PROTOTYPE(name, args) which are effectively no-ops, and a host of other little annoyances that make the code - at least in my opinion - rather unidiomatic and painful to read C.
subwindow 16y ago
Not knowing much about OS design, is there any inherent reason why operating systems built on microkernels seem to be so unsuccessful? They always seem really elegant, but are never widely adopted (with the possible exception of Mach -> OS X).
- wmf 16y ago
  I think the main reason is poor marketing. Teams built microkernels, but of course a microkernel is not useful on its own so they had to build a complete OS. But being already tired (or near graduation) from building the kernel itself, they simply ported Unix to run on top of their microkernels, which led to a slower OS with no new features. There are benefits to microkernels, but all these benefits were hidden or wasted by Unix. By this time, patience (and thus funding) for microkernels had run out and researchers had to find something else to work on.
- ori_b 16y ago
  the OSX version of Mach has subsumed so much back into the kernel that it can barely be considered a microkernel any more. The thing is that for most systems, microkernels are a performance liability, (it's possible to make them perform well, but it's very hard to do while keeping memory protection) and with lots of hardware they tend not to be a big safety win - if you can wedge the hardware through bad commands, it doesn't matter if the commands originated in userspace or kernelspace.
  - dflock 16y ago
    This happened to the Windows NT microkernel too - they just kept shoving more and more stuff back into kernelspace for performance reasons, starting with Graphics drivers in NT4, and going from there. I think they may have yo-yo'd on Graphics Drivers later for stability reasons, but I've taken my eye off Windows since I stopped using it.
- Avshalom 16y ago
  Unsuccessful on the desktop, qnx for instance is a microkernel and is quite successful. On the desktop there's a lot of inertia, you need apps (which is a chicken and egg thing). As wmf said, you see a lot of poor unix on top of the kernel so there isn't even a compelling reason to use it.
CitizenKane 16y ago
I find it fascinating that the actor model seems to be the model for creating reliable software. You can see it in Scala or Erlang at the user level, get it in MINIX3 at the kernel level. I think if you combined the two you could potentially create systems which stay up for years.
- rbanffy 16y ago
  I have met a couple of QNX-based, also microkernel-based, systems that had uptime measured in years. Lovely OS. I learned C on it. MINIX reminds me of GNU/HURD. Since they are all Unix-ish from the application's point-of-view, I have hope they someday can more or less compete on equal footing with more traditional monolithic (it would be fair to call OSX "duolithic") OSs like Linux, BSD, Solaris. Very usable desktops like the Gnome I am using to write this don't care much about what is under the libraries they link against. They would be fine on top of any OS as long as libraries provided the environment they expect. Oddly enough, the first time I ran Gnome was on top of IRIX.
vital101 16y ago
In my undergraduate operating systems class we hacked away at an early version of Minix. The level of detailed code documentation always just blew me away.
pedrocr 16y ago
This 6k vs 6M LoC comparison is pretty dubious. If your disk driver has a bug and overwrites some data you're just as screwed up, be it running in userspace or kernel space. The argument these bugs are less powerful because they are now in userspace "can't do very much" is at best limited. Drivers can screw up hardware just as easily, filesystems can screw up your data just as easily, etc. The memory grant stuff seems interesting though and I see how that can protect you from some forms of memory corruption. Running all these processes in userspace seems to gain you some capabilities to more easily respawn/reset drivers. Live upgrade seems exciting. I wonder if you are paying for that in added complexity that is hard to debug. The tests they did are simulating basically hardware errors, and it does seems to be quite resilient to those. In practice I fear the software bugs more. The bugs I actually see in Linux tend to be oopses generated by bad code that simply disable the driver. The bad ones screw up the hardware they are controlling and require a reboot. It is unclear in these situations that the driver can be correctly reset without resetting the hardware too. I wonder how much of this respawn/update functionality you can apply easily to a Linux kernel right now. Most drivers and filesystems can already be built as modules and loaded/unloaded in a live kernel. I wonder how much that can be extended.
- arohner 16y ago
  Exactly. Linux is also useful enough to run the laptop Tannenbaum's presentation is running on while no version of Minix is. (He's running windows, but it could have been Linux) Minix drivers would still have to exist, and to be usable, they still need access to hardware. There's no presented reason why Minix drivers should have fewer bugs / LoC than linux, except that individual drivers can't take down other "kernel" processes. That might get you minor improvements in reliability, but it won't fix this issue of bugs existing in hardware drivers in the first place. IMO, the way forward in reliability is a kernel written in a more correct, more expressive (haskell-ish) Programming Language.
  - rbanffy 16y ago
    > There's no presented reason why Minix drivers should have fewer bugs / LoC than linux On a monolithic kernel, each and every driver is aware (or at least can be) of each and every other driver linked into the kernel. It may create added complexities that should be absent and abstracted in microkernel-based OSs. Microkernels are not a silver bullet and buggy drivers will be able to put the system - buses, coprocessors, whatever - in weird states that can hang or crash the machine. I like the idea of parameter validation on every function. That and extensive unit tests built into the kernel. Tests could be invoked on boot with a specific switch and the kernel would perform a self-test (with crash detection) before bringing up your system. This could help find hardware incompatibilities and other weird defects that could affect reliability of the whole box. I don't think we would need a Haskell-like language. You can do very Haskell-ish things in C. All it takes is lots of discipline (just as much as writing Haskell) Maybe forcing kernel developers to learn Haskell would help ;-)
phaedrus 16y ago
The self-healing thing in Minix 3 really works. Some years ago I installed Minix 3 on a very old Thinkpad that had an esoteric video hardware quirk that would crash most OS's. It was "designed for Windows 95" and by God they meant it because you couldn't run anything else on it. Neither Linux nor Windows 98 would run for very long before the hardware would cause a driver crash and a kernel panic/bluescreen (even in text mode). But with Minix 3 the video driver would just transparently restart after each crash, so smoothly that I wouldn't notice it unless I was watching the logs.
- axman6 16y ago
  That's awesome, and I'm sure its the sort of story the developers would love to hear about.

51 points by axman6 16y ago

Absolutely fascinating lecture. Very much worth watching.

After watching the lecture, just download Minix, setup it up in VMWare/Virtualbox/Bochs and hack something in it. Really, do it. It's amazingly cool OS and fun to play with.

switch007 16y ago

His book, "Modern Operating Systems", is a fascinating read for any geek. He discusses MINIX a fair bit (unsurprisingly!)

michael_dorfman 16y ago
Or, just get his "Operating Systems: Design and Implementation", which is a great read, and contains the full MINIX3 source code (printed and on CD).
- rbanffy 16y ago
  Wow... I remember having read that in 88 or 89... It's a bit sad MINIX 1 would still be considered pretty modern.

yan 16y ago

MINIX is a fantastic kernel to practice kernel hacking on and see how operating systems function without the real world cruft of performance and portability hacks.

ori_b 16y ago
Personally, I found the code relatively painful to follow through. I'm not even talking about how the parts communicated - the code was difficult for me to trace through in the small. Even when compared to Linux or the BSDs, let alone Plan 9. K&R prototypes, overly decorative comments that just echo the name of the function, defining macros like 'PUBLIC' and FUNCTION_PROTOTYPE(name, args) which are effectively no-ops, and a host of other little annoyances that make the code - at least in my opinion - rather unidiomatic and painful to read C.

subwindow 16y ago

Not knowing much about OS design, is there any inherent reason why operating systems built on microkernels seem to be so unsuccessful? They always seem really elegant, but are never widely adopted (with the possible exception of Mach -> OS X).

wmf 16y ago
I think the main reason is poor marketing. Teams built microkernels, but of course a microkernel is not useful on its own so they had to build a complete OS. But being already tired (or near graduation) from building the kernel itself, they simply ported Unix to run on top of their microkernels, which led to a slower OS with no new features. There are benefits to microkernels, but all these benefits were hidden or wasted by Unix. By this time, patience (and thus funding) for microkernels had run out and researchers had to find something else to work on.
ori_b 16y ago
the OSX version of Mach has subsumed so much back into the kernel that it can barely be considered a microkernel any more. The thing is that for most systems, microkernels are a performance liability, (it's possible to make them perform well, but it's very hard to do while keeping memory protection) and with lots of hardware they tend not to be a big safety win - if you can wedge the hardware through bad commands, it doesn't matter if the commands originated in userspace or kernelspace.
- dflock 16y ago
  This happened to the Windows NT microkernel too - they just kept shoving more and more stuff back into kernelspace for performance reasons, starting with Graphics drivers in NT4, and going from there. I think they may have yo-yo'd on Graphics Drivers later for stability reasons, but I've taken my eye off Windows since I stopped using it.
Avshalom 16y ago
Unsuccessful on the desktop, qnx for instance is a microkernel and is quite successful. On the desktop there's a lot of inertia, you need apps (which is a chicken and egg thing). As wmf said, you see a lot of poor unix on top of the kernel so there isn't even a compelling reason to use it.

CitizenKane 16y ago

I find it fascinating that the actor model seems to be the model for creating reliable software. You can see it in Scala or Erlang at the user level, get it in MINIX3 at the kernel level. I think if you combined the two you could potentially create systems which stay up for years.

rbanffy 16y ago
I have met a couple of QNX-based, also microkernel-based, systems that had uptime measured in years. Lovely OS. I learned C on it. MINIX reminds me of GNU/HURD. Since they are all Unix-ish from the application's point-of-view, I have hope they someday can more or less compete on equal footing with more traditional monolithic (it would be fair to call OSX "duolithic") OSs like Linux, BSD, Solaris. Very usable desktops like the Gnome I am using to write this don't care much about what is under the libraries they link against. They would be fine on top of any OS as long as libraries provided the environment they expect. Oddly enough, the first time I ran Gnome was on top of IRIX.

vital101 16y ago

In my undergraduate operating systems class we hacked away at an early version of Minix. The level of detailed code documentation always just blew me away.

pedrocr 16y ago

This 6k vs 6M LoC comparison is pretty dubious. If your disk driver has a bug and overwrites some data you're just as screwed up, be it running in userspace or kernel space. The argument these bugs are less powerful because they are now in userspace "can't do very much" is at best limited. Drivers can screw up hardware just as easily, filesystems can screw up your data just as easily, etc. The memory grant stuff seems interesting though and I see how that can protect you from some forms of memory corruption. Running all these processes in userspace seems to gain you some capabilities to more easily respawn/reset drivers. Live upgrade seems exciting. I wonder if you are paying for that in added complexity that is hard to debug. The tests they did are simulating basically hardware errors, and it does seems to be quite resilient to those. In practice I fear the software bugs more. The bugs I actually see in Linux tend to be oopses generated by bad code that simply disable the driver. The bad ones screw up the hardware they are controlling and require a reboot. It is unclear in these situations that the driver can be correctly reset without resetting the hardware too. I wonder how much of this respawn/update functionality you can apply easily to a Linux kernel right now. Most drivers and filesystems can already be built as modules and loaded/unloaded in a live kernel. I wonder how much that can be extended.

arohner 16y ago
Exactly. Linux is also useful enough to run the laptop Tannenbaum's presentation is running on while no version of Minix is. (He's running windows, but it could have been Linux) Minix drivers would still have to exist, and to be usable, they still need access to hardware. There's no presented reason why Minix drivers should have fewer bugs / LoC than linux, except that individual drivers can't take down other "kernel" processes. That might get you minor improvements in reliability, but it won't fix this issue of bugs existing in hardware drivers in the first place. IMO, the way forward in reliability is a kernel written in a more correct, more expressive (haskell-ish) Programming Language.
- rbanffy 16y ago
  > There's no presented reason why Minix drivers should have fewer bugs / LoC than linux On a monolithic kernel, each and every driver is aware (or at least can be) of each and every other driver linked into the kernel. It may create added complexities that should be absent and abstracted in microkernel-based OSs. Microkernels are not a silver bullet and buggy drivers will be able to put the system - buses, coprocessors, whatever - in weird states that can hang or crash the machine. I like the idea of parameter validation on every function. That and extensive unit tests built into the kernel. Tests could be invoked on boot with a specific switch and the kernel would perform a self-test (with crash detection) before bringing up your system. This could help find hardware incompatibilities and other weird defects that could affect reliability of the whole box. I don't think we would need a Haskell-like language. You can do very Haskell-ish things in C. All it takes is lots of discipline (just as much as writing Haskell) Maybe forcing kernel developers to learn Haskell would help ;-)

phaedrus 16y ago

The self-healing thing in Minix 3 really works. Some years ago I installed Minix 3 on a very old Thinkpad that had an esoteric video hardware quirk that would crash most OS's. It was "designed for Windows 95" and by God they meant it because you couldn't run anything else on it. Neither Linux nor Windows 98 would run for very long before the hardware would cause a driver crash and a kernel panic/bluescreen (even in text mode). But with Minix 3 the video driver would just transparently restart after each crash, so smoothly that I wouldn't notice it unless I was watching the logs.

axman6 16y ago
That's awesome, and I'm sure its the sort of story the developers would love to hear about.