The one thing MINIX really needs is a maintainer.

The 3.3.0-rc8 or whatever version has been sitting there for several years, despite all blockers already fixed. Just because there's nobody at the helm to push the release out.

There's also significant unmerged work that's just waiting for someone to merge it.

It's not just the lack of active maintainers. MINIX 3 is a technological dead-end on multiple fronts and the various grants and funding sources have dried up.

The micro-kernel is mostly unchanged from its previous incarnations. It can be described as an hollowed-out Unix-like kernel design from the 80's, to the point where a fair number of its syscalls are direct equivalent to Unix ones. Basic features taken for granted nowadays, like 64-bit support, SMP or kernel threads are missing. Its code is especially old and difficult to work with.

The driver layer works best with a computer from 20 years ago. There's no support for USB (on x86), NVMe, display controllers, UEFI and so on. I don't think that booting on modern hardware would be even possible at this point without some major overhaul.

The service layer is similarly outdated. The most modern filesystem supported is ext2 and it wasn't very stable from what I remember. The native MINIX 3 file-system implementation is solid, but its design is very similar to the System V file system from the early 80's. The most advanced isolation mechanism available is chroot and there's no support for running multiple, isolated userspace instances, which is a shame for a micro-kernel, service-based operating system.

Replacing the outdated MINIX userland with a source port of NetBSD's userland a decade ago was a colossal mistake in hindsight. The NetBSD source tree required a lot of modifications to make this work and back-porting newer versions of NetBSD's source tree is extremely difficult. Instead, a NetBSD syscall translation layer to achieve binary compatibility would've probably been a far more maintainable solution. Additionally, pkgsrc support wouldn't be a problem either.

Finally, I'm pretty sure no one used it as a daily driver back in the 2010's. While it was reasonably functional through SSH inside a VM, trying to use it on real hardware was an exercise in frustration because of all the sharp edges.

Don't get me wrong, MINIX 3 has extremely cool features like the ability to transparently updating system services on-the-fly or extreme resiliency against device driver crashes. The presentation talks done by Andrew Tanenbaum [1] are in my opinion still extremely good to this day and a fair number of the research papers on the MINIX 3 are worth the read. I'm not trying to discourage anyone from trying it out or stepping up as a maintainer, but there's a reason why it became unmaintained.

[1] https://www.youtube.com/watch?v=MG29rUtvNXg (there are multiple versions of it done over the years)

Source: I'm a former contributor.

So, what's your suggestion for... umm... practical/real world OS dev class? xv6 code is really compact, but toyish?

The key problem is:

> practical/real world

Definitions of that vary wildly.

Oberon is a personal favourite of mine: tiny, a few hundred KLOC for the entire OS, compiler IDE, UI, in a native-code-compiled, type-safe language.

Ah, another Niklaus Wirth's work. Any guide on how to build and run it?

Book and code are available from Wirth's site: https://people.inf.ethz.ch/wirth/ProjectOberon/index.html

But the mirror is a little nicer looking (although older? It says, "The second (2013) edition of the book and source code are published on Prof. Wirth's website. We provide links to the original material here, and local zipped copies, with kind permission from the authors."): http://www.projectoberon.com/

Several emulators for the Oberon RISC CPU are available:

In C with SDL graphics: https://github.com/pdewacht/oberon-risc-emu

In JS and Java, from the live version above: http://schierlm.github.io/OberonEmulator/

In Go: https://github.com/fzipp/oberon

People have used Wirth's Verilog with FPGAs to make actual Oberon workstations.

(My own somewhat embarrassing Python emu: https://git.sr.ht/~sforman/PythonOberon )