On 1/29/20, Martin Decky martin.decky@huawei.com wrote:
I am not good in predicting the future. I can only try to influence it. But still I think you are overgeneralizing a bit here. Not everyone is writing Linux programs. Many people write Windows programs (if we like it or not). Many people write programs for managed environments such as JVM and .NET (among others) or use high-level languages such as Python, R and Haskell (among others) and they don't really care much about the underlying OS. Many people actually write programs for niche environments (i.e. RTOSes).
Saying that Linux (or Unix, for that matter) is the entire world and anything that does not try hard to mimic Linux (or Unix) is deemed to fail is just black-and-white thinking to me. The world is actually quite colorful :) and it is surely not static.
A non-Unix-like OS isn't necessarily doomed to fail, but it's still not going to have as broad appeal as a Unix-like one.
But I fail to see why do you label the approaches of others as "penalty boxes" with respect to full genuine Linux compatibility while you don't label your own approach as such. In case you plan to throw out setuid executables (your own words) then you can hardly achieve full Linux compatibility.
To me a "penalty box" environment is one that segregates legacy applications to a container that must be visibly separate from the rest of the system and has limited support for native features, as opposed to one that tries to be more of a wrapper/filter that integrates into the native environment.
And I'm not actually planning to support 100% compatibility with Linux. UX/RT will be compatible with the vast majority of Linux applications and will allow running them in basically the same environment as native programs (with overlays for Linux libraries, procfs, and sysfs). Anything that expects to manage logins won't work except with fakeroot (in which case it will only be able to manage logins within the fakeroot environment itself).
Even though setuid executables won't be supported natively (fakeroot will implement setuid within its own environment to the extent allowed by permissions) there will be a facility to mark particular binaries as running with elevated privileges, which will allow defining rules to determine when privilege escalation actually takes place and what kind of privileges the process gets (sort of like an implicit sudo but more flexible).