On 1/29/20, Martin Decky <martin.de...@huawei.com> wrote: > > 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. >
Even if it's more tightly integrated, it's still a penalty box IMO if it's a second-class citizen within an incompatible native environment (which few people are going to port anything to no matter how good it is because any new OS is going to have limited market share, leaving pretty much everyone to just write Linux programs, much as with OS/2 and Windows back in the 90s). > > 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 about QNX? It's one of the most practical and successful microkernel OSes in the world and it's natively Unix-like. It's not perfect, but none of those imperfections are really inherent to the Unix-like architecture. Pretty much every other OS developer seems to ignore it though. I really don't get why that is. UX/RT will more or less just take QNX's general architecture and enhance/fix a lot of things. Assuming it is successful, it will only be the second working QNX-like OS other than QNX itself of which I am aware (VSTa was the first QNX-like OS besides QNX itself that I am aware of, but it is now abandoned). > > 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 > UX/RT won't just be a legacy-misfeature-for-legacy-misfeature compatible reimplementation of conventional Unix on a microkernel. There will be a lot of longtime Unix features that it will either throw out completely (e.g. setuid executables, binding of device nodes by major/minor numbers, utmp) or reimplement on top of new APIs (e.g. fork, which will be be built on top of an API that allows creating a "blank" process and manipulating its state, and BSD sockets, which will be reimplemented on top of a filesystem-based API sort of like that of Plan 9). Even though it will be superficially familiar-looking in a lot of ways, it will still be quite different from conventional Unix. _______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
