Re-branding as MinixBSD ?

[Patrick]

Hi Everyone

I hope this thread won't cause trouble. It's just brainstorming, feel
free to ignore it, I won't be offended.

I was just thinking that the word Minix has some competition now and
lots of people seem to download Minix but not so many post to the list.

Would calling ourselves MinixBSD and providing a one line description like:

"Micro Kernel BSD" give people an idea of what the project is about at a
glance?

Is it fair to say that at this point we are a BSD distro ?

Just throwing it out there....

-Patrick

[Jean-Baptiste Boric]

Hi,

Is it fair to say that at this point we are a BSD distro ?

No. At least not yet.

While we do have NetBSD's userland now, our service, driver and kernel layers are definitively not BSD-derived. As long as RUMP isn't imported we lack the kernel part of a BSD.

[David van Moolenbroek]

Hey,

On Saturday, May 6, 2017 at 3:25:20 PM UTC+2, Patrick McC^very wrote:

Would calling ourselves MinixBSD [..]

Given the NetBSD userland and MINIX operating system, following GNU/Linux, BSD/Minix might make more sense..

FWIW, I think discussions like this one are healthy and welcome, but rebranding is an absolute nightmare in every possible way, so it basically won't happen unless there is a really good reason.

Regards,
David

[Patrick]

Hi David

Yep ! Making a formal change would be a nightmare. I have a little
business, I am just a one person operation but we have a house so I
incorporated to protect it. I wasn't trying to run away from creditors
and such, I just wanted to stay the same legal entity with a cosmetic
name change.

What a pain in the butt....

Would using Minix/BSD work as a sort of nickname? As in :

Minix could be thought of as Minix/BSD, BSD with a micro-kernel.

I know Jean-Baptitste was saying we are not really there yet but if we
use phrases like "sort of", maybe that will work?

-Patrick

[Jean-Baptiste Boric]

 

Would using Minix/BSD work as a sort of nickname? As in :

Minix could be thought of as Minix/BSD, BSD with a micro-kernel.

I know Jean-Baptitste was saying we are not really there yet but if we
use phrases like "sort of", maybe that will work?

MINIX's situation with regards to NetBSD is rather unique: the lowest layers of the NetBSD standard libraries are rewritten to use MINIX syscalls instead of NetBSD syscalls. That means we are source-compatible with NetBSD, but not binary-compatible since we don't have a syscall compatibility layer (whether we should is another question). That approach can be compared to the Windows Subsystem for Linux, but unlike WSL we can't run native binaries from the original OS.

With that in mind, I guess the most accurate statement that can be made currently is that we are "NetBSD flavored".

Because while we taste like NetBSD, our internals are still very much MINIX. It's not that being a micro-kernel is at odds with being a BSD (both NetBSD and DragonFlyBSD have made some work in that area), but the BSD name comes with a history, a source code lineage and a reputation. I won't be comfortable saying we are a "real" BSD derivative until we also run a sizable amount of BSD kernel code (namely, at least replace most of our driver layer with RUMP), but that is just my personal opinion ; I'm not part of the core MINIX team after all.

Another thing to consider is our relationship with NetBSD. Currently, while there is some level of unofficial acknowledgment (at least a couple of NetBSD developers have posted some messages here, or talked with MINIX gurus at conventions) the MINIX project and the NetBSD project are completely separate. We could try to create closer ties with our "upstream", but I think we'll need at least to run RUMP to really catch their attention (at the very least, we'll catch Antti Kantee's). There are also other projects like HelenOS, where we could share (or copy-paste) some code or ideas.

Point is, MINIX does not exist in a vacuum, we should try to partner up with others in order to take over the world.

[David van Moolenbroek]

All,

On Saturday, May 6, 2017 at 11:09:16 PM UTC+2, Jean-Baptiste Boric wrote:

MINIX's situation with regards to NetBSD is rather unique: the lowest layers of the NetBSD standard libraries are rewritten to use MINIX syscalls instead of NetBSD syscalls.

I wouldn't say it is that unique; again, see GNU/Linux. As such, I wasn't kidding about the "BSD/MINIX" name - there would be a fair parallel argument for that. It would be an understatement to say that the Linux community isn't entirely in agreement on that point either, though. For now, in our case, I think it would be best not to introduce confusion with nicknames or whatnot - we already have serious trouble even keeping the Minix/MINIX/MINIX3/MINIX 3 terminology consistent. But we can revisit all this at any time. In addition, those who end up making a custom MINIX distribution (or even fork MINIX) can use whatever name they wish, of course.

As for the rest, I'd like to add my personal view, for what it is worth. Generally speaking, one of the current goals of the MINIX operating system is to be as much "NetBSD-like" as is useful for maintenance reasons of userland (both in the base system and in the form of packages). In a nutshell, we want MINIX to be *like* NetBSD to the extent that it is useful to us. We don't want MINIX to *be* NetBSD. After all, there already is NetBSD. As such, I for one don't see a major role of NetBSD code and RUMP in the core of the operating system (perhaps as opposed to device drivers), because the logical conclusion of such an approach is a microkernel-ized version of NetBSD, in which case it would be better to drop MINIX altogether and start over with RUMP. In other words: if we start to chip away from MINIX's *identity* that way, then we might as well give up and go home. That was one of the reasons why I went with lwIP rather than the NetBSD TCP/IP stack, too, although not the only one. I understand, and respect, that others may disagree on any or all of this. As far as I am concerned, we can and should discuss such things on a case-by-case basis. Overall though, given the limited manpower we have at our disposal, I do hope that we don't have to sacrifice too much of MINIX's identity in order to keep the project going.

Regards,
David

[Jean-Baptiste Boric]

 

As for the rest, I'd like to add my personal view, for what it is worth. Generally speaking, one of the current goals of the MINIX operating system is to be as much "NetBSD-like" as is useful for maintenance reasons of userland (both in the base system and in the form of packages). In a nutshell, we want MINIX to be *like* NetBSD to the extent that it is useful to us. We don't want MINIX to *be* NetBSD. After all, there already is NetBSD. As such, I for one don't see a major role of NetBSD code and RUMP in the core of the operating system (perhaps as opposed to device drivers), because the logical conclusion of such an approach is a microkernel-ized version of NetBSD, in which case it would be better to drop MINIX altogether and start over with RUMP. In other words: if we start to chip away from MINIX's *identity* that way, then we might as well give up and go home.

To clarify, I don't advocate to replace everything inside MINIX with NetBSD code. Indeed, NetBSD isn't MINIX.

For me, MINIX's identity is about three things: multiple user-mode server architecture, shallow learning curve and UNIX compatibility. As it happens, this makes for an operating system that is great respectively for research, education/tinkering and, well, UNIXy stuff. Recent focus on reliability comes in part from the first point (and lots of hard work to make it happen). While MINIX's raison d'être is officially no longer in teaching students, it is ironically easier than ever to get into for new developers (documentation staleness and a few dark corners notwithstanding). The UNIX side is there mainly because of MINIX's history, but it still permeates its design so much that even the micro-kernel has a certain UNIX flavor to it (and is not very useful outside of this context).   

MINIX's value does not reside in its userland, hence its replacement by NetBSD's a few years ago. I'd argue it's the same thing for drivers, which is why INET got replaced by lwip. We don't want to needlessly duplicate development efforts on stuff that is not what MINIX is about, but that doesn't mean we should try to get rid of what makes MINIX, MINIX. 

That was one of the reasons why I went with lwIP rather than the NetBSD TCP/IP stack, too, although not the only one. I understand, and respect, that others may disagree on any or all of this. As far as I am concerned, we can and should discuss such things on a case-by-case basis. Overall though, given the limited manpower we have at our disposal, I do hope that we don't have to sacrifice too much of MINIX's identity in order to keep the project going.

There are far greater dangers to MINIX right now than a singularity with NetBSD (which is really unlikely to happen in my opinion). While NetBSD is undoubtedly about UNIX compatibility, it is neither particularly easy or hard to get into for a developer and it is most certainly a monolithic design. If anything, the biggest threat to MINIX's identity is the growing pain of legacy code and outdated design decisions, because that directly goes against the shallow learning curve (documentation is a growing concern, but it has not yet reached existential-threat level).

One example is VM: beyond the somewhat questionable coding style by today's standards, it owns the raw page tables and strongly assumes a two-level layout. That means the initialization code is quite frankly insane (pt_init(), I'm looking at you), moving to 64 bit or PAE is outright impossible for now and VM has effectively kernel-level privileges (unlike any other server, a bad bug in VM can outright kill the micro-kernel). Just because VM works does not mean it's not a danger to MINIX, quite the opposite.

Another example is the micro-kernel. It's not as nasty as VM, but the current implementation is just meh. One issue I have with it is that its elementary unit is the process, which is too high-level and in part prevents us from implementing kernel threads. Magenta (the micro-kernel behind Fuchsia), L4 and HelenOS uses address spaces and threads as their elementary units, so that a process is "just" an address space and a collection of threads. As an elementary unit, our micro-kernel processes are just too big and (dare I say?) too monolithic.

In short, I don't think NetBSD is much of a threat to MINIX's identity ; rather, in my opinion, MINIX's own technical debt is a far more serious threat to its own existence. 

[David van Moolenbroek]

Hey,

On Monday, May 8, 2017 at 9:32:42 PM UTC+2, Jean-Baptiste Boric wrote:

In short, I don't think NetBSD is much of a threat to MINIX's identity ; rather, in my opinion, MINIX's own technical debt is a far more serious threat to its own existence.

While I don't think it's easy (or really necessary) to assess which is the bigger threat, I completely agree that the latter is also a major issue! On the upside, at least we won't run out of things to do anytime soon ;)

Regards,
David