Ask HN: Is Minix dead? No commits since 2018
git.minix3.org
git.minix3.org
https://groups.google.com/g/minix3/c/nUG1NwxXXkg
Short story as I watched it: Tanenbaum got a couple grants totalling several million Euro. He hired some of his grad students to work on making it a production system. They made a lot of improvements, research-wise, but they also sort of made a mess of things. What they didn't do is set up any reasonable project infrastructure (e.g., a bug tracker) that would allow Minix as a project to grow into a healthy, thriving project at a size beyond those who were being paid to work on it, and for it to outlive their interest in it. The userspace was largely replaced by NetBSD's, and that involved clang replacing ack, so builds went from ~10 minutes to 3+ hours. Lots of small stuff like this, adding up to a project where no one is willing to exercise ownership and few outsiders are equipped to deal with it in its current state (even if interested).
The best thing that you could do if you want Minix to be a thing is to prepare yourself for a deep dive and not look to "the community" with the belief that there is some consensus/approval to be had. Take charge in a fork of your own and make it the project you want it to be. If you wait for anyone else to take ownership, you're going to be waiting for a long time. If Minix is "dead", it's because poor ownership + the bystander effect killed it.
Shades of excuses #1, #2, and #3 from jwz's "nomo zilla" are pretty appropriate here as well.
The reason why it was done is because the MINIX3 project felt that they didn't have the manpower to maintain a compiler toolchain, base userland and packages on top of the actual operating system. Which, in retrospect, was spot on. Having a modern toolchain also enabled work such as live updates of almost every driver and service without interruption of services, by instrumenting LLVM to generate all required information, as well as the ARM port.
This also brought vastly increased compatibility when compared to other Unix-likes, enabling a fair amount of pkgsrc packages to build and run without patches. Reinventing the wheel from scratch as with SerenityOS is fun, but not very helpful if you want to run other people's software, especially if all you have is a C89 compiler (ACK).
There is a bug tracker in the form of GitHub issues that came as part of the migration to GitHub and a Gerrit server, which also happened before I got involved.
Now, I'm not Andy Tanenbaum nor one of the MINIX3 gurus and I certainly don't have the full picture myself, but merely saying the project slumbered because of poor ownership isn't actually helpful to learn lessons from it. Software project management is anything but easy, especially if you lack paid contributors.
I doubt that clang would be reason not to volunteer for MINIX3. That said, I personally don't like what MINIX3 has become.
In the end, if you want to have a small, volunteer-based software project, you need somebody with a vision and who is also able to contribute quite a lot of time to the project (and possibily also quite a bit of resources).
The MINIX3 didn't have such a person in the community so the transition from paid developers to a community supported project failed.
As for the MINIX2 fork I assume it's Minix-vmd. MINIX didn't switch to ELF before the 3.2.0 release, so you either need a toolchain that can output the traditional a.out file format or add ELF support to MINIX2. Not impossible, but probably more work than maintaining a MINIX2 fork for private pleasure warrants.
I think adding minimal ELF support would not be a lot of work.
Do you have pointers to online resources on Minix-vmd and a public source tree repository somewhere? minix-vmd.org seems down... No guarantees, but I do seem to be the type that does random drive-by contributions to open-source software.
That said, the sources on minix-vmd.org are quite old.
It seems that last time I put something online is also already awhile ago: http://stereo.hq.phicoh.net/Minix-vmd/images/
Are those real numbers? Yikes. I mean, I don't disbelieve it, it's just a reminder about how far we've fallen. Modern compilers are indeed amazing tools, but those last 8-10% of features (performance, safety, etc...) have come at an absolutely staggering price.
And clang isn't really that big an offender, being only a tiny bit slower than GCC. C++ and Rust are a solid order of magnitude slower still.
Plan 9 is similar: a full system rebuild takes about 45 seconds on my hardware. A clang (and just a clang build) build on similar hardware takes about 2 hours.
I just don't get how the gulf can be this wide on something so many devs are clearly frustrated about.
Modern optimizing compilers are solving lots of hoary computational graph problems, etc., behind the scenes.
This had NOTHING to do with
> those last 8-10% of features (performance, safety, etc...) have come at an absolutely staggering price
SAS C had better generated code and more features.
It was purely a question of architecture - SAS C was architected for speed, and actively used caches (especially precompiled header files) to avoid re-doing work. GCC didn't, and I've seen no hint of that appearing in GCC since.
Yeah, software development is a difficult profession, not a thing a grad student in CS can manage. But code written in academia is for the most part garbage in general.
I'm a big fan of microkernels, I think Tanenbaum had it right in his spat with Linus but at the same time Minix' implementation is very far from what could have been a fantastic little OS.
Posix compliance on the one side and running a true microkernel on the other is a hard problem, and after all the real goal of Minix was not to 'be the best microkernel' but to simply provide an OS for study purposes to students at VU and other universities.
If you want to see what an ideal microkernel looks like take a look at the QnX architecture, that's much closer.
>If you want to see what an ideal microkernel looks like take a look at the QnX architecture, that's much closer.
Have you looked at Genode + seL4?
Can you give some examples?
By the way, my Minix knowledge is somewhat dated, I always thought that it had huge potential if the 'holy houses that Andrew built' would have been allowed to be pushed over, even if that would come at the price of POSIX compatibility, which as far as I'm concerned is overrated if it is the thing that holds us back from having an ultra reliable field upgradeable operating system. The big problem with POSIX is 'fork', it more or less assumes that you're looking at UNIX and fork was a kludge all along that just happened to solve a couple of nasty little problems that have to do with file descriptors. It's one of those 'leaky abstractions' that end up haunting you forever if you do not address them immediately and decisively. But because POSIX compliance is what got Minix established in the first place it became very hard to let go of that. Plan 9 suffers from the same issue by the way.
https://en.wikipedia.org/wiki/Fork_(system_call)
I'm all for reliability over performance, unfortunately the rest of the world seems to disagree with me.
Interesting read, thanks for sharing.
jwz.org/gruntle/nomo.html
edit: JWZ doesn't like HN, copy and paste the link
I'd wager Minix suffered from its original license (not really open source or "free" software) and Tanenbaum not being an egomaniac like Torvalds (for better or worse).
While others have noted that grant money has run out, for me MINIX3 is only as good as its weakest link: its microkernel has a really dated design. Imagine taking 1980s Unix and gutting it until you have a microkernel: it has a fork() primitive oddly enough, it's not SMP-safe, it's 32 bit only, processes only have one thread... It's the one area of the OS that hasn't changed that much since 1987.
So while there has been some very good research done on it (https://wiki.minix3.org/doku.php?id=publications, especially of note reliability in face of drivers and services misbehaving or crashing as well as live update of almost all drivers and services without interruption of service), it cannot take advantage of modern 64 bit, multi-core processors.
Furthermore, the second weakest link is driver support. Running on bare metal is possible but vintage hardware is best suited for it because of the limited hardware support. Especially problematic is the lack of USB support on x86. NetBSD's rumpkernel would have been a potential in-tree solution to fix this, but sadly it has never been done.
Anyways, these days the Zircon microkernel seems extremely promising. The design seems well thought-out, the object/handle/IPC mechanisms are especially interesting because it's rather unlike everything else done at this point that I'm aware of and processes can only interact with the rest of the system through handles, so it's trivial to sandbox things.
As for me on OS development, right now I'm having fun hacking on SerenityOS. It's a sin for a micro-kernel guy like me, but who's to say I can't have a little bit of fun on the side?
My understanding was that Tanenbaum made it as a teaching tool and always resisted attempts to modernize it too much, lest it becomes too complicated for students to understand. The lack of SMP support may well be one of those things.
That is not to say that MINIX ever was just a toy OS, it was self-hosted from the first publicly released version if I'm not mistaken. But it takes much, much more than that to be a daily use OS nowadays.
What's your opinion on Genode (on seL4)?
(redox-os seems to be heading the way of the dodo as well...)
Regarding seL4, I haven't played with it but I did read their whitepaper. I believe they are setting the gold standard for microkernels in reliability and correctness. Not many systems can claim to have a formally-verified trusted computing base of not only their source code, but the binary artefacts too. This is the closest kernel project I know of that can potentially mitigate against attacks as described in the paper "Reflections on Trusting Trust" by Ken Thomson.
That is not to say that their approach is fool-proof. Like any proof, they make assumptions, which in this case is that the base hardware (CPU, MMU, memory...) does and only does what their specification claims, which the long list of erratas in Intel CPUs as well as Spectre, Meltdown, rowhammer, the Intel Management Engine debacle and others showed that they definitely don't. Not that other hardware vendors are immune too, by the way.
Their formally-verified proof is also limited to the microkernel. So while they claim to guarantee that userland processes can't compromise the microkernel nor compromise other userland processes through the microkernel (which does have its uses in embedded systems requiring high reliability), it has no bearing on what the userland does. Heartbleed wouldn't have been stopped by seL4 for example, not to mention social engineering, evil maid attacks, DMA attacks, attacks on packaging system (I lost count of the number of NPM modules that were compromised over the years), not to mention plain user stupidity.
In a way, "Reflections on Trusting Trust" by Ken Thomson has never been more relevant than today. On a typical Linux desktop operating system, we effectively blindly assume that hundreds of millions of lines of code, taken from tens of thousands of code repositories from the Internet, written in mostly unsafe languages (or languages whose interpreters/VMs are written in unsafe languages), running on a monolithic kernel with tens of millions of code written in C, running on hardware that is effectively a big black box, does what they're supposed to do and nothing more.
Even if you do audit stuff, a human can't possibly audit everything from the LLVM compiler to your web browser, not to mention we are effectively emotionally-driven, tribal-minded, chemically-influenced, prejudiced, illogical and error-prone ape brains and anyone pretending to be a perfect Vulcan is either delusional or lying.
Not to mention, I just read their whitepaper and thought to myself "yeah, sounds good". I haven't actually audited seL4, their methodology and their proof, so... As the meme says: everything is fine?
In practice, mathematicians also assume "that problems we don't deal with directly are taken care of by somebody else in good faith". We use theorems that others proved, and we trust that the authors and the reviewers did their job, without inspecting the proofs ourselves. Sometimes mistakes slip through, but they are usually caught fairly quickly, and can be fixed locally. In other words, we are less strict than we like to think we are, but we get away with it perfectly well.
The wonders of copyleft...
I knew I specifically wanted to dig into minix as a pastime. In my mind, the text book(s), and a fully featured Unix with a small code base were a unique combination...
That is, until I sat down to actually buy the book. The $200 price tag was beyond sticker shock. It was literally offensive.
I didn’t take long to find Operating Systems: Three Easy Pieces (OSTEP)[1]. The book can be had for Legally FREE or Affordable. And the introduction contained (among everything else) a brief manifesto admonishing the crazy high prices of college text books.
The book is funny, technically excellent, and also features a tiny-sized Unix like operating system: xv6.
Pouring my hours into this book and learning the XV6 operating system was time well spent.
[1]: https://pages.cs.wisc.edu/~remzi/OSTEP/?source=techstories.o...
Does anyone have any OS course / book recommendations?
I've worked my way through the excellent MIT course on xv6 [0], but I'm not sure what to work on next. Something related to Linux or one of the BSDs would be nice to see how things are done in the real world.
I cannot recommend this MIT course enough for those getting started. The projects are set up in a very nice way (i.e. if you can't complete one tricky assignment, you don't need it as a prereq for later ones) and the code is very simple. They've also gone to great lengths to set it up in a simple way (e.g. using cross-compilation for RISCV on qemu). It's also a great experience to really understand OS, as you'll make mistakes that will leave you scratching your head until you realize you messed up your page table and yeeted your kernel stack out of your address space.
Here are some other nice OS textbooks from a Unix standpoint that I've used over the years whenever I need to study some aspect of Unix in depth:
- The Design of the UNIX Operating System by Maurice Bach (1986)
- The Design and Implementation of the FreeBSD Operating System, 2nd Edition by McKusick, Neville-Neil, and Watson (2014)
- UNIX Internals: The New Frontiers by Uresh Vahalia (1996) (note that this book covers the implementations of Unix variants that were contemporary in 1996)
Do these books (or perhaps courses around them) contain a graduated set of exercises for understanding?
That's the thing that was so great about the MIT course, but it's been difficult to find that elsewhere.
A similar course with a great pedagogical progression was CS631 at Stevens [0], which went over Advanced Programming in the Unix Environment with a bunch of videos and exercises.
Personally I'm having fun hacking on SerenityOS. So far I've done a NE2000 network card driver, net booting, fixes to boot on an old Athlon XP computer, fixes to the ext2 filesystem, printing lines numbers in the JavaScript interpreter backtraces, some keyboard accessibility stuff (https://github.com/SerenityOS/serenity/commits?author=boricj)... Basically any random thing that I find fun to work on.
I must put in the review one day. (-:
But there's still no minimal decent desktop (e.g.: lxqt)
Intel is not required to share the source code (and they don't).
If MINIX as a publicly developed project does die then it's a data point for copyleft licensing being more robust.
And it's exposed on the network because its used in Intel Management Engine.
Meanwhile the Linux kernel is going strong with many companies helping maintain it.
Seems like a shortsighted decision on Intel's part.
Linux only drops support when nobody uses the architecture anymore. And if Intel is using it for ME then there's a big case to be made for keeping it.
Sounded interesting, and somehow I found a copy of Minix for my 386 that I cobbled together from parts. Not sure where I got it, but probably downloaded from a BBS. A year or two later after getting a job, I'd discover Sun, SGI, and Linux. My experience with Minix helped me get around at the shell.
Used it for an undergrad operating systems course. Never used it again.
https://www.networkworld.com/article/3236064/minix-the-most-...
But if it's written in C..
Secondly, non-C/C++ use in OSs is uncommon, and thus considered research.
Thirdly, the microkernel with the strongest formal proof of correctness, seL4, is written in C.
Looks very promising, but they are still on Beta. [1]https://www.haiku-os.org/
Haiku is a conventional monolithic design, like BeOS, in fact arguably more so than shipped releases of BeOS because BeOS had a separate TCP/IP stack which made its network performance abysmal, Be Inc. had been working to fix that by just plonking the entire stack inside the kernel, and Haiku copies this approach. Like BeOS, Haiku is written in some specific dialect of C++.
So the main similarity is that Haiku also hasn't shipped a version 1. Although that's maybe more striking after 20 years of development than Redox's 5-6 years.
For futureproofing it, perhaps make a Docker container of it
You can't (directly) put an OS in a Docker container. Docker is an application container technology, not an OS virtualisation technology. Apps inside Docker run in user mode under the Linux (or less commonly, Windows) kernel.
What you can do, is put an emulator in Docker, and put the OS in the emulator image. However, if your OS runs on a common platform (e.g x86 or x86-64), there is probably not much value to creating a Docker container vs just serving up the VM (such as a disk image or OVA file) for use with QEMU or VirtualBox or whatever.
If you are dealing with a more obscure platform, it can make more sense to package the image and emulator together into a Docker container. For example, I put the 1970s vintage IBM mainframe operating system MVS 3.8J [0] in a Docker container. I think that makes more sense because it requires a less common emulator (Hercules as opposed to QEMU or whatever), and Hercules needs to be configured with a specific configuration to make it work.
It's not hard. I got a copy of DEC VAX/VMS running inside SimH a decade ago, in one evening's work.
I think "machine preservation via emulation" may need to be a thing. Supposedly there's thousands of science papers, for example, whose supporting code may no longer trivially run...
Interestingly, Linux might be right behind it, at second place, dominating servers, cars, and all sorts of industrial devices.
But funnily enough in the end, when it comes to laptop and desktop computers, the Windows NT kernel, and the macOS Darwin kernel are still the reigning champions. It’s funny, because I think in the 90s, every OS designer was trying to take the place of MS-DOS/Windows/Mac. The two flamewar[*] buddies won out in the end, but likely not in the market segments they had initially expected to win.
Minix is full OS.
Intel's number wouldn't even be half of that.
Applications make use of Java and Kotlin frameworks, ISO C and C++ standard libraries and a couple of Android specific native APIs.
Android can be running on top of Zircon or any BSD tomorrow, besides OEMs and device rooters, no one else would notice.
Doesn't matter how one tries to sell it, it isn't GNU/Linux and doesn't count as such.
Probably, ,my teleco's router runs Linux, too.
And I say this as a desktop OpenBSD user.