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