5 ms·
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.
by boricj 4y ago
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 https://www.youtube.com/watch?v=MG29rUtvNXg (there are multiple versions of it done over the years)
Source: I'm a former contributor.
- anta40 4y agoSo, what's your suggestion for... umm... practical/real world OS dev class? xv6 code is really compact, but toyish?
- mhh__ 4y agoLinux? (Obviously depends on what you want to teach but in terms of practicality it may be daunting to comprehend the whole kernel – of course it is – but equally the ground is very well trodden)
- anta40 4y agoErr... well I get it. What I mean is something less complex than Linux, and still usable enough for real world tasks? I can understand the xv6 codebase in a few days (obviously couldn't say the same thing about Linux), and it's very easy to rebuild, but for me it only stays inside QEMU. Or perhaps take a more realistic approach: production-grade kernel is complex, thus you are not be expected to understand the whole thing in short time?
- hakfoo 4y agoI suppose that reveals something: cheap virtualization completely changes the OS development experience. Even beyond teaching toys, there are huge projects now (SerenityOS for example) where "runs on bare metal" is barely, or not a consideration. I wonder if this causes stagnation in the niche of device driver development-- if all you have to worry about is a handful of "friendly" VM devices, who is learning to deal with the hassles of persnickety real hardware?
- throwawaylinux 4y agoNo it doesn't because the cutting edge of device driver development is on high performance devices in the hypervisor or IO server layer, passthrough and virtualized functions, etc. So it's all the same challenges as before with additional complexity that you also have to virtualize them either by passing function to the guest or by introducing a virtual server layer above them that has to perform well. I don't know if I've ever seen much innovative device driver development work going on in toy or learning operating systems before virtio type interfaces. Before that most of them used a couple of the simplest hardware available anyway. There has long been (and still is) a bunch of different emulated hardware that something like qemu offers (and not too hard to add your own emulated hardware) that you can trivially add to your VM if you want to develop device drivers. A number of real hardware companies nowadays actually contribute their hardware models to qemu and even develop to them internally for pre-release development and CI and regression testing. So I would argue running in VMs with capable device model support like QEMU has actually made learning and developing hardware device drivers more accessible rather than less.