I took a serious look at MINIX over the winter, and digested several of Tanenbaum's talks around that time. (For anyone wondering if this talk contains anything substantially different from past ones, the answer is no.)

Here are some things to add:

- Nowadays x86 is built with LLVM by default, and ARM is using GCC.

- X11 is mentioned in the video, but the 3.3.0 release from last fall didn't ship with a working X server, although past releases have. There is a message on the mailing list from someone who writes that they've got it working on a subsequent snapshot release.

- You may have heard something in the past about 10 minute build times. That info is out of date as of the switch to NetBSD userspace for 3.3.0. MINIX itself (i.e., all the interesting parts) still only takes about 10-15 minutes to build, but there's no way to just slurp down the sources for its kernel/drivers/servers to build a MINIX "core" and then supplement it with the prebuilt binaries for userspace (at least, not without doing some significant work on your end to allow for that). The initial build for x86 on my modest machine takes about 3 hours, almost all of it spent building LLVM twice.

- For anyone looking for serious collaborators, MINIX is seriously lacking in infrastructure from a project/community standpoint. E.g., a fair bit of documentation is missing and much of what you will find on the wiki is out of date. Development processes are neither documented nor easily discoverable because there are effectively no development processes in place. Until about six months or so ago, MINIX was without a bugtracker. Organizationally/project-wise, the whole thing is pretty sparse.

- If you have watched previous talks on MINIX, e.g. FOSDEM 2010, you will be familiar with the open calls for those interested in working for pay, using the money from the two grants mentioned in this video. That money is now gone. During that time, MINIX was basically a research project run by grad students who were working ~full time on MINIX, with the funding from those grants. It's the same now as far as the student-run aspect goes, but with drastically fewer contributions. Not much of the paid man hours seem to have gone towards scaffolding out project infrastructure as I mentioned before, or the sorts of drudge work that volunteers are unlikely to take up.

- The code quality is... I dunno, fair? As I mentioned before, there are/were effectively no development processes in place; no code review, etc. So there's a fair bit of nastiness that got checked in directly, like copy and paste, especially among the arch-specific boot time stuff; the comments are fairly sparse; and you can find dead code and references to routines/fields that either no longer exist or have been renamed, even in the relatively short (~500 line) main.c.

For anyone looking in to maybe starting to work with MINIX, I'd suggest assessing whether or not you would be comfortable striking out and doing things on your own, and then being prepared to do so. With MINIX, you aren't going to find a thriving community that you can just add your piece to, so as to contribute to the effort. You might run into a certain level of that sort of old-guard, paralyzing stop energy, so in a way it's got a lot of the downsides of a greenfield project except with few, if any, of the upsides.

Thanks for this post. That is very interesting. It seems like a shame, because a project like this is a long road. If they haven't built a place where work can continue it will likely fade away.

I would love to see a sustainable, non-vapourware, micro-kernel. I've _heard_ such great things about them :)