Dear Andrew, > Is it natively Unix-like, or is the Linux compatibility layer some kind of > containerized "penalty box" that doesn't really integrate into the system?
Neither. The OS is NOT a Unix clone, but the Linux compatibility tries to be as tightly integrated as possible. Unfortunately, I cannot go into details. Windows Subsystem for Linux version 1 (not version 2) has had a similar goal, but we target even tighter integration. Of course, it is a delicate balancing act, as I try to explain below. > Also, since you're not developing it publicly , that may limit its ability to > compete with Linux, which of course has a completely open development > model without copyright assignment. In addition, from one article I read, it > sounded like even though it is going to be open source eventually, it was > designed with the assumption that it would be running on tivoized devices > with locked bootloaders, with no way for the user to get full control. I cannot really add any comment to this. I am a researcher, not a manager :) In my previous email, I have merely pointed to the existence of our effort. I am not promoting it nor advocating our development model :) > From what I understand, Hurd doesn't implement a lot of Linux-kernel- > specific APIs. Yes. This is exactly the reason why I have made the distinction between "syscall-level compatibility" and "glibc-level compatibility". > For my purposes, I would much rather have an OS that runs Linux > programs natively rather than having to port every single application > I want to run. Unfortunately, a bitter truth is that there will never be a better Linux than Linux. >From my experience, designing an inherently better (i.e. more robust, more >safe, more secure, etc.) OS with a microkernel design and at the same time >having an almost complete compatibility with a legacy OS of a completely >different design (e.g. Linux, Unix) is inevitably corrupting both goals. What do I mean by this? Having some kind of compatibility layer for running unmodified legacy programs is certainly a nice feature, but it should be a last resort option, not a first-class option for a microkernel-based system. We simply need to draw the line somewhere and cut ourselves from the legacy ideas that are no longer useful [1]. There are viable ways (i.e. virtualization) for running 100% genuine Linux on top of a microkernel-based OS without compromising the microkernel design. [1] https://blog.systems.ethz.ch/blog/2019/fork.html Best regards Martin Decky _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
