State of Minix 3…

[Perry Metzger]

I note that traffic on the Minix 3 development list seems to have died out and that no commits seem to have happened in almost five years. Is it reasonable to believe that official development has ended and the codebase is now orphaned?

Perry

[Peter Shkenev]

On Wed Apr 12, 2023 at 4:41 AM MSK, Perry Metzger wrote:

Hello,

> I note that traffic on the Minix 3 development list seems to have died out
> and that no commits seem to have happened in almost five years.

Pull requests from various compassionate people ocasionally arrive at
Github mirror.

> Is it
> reasonable to believe that official development has ended and the codebase
> is now orphaned?

Unfortunately, developers are busy with their lives and cannot commit
themselves to MINIX, so development is effectively suspended. Even
though, you are encouraged to join MINIX IRC channel and try to stir up the
development.

As for 'orphaned' part, it depends on the meaning you are implying. If
you are talking about ownership, then nothing changed in this regard:
MINIX code owners are the same.

>
> Perry
>

---
Best regards,
Peter

[Thomas Cort]

With Andrew Tannenbaum leaving the VU and retiring, the main driving force behind minix development is no longer there. Without student projects and grants and research and summer of code, there isn't a lot of developer interest.

In recent years I've lost interest as I feel the future is 64-bit ARM and possibly RISC-V and that's a space where Minix doesn't have a presence. Adding a 64-bit architecture probably wouldn't be trivial. With the NetBSD userland, there isn't much to differentiate Minix from other POSIX operating systems other than the microkernel architecture. IMHO, NetBSD isn't a first choice for POSIX operating systems or even BSD based operating systems. With the Minix kernel and servers, it is less featureful than NetBSD with its monolithic kernel, so I have trouble seeing where Minix fits in now and in the future.

For what it's worth, I've got some admin privileges on github and Google Groups. I feel a bit like an outsider as most of the minix crew are former VU students and I've mostly lost touch with them, so I'm reluctant to just start merging stuff or make big decisions. Though I guess at this point any activity would be better than nothing.

Thomas C.

On Tue, Apr 11, 2023 at 9:41 PM Perry Metzger <pe...@piermont.com> wrote:

I note that traffic on the Minix 3 development list seems to have died out and that no commits seem to have happened in almost five years. Is it reasonable to believe that official development has ended and the codebase is now orphaned?

Perry

--
You received this message because you are subscribed to the Google Groups "minix-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to minix-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/minix-dev/8b7a71d3-5ccb-4432-88b8-f5c2f08954c7n%40googlegroups.com.

[Perry Metzger]

I think there’s no need to differentiate it on userland; the whole point of the project is the very different kernel architecture. Minix 3 is the only extant and functioning open source implementation of the POSIX API in a multiserver microkernel. It remains an architecture that has substantial security and reliability advantages over monolithic kernels, and as such it’s the only game in town if you want to experiment with that architecture. There is no need for a userland that is in any way distinct from NetBSD’s at this stage if one wants to play with microkernels.

I’ve been contemplating possibly forking the Github copy of the repository and doing some recreational renovation work. It doesn’t look like making the thing 64 bit clean would actually be that horrible. I was interested in figuring out if there was any point in working within the extant web site and repository; my guess is probably not given that it’s become a ghost ship and that the owners are AWOL and that no one wants to work on things that aren’t on Github these days.

If one wanted to start adding features in the form of additional device support etc., Pooka’s “Rump Kernel” approach should permit mass incorporation of drivers from Linux and NetBSD without any real work, but first there would need to be an actual operating project that accepted commits.

Perry

[Peter Shkenev]

Greetings, Thomas! Nice to meet MINIX developers here!

On Wed Apr 12, 2023 at 12:08 PM UTC, Thomas Cort wrote:
> With Andrew Tannenbaum leaving the VU and retiring, the main driving force
> behind minix development is no longer there. Without student projects and
> grants and research and summer of code, there isn't a lot of developer
> interest.
>
> In recent years I've lost interest as I feel the future is 64-bit ARM and
> possibly RISC-V and that's a space where Minix doesn't have a presence.
> Adding a 64-bit architecture probably wouldn't be trivial.

I agree with you. There is a lot of work to be done to bring Minix to
those architectures. At least there is a port of Minix to 32-bit ARM,
and I think this is better than nothing.

Some of work on x86/x86_64 direction still could be beneficial for
Aarch64, e.g. x86_64 enablement itself. Also, I do not think x86_64 is
going away any time soon.

> With the NetBSD
> userland, there isn't much to differentiate Minix from other POSIX
> operating systems other than the microkernel architecture.

Foreign userland was chosen because it was supposed to be easier to
maintain than Minix's own userland. There is still a lot of work to be
done (on both userland and OS sides).

The problem I have encountered while working with userland is lack of
expertise. While David Van Moolenbroek helped me a lot with Minix side
of things (I am very grateful for this), developers that are
knowledgeable with userland. Help with userland would be much
appreciated.

In my opinion, Linux's approach of not delivering userland at all is very
interesting. It allows a great amount of flexibility in customizing your
system, from embedded devices with busybox to desktops and servers with
more advanced system software set. However, it does not seem to be a
viable solution for Minix.

> IMHO, NetBSD
> isn't a first choice for POSIX operating systems or even BSD based
> operating systems. With the Minix kernel and servers, it is less featureful
> than NetBSD with its monolithic kernel, so I have trouble seeing where
> Minix fits in now and in the future.

I think that it is now pointless to chase market coverage. Current
status quo of Linux being the king of servers, Windows being the
standard desktop OS and BSDs being used in some cases is not going to
break anytime soon. The only hope for Minix in this direction is Intel.

> For what it's worth, I've got some admin privileges on github and Google
> Groups. I feel a bit like an outsider as most of the minix crew are former
> VU students and I've mostly lost touch with them, so I'm reluctant to just
> start merging stuff or make big decisions. Though I guess at this point any
> activity would be better than nothing.

It would be much appreciated if you review some pull requsts. I do not
want to brag, but one of them is mine. Also Marcelo Alencar posted quite
helpful pull request.

>
> Thomas C.
>

---
Best regards,
Peter

[Perry Metzger]

The function of hard forks in open source is to deal with situations in which the project management have started inhibiting development, either by falling asleep or for whatever other reason. I think it would be quite reasonable to hard fork Minix at this time so that pull requests could be dealt with reasonably. If the rest of project management eventually wake up, the nice thing about Git is that the fork could be merged back.