by Andrew S. Tanenbaum ◦Vrije Universiteit (VU, Free University) in 1987 ◦designed to help teach class about Operating Systems •Current major version (3) shares no code with previous versions "MINIX 1 and MINIX 3 are related in the same way as Windows 3.1 and Windows XP are: same first name" -- Andrew S. Tanenbaum
conveyed in Tanenbaum's textbook, Operating Systems: Design and Implementation ◦syscall-compatible with 7th edition UNIX •MINIX 1.5 ◦released in 1991 ◦supported many more platforms ▪Motorola 68000 and SPARC architectures ▪supported Atari ST, Commodore Amiga, Apple Macintosh, Sun SPARCstation ▪unofficial ports to Intel 386, National Semiconductor NS32532, ARM
architectures except for x86 and SPARC ◦used as example for second edition of textbook ◦POSIX.1 compliant ◦TCP/IP stack replaced "Amoeba" network protocols
free and open source software ▪previous versions had a restrictive license that required a fee, included in the textbook price ◦first release available as a "live" image ◦only supports x86 ◦focused heavily on reliability ◦added X11 support
◦participated in GSoC every year since 2006 •pkgin package manager ◦manages pkgsrc binary packages •POSIX compliant •~650 UNIX programs ported to MINIX •Extremely high reliability •Microkernel architecture
a very nonrestrictive license •OLPCs and other netbooks •web/file/DNS/anything server •Embedded systems: cell phones, consumer electronics •Teaching operating systems concepts
usage ◦only supports a single architecture: x86 ▪ports to ARM and PPC are in progress ◦hardware requirements ▪i386 or greater Pentium processor ▪16MB of RAM ▪50MB of persistent storage (unless using live image) •very barebones: need to fetch "standard" packages (bash, gcc, make, ...) manually •porting software from other UNIX-like OSes is non-trivial ◦no cross-compiler support in gcc ◦software must be compiled in MINIX ◦as a consequence, not very many programs exist
microkernel •Entire kernel contains ~6000 lines of C code •Derives most of its reliability from removing device drivers from the kernel •Device drivers run as user-mode processes ◦use virtual memory ◦well isolated ◦can't bring down the OS ▪even bad pointer dereferences
drivers ◦automatically replaces drivers upon crash ◦often transparent to the user •Priority governed by the scheduler ◦drivers stuck in an infinite loop will have priority gradually lowered ◦priority is lowered to the point of complete unresponsiveness ◦now unresponsive, driver will be killed and replaced by the reincarnation server
to notifications ◦notifications are sent to the appropriate driver ◦if the program has registered as listening for the notification, it will be immediately interrupted ◦otherwise, the notification gets added to a message queue which the driver may check at its leisure