Minix on X86_64, at no time?

[Viola Zoltán]

Hi, boys and girls... Excuse me for the bad English! I haved a play to use the Minix not only for study/education, but in my daily home "work", for "desktop" goals! I am a "half-profi" Linux user ("power user", "expert user") since cca ~10 years, I like the commandline and ncurses applications, I use now my own LFS implementation, and I already created a new programming language (it is an "interpreter" type). But I not like the very bloatware Linux-kernel, the illogical, inconsequence interfaces, etc, and think, I probe the Minix. Okay, but I am very disappointed, because as I read, the newest Minix, sorry, not available in nativ x86_64 version!

I am atrocious, capital sad! Cheafly, because in the tutorial and todo-list written, that the minix-group has as the mainly goal the ARM developing, not the X86-64!

I have a Lenovo ThinkPad T530, with 16 GB RAM, & Intel videocard. I am ready for very lot of compromise, during I use the Minix, but NOT that I use an operating system, which cannot use realtime, native my 64 bit processors& RAM. The 64 bit emulation is for me unacceptable, because then I cannot have the advantages of my fast computer. Emulation is always much slowest, than the native usage.

In which time to be expected the x86_64 release of the Minix?! Please tell me, if it is available!

Another topic: I have an own forum, at the link: http://parancssor.info/forum
The name "parancssor" mean in the hungarian language: "commandline". If the Minix community would like a forum, I am ready to create a full subsection in this forum for the Minix, and the peoples who like the Minix, can talking in that place, on the forum. Of course, this possibility is absolute free. And, my domain is full commercial/advertising free. No stupid flashes, etc.

[Jean-Baptiste Boric]

Hi,

I am atrocious, capital sad! Cheafly, because in the tutorial and todo-list written, that the minix-group has as the mainly goal the ARM developing, not the X86-64!

Well, there's no real compelling technical reasons to port Minix to x86_64 for the moment.

Minix was ported to ARM because the characteristics of Minix (micro-kernel, self-healing, small size) makes it a good candidate for the embedded market, which uses ARM processors most of the time.

I have a Lenovo ThinkPad T530, with 16 GB RAM, & Intel videocard. I am ready for very lot of compromise, during I use the Minix, but NOT that I use an operating system, which cannot use realtime, native my 64 bit processors& RAM. The 64 bit emulation is for me unacceptable, because then I cannot have the advantages of my fast computer. Emulation is always much slowest, than the native usage.

In an hardware installation of Minix (NOT inside a emulator), good old x86 is not emulated by your x86_64 processor, it is executed natively. There is a tiny performance hit compared to an x64 program/kernel, but that's mainly because there's more registers compared to x86, not because there's any kind of emulation going on at this level.

Even in a QEMU-style emulator, you do not have a performance hit (as large) as if you emulated a PowerPC or MIPS processor, because the instruction set is shared between the virtual machine and the real machine, so it can just execute the virtual machine's code directly (greatly simplified, but mostly true).

Now, you won't be able to use more than ~3 GiB of RAM while running a 32 bit operating system on a x86_64 processor (simplified again, but true as far as Minix is concerned). If you need to use that much RAM, there's probably going to be more important issues you would run into while using Minix at the moment anyway.

Again, no real compelling technical reasons to port Minix to x86_64 for the moment, given the situation.

 

In which time to be expected the x86_64 release of the Minix?! Please tell me, if it is available!

It isn't, and as far as I know it isn't being worked on at the time.

It doesn't mean that a x86_64 version wouldn't be welcomed if someone made it, but nearly all Minix users wouldn't see a difference compared to x86 for now.

Another topic: I have an own forum, at the link: http://parancssor.info/forum
The name "parancssor" mean in the hungarian language: "commandline". If the Minix community would like a forum, I am ready to create a full subsection in this forum for the Minix, and the peoples who like the Minix, can talking in that place, on the forum. Of course, this possibility is absolute free. And, my domain is full commercial/advertising free. No stupid flashes, etc.

We already have this Google Group :-)

That would be a great idea, but most of the users and developpers are here, so you'd need to be able to gain a critical mass of forum users to make it self-sustaining. You'll probably need at least 6-8 regular (even if newbies) users and at least one guy who knows what he is doing.

Also, unless you can also attract Minix developpers or advanced users, then tough questions/problems may go unsolved or be redirected here. It really depends on what kind of community you want to build.

[David Powers]

It used to be an 8-bit limit, with Apple choosing the weakest of the family.  Then a 16-bit limit.  Then a 19.5 bit limit imposed by Microsoft. Now it is the 31.5 bit limit that characterises a toy computer/OS (and assumed in BSD as never going to be used up), within even phones having more memory available to an app. Then we had the 39.5-bit AMD limit currently being jacked up to 47.5 and 51.5 bits (with the sign-extension split for kernel/user memory very analogous to the 640KB split of the 80286 PC era and the Windows-XP/Minix3 3GB split).

I see huge compelling reasons to go to X86-64 (my AV projects/programs simply cannot run in 31.5 bits - think CD-->DVD-->BD/HD).

It is not appropriate for driver's to have to be inside the kernel, and there are problems with Hurd, XNU, XOK, etc.

It is very disappointing not to be able to use Minix because it would cripple my machines.

I am looking at considering a student project to produce an X86-64 microkernel...

But where the best starting point is Minix3 remains to be seen!

The reasons are both technical and practical!!!

Is anyone else out there interested in 64-bit?

[Jean-Baptiste Boric]

I see huge compelling reasons to go to X86-64 (my AV projects/programs simply cannot run in 31.5 bits - think CD-->DVD-->BD/HD). [...] It is very disappointing not to be able to use Minix because it would cripple my machines.

Besides the address space issue, not having SMP, SSE, 3D acceleration or a 64-bit capable file-system would also be issues for that kind of work.
 

I am looking at considering a student project to produce an X86-64 microkernel...

I'm currently porting MINIX 3 with two fellow students to the Raspberry Pi 2/3 as a student project. We're one week in and we have the micro-kernel (barely) working for now. That's with an already-supported architecture as a basis and me being well-versed in arcane low-level stuff and the MINIX source code.

Porting MINIX 3 to the x86_64 will be much harder than what I'm doing right now. The cross-toolchain, arch-specific code (kernel, VM, libraries...), virtual memory, syscalls and 64 bit cleanliness issues (mostly in minix/ipc.h) are things amongst others I don't have to deal with compared to a full-blown port to a new, 64-bit processor.

I think it's doable, but it's going to be a pretty big project.

Is anyone else out there interested in 64-bit?

Personally, I don't need a x86_64 port of MINIX. But it would be nice to have it, if only to future-proof MINIX from i386 and 32-bits ARM obsolescence as they won't be around forever.

[Antoine LECA]

On 2016-05-24 05:19Z, David Powers wrote:
> It used to be an 8-bit limit, with Apple choosing the weakest of the
> family. Then a 16-bit limit. Then a 19.5 bit limit imposed by Microsoft.
> Now it is the 31.5 bit limit that characterises a toy computer/OS (and
> assumed in BSD as never going to be used up), within even phones having
> more memory available to an app. Then we had the 39.5-bit AMD limit
> currently being jacked up to 47.5 and 51.5 bits (with the sign-extension
> split for kernel/user memory very analogous to the 640KB split of the 80286
> PC era and the Windows-XP/Minix3 3GB split).

You have forgotten the 36-bit limit of the Intel P6 hardware design
(commonly called PAE.) This is annoying, as it is highly relevant to
your cause, since as you probably know, the PAE mode is required to be
able to switch to long mode and then use the X86-64 architecture.
And no, MINIX-i386 VM is NOT able to deal with that 36-bit barrier, and
is stuck to the lower ring.


Antoine

[bertbr...@googlemail.com]

Hi Jean-Baptiste,

On Tuesday, May 24, 2016 at 10:09:40 AM UTC+2, Jean-Baptiste Boric wrote:

I see huge compelling reasons to go to X86-64 (my AV projects/programs simply cannot run in 31.5 bits - think CD-->DVD-->BD/HD). [...] It is very disappointing not to be able to use Minix because it would cripple my machines.

Besides the address space issue, not having SMP, SSE, 3D acceleration or a 64-bit capable file-system would also be issues for that kind of work.

TBH, it sounds to me like we do not need 64 bit because the other components are not 64 bit aware. I think, every OS starts from supporting 64 bit at kernel level. Personally, I can also live with a 64bit kernel (long mode) and 32 bit userland. A amd64 port of minix is also from my POV crucial to really use minix in day by day manner on bare metal. 

 

I'm currently porting MINIX 3 with two fellow students to the Raspberry Pi 2/3 as a student project. We're one week in and we have the micro-kernel (barely) working for now. That's with an already-supported architecture as a basis and me being well-versed in arcane low-level stuff and the MINIX source code.

Porting MINIX 3 to the x86_64 will be much harder than what I'm doing right now. The cross-toolchain, arch-specific code (kernel, VM, libraries...), virtual memory, syscalls and 64 bit cleanliness issues (mostly in minix/ipc.h) are things amongst others I don't have to deal with compared to a full-blown port to a new, 64-bit processor.

Do not get me wrong, I really encourage community effort a lot, but even Raspberry Pi is already a 64bit CPU and has more than one core. So doing the SMP right for example would also allow us push x86 AND arm forward the same time.

brgds,

Bert

[bertbr...@googlemail.com]

Hi David,

On Tuesday, May 24, 2016 at 8:28:11 AM UTC+2, David Powers wrote:

It is very disappointing not to be able to use Minix because it would cripple my machines.

full ack. 

I am looking at considering a student project to produce an X86-64 microkernel...

Is anyone else out there interested in 64-bit?

A friend of mine is definitely interested in making minix run on x86-64. He's working actively on supporting Intel Baytrail (e.g. Minnowboard Max/Turbot). He made it working so far and you can already install it and use minix via serial on MinnowBoard (http://wiki.minnowboard.org/MinnowBoard_MAX) and its already part of public master. IIRC there's some small ifdef in serial.c, he explains it in one of the talks @MinixCon2016.

HTH,

Bert

[Jean-Baptiste Boric]

TBH, it sounds to me like we do not need 64 bit because the other components are not 64 bit aware. I think, every OS starts from supporting 64 bit at kernel level. Personally, I can also live with a 64bit kernel (long mode) and 32 bit userland. A amd64 port of minix is also from my POV crucial to really use minix in day by day manner on bare metal. 

Unlike traditional monolithic kernels like Linux, the drivers and nearly all kernel features are running in separate user-mode processes. That means the servers and drivers have to run as 64-bit user processes in order to take advantage of amd64, since the micro-kernel doesn't do much.

Running MINIX in long mode requires far more than just making the micro-kernel 64-bit, we really do need 64-bit user processes too for the operating system to run in long mode.

An i386 VM server in an amd64 environment just won't work.

Do not get me wrong, I really encourage community effort a lot, but even Raspberry Pi is already a 64bit CPU and has more than one core. So doing the SMP right for example would also allow us push x86 AND arm forward the same time.

I'm working in my spare time on things I can and want to work on. SMP is something I can't work on. Not that I don't want to, but I'm simply not good enough to pull that off.

Also, in my opinion making RUMP run on MINIX is more needed right now than a 64-bit port or SMP. It would give us lots of production-grade NetBSD drivers, file systems and a good TCP/IP stack on both i386 and ARM.

SMP won't happen until somebody actually makes it happen.

[u-l...@aetey.se]

On Tue, Jun 07, 2016 at 01:25:55PM -0700, Jean-Baptiste Boric wrote:
> Running MINIX in long mode requires far more than just making the
> micro-kernel 64-bit, we really do need 64-bit user processes too for the
> operating system to run in long mode.
>
> An i386 VM server in an amd64 environment just won't work.

This is presumably a consequence of certain implementation choices
(defining interfaces in terms of C structs, not byte sequences). Certainly
the alternative would imply performance penalties when the chosen format
does not coincide with a "native" structure, but it would make supporting
CPU families over width ranges (like 32 vs 64) much easier.

In theory this would even allow to run different processes on different
totally incompatible CPUs (given some form of MP of course).

I guess a change like that, making the internal OS interfaces independent
of CPU bit width and endianness, iow in the same fashion as in networking,
would not _have_ to be very intrusive, could possibly even exist as a
build time choice.

Of course if the current code hardcodes the assumptions in too many
places, a change would have to be more intrusive, but then even more
useful as a cleanup.

Rune

[Antoine LECA]

On 2016-06-08 08:50, u-l...@aetey.se wrote:
> On Tue, Jun 07, 2016 at 01:25:55PM -0700, Jean-Baptiste Boric wrote:
>> Running MINIX in long mode requires far more than just making the
>> micro-kernel 64-bit, we really do need 64-bit user processes too for the
>> operating system to run in long mode.
>>
>> An i386 VM server in an amd64 environment just won't work.
>
> This is presumably a consequence of certain implementation choices
> (defining interfaces in terms of C structs, not byte sequences).

I won't have put it that way (I see it as using MINIX using messages
versus your proposal to use a wire-oriented protocol much like sockets)
but you are right, this is a design choice.

Which just makes it harder to change.

> Certainly
> the alternative would imply performance penalties when the chosen format
> does not coincide with a "native" structure, but it would make supporting
> CPU families over width ranges (like 32 vs 64) much easier.

You did not get Jean-Baptiste's point. The API has nothing to do here.
The i386 VM, with its 3 levels of 1024 32-bit-addressed-page tables, is
completely useless when tables have 512 entries of 64-bit addresses.
And you cannot run a amd64 kernel without a VM server since MINIX now
heavily relies on shared libraries.


> In theory [...]

In practice, MINIX is almost stopped due to lack of workforce. Many
features are desirable (often quoted are threads, for example); but
without code proposals, it won't become reality.


Antoine

[u-l...@aetey.se]

On Sun, Jun 12, 2016 at 07:32:06PM +0200, Antoine LECA wrote:
> You did not get Jean-Baptiste's point. The API has nothing to do here.
> The i386 VM, with its 3 levels of 1024 32-bit-addressed-page tables, is
> completely useless when tables have 512 entries of 64-bit addresses.
> And you cannot run a amd64 kernel without a VM server since MINIX now
> heavily relies on shared libraries.

Oh of course I misinterpreted the point and thought of servers
in general. Thanks for putting this straight. Surely VM has to differ.

> > In theory [...]
>
> In practice, MINIX is almost stopped due to lack of workforce. Many
> features are desirable (often quoted are threads, for example); but
> without code proposals, it won't become reality.

Sigh.

Rune

[David Siebert]

Well, there's no real compelling technical reasons to port Minix to x86_64 for the moment.

Minix was ported to ARM because the characteristics of Minix (micro-kernel, self-healing, small size) makes it a good candidate for the embedded market, which uses ARM processors most of the time.

I would disagree with those statements.
1. I see Minix 3 as having real potential as an OS for a NAS, router, VOIP system and so on.  SMP, 64 bit support, and maybe ZFS could all be added to make Minix 3 suitable for those applications.

[Jean-Baptiste Boric]

Let's take real-world examples with what is inside my house to get a scale of what's needed.

The Synology DS-216 NAS has a dual-core 32-bit ARM processor clocked at 1.3 GHz and 512 MiB of RAM, which is more than enough for transcoding videos on-the-fly and I suppose a reasonably light usage of ZFS if it actually supported it.

The Synology DS-109j NAS has a single-core 32-bit PowerPC clocked at 266 MHz and 32 MiB of RAM. It's nowhere near as powerful as its distant cousin, but it still gets the job done streaming Full HD movies to my TV even after all these years.

Conclusion : we do not need SMP, 64 bit support or ZFS to make MINIX 3 suitable as a light NAS operating system. However, MINIX 3 won't scale towards more heavyweight solutions or ZFS unless some significant work is done first.

The Netgear WGT624 WiFi router has a really slow 32-bit MIPS processor from 2003 and 16 MiB or RAM. Even if I should probably give it to a museum at this point, it can still route packets faster than my ADSL line can download them or the DS-109j can stream data.

Conclusion : we do not need SMP or 64 bit support to saturate a consumer-grade ADSL line with plenty of bandwidth to spare. If you have fiber or an extensive network infrastructure then it's another story.

We're not going to beat feature-packed, crazy-optimized FreeBSD or Linux images at their own game. There's simply not enough manpower to do that. However, MINIX 3 can win on reliability and security against the big guys.

I purposely do not attempt to compare with established ridiculously reliable systems like QNX, VxWorks and others since MINIX 3 has always been more of an academical endeavor by researchers, students and volunteers rather than a commercial project with backing by big companies.

[bertbr...@googlemail.com]

Hi Jean-Baptiste,

On Friday, August 12, 2016 at 10:54:07 PM UTC+2, Jean-Baptiste Boric wrote:

Let's take real-world examples with what is inside my house to get a scale of what's needed.

The Synology DS-216 NAS has a dual-core 32-bit ARM processor clocked at 1.3 GHz and 512 MiB of RAM, which is more than enough for transcoding videos on-the-fly and I suppose a reasonably light usage of ZFS if it actually supported it.

The Synology DS-109j NAS has a single-core 32-bit PowerPC clocked at 266 MHz and 32 MiB of RAM. It's nowhere near as powerful as its distant cousin, but it still gets the job done streaming Full HD movies to my TV even after all these years.

Conclusion : we do not need SMP, 64 bit support or ZFS to make MINIX 3 suitable as a light NAS operating system. However, MINIX 3 won't scale towards more heavyweight solutions or ZFS unless some significant work is done first.

with that kind of argumentation we can also say an electric car makes no sense because my existing car is still driving. From my POV, multiple cores wont go away as the internet wont go away, too. And if it really matters what we have at home: 

My NAS is a QNAP TS-451+, which has a  Quad-core Intel Celeron 2.0GHz, 64 bit and 512 MB RAM, so PAE and long mode (from my POV long mode already helps) seem to be not necessary, but SMP will really make a difference, four cores means at least twice of the workload, even with a worse SMP enabled scheduling.

The Netgear WGT624 WiFi router has a really slow 32-bit MIPS processor from 2003 and 16 MiB or RAM. Even if I should probably give it to a museum at this point, it can still route packets faster than my ADSL line can download them or the DS-109j can stream data.

Conclusion : we do not need SMP or 64 bit support to saturate a consumer-grade ADSL line with plenty of bandwidth to spare. If you have fiber or an extensive network infrastructure then it's another story.

Lucky guy, my line is a fibre to the home, having 150mbit, no chance to even run it with a PC engines alix. The box has 100 MBit only. The successor (PC engines APU2) has GBit Lan, 1 GHz Jaguar quad core 64bit CPU with 4 GB RAM. Now, we need at least SMP and PAE, long mode would be still an advantage for sure. Funny side note: ATM, you would not be able to use minix at all for your router because AFAIK minix does not even allow two nics the same time and if im wrong (hopefully) theres no IP routing there at all.

 

We're not going to beat feature-packed, crazy-optimized FreeBSD or Linux images at their own game. There's simply not enough manpower to do that. However, MINIX 3 can win on reliability and security against the big guys.

Its no competition, its a matter of having an OS being useful at all or not. We do not need a full blown user land, we need a broad base to install it at all. IIRC you proposed the PR for the RPi, right? So, if you do not want to attend in the game of linux/bsd, why did you port it? having a network stack would help you more to install it on a low end machine in your house to run your router? *scnr*

 

I purposely do not attempt to compare with established ridiculously reliable systems like QNX, VxWorks and others since MINIX 3 has always been more of an academical endeavor by researchers, students and volunteers rather than a commercial project with backing by big companies.

 

From my POV thats exactly why no one (no one in terms of lacking community, a couple of guys doing still commits) contributes to minix and why so many think, you do not have to consider it, its made by crazy rocket scientists, who still believe in having a better approach with the micro kernel. And if someone would really try out, he's getting frustrated fast. An OS should run on bare metal as well, not only in the emulators. Furthermore, IIUC beginning with minix3 the main purpose was not longer the academia and research and the focus shifted towards making minix mature and ready to use for real world use cases?

I do not think, we will go back to 32 bit single core systems with less than 4 gb ram and we should accept it and make minix run on 64bit multicore environments, too. All the strengths you mentioned will be there in a 64bit multicore environment, too and its simply time to accept the progress from my POV.

brgds,Bert

[Jean-Baptiste Boric]

with that kind of argumentation we can also say an electric car makes no sense because my existing car is still driving. From my POV, multiple cores wont go away as the internet wont go away, too. And if it really matters what we have at home: 

My NAS is a QNAP TS-451+, which has a  Quad-core Intel Celeron 2.0GHz, 64 bit and 512 MB RAM, so PAE and long mode (from my POV long mode already helps) seem to be not necessary, but SMP will really make a difference, four cores means at least twice of the workload, even with a worse SMP enabled scheduling.

I do not disagree with the fact that 64-bit support and SMP would be tremendous improvements. However, these improvements won't happen until someone makes them happen.

The examples I gave are examples that could be implemented in practice in a reasonable amount of time and difficulty given MINIX's current state.
 

The Netgear WGT624 WiFi router has a really slow 32-bit MIPS processor from 2003 and 16 MiB or RAM. Even if I should probably give it to a museum at this point, it can still route packets faster than my ADSL line can download them or the DS-109j can stream data.

Conclusion : we do not need SMP or 64 bit support to saturate a consumer-grade ADSL line with plenty of bandwidth to spare. If you have fiber or an extensive network infrastructure then it's another story.

Lucky guy, my line is a fibre to the home, having 150mbit, no chance to even run it with a PC engines alix. The box has 100 MBit only. The successor (PC engines APU2) has GBit Lan, 1 GHz Jaguar quad core 64bit CPU with 4 GB RAM. Now, we need at least SMP and PAE, long mode would be still an advantage for sure. Funny side note: ATM, you would not be able to use minix at all for your router because AFAIK minix does not even allow two nics the same time and if im wrong (hopefully) theres no IP routing there at all.

Just for the improved latency and reliability I'd jump to fiber in a heartbeat given the occasion... My bandwidth is actually pretty decent for ADSL in practice.

MINIX definitively supports multiple NICs since Lazar Stričević made a presentation at MINIXCon about link aggregation, but it has to be manually configured since netconf doesn't handle that.

The legacy IP stack doesn't support routing, but David van Moolenbroek's presentation mentioned that LWIP will replace it, which would allow routing among other things.
 

 

We're not going to beat feature-packed, crazy-optimized FreeBSD or Linux images at their own game. There's simply not enough manpower to do that. However, MINIX 3 can win on reliability and security against the big guys.

Its no competition, its a matter of having an OS being useful at all or not. We do not need a full blown user land, we need a broad base to install it at all. IIRC you proposed the PR for the RPi, right? So, if you do not want to attend in the game of linux/bsd, why did you port it? having a network stack would help you more to install it on a low end machine in your house to run your router? *scnr*

I did propose the PR for the Raspberry Pi. The reason why I did it is because it was my end of year project in school. Rather than making a tiny, boring x86 OS in three weeks and throw it in the recycle bin once finished like most other people in my class, I along with a couple of friends decided we could do something a bit more useful and vastly more fun with our time.

About the full blown user land : the base is in much better shape than before (trying to get applications to run before MINIX had virtual memory, the NetBSD userland and pkgsrc was probably highly frustrating), but in my opinion we are still lacking a lot in both categories compared to any Linux distribution or BSD variant.

Fact is, user base and developer manpower are the two most important things in a open source project (or at least pretty darn important), but MINIX doesn't have a lot of either so the situation is not going to massively improve overnight.

I purposely do not attempt to compare with established ridiculously reliable systems like QNX, VxWorks and others since MINIX 3 has always been more of an academical endeavor by researchers, students and volunteers rather than a commercial project with backing by big companies.

 

From my POV thats exactly why no one (no one in terms of lacking community, a couple of guys doing still commits) contributes to minix and why so many think, you do not have to consider it, its made by crazy rocket scientists, who still believe in having a better approach with the micro kernel. And if someone would really try out, he's getting frustrated fast. An OS should run on bare metal as well, not only in the emulators. Furthermore, IIUC beginning with minix3 the main purpose was not longer the academia and research and the focus shifted towards making minix mature and ready to use for real world use cases?

MINIX 3 is still suitable for academia, even with the latest versions : it's far easier to wrap your head around than any BSD or Linux source code (or at least that's my personal experience). That wouldn't prevent it by itself from being useful in the real world.

In my opinion, the biggest problem is that MINIX is fundamentally an academic operating system project. Students make thesis on it and write cool stuff (as can be observed by looking at the publications wiki page), but more often than not their work does not end up in the source tree for various reasons. That is a lot of wasted opportunity and Tanenbaum actually wrote about it (http://cacm.acm.org/magazines/2016/3/198874-lessons-learned-from-30-years-of-minix/fulltext) : turns out students who want to bang out their papers and programmers who want to keep stuff stable and at production-grade quality have highly diverging priorities.

Another problem is dog fooding. I do not think that anyone is using MINIX as their main operating system these days and it shows. Recently I started to tinker with pkgsrc and I decided to do that from within MINIX with X11, since there's no real other way to do that. I'm having such a hard time getting work done it's not even funny. I discovered that gettext is broken over pthreads (ironically possibly because of a patch I submitted quite a while ago) and does not build for now, which pretty much breaks every non-trivial package in turn (pkgin isn't affected since the binaries are pre-built). X11 isn't stable when under stress from multiple xterm windows so X11 processes tend to vanish from time to time when I'm multitasking.

I do not know if those issues are just caused by something on my side, but holy crap.

Yet another problem is that it isn't commercially-backed. No commercial backing means no contributions from paid employees : we have to make due with volunteers and academia. I honestly can't come up with any reason compelling enough why a big company would choose MINIX instead of an established big player such as QNX, VxWorks, Linux, FreeBSD, Windows... Surviving driver crashes and live updating the system is incredibly neat, but the existing solutions are simply good enough.

That is the final problem : the "worse" existing alternatives are good enough. Plan 9 from Bell Labs, the Mach micro-kernel and a bunch of other successors of UNIX taught us a lesson : just merely being technically superior in every way doesn't mean you will replace an established product. MINIX would still have a lot of catching up to do before we'd even get to this point.

I do not think, we will go back to 32 bit single core systems with less than 4 gb ram and we should accept it and make minix run on 64bit multicore environments, too. All the strengths you mentioned will be there in a 64bit multicore environment, too and its simply time to accept the progress from my POV.

I've been thinking about it and how we could get those features. The most reasonable plan I came up with is to adopt HelenOS's micro-kernel and basically re-implement VM and MINIX's kernel API on top of it so that the rest of MINIX doesn't notice. That plan is utterly insane, but at the same time that would unlock so many features and cooperation with a (relatively) far more active developer community it might be just crazy enough to work.

Also, making RUMP run on top of that would pretty much solve all of MINIX hardware support problems forever, but one crazy idea at the time.

I looked a bit at HelenOS's micro-kernel and on the surface it does seems doable. To be honest, I'm more worried about the fact that this would basically mean creating MINIX 4, if calling it MINIX would still be appropriate ; having dynamic allocation and virtual memory policy inside the micro-kernel is probably going to be a big no-no here ; cooperating with a project that has radically different goals, development methods and philosophy could be quite tricky.

It's actually quite fun to compare MINIX and HelenOS : each one has basically the features that the other does not.

[David & Susan Powers]

Just a comment that I don't see the relevance of WiFi or ADSL throughput.  48- and 64-bit processing is about running (user) jobs that need lots of memory (terabytes). 

Think AI/ML type applications.  But if you do want to talk datarate rather than data, cameras on a phone or a laptop are capable of generating a terabyte an hour. In my house, I am ALWAYS coming up against my memory limits on machines that HAVE much more than the tiny 4GB that Minix allows.  Doesn't your laptop?  

The free versions of Mac OSX won't run properly without more memory than that (and a solid state disk to allow boosting it further).  At the moment it is the best platform I have to work on, although it is much less efficient than it was in Snow Leopard days. Similarly Windows 7-10 are big backward step in terms of processing power and efficiency.  For robotic/mobile/wearable work I've found the best Windows to use is still XP (or some form of Linux if you can do the best of the bad bunch tradeoffs there).

Oh for the days when there was Unix...

-- david & susan Powers
mobiles: all always open for SMS... calls depend on what country we're in 
Australia (OS: 21Jul-15Aug):  +61 414 824 307 (dP exc. OS)    &      +61 468 365 614 (sP inc. RU/Aug)

International (21Jul-15Aug):    +372 571 645 40 (dP exc. CA/Jul) &  +372 810 660 40  (sP inc. CA/Jul)

Europe  (1Aug-15 Aug2016):     +61 481 490 254 (dP)                     &  +61 481 492 194 (sP)

--
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/ONNF27C69lo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to minix3+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.