5 ms·

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 fixe

by snvzz 4y ago

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.

roywashere 4y ago
I noticed the same. During lockdown I felt bored and thought about porting my fav software to minix only to find out that minix is really dead nowadays
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 ago
  So, what's your suggestion for... umm... practical/real world OS dev class? xv6 code is really compact, but toyish?
  - mhh__ 4y ago
    Linux? (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 ago
      Err... 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 ago
        I 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 ago
        No 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.
guestbest 4y ago
I think TempleOS is a better unmaintained operating system.
- skissane 4y ago
  The original is forever frozen in time as a memorial to Terry’s genius, but there is an (at least somewhat) actively maintained fork, which has added features of which Terry himself would not have approved - https://github.com/Zeal-Operating-System/ZealOS https://github.com/Zeal-Operating-System/ZealOS is the main one, which was last updated only a couple of months ago; by contrast, Minix’s last commit appears to have been in 2018 - https://github.com/Stichting-MINIX-Research-Foundation/minix https://github.com/Stichting-MINIX-Research-Foundation/minix But maybe that’s the answer for MINIX too - maybe one of the people who have authored all those unreviewed PRs might start a community-based fork. If all the activity moves to the fork, there is a chance the originators might officially bless it
  - fijiaarone 4y ago
    I think some things were added to Jesus’s OS that He wouldn’t have approved of.
cvalka 4y ago
The one thing MINIX needs is to disappear.
- mardifoufs 4y ago
  I dont know a lot about MINIX but why is that the case?

by snvzz 4y ago

roywashere 4y ago

I noticed the same. During lockdown I felt bored and thought about porting my fav software to minix only to find out that minix is really dead nowadays

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 ago
So, what's your suggestion for... umm... practical/real world OS dev class? xv6 code is really compact, but toyish?
- mhh__ 4y ago
  Linux? (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 ago
    Err... 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 ago
      I 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 ago
        No 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.

guestbest 4y ago

I think TempleOS is a better unmaintained operating system.

skissane 4y ago
The original is forever frozen in time as a memorial to Terry’s genius, but there is an (at least somewhat) actively maintained fork, which has added features of which Terry himself would not have approved - https://github.com/Zeal-Operating-System/ZealOS https://github.com/Zeal-Operating-System/ZealOS is the main one, which was last updated only a couple of months ago; by contrast, Minix’s last commit appears to have been in 2018 - https://github.com/Stichting-MINIX-Research-Foundation/minix https://github.com/Stichting-MINIX-Research-Foundation/minix But maybe that’s the answer for MINIX too - maybe one of the people who have authored all those unreviewed PRs might start a community-based fork. If all the activity moves to the fork, there is a chance the originators might officially bless it
- fijiaarone 4y ago
  I think some things were added to Jesus’s OS that He wouldn’t have approved of.

cvalka 4y ago

The one thing MINIX needs is to disappear.

mardifoufs 4y ago
I dont know a lot about MINIX but why is that the case?