Rebuild Minix with GNU/GCC natively #341
Comments
|
Hello,
On Wed Feb 15, 2023 at 9:02 AM MSK, Phrunsys Emmasson wrote:
Hello guys I have been working with Minix for a long while and one of the main key points that honestly comes to mind as to why we are not on the Linux level is because Minix's build system is too complicated and huge for contribution - Consider outdated too.
Sorry, but I will put it bluntly: MINIX is *never* going to get on "Linux
level", unless Linux dies for some reason and on that day MINIX is ready
to satisfy needs of former Linux users. Both points are hypothetical,
and there are systems which are much more likely to become Linux
successors, like FreeBSD.
As for now, MINIX severely lacks support for modern hardware: x86_64,
SMP, USB, WI-FI to name a few. Also MINIX lacks APIs for userspace: due
to transition to NetBSD userpace, POSIX layer is still incomplete.
But even if Minix supported every piece of hardware
and applications that Linux supports, nobody would consider switching
their operating system because that imposes a lot of complications,
risks and costs. For example, let us assume you want to migrate your
servers from Linux to MINIX.
1) You need to find people who can administer your Minix servers. This
is an *extremely small* number of MINIX enthusiasts across the globe.
Good luck finding one.. Even you managed to find one, their salary would
*extremely* large due to lack of supply and would easily override any
profits of migrating on MINIX.
2) You need to port your software to run on MINIX. It would be easy only if
you use only portable POSIX interfaces. But if you use Linux-specific
interfaces (epoll, inotify, splice, signalfd, EBPF to name a few), you
will have hard time to rewrite your software to use alternatives
provided by MINIX (if they exist at all).
If you use third-party non-free software, good luck convincing authors
to port it on MINIX.
3) Finally, how are you supposed to benefit from migrating to MINIX? You
are supposed to get better reliability and security due to microkernel
architecture. But what if the system does not deliver on promise? What
if you do not get enough performance? Are you going to discard all the
work and return to Linux.
As you see, MINIX build system is the least concern here.
On the other hand, the build system can definitely be improved. Pull
requests are welcome as always. Please note that the most of it came
from NetBSD.
I am suggesting we rebuild minix with GCC naively (no cross compile)
Sorry to burst your bubble, but you cannot compile operating systems
without cross-compiler. I. e. you need to link Minix userspace programs
against Minix-provided libc. Native GCC would link them against libc of
your distribution.
For more details, please read [1].
then we add an x86_64 architecture on the Micro kernel.
Adding 64-bit support to Minix requires more work than selecting
compiler.
With Minix, I intend to base my research around AI
AI has nothing to do with operating systems, and with Minix in
particular.
[1] https://wiki.osdev.org/Why_do_I_need_a_Cross_Compiler%3F
… but the build system is still a mess and makes the entire code base look so huge. If in favor of my point, Kindly contribute to my Minix Branch that way we can request pull requests. Or if merges are declined, who cares. Its all a hobbyist venture
--
Reply to this email directly or view it on GitHub:
#341
You are receiving this because you are subscribed to this thread.
Message ID: ***@***.***>
|
|
Hello, Operating systems can be built without cross compiling. Assuming you are only building for one architecture and expect that build to run all all supportive architectures like the one that built the binaries, that way consider the building of Linux and busybox, One downloads the kernel - builds the kernel using a native compiler and in turn gets a bzImage - he/she also downloads busybox builds and creates an initramfs - afterwards they have a working kernel and a ram filesystem. They can later use qemu or choose to create a bootable iso using grub-mkrescue. Points to note:
But for Minix:
NOTE: MORE IMPORTANTLY: |
|
A point you should note: Consider building Linux and Busybox - all you do is not even cross compile, you just build binaries that expect an x86_64 CPU for the case of linux and also tune your busybox the same |
|
For that case too, too dominate at least a field off Linux calls to first majorly build and develop Minix on on architecture or CPU (AMD or Intel) - and for your point that: "AI has nothing to do with operating systems, and with Minix in |
|
How about if we changed Minix research and purpose to Artificial
Intelligence rather than just education?!
…On Wed, Feb 15, 2023 at 2:40 AM Peter ***@***.***> wrote:
Hello,
On Wed Feb 15, 2023 at 9:02 AM MSK, Phrunsys Emmasson wrote:
> Hello guys I have been working with Minix for a long while and one of
the main key points that honestly comes to mind as to why we are not on the
Linux level is because Minix's build system is too complicated and huge for
contribution - Consider outdated too.
Sorry, but I will put it bluntly: MINIX is *never* going to get on "Linux
level", unless Linux dies for some reason and on that day MINIX is ready
to satisfy needs of former Linux users. Both points are hypothetical,
and there are systems which are much more likely to become Linux
successors, like FreeBSD.
As for now, MINIX severely lacks support for modern hardware: x86_64,
SMP, USB, WI-FI to name a few. Also MINIX lacks APIs for userspace: due
to transition to NetBSD userpace, POSIX layer is still incomplete.
But even if Minix supported every piece of hardware
and applications that Linux supports, nobody would consider switching
their operating system because that imposes a lot of complications,
risks and costs. For example, let us assume you want to migrate your
servers from Linux to MINIX.
1) You need to find people who can administer your Minix servers. This
is an *extremely small* number of MINIX enthusiasts across the globe.
Good luck finding one.. Even you managed to find one, their salary would
*extremely* large due to lack of supply and would easily override any
profits of migrating on MINIX.
2) You need to port your software to run on MINIX. It would be easy only if
you use only portable POSIX interfaces. But if you use Linux-specific
interfaces (epoll, inotify, splice, signalfd, EBPF to name a few), you
will have hard time to rewrite your software to use alternatives
provided by MINIX (if they exist at all).
If you use third-party non-free software, good luck convincing authors
to port it on MINIX.
3) Finally, how are you supposed to benefit from migrating to MINIX? You
are supposed to get better reliability and security due to microkernel
architecture. But what if the system does not deliver on promise? What
if you do not get enough performance? Are you going to discard all the
work and return to Linux.
As you see, MINIX build system is the least concern here.
On the other hand, the build system can definitely be improved. Pull
requests are welcome as always. Please note that the most of it came
from NetBSD.
> I am suggesting we rebuild minix with GCC naively (no cross compile)
Sorry to burst your bubble, but you cannot compile operating systems
without cross-compiler. I. e. you need to link Minix userspace programs
against Minix-provided libc. Native GCC would link them against libc of
your distribution.
For more details, please read [1].
>then we add an x86_64 architecture on the Micro kernel.
Adding 64-bit support to Minix requires more work than selecting
compiler.
> With Minix, I intend to base my research around AI
AI has nothing to do with operating systems, and with Minix in
particular.
> but the build system is still a mess and makes the entire code base look
so huge. If in favor of my point, Kindly contribute to my Minix Branch that
way we can request pull requests. Or if merges are declined, who cares. Its
all a hobbyist venture
>
> --
> Reply to this email directly or view it on GitHub:
> #341
> You are receiving this because you are subscribed to this thread.
>
> Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub
<#341 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AXII3P33WQIP4HP6PJFJHKTWXSB75ANCNFSM6AAAAAAU4NN3ZY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***
com>
|
|
In the interests of not leaving you wondering if anyone has read your comments I have the following input:
I am pleased you have taken an interest in Minix. If you wish for further discussion in a more appropriate setting there is an IRC channel on Libera Chat that you can join. Please be mindful that asking for sweeping changes may not go down very well. We do welcome interested ones and if you decide to fork Minix some may be curious to see how you get along. Just in case you were unaware there are a few other microkernel systems that you may be interested in:
I am going to refrain from replying to any other comments in this thread since I don't consider this a valid issue. You can find me on the previously mentioned IRC network should you wish to discuss further. It would be a shame if someone had to lock this thread. |
|
Hi, I have had an interest in Minix since the original release for the PC on floppy. What I require for my Rasberry PI4 is : A Minix I can compile under Raspian with GCC A Minix that does not have the bloat of Linux, is secure and suitable for single application realish time use. A Minix I can modify as required. When my other system development work is complete I will put some time into this. Advice ? |
Hello guys I have been working with Minix for a long while and one of the main key points that honestly comes to mind as to why we are not on the Linux level is because Minix's build system is too complicated and huge for contribution - Consider outdated too.
I am suggesting we rebuild minix with GCC naively (no cross compile) then we add an x86_64 architecture on the Micro kernel.
With Minix, I intend to base my research around AI but the build system is still a mess and makes the entire code base look so huge. If in favor of my point, Kindly contribute to my Minix Branch that way we can request pull requests. Or if merges are declined, who cares. Its all a hobbyist venture
The text was updated successfully, but these errors were encountered: