The future of Minix.

[stux atMinix]

Hi everyone,

I mentioned a long time ago I would make this post and real-life issues and commitments have kept me from doing so.  This, sadly, reflects on the difficulties of moving this project forward as many of the previous volunteers have had to devote their time an energy to focus on their jobs and real-world endeavours.   Well, I'm finally sitting down and taking some time try to carefully craft this post.

I'll divide the post into 3 parts:
* I'll try to discuss the state of Minix as an organization
* I'll attempt to summarize the work that is pending to erase Minix's technical debt
* I'll try to explore our options with regard to the future of Minix

I'll also use lots of bullet points as it helps me keep my thoughts organized :)

The State of Minix:

• Currently, Minix is both an Operating System and a Dutch Non-profit (Stichting MINIX Research Foundation). The non-profit is the steward of the Operating System, its maintenance and Development. As I understand it, the non-profit is owned by Andrew S. Tanenbaum [https://en.wikipedia.org/wiki/Andrew_S._Tanenbaum] and its property and operation are managed by former VU students who worked on Minix with AST.  I believe that there is meant to be a board of volunteers that are tasked with managing the foundation.  (Please reply to correct any errors.)
• For the record, I am not directly involved with the management of the code or the foundation.  At most, I try to remain an active participant in the community whenever possible.
• Unfortunately, most of these volunteers have full-time jobs, families and/or real-world commitments that prevent them from givin their attention to the project.  (I should know, I too have to prioritize these commitments over the project).
• That means that there are no full- or part-time developers working on the operating systems, and no full- or part-time staff maintaining our servers and digital properties.  We do have one volunteer who is available for server maintenance in case of emergencies. This has left the project in a state where it can be considered dead or in Hibernation.  (I'd like to be optimistic and consider it to be in Hibernation.)
• However, Minix is a name that retains wide recognition.  It is still used as teaching material for OS development worldwide.  Regularly, people inquire about the state of the OS or details about the OS on IRC and on this google group (simply read through recent posts for relevant examples).  There are people regularly interested in volunteering for the project, but unfortunately lack the technical background and experience needed.

What work needs to be done?:
Here is a list of some of the most crucial items to erase some of Minix's technical debt:

• * Fix cross-compilation issues in Debian [https://github.com/Stichting-MINIX-Research-Foundation/minix/issues/229].  This is the most common cross-compilation platform.  Changes in gcc seem to be preventing users from simply running the release tools with no modification.
• * Enable user thread support on pkgsrc packages.  Most modern software now assumes that operating systems provide native thread support. Minix does not. Instead, packages need to be automatically compiled and built while using userspace threading libraries available in Minix.  I've been told pkgsrc is supposed to automatically do this, but for some reason it's broken in Minix.  This prevents modern packages from building in Minix due to dependencies (for example: all packages that depend on a modern version of python won't build if python itself won't build). 
• * Bring Minix's userland up to par with current NetBSD [https://github.com/Stichting-MINIX-Research-Foundation/minix/issues/258].  This is not a straightforward process and this was previously conducted by a volunteer.  This may in some way be related to the pkgsrc/threading issue I mentioned above. 
• * Complete work for Clang Support on ARM [https://github.com/Stichting-MINIX-Research-Foundation/minix/pull/195].  This is one of those loose threads that doesn't prevent a release but would be nice to finish up.  On x86 Minix uses the clang compiler to build its code.  However, on ARM there were technical reasons that forced builds to use gcc to build its code.  The linked pull request fixes that.  However there are a few tests that fail which need to be resolved before the pull request can be pushed to the master branch.

Here is a list of lower-priority items that nevertheless need to be implemented in order to turn Minix into a modern OS and fully erase its technical debt. Some and more of these items can be found in the Wishlist [https://wiki.minix3.org/doku.php?id=wishlist:start], David's wishlist [https://wiki.minix3.org/doku.php?id=wishlist:david] and Roadmap [https://wiki.minix3.org/doku.php?id=roadmap]:

• Complete and merge work done on a Raspberri Pi port of Minix [https://github.com/Stichting-MINIX-Research-Foundation/minix/pull/134] from GSOC 2017[https://wiki.minix3.org/doku.php?id=soc:2017:start].  This work is important because there were improvements made to the kernel that made it more generic and easier to port to new platforms. This would likely facilitate several of the items listed below.
• Port Minix to x64 [https://wiki.minix3.org/doku.php?id=soc:2018:start].  This was a proposed GSOC that never received funding.  Minix only builds on x86 and runs on x64 under emulation. This port would allow Minix to run natively on x64 and use all of the RAM available in the system.  The caveat is that PAE support is required in x64 (which Minix does not have) and there may be minor issues with pointer types in some parts of the code.
• Add kernel thread support. This is a bigger issue than it sounds.  Currently, each process can support only a single thread and would emulate multiple threads using user libraries.  Unfortunately, this has performance implications since any single blocking operation (such as I/O) blocks all threads.  Not only the kernel, but all servers have to be updated to support a platform where a process can have multiple threads each blocking independently.
• RUMP support: Supporting the RUMP kernel [https://en.wikipedia.org/wiki/Rump_kernel] has the potential of allowing Minix to use all or most of NetBSD's drivers with little porting necessary.  This is why it's listed in both the 2017 and 2018 GSOC proposals.
• USB Support:  another big requirement since all modern hardware depends on USB.  USB development was explored but no implementations are available.  As I understand it there are other requirements (such as ACPI and APIC support) that need to be met.  It is the hope that RUMP can provide these for free or cheap-as-free.
• Add SMT Support: who doesn't like multi-core architectures?  Minix can only run on one CPU and we need to change that. There is a pull request [https://github.com/Stichting-MINIX-Research-Foundation/minix/pull/292] that attempts just that but it hasn't been pushed to master, let alone thoroughly vetted and tested.  If threading support is implemented, these changes may need to be revisited.
• Implement Job Control [https://wiki.minix3.org/doku.php?id=wishlist:david] - this is necessary to get all the POSIX goodies [https://en.wikipedia.org/wiki/Job_control_%28Unix%29] people are used to such as process grouping.
• Security Hardening Minix: code audits, security audits, and eventual formal verification like SEL4 should also be a long term goal.  Due to technical debt, Minix may vulnerable to exploits that have already been secured in other OSes. Some of the speculative execution vulnerabilities come to mind (though the Minix microkernel architecture itself may naturally prevent some of these).  Minix's service model means people have to jump more hoops to do something nasty to the OS.  But if minix were to gain popularity, it would get the same scrutiny as mainstream OSes and have those extra hoops discovered.

This list is long but not exhaustive. None of the items are simple either.  However, tackling the above items should bring Minix nearly on par with NetBSD's software and hardware support. For those who are not aware: Minix adopted NetBSD's userland in order to allow developers to focus on the Microkernel architecture itself.  Among other things, RUMP was believed to be the right approach to abstracting hardware support from the kernel architecture and one of the factors in deciding which BSD's userspace to adopt.  However, that doesn't mean tools from the other major BSDs can't be used. But being able to virtually replace the NetBSD kernel with Minix's architecture was the eventual goal behind this decision.


What are our future options?
As mentioned above, minix has interest but no full time developers or managers.  But there is name recognition and interest remains despite the lack of updates.
Here are some options going forward:

• We could associate with a larger group like Debian's SPI [https://en.wikipedia.org/wiki/Software_in_the_Public_Interest].  This group supports projects of various sizes, license types and project types.  They help raise funding and are probably available for consulting.  Their experience could be a valuable asset to a project such as Minix.
• We could directly collect money for full time developers like React OS [https://www.reactos.org/donating].  This would be easier with a larger and more experienced group.
• We could find a new academic sponsor.  With AST's retirement, there are no stakeholders with academic interest in leading the project.  Announcing a search for academic partners might be an option.
• We could maybe do both things: How do we keep minix as both a practical and educational OS?  Many people say Minix's code has become "complicated" but modern OS development *is* complicated.  Minix is one of the few "simpler" OSes out there whose source is well-documented enough to be used for OS development curriculum.  Whatever developer(s) are hired could keep that as a goal during development.
• A related goal could be to maybe create a community / Wiki 4th edition version of the OS book? That is, to update and organize the documentation enough where a Creative Commons licensed edition of the OS book could be published.  (Hard copy proceeds would fund the Minix non-profit.)
• We also need to finalize a 3.4 release and plan for a solid 3.5 release implementing as many of the items above as possible. Each release gathers further interest in the project and can create a positive feedback loop for the project in terms of support and interest.

All of these options require two key things: Money and active personnel. In addition to full-time developers we need people to manage public relations, funding and project management.  People to update documentation would cover the educational end of things.  We also need an active board to steer the hiring of said people. Forking the project has been mentioned in other projects.  That is fine, but the group doing the fork will eventually have to tackle all of the problems and issues I've mentioned in this post.  Ideally, Minix and its foundation should be the one revitalized in order to lead this effort.

I'd like to hear the opinion of both new contributors as well as the developers to contributed their blood, sweat and tears to turn Minix into the amazing OS that it is and who also had grand dreams to turn it into the OS that it needs to be.

-Stux

[Roger Voss]

Hey Stux,

Well, I took an interest in Minix a few months back - partly due to my immersion into the retro-computing scene over the last year. But also, because am an empty nester, I've had a bit of time to pursue computer science related interest that hadn't pursued up to now - like language parser implementation and operating system implementation. I can program in C++ and am tracking closely on that language in its post C++11 versions. Have programmed a bit in various assembly languages. So basically have that skill set.

The retro computing phenomena has done much to remind me of the fact that modern operating systems are using incredible amounts of memory to do what they do relative to the late 80s and early 90s operating systems. There is a YouTube video showing Slackware Linux 1.1.2 from 1994 being brought up on a 386 vintage PC clocked at 40 MHz and with 4 MB of RAM. My Linux desktop PC clocks at over 3 GHz, has 12 cores, and 32 GB of RAM. The Linux I use was installed from a 2 GB iso image on a usb stick, while that old Slackware Linux installed from a boot floppy and then a 1.4 MB distro floppy that had the entire release. The comparison of typical modern Linux vs early to mid 90s indicates a vast leap forward in resource requirements. Yet look at an Acorn RISC OS computer that came out in 1987 and how nimbly it runs a GUI - or install RISC OS today on a $35 Rasberry Pi. (Not sure on Haiku OS - but it is probably fairly lean on resource requirements too.)

Yes, yes, the modern OS is doing a whole lot more these days, but still...one wonders if a going back to basics and trying to bring up the OS again could result in something that is lean and mean for a desktop kind of user - while bringing back some of the fun of the earlier systems. For instance, RISC OS has the powerful and capable BBC BASIC incorporated that has high level graphics commands. Novice users can hop into BBC BASIC and do some interesting and fun things very quickly - it's a much better BASIC dialect than Bill Gates BASIC.

Guess what am saying - in addition to getting Minix OS alive and well again as a teaching OS, maybe it could also set itself another specific kind of goal - such as aiming to be an OS that revitalizes some of the fun of the 80s and 90s era computing, that could, say, run very well on a 100 MHz 486 with 128 MB of RAM (maybe comparable to the 486 core in the MiSTer project as the minimum hardware target, which can run Windows 3.x).

As to 64 bit support, well, one could support PAE in the page mapping implementation only, yet still keep the kernel and user mode programs as 32-bit. Only the page mapping implementation itself would be aware of the greater than 4 GB physical memory of typical 64-bit computers. Staying 32-bit would retain an emphasis on keeping all the software to be lean and mean. Plus, on x86 CPUs its possible to use the segmentation stuff to support a memory model of up to 4 GB code and 4 GB data/stack, but, where, say, 1 GB from the data segment is reserved for the kernel/OS address space. So that would mean a 32-bit user mode program that can be up to 4GB code and up to 3 GB data/stack - a substantial uptick over the typical 32-bit program memory model that crams code/data/stack all into just 2 or 3 GB address space (because segmentation is almost always completely ignored other than for far calls and interrupt handlers).

Once user-mode programs are 64-bit, well, that will promote software bloat and will soon be back to the equivalent of contemporary Linux and Windows OS - huge memory sucking behemoths. Running lots of programs that use all that 16 or 32 GB on the system motherboard is more important to most users than running individual 64-bit programs. Myself? I typically implement a controlling program that forks itself into child processes to do the real work. So 32-bit programs can easily handle very large workloads.

Another thing would be to, yes, implement page mapping of memory so every process enjoys an virtual address space, but don't bother to implement the complexity of demand paging. As Tanenbaum says, modern computers have oodles of memory. So jettison demand paging and just enable the old school Unix swapping feature so that a process can be swapped out to persistent storage. Process swapping could be the basis for implementing a suspend feature (important for laptop computing). (Minix supposedly already has support for process swapping though is supposedly not enabled by default.)

Demand paging is complicated and yet just not all that necessary in an age of 8, 16 or 32 GB populated motherboards. This would serve to keep Minix simplified and teachable.

I could ramble on some more on my various Minix musings, but will just say that am interested, am reading through a couple of different Tanenbaum OS text books on my lunch breaks, and I've started out prototyping a page mapping implementation that am writing in C++17 (exceptions and RTTI disabled).

But I've been going at my own pace because am just doing all this so far as a personal learning exercise. Yeah, I have a demanding day job too. I tend to cram my hobby stuff into the week-ends.

--RogerV

[Adam Storm]

Hi Roger,

I agree that computers these days seem to be very inefficient. It seems ridiculous how poor performance seems to be. I'm currently using wintel with windows 10 on quad processor with 8GB RAM and I feel something is wrong with it as far as performance. Been watching minix but not doing anything with it.

Do you have any projects as far as improved computers? I'm thinking minix being a better multi-processor Os could be a significant improvement. Any thoughts on that?

Adam
https://www.youtube.com/watch?v=ElKdLzZS5xY

On Saturday, February 29, 2020, 10:49:00 PM PST, Roger Voss <roger....@gmail.com> wrote:

Hey Stux,

Well, I took an interest in Minix a few months back - partly due to my immersion into the retro-computing scene over the last year. But also, because am an empty nester, I've had a bit of time to pursue computer science related interest that hadn't pursued up to now - like language parser implementation and operating system implementation. I can program in C++ and am tracking closely on that language in its post C++11 versions. Have programmed a bit in various assembly languages. So basically have that skill set.

The retro computing phenomena has done much to remind me of the fact that modern operating systems are using incredible amounts of memory to do what they do relative to the late 80s and early 90s operating systems. There is a YouTube video showing Slackware Linux 1.1.2 from 1994 being brought up on a 386 vintage PC clocked at 40 MHz and with 4 MB of RAM. My Linux desktop PC clocks at over 3 GHz, has 12 cores, and 32 GB of RAM. The Linux I use was installed from a 2 GB iso image on a usb stick, while that old Slackware Linux installed from a boot floppy and then a 1.4 MB distro floppy that had the entire release. The comparison of typical modern Linux vs early to mid 90s indicates a vast leap forward in resource requirements. Yet look at an Acorn RISC OS computer that came out in 1987 and how nimbly it runs a GUI - or install RISC OS today on a $35 Rasberry Pi. (Not sure on Haiku OS - but it is probably fairly lean on resource requirements too.)

Yes, yes, the modern OS is doing a whole lot more these days, but still...one wonders if a going back to basics and trying to bring up the OS again could result in something that is lean and mean for a desktop kind of user - while bringing back some of the fun of the earlier systems. For instance, RISC OS has the powerful and capable BBC BASIC incorporated that has high level graphics commands. Novice users can hop into BBC BASIC and do some interesting and fun things very quickly - it's a much better BASIC dialect than Bill Gates BASIC.

Guess what am saying - in addition to getting Minix OS alive and well again as a teaching OS, maybe it could also set itself another specific kind of goal - such as aiming to be an OS that revitalizes some of the fun of the 80s and 90s era computing, that could, say, run very well on a 100 MHz 486 with 128 MB of RAM (maybe comparable to the 486 core in the MiSTer project as the minimum hardware target, which can run Windows 3.x).

As to 64 bit support, well, one could support PAE in the page mapping implementation only, yet still keep the kernel and user mode programs as 32-bit. Only the page mapping implementation itself would be aware of the greater than 4 GB physical memory of typical 64-bit computers. Staying 32-bit would retain an emphasis on keeping all the software to be lean and mean. Plus, on x86 CPUs its possible to use the segmentation stuff to support a memory model of up to 4 GB code and 4 GB data/stack, but, where, say, 1 GB from the data segment is reserved for the kernel/OS address space. So that would mean a 32-bit user mode program that can be up to 4GB code and up to 3 GB data/stack - a substantial uptick over the typical 32-bit program memory model that crams code/data/stack all into just 2 or 3 GB address space (because segmentation is almost always completely ignored other than for far calls and interrupt handlers).

Once user-mode programs are 64-bit, well, that will promote software bloat and will soon be back to the equivalent of contemporary Linux and Windows OS - huge memory sucking behemoths. Running lots of programs that use all that 16 or 32 GB on the system motherboard is more important to most users than running individual 64-bit programs. Myself? I typically implement a controlling program that forks itself into child processes to do the real work. So 32-bit programs can easily handle very large workloads.

Another thing would be to, yes, implement page mapping of memory so every process enjoys an virtual address space, but don't bother to implement the complexity of demand paging. As Tanenbaum says, modern computers have oodles of memory. So jettison demand paging and just enable the old school Unix swapping feature so that a process can be swapped out to persistent storage. Process swapping could be the basis for implementing a suspend feature (important for laptop computing). (Minix supposedly already has support for process swapping though is supposedly not enabled by default.)

Demand paging is complicated and yet just not all that necessary in an age of 8, 16 or 32 GB populated motherboards. This would serve to keep Minix simplified and teachable.

I could ramble on some more on my various Minix musings, but will just say that am interested, am reading through a couple of different Tanenbaum OS text books on my lunch breaks, and I've started out prototyping a page mapping implementation that am writing in C++17 (exceptions and RTTI disabled).

But I've been going at my own pace because am just doing all this so far as a personal learning exercise. Yeah, I have a demanding day job too. I tend to cram my hobby stuff into the week-ends.

--RogerV

On Saturday, February 29, 2020 at 11:10:08 AM UTC-8, stux atMinix wrote:

Hi everyone,

I mentioned a long time ago I would make this post and real-life issues and commitments have kept me from doing so.  This, sadly, reflects on the difficulties of moving this project forward as many of the previous volunteers have had to devote their time an energy to focus on their jobs and real-world endeavours.   Well, I'm finally sitting down and taking some time try to carefully craft this post.

I'll divide the post into 3 parts:
* I'll try to discuss the state of Minix as an organization
* I'll attempt to summarize the work that is pending to erase Minix's technical debt
* I'll try to explore our options with regard to the future of Minix

I'll also use lots of bullet points as it helps me keep my thoughts organized :)

The State of Minix:

• Currently, Minix is both an Operating System and a Dutch Non-profit (Stichting MINIX Research Foundation). The non-profit is the steward of the Operating System, its maintenance and Development. As I understand it, the non-profit is owned by Andrew S. Tanenbaum [https://en.wikipedia.org/ wiki/Andrew_S._Tanenbaum] and its property and operation are managed by former VU students who worked on Minix with AST.  I believe that there is meant to be a board of volunteers that are tasked with managing the foundation.  (Please reply to correct any errors.)

• For the record, I am not directly involved with the management of the code or the foundation.  At most, I try to remain an active participant in the community whenever possible.
• Unfortunately, most of these volunteers have full-time jobs, families and/or real-world commitments that prevent them from givin their attention to the project.  (I should know, I too have to prioritize these commitments over the project).
• That means that there are no full- or part-time developers working on the operating systems, and no full- or part-time staff maintaining our servers and digital properties.  We do have one volunteer who is available for server maintenance in case of emergencies. This has left the project in a state where it can be considered dead or in Hibernation.  (I'd like to be optimistic and consider it to be in Hibernation.)
• However, Minix is a name that retains wide recognition.  It is still used as teaching material for OS development worldwide.  Regularly, people inquire about the state of the OS or details about the OS on IRC and on this google group (simply read through recent posts for relevant examples).  There are people regularly interested in volunteering for the project, but unfortunately lack the technical background and experience needed.

What work needs to be done?:
Here is a list of some of the most crucial items to erase some of Minix's technical debt:

• * Fix cross-compilation issues in Debian [https://github.com/Stichting- MINIX-Research-Foundation/ minix/issues/229].  This is the most common cross-compilation platform.  Changes in gcc seem to be preventing users from simply running the release tools with no modification.

• * Enable user thread support on pkgsrc packages.  Most modern software now assumes that operating systems provide native thread support. Minix does not. Instead, packages need to be automatically compiled and built while using userspace threading libraries available in Minix.  I've been told pkgsrc is supposed to automatically do this, but for some reason it's broken in Minix.  This prevents modern packages from building in Minix due to dependencies (for example: all packages that depend on a modern version of python won't build if python itself won't build). 

• * Bring Minix's userland up to par with current NetBSD [https://github.com/Stichting- MINIX-Research-Foundation/ minix/issues/258].  This is not a straightforward process and this was previously conducted by a volunteer.  This may in some way be related to the pkgsrc/threading issue I mentioned above. 
• * Complete work for Clang Support on ARM [https://github.com/Stichting- MINIX-Research-Foundation/ minix/pull/195].  This is one of those loose threads that doesn't prevent a release but would be nice to finish up.  On x86 Minix uses the clang compiler to build its code.  However, on ARM there were technical reasons that forced builds to use gcc to build its code.  The linked pull request fixes that.  However there are a few tests that fail which need to be resolved before the pull request can be pushed to the master branch.

Here is a list of lower-priority items that nevertheless need to be implemented in order to turn Minix into a modern OS and fully erase its technical debt. Some and more of these items can be found in the Wishlist [https://wiki.minix3.org/doku. php?id=wishlist:start], David's wishlist [https://wiki.minix3.org/doku. php?id=wishlist:david] and Roadmap [https://wiki.minix3.org/doku. php?id=roadmap]:

• Complete and merge work done on a Raspberri Pi port of Minix [https://github.com/Stichting- MINIX-Research-Foundation/ minix/pull/134] from GSOC 2017[https://wiki.minix3.org/ doku.php?id=soc:2017:start].  This work is important because there were improvements made to the kernel that made it more generic and easier to port to new platforms. This would likely facilitate several of the items listed below.
• Port Minix to x64 [https://wiki.minix3.org/doku. php?id=soc:2018:start].  This was a proposed GSOC that never received funding.  Minix only builds on x86 and runs on x64 under emulation. This port would allow Minix to run natively on x64 and use all of the RAM available in the system.  The caveat is that PAE support is required in x64 (which Minix does not have) and there may be minor issues with pointer types in some parts of the code.

• Add kernel thread support. This is a bigger issue than it sounds.  Currently, each process can support only a single thread and would emulate multiple threads using user libraries.  Unfortunately, this has performance implications since any single blocking operation (such as I/O) blocks all threads.  Not only the kernel, but all servers have to be updated to support a platform where a process can have multiple threads each blocking independently.

• RUMP support: Supporting the RUMP kernel [https://en.wikipedia.org/ wiki/Rump_kernel] has the potential of allowing Minix to use all or most of NetBSD's drivers with little porting necessary.  This is why it's listed in both the 2017 and 2018 GSOC proposals.

• USB Support:  another big requirement since all modern hardware depends on USB.  USB development was explored but no implementations are available.  As I understand it there are other requirements (such as ACPI and APIC support) that need to be met.  It is the hope that RUMP can provide these for free or cheap-as-free.

• Add SMT Support: who doesn't like multi-core architectures?  Minix can only run on one CPU and we need to change that. There is a pull request [https://github.com/Stichting- MINIX-Research-Foundation/ minix/pull/292] that attempts just that but it hasn't been pushed to master, let alone thoroughly vetted and tested.  If threading support is implemented, these changes may need to be revisited.
• Implement Job Control [https://wiki.minix3.org/doku. php?id=wishlist:david] - this is necessary to get all the POSIX goodies [https://en.wikipedia.org/ wiki/Job_control_%28Unix%29] people are used to such as process grouping.

• Security Hardening Minix: code audits, security audits, and eventual formal verification like SEL4 should also be a long term goal.  Due to technical debt, Minix may vulnerable to exploits that have already been secured in other OSes. Some of the speculative execution vulnerabilities come to mind (though the Minix microkernel architecture itself may naturally prevent some of these).  Minix's service model means people have to jump more hoops to do something nasty to the OS.  But if minix were to gain popularity, it would get the same scrutiny as mainstream OSes and have those extra hoops discovered.

This list is long but not exhaustive. None of the items are simple either.  However, tackling the above items should bring Minix nearly on par with NetBSD's software and hardware support. For those who are not aware: Minix adopted NetBSD's userland in order to allow developers to focus on the Microkernel architecture itself.  Among other things, RUMP was believed to be the right approach to abstracting hardware support from the kernel architecture and one of the factors in deciding which BSD's userspace to adopt.  However, that doesn't mean tools from the other major BSDs can't be used. But being able to virtually replace the NetBSD kernel with Minix's architecture was the eventual goal behind this decision.


What are our future options?
As mentioned above, minix has interest but no full time developers or managers.  But there is name recognition and interest remains despite the lack of updates.
Here are some options going forward:

• We could associate with a larger group like Debian's SPI [https://en.wikipedia.org/ wiki/Software_in_the_Public_ Interest].  This group supports projects of various sizes, license types and project types.  They help raise funding and are probably available for consulting.  Their experience could be a valuable asset to a project such as Minix.
• We could directly collect money for full time developers like React OS [https://www.reactos.org/ donating].  This would be easier with a larger and more experienced group.

• We could find a new academic sponsor.  With AST's retirement, there are no stakeholders with academic interest in leading the project.  Announcing a search for academic partners might be an option.
• We could maybe do both things: How do we keep minix as both a practical and educational OS?  Many people say Minix's code has become "complicated" but modern OS development *is* complicated.  Minix is one of the few "simpler" OSes out there whose source is well-documented enough to be used for OS development curriculum.  Whatever developer(s) are hired could keep that as a goal during development.
• A related goal could be to maybe create a community / Wiki 4th edition version of the OS book? That is, to update and organize the documentation enough where a Creative Commons licensed edition of the OS book could be published.  (Hard copy proceeds would fund the Minix non-profit.)
• We also need to finalize a 3.4 release and plan for a solid 3.5 release implementing as many of the items above as possible. Each release gathers further interest in the project and can create a positive feedback loop for the project in terms of support and interest.

All of these options require two key things: Money and active personnel. In addition to full-time developers we need people to manage public relations, funding and project management.  People to update documentation would cover the educational end of things.  We also need an active board to steer the hiring of said people. Forking the project has been mentioned in other projects.  That is fine, but the group doing the fork will eventually have to tackle all of the problems and issues I've mentioned in this post.  Ideally, Minix and its foundation should be the one revitalized in order to lead this effort.

I'd like to hear the opinion of both new contributors as well as the developers to contributed their blood, sweat and tears to turn Minix into the amazing OS that it is and who also had grand dreams to turn it into the OS that it needs to be.

-Stux

--
You received this message because you are subscribed to the Google Groups "minix3" group.
To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/minix3/ea4aaa38-9f00-44ca-bc15-c2c3338d6e56%40googlegroups.com.

[Pablo Pessolani]

Hi:

   First: I love Minix. I have worked on several proyects based on it for years. But, now I think that is too expensive (time and people) to make Minix a competitive OS against Linux or Windows without strong sponsors.

   Now, virtualization is the key technology. I think that is a best option not doing Minix as a true OS (with drivers which never be updated and unsupported hardware) instead a Userspace OS. I have implemented Minix 3 IPC as a linux kernel module (called M3-IPC as a subkernel) supporting several isolated instances of Minix over Linux (MoL) concurrently. Now M3-IPC support IPC between processes in diferent hosts (or nodes) but belonging to the same MoL instance, making it a basic distributed OS.

  With this approach (Linux as hosts of several distributed intances of Minix) one can experiment with different level technologies such as Unikernels, userspace replicated drivers, user space filesystems, etc.

  The hard work (device drivers) is delegated to Linux, which provides user space processes with several abstractions like device files, TUN/TAP devices, etc.

 

  I'd like to hear the opinion of the group.

Regards.

PAP

 

   

---

De: 'Adam Storm' via minix3 <min...@googlegroups.com>
Enviado: domingo, 1 de marzo de 2020 10:22
Para: min...@googlegroups.com <min...@googlegroups.com>
Asunto: Re: [minix3] Re: The future of Minix.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/minix3/573492481.2595893.1583068943135%40mail.yahoo.com.

[Roger Voss]

Hi PAP,

I spent some time studying Xen hypervisor and that could be a way to bootstrap the approach you're describing here (let some other OS layer handle device drivers and run Minix as a guest OS).

I found that Xen got re-written when it was targeted to the ARM processor and was cleaned up a lot (relative to x86 Xen).

I also found that the automotive industry sponsored some interesting research where they wanted to take a multi-core ARM, dedicate a core or two to a Linux kernel running in domain 0, and then run Android as a para-virtualized guest OS in some other domain.

The idea was to completely sandbox Android, which would handle the display console UI and interact with the dangerous Internet.

The domain 0 kernel would keep on chugging (on the ARM cores pinned to it - which Xen supports easily doing in its configuration) where it would continue to service more vital activities in monitoring the automobile, etc.

The favored Xen approach is to use para-virtualization of the guest OS(es)  that run in other domains other than the special domain 0. So device drivers for those guest OS have to be written in a particular way to support this para-virtualization approach. Needless to say this can be done in a manner where the guest OS can essentially rely on the device drivers of the domain 0 OS to do the heavy lifting real work.

So am seeing how one could bring up a very minimal Linux kernel in domain 0, utilize actual Linux device drivers (which comparatively speaking are lavishly supported in the luxuriant Linux community), and then just write some Xen para-virtualization drivers for Minix where it runs as a Xen guest OS. Probably the exiting Minix drivers would be relatively easy to convert to Xen para-virtualization drivers.

This would tend to set up Minix to be in a much better environment as to using it in education situation where the idea is to make it relatively easy to experiment and debug operating system level code. The Xen hypervisor and the domain 0 kernel provide a stable base while developing and experimenting with the Minix OS implementation.

Naturally Xen para-virtualization approach is much more performant than full blown virtualization of all aspects of CPU interrupt handling as is done when supporting closed source operating systems like Windows. So a para-virtualized guest operating system under Xen can run much closer to normal native performance. Of course its only a feasible approach for operating systems in which the source code is fully open.

Oh, and on the ARM version of Xen, it supports three privilege levels. The Xen hypervisor runs as most privileged, then domain 0 kernel and its device drivers run at middle privilege, and then user mode privilege for everything else. Naturally this approach can be taken on x86 too as there are 4 privilege levels to tap into (though most protected mode x86 OSes only use 2 of them).

Just a thought.

--RogerV

To unsubscribe from this group and stop receiving emails from it, send an email to mi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/minix3/ea4aaa38-9f00-44ca-bc15-c2c3338d6e56%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "minix3" group.

To unsubscribe from this group and stop receiving emails from it, send an email to min...@googlegroups.com.

[Roger Voss]

Hi ageslome,

At the moment Minix doesn't have any architectural support toward either operating system native threads or multi-core true parallelism. The two capabilities could be somewhat related in respect to undertaking work to add these to Minix. IOW, it probably would not be a good idea to concentrate on just supporting true native threading, and then in a completely separate effort, strive to support multiple CPU cores - probably best to design and implement these two enhancements in tandem.

Would Minix then come out as better (more performant) in multi-core parallelism than existing operating systems?

Well, in the sense that Minix is a much smaller OS over all and is not running nearly the amount of, say, services the way Windows does (and Linux distros can run quite a few services as well), and won't be loading up and consuming near as much memory - for a while that alone would perhaps give it an edge. But one has to think that by now both Linux and Windows have had a lot more man hours of effort devoted to fine-tuning the scheduling algorithms and context switching. So I for one would not just waltz into such a project and think that am necessarily going to beat those guys (and gals) at this particular game.

Here is what my personal goals are:

- get to a very lean and mean OS that runs in protected mode on 386 (well, actually 486) and decedent CPUs (whether Intel, AMD, or MiSTer FPGA)

- implement page mapping in order to enable each process to have its own virtual address space

- try to abstract lowest levels of OS, such as page mapping where deals with physical memory, to be layered underneath the OS kernel (kind of like a quasi, and super simplified, hypervisor layer that sits at the lowest, most privileged architecture layer)

- that hypervisor-like layer would also handle real interrupts and then dispatch them to the OS kernel and its drivers in a para-virtualization manner (yes, akin to Xen hypervisor)

- make use of all the x86 privilege levels:

  0) quasi hypervisor most privileged

  1) then kernel

  2) then device drivers and OS services

  3) and then user mode programs

- use PAE in the page mapping layer when detecting running on 64-bit CPU so more than 4GB physical RAM can be utilized, but kernel and user programs remain 32-bit

- use x86 segmentation to enable the process model to support 4GB code segment, 4GB data/stack segment, but where 1 GB of data segment is reserved for kernel address space

- avoid implementing demand paging and instead rely on Minix process swapping (use this to build a suspend feature for use when running on laptops)

- add native threading

- add multi-core support

- get X-Windows up and going again - just to provide a GUI

- but also look at alternative GUIs such as the one in RISC OS and especially in Haiku

I want to get to a GUI desktop behavior where the mouse cursor and blinking text cursor are always responsive and are never flaking out, and that windows can always be moved about responsively. If the OS fails to deliver that kind of user experience, then in my eyes it's all been a big failure. (And this is why am willing to ditch X-Windows and go with an alternative windowing GUI desktop - get back to that late 1980s lean and mean GUI desktop.)

Am not as riveted on supporting 64-bit kernel and 64-bit user processes, but wouldn't fight doing that - just would be at the bottom of my personal priority list.

Now if all the above bullet list items could be checked off, then would turn attention to coming up with a way to use Linux device drivers (the binary drivers - not source code that gets modified)

This could be a hard undertaking because Linux device drivers get linked into the kernel when they're loaded, and so they have some direct access to symbols that exist in the kernel image. Minix device drivers run in a user mode process and rely on optimized message passing for interacting with the kernel. And this approach is intentional as Tanenbaum believed that an OS could be made more robust and secure if device drivers were taken out of privileged kernel space.

Well, I have some ideas on how to go about attempting this (using Linux device drivers as is) - not sure if could be done, but if it could, then that would be an excellent way to definitively solve the device driver problem - just leverage off of the luxuriant Linux community for device drivers. (And yes, would still stick with Tanenbaum's microkernel approach.)

So that's my fantasy for enhancing Minix.

Obviously I listed a couple of things that sound a bit x86 specific, but in going to ARM, the ARM CPU can support 3 privileged levels so:

0) quasi hypervisor most privileged

1) then kernel

2) and then device drivers, OS services, and user mode programs

As to the x86 segmentation, well on ARM a 32-bit process would indeed be limited to a program memory map model of just 2 to 3 GB address space in which to fit code/data/stack. So 64-bit support will indeed be the way to break that barrier.

However, as things stand now, all the ARM devices, even though they're now sporting 64-bit CPUs, are being implemented as SoCs (for smart phones) where they have up to a max of 4GB of RAM. Even the Pinebook Pro laptop is built using an ARM SoC limited to 4GB RAM. (Things get more complicated to implement a bus in which standard, off the shelf memory expansion modules can be used.)

Will folks end up using 64-bit ARM devices that have 16, 32, or 64GB of motherboard RAM - not really happening yet. Not sure when it will be a thing. For desktop computing, where tethered to power, it's not as compelling to hurry up and get to low power consumption ARM based systems. Yet turning a smart phone ARM SoC into a decent laptop is imminently reasonable as really helps get price down (Pinebook Pro - $200).

--RogerV

To unsubscribe from this group and stop receiving emails from it, send an email to min...@googlegroups.com.

[Dark-wolf]

---- Roger Voss a écrit ----

To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/minix3/808c2f4b-2366-4c69-82fd-9ae21bb32c3b%40googlegroups.com.

[Dark-wolf]

Hi Roger,

Thanks for your reply.

Isn't possible to use NetBSD or FreeBSD driver modules, rewrite for MiniX system call, and use it on MiniX userland space ?

Write IPC and system call between many MiniX kernel in the same CPU but one pers core...

I will try...

Dark.

---- Roger Voss a écrit ----

Hi Dark-wolf,

I think you'll find the Xen hypervisor does pretty much what you describe.

It runs one particular kernel in what it calls domain 0, that kernel will tend to be primary. Xen allows for cores (in a multi-core CPU) to be pinned to a domain.

That kernel will tend to be the one that has the device drivers that handle most of the hardware devices.

Then other operating system kernels get run as guest in other domains and they must implement para-virtualized device drivers, but this is much more performant than emulating the interrupts the way VM software has to do for closed source operating systems such as Windows.

Also, services can be run in a domain. For instance, one can implement a file system service and dedicate it into a domain - and of course multiple file systems could be done that way. Same with a networking stack. Heck, in addition to sockets, might even put high level HTTP handling into a service running in a domain.

So the way to go here would be to use Xen to run a stripped down Linux kernel in domain 0, use Linux device drivers, and then implement para-virtualization drivers for Minix and have it run in a guest domain.

This has the advantage of letting Minux leverage essentially off of Linux device drivers, and could be a rather sensible setup for positioning Minix as a teaching OS (its actual intent, of course), as would provide for a stable environment to experiment with Minix, try out new things, and debug it.

--Roger

On Mon, Mar 2, 2020 at 6:26 AM Dark-wolf <dark...@ovh.fr> wrote:

Hi all,

May be can use one kernel by core and do an IPC to speak between each kernel... Like PS3 have one master cpu and some else cpu for specific work. Can dispatch the core charge to different core... It's just idea.

I think too need to write one single UI, like haiku, but I think need can use it at the same with mouse and keyboard like a tiling... And a frame buffer for TTY using... And to, two ways, one for server and one for desktop. Or a simple cli with frame buffer for server use and a meta package for desktop use...

Support more than 4Go is important I think for server use.

And desktop use...

... I lost else I want say ...

BR,

Dark.

---- Roger Voss a écrit ----

> To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/minix3/808c2f4b-2366-4c69-82fd-9ae21bb32c3b%40googlegroups.com.

---- Roger Voss a écrit ----

To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/minix3/808c2f4b-2366-4c69-82fd-9ae21bb32c3b%40googlegroups.com.

[Steve Jones]

Great summary Stux, thank you for going through things so methodically. Unfortunately it's far easier to get opinions on technical directions, than it is to get input on a purpose and support for a project. And I think that is the key question, because people are less likely to commit their time, energy, or money without a good understanding of the goals and methods.

It's possible to have a project without an organization, but this is less likely the larger and more complicated the project is - and especially if money is going to be involved. Since there's an existing organization (Stichting MINIX Research Foundation), the easiest thing would be to work with or revitalize that organization. Do we know what the official purpose, mission, et cetera of that organization is?

--S.

[pplo]

Hi Stux,

Thank you for going through the hard work and summarize the current state of Minix3. It's a great bullet list to check future things to do, all in one post.

-- pplo

[peter bennett]

I'm not sure that my vote should be counted. I'm not a contributor.But I'd like to be.

I like all of the options suggested by Stux. I guess the final decisions may be made by anyone who is able to get behind one of the options and push. I don't see any of the options as mutually exclusive.
Certainly a number of these things can be done at the same time.

Any way we can gain some active contributors to get us nearer a 3.4 release would be great.
If I can find the time I'd like to update the wikkibook https://en.wikibooks.org/wiki/Minix_3
make it a guide for anyone who wants to understand how the kernel works.

Are there any copyright issues with lifting text straight from the Minix 3 Wikki and agging it to a Wikibook?

[Vishal Oza]

I do not see any real copyright issues with lifting text straight from the Minix 3 Wiki and adding it to a Wikibook other then even the Wiki is dated? Keep in mind I am not part of the Minix Wiki team and I am looking at the Wiki from a licencing issue point of view. I think you should be find as long as you give the official Wiki maintainers access to update the Wiki books

--
You received this message because you are subscribed to the Google Groups "minix3" group.
To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/minix3/417e7dfa-d820-40e6-a642-d0f5b814b05e%40googlegroups.com.

[stux atMinix]

Hi everybody,

Thank you very much for responding to my initial post! It's good to see that there is interest, but it's sad to see that the administrative side of things is lacking support :(.  Well, in the meantime we'll keep doing what we can and I'll post a longer response a bit later.  For now I'd like to address the question of copyright of the original Minix 3 book.

Sadly, it's not clear what license the wiki has been published in.  I doubt any of the authors would care for the text to be treated as anything other than open source but without any explicit text listing the license I'm afraid that the copyright might remain "closed source".  I'll try to see if I can get clarity on that from the powers that be. For the time being, attribution to the minix wiki itself (and its contributors) on the pages lifted from it, might be a necessary step to at least identify the pages in question. 

Thanks again for your interest and contributions! :)

-Karli

On Sunday, March 22, 2020 at 6:25:41 PM UTC-4, Vishal Oza wrote:

I do not see any real copyright issues with lifting text straight from the Minix 3 Wiki and adding it to a Wikibook other then even the Wiki is dated? Keep in mind I am not part of the Minix Wiki team and I am looking at the Wiki from a licencing issue point of view. I think you should be find as long as you give the official Wiki maintainers access to update the Wiki books

On Sun, Mar 22, 2020 at 2:44 PM peter bennett <peter....@gmail.com> wrote:

I'm not sure that my vote should be counted. I'm not a contributor.But I'd like to be.

I like all of the options suggested by Stux. I guess the final decisions may be made by anyone who is able to get behind one of the options and push. I don't see any of the options as mutually exclusive.
Certainly a number of these things can be done at the same time.

Any way we can gain some active contributors to get us nearer a 3.4 release would be great.
If I can find the time I'd like to update the wikkibook https://en.wikibooks.org/wiki/Minix_3
make it a guide for anyone who wants to understand how the kernel works.

Are there any copyright issues with lifting text straight from the Minix 3 Wikki and agging it to a Wikibook?

--
You received this message because you are subscribed to the Google Groups "minix3" group.

To unsubscribe from this group and stop receiving emails from it, send an email to min...@googlegroups.com.

[Prime Seal]

I have decided to that I am going modifying Minix 3.1.0 Book, although it uses Ack-compiler. I can create gitlab for sharing my modifications

[Prime Seal]

Minix 3 has FAQ on it's website

[Alessandro Coppelli]

My two cents...

Minix3 could be used in embedded hardware where speed and reliabilty are important.

When you program embedded system it's not important to have a graphical interface and have threads could lead to a more responsive system but would make the development and debugging phases harder than processes and IPC programming-I'm thinking at  ROS nodes and messaging.

It could be interesting to have a tutorial, template or some stuff to simplify, or better automate, porting in different hardware.

I believe that, in this manner, the Minix3 project could 'capture' new developers and perhaps used like FreeRtos ( again: often it is not important real time OS but have a good C platform to develop your projects )

Ale

[Giovanni]

On 03/30/2020 11:53 AM, Alessandro Coppelli wrote:

> Minix3 could be used in embedded hardware where speed and reliabilty
> are important. When you program embedded system it's not important to
> have a graphical interface and have threads could lead to a more
> responsive system but would make the development and debugging phases
> harder than processes and IPC programming-I'm thinking at ROS nodes
> and messaging.
>
> It could be interesting to have a tutorial, template or some stuff to
> simplify, or better automate, porting in different hardware. I
> believe that, in this manner, the Minix3 project could 'capture' new
> developers and perhaps used like FreeRtos ( again: often it is not
> important real time OS but have a good C platform to develop your
> projects )

Thought I'm not interested any more in Minix development I've been
active at the time of Minix2 that was, at least for me, a perfect source
of information when I was working on an OS for the GSM subsystem that my
company was developing. Minix2 was good as a teaching tool and I
appreciated the Minix3 new development (I had the chance to test early
releases) but soon I found that people out there were asking too much
and that they were going too fast. They do not have the way of thought
after Linus Torvalds nor there are such conditions as at the beginning
of the nineties.

Your comments are proper to the present development status. Minix3
would have been good to be used in our project for its scalability and
robustness but it came too late. I think that more efforts should be
oriented to: a) debugging tools, b) porting for different architectures,
c) optimization of the kernel, d) documentation, e) tool for cross
developing.

Unfortunately people at the University seem to have abandoned and the
people out in the network reclaim features that require thousands of
manpower hours. The target is too high to start with!

Nowadays Minix can't be a widespread OS because it lacks multi-core and
thread support. These features block any further usage on modern
devices - it is my opinion but when I read that my smartphone has 8
cores I smile to those that think Minix can spread out.

You are right. Minix would be good for embedded systems and, rather
than focusing on applications, there should be a team of developers for
improving the kernel for various platforms, develop support tools and
support documentation.

Giovanni
--
Giovanni Falzoni
Personal Web Page: <http://giovanni.homelinux.net/>

[Murilo Reis]

Hey,  about the foundation, there is an website? a way to contact it? it is possible to create a new foundation?

[Vishal Oza]

Yes there is a website Minix3.org, but there is no true Minix Foundation. The closest thing to a Minix Foundation is the Stichting MINIX Research Foundation and I am not sure if they are still going. You could contact them through in...@minix3.org.

To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/minix3/2841bf1d-12c7-4619-93b4-f510fa9cc6den%40googlegroups.com.

[Err Ss]

The minix3 mail server runs on Ubuntu:

220 server.minix3.org ESMTP Postfix (Ubuntu) [465 ms]

Why arent they using minix? There are many MTAs that could run on Minix.

> To view this discussion on the web visit https://groups.google.com/d/msgid/minix3/CAGZfAQ4vWZnvO-131CZcviWzk0SA90weFR91Wg-ibV1-78mLnQ%40mail.gmail.com.

[Giovanni]

On 08/16/2020 06:20 PM, Err Ss wrote:

> The minix3 mail server runs on Ubuntu:
> 220 server.minix3.org ESMTP Postfix (Ubuntu) [465 ms]
>
> Why arent they using minix? There are many MTAs that could run on Minix.

I've been following Minix since release 1.5 but always considered it a
good tool for teaching and nothing else. It was a simple, plain system
and never got so big to be easily handled at the University.

But release 3.x made a big step forward for complexity and size.
Moreover Dr. Tanenbaum has retired and since then Minix ha slowly
started to die. What happened to the co-author of the book?

People around the world tried to port application from to Minix but
there isn't a collection of packages that make a real distribution ready
to be installed. I don't know the situation for other environment
except X86 for which Minix is missing support for modern processor.

I suppose that Minix is still under development at the Vrije University
but only for what applies to the kernel they never got committed to
support a large distribution. Without the availability of distributions
Minix will never have a place in the world of servers.

Ciao
Giovanni

[Vishal Oza]

I think that Minux has not been worked on for a few years with the last official release being 3.3.0 and the 3.4 release candidate? I think the holding issue now is with NetBSD compatibility. 

--
You received this message because you are subscribed to the Google Groups "minix3" group.
To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/minix3/d150e03a-d84f-c21e-2dd1-b230d3425967%40inwind.it.

[stux atMinix]

As mentioned in my original post, there is a lack of money and manpower with regards to the project.  With the retirement of AST, there is unfortunately no one working on Minix at the VU.  Stewardship of the project is now in the hands of the non-profit foundation but no one is actively at the helm and no money has been raised.  It doesn't help that Google hasn't funded micro kernel development in its GSOC program since 2018 afaik.

In order for Minix to catch up to its technology debt we need volunteers willing to provide time and money to its development.  That's what the project is lacking the most, unfortunately.

On Monday, August 17, 2020 at 12:02:40 PM UTC-4, Vishal Oza wrote:

I think that Minux has not been worked on for a few years with the last official release being 3.3.0 and the 3.4 release candidate? I think the holding issue now is with NetBSD compatibility.

[Murilo Reis]

I'm not that involved, but it seems more a lack of direction too, there is no way to a interested volunteer know what to do. I feel that the project needs a leadership, someone or an council that makes the decisions.

--
You received this message because you are subscribed to a topic in the Google Groups "minix3" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/minix3/nUG1NwxXXkg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to minix3+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/minix3/24ae1470-10d9-435e-acaf-9465619650a4o%40googlegroups.com.

[Armin Faltl]

Hi,

I'm not involved in the project either, but once bought a Beagle Bone Black to run Minix 3 on it, then checked for new versions and read on BSD forums, that the compatibility was no longer present...

However, I agree with above poster, that direction and leadership (like by a council) is the basis for attracting money and manpower.

It's really sad, that the roadmap is so dated.

My intention when looking into Minix 3 was to build a very secure system, sort of a stronghold in my network.

The micro kernel and still very low number of lines as well as advertising statements made this very attractive.

I try to buy hardware, to support my OS and application, not the other way round.

Even more attractive would be a Minix 3/64 with multithreading and multi processor capability.

All provided, that security can be maintained.

I don't fully understand the proposed hypervisor concept, but I believe that some balance between scheduling

in the (guest) kernel and in the hypervisor has to be found. Certainly drivers should be at a lower privileg level

than scheduling, memory management and IPC.

Looking at GUIs I support the idea, that a system with guaranteed fast response is desirable, and therefore

an approach like Wayland or the others mentioned above makes sense.

What I really want to have is a computing platform, that I can trust. I thought that Minix 3 has the potential

to build such a platform for an Intel, ARM, RISC V, SPARC or Power based machine in the mid term future.

If I had 3 wishes, it would be 64-bit, multicore and multithreading.

[Wolfgang Keller]

Hello Stux

Good summary, but I have one question here: Does the Minix project have a manager? Otherwise it should urgently look for one.

Seeing the stats about the project I would have to conclude that it's dead. There is a RC6 for version 3.4 in store but nothing has changed to even the code base since three years. How is that possible if there is someone interested in the management? And second, if I may says so, I am surprised the original owners at the Free University appear to have so little interest in their product which has gathered some reputation. I mean it's not little, it's nothing.

[johnswolter]

I've -been lurking around this conversation off & on for sor time.  My interest in MINIX3 is to see about whether its security potential could be distributed across a data center & to orther Data Centers securely.  It would be a distributed software Infiniband.  It would scale from key-fob to key-centers

Reading about the "Any Kernal" seems a direct of reversal of a Microkernal's OS componemts' isolation.  Isolation is an importan for example by requiring credentials for components' message based communication for distributed executions.  Like Yocto's varient OS generation of different version of LINIUX,  MINIX3 could be designed & generated per application along with an SDK.  Still a static reult.

A step beyond that is dynamic reconfiguration   MINIX3 or 4,5,6.,,, could serve as an OS that would manufacture itself per designer  requests.  MINIX then would be a species adapting to a supervising ecosystem.  It would redefine the meaning what is a real-time OS.

[recombinant]

Plenty of excellent thoughts in this thread.

How about replacing header guards with some more appropriate for a project the size of Minix3?

e.g. for minix/kernel/proc.h

#ifndef MINIX_KERNEL_PROC_H_
#define MINIX_KERNEL_PROC_H_
/* ...code */
#endif /* MINIX_KERNEL_PROC_H_ */


or for minix/include/minix/ipcconst.h

#ifndef MINIX_INCLUDE_MINIX_IPCCONST_H_
#define MINIX_INCLUDE_MINIX_IPCCONST_H_
/* ...code */
#endif /* MINIX_INCLUDE_MINIX_IPCCONST_H_ */


A simple finite task to implement. Easy to check for compliance.

Then pick the next simple task. Take Minix3 into the future. 

[Janusz Wolak]

Hello Stux,

In my opinion from the proposition how to keep the Minix3 development
I would votes on:
- We could directly collect money for full time developers like React OS
and partially:
- We could find a new academic sponsor
but also might be found a company which becomes a "golden" sponsor ?

About the future of what Minix3 should support I can see it as a
reliable real-time system which can be used in industries devices.
It can find a place in high critical control systems (f.ex. energy
distributing, supervision etc.)
I do not think it can be worth now to focus on consumer market devices
like f.ex smartphones.
I suggest searching for an industry company which is interested to use
Minix3 in their devices (f.ex. industrial computers) and make an open
source solution alternative for commercial software (micro kernel
based real time OS) products in that area.

BTW remember ReactOS when I had seen it the first time in 2008...but
now I can see that after 12 years it is still under development, so
maybe it is not a bad solution.

BR,
JW

pt., 30 paź 2020 o 22:01 recombinant <stephe...@recombinant.me.uk>
napisał(a):

> --
> You received this message because you are subscribed to the Google Groups "minix3" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to minix3+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/minix3/4d2bcaa7-f8cd-4f37-bebb-afd545f44680n%40googlegroups.com.

[Max Humphrey]

Hello All!

I've had a google alert for Minix 3 for a while and it's been sad given the awesome potential of minix3 that very little has come up. Since this topic is relatable, wanted to give my $2 cents.

Looking at the above comments, that there is a lack of direction or BDFL to move things forward, maybe it's best to start with our individual goals and start to grow a shared vision?

For me, I'm a big science fiction fan and the idea of relying on Windows in space is terrifying! I think a huge lack of investment and energy away from consumer driven operating systems and towards efficient and secure operating systems like Minix 3 is better for the whole world! No more embedded Windows! ( BART in  San Francisco runs it's teller machines on Windows 2k which is always funny and sad).  I think recent developments in say RISC-V are aligned with this vision of a more open set of systems.

what excited you about Minix 3 or got you to this Google group?