Is someone likely to build a Rust OS that is real and useful? Yes. Projects are already in progress, and even if they all shut down, I'm sure more will exist in the future.
Is that Rust OS going to experience "success" by traditional metrics, such as taking a significant chunk of Linux's marketshare away, and becoming a viable thing you can run on some real piece of hardware for some real purpose? I won't say "no" but it will be at least a decade before that will happen. Not because Rust is bad, or the resulting OS will be bad, but all the entrenched advantages existing OSes have are just staggeringly huge. If a perfect OS jewel of perfection appeared today, but with no other support for it (no software, drivers, applications that can only run on it, etc.) it would be a long, long time for it to get any traction.
The key to getting there (aside from the driver issue), I think, would be creating an environment that is simple, easy to work with, and friendly to creating new tools. The faster you can spin up new tooling, and the more you want to, the more willing people will be to move to the new system. Then you provide VMs, emulators, and/or compatibility environments for running software from "legacy" systems.
Do not attempt to make a new posix system, because we already have giant, entrenched, mature posix OSs and you'll bring nothing new or interesting enough to the table to warrant switching while being held back by the creaking old standard.
I'd be willing to make a lot of sacrifices to move to an OS that met my personal list of wants.
You can do it in a VM or compatibility layer. Your OS can support "personalities" like Windows uses to implement WSL, but with containers. So now you can have multiple POSIX containers on your non-POSIX system.
You should encourage people to make native software using the new paradigms and abstractions of the OS, built from the ground up with decades of hindsight, rather than encouraging crappy ports.
> You can only get adoption of a non-POSIX OS if it offers something really unique to the user
At this point, just not being built on 50 year old crappy standards would be pretty unique. I have my own personal wish-list of features that would lure me in even if the only hardware supported was an RPi.
You still end up in the OS/2 situation - even if non-native apps didn't always run great, had much worse memory usage, didn't feel native, etc... they were still good enough that nearly nobody (comparatively) wrote native OS/2 apps. It's not impossible to imagine an alternate past where OS/2 had worse DOS/Windows compatibility and ended up more successful! (In actuality, I think it'd probably have done even worse — showing that the strategic options to replace the foundation of an entrenched ecosystem are "bad" vs. "worse".)
I'd like to see other paradigms explored, too, but it seems unfortunately hard to get there from here.
There were plenty of free and open operating systems. Linux and FreeBSD had the advantage of also being similar if not the same as what they were replacing, as well as allowing a lot of the software that was designed for UNIX's to also work with little or no change. In other words, they cloned the look, feel and compatibility (well , FreeBSd didn't really clone it, it IS it).
AFAIK, any possible nebulous legal situation with FreeBSD should have been resolved by late 1994[1], which is extremely early in Linux's lifetime if we're talking about supplanting major operating systems. I think you're right that there weren't a lot though.
That said, I can't imagine Linux actually having gone very far if it wasn't a UNIX clone. I think it would have been a real long uphill battle and it would have gotten handily beat by whatever open source UNIX clone came along next, for the pure reason that it's much easier to deal with POSIX compliance (and all the software it brings that actually makes it worthwhile to run the OS) when trying to copy a system that already did it and worked out the kinks.
I mean, if someone came out with a free (maybe open source) version of Windows at that time which was legal, we could easily be living in a world where that's the dominant free OS.
I guess what I'm saying that that being vastly better on one metric (in this case, free) doesn't necessarily mean you'll take over a market (because a free operating system that can't run any software isn't very useful), and just being a clone won't either, but being a clone that's generally as good one most metrics and vastly better on a few others (e.g. a UNIX which is also free and open source, instead of just some other UNIX) may.
That said, hiding the POSIX API behind a compatibility layer like WSL can have some major advantages because it means that updates to either side can be done independently. That would mean you can have the unique offering and the compatibility. You could then also look at turning WINE into a compatibility layer for the same functions and have a lot of other software work similarly.
You pretty much have to have a POSIX compatibility layer just to support stuff without resorting to VMs.
That said, there is a lot of room to innovate in OS/userspace boundaries that don't rely on POSIX APIs--see epoll/kqueue/iocp for one place where this innovation already occurred. I'd love to see better alternatives to POSIX signals, for example. So an OS that treats POSIX as a mere compatibility layer and not the primary driver of its design could be welcome.
Windows is not admitting defeat as such, rather taking advantage of those unhappy Apple customers that just want a POSIX shell and don't care about writing Objective-C and Swift based software, the actual customer base Apple cares about.
WSL is more of an emulator though - it's isolated in its own box, and the rest of Windows doesn't see the POSIX view of the world. If you're writing a library, and you want it to be used on Win32, you can't assume POSIX.
Most of the action on desktop takes place in a browser though. So I think you could go a long way by getting to the point where you can run Firefox or Chrome (or some other webkit etc. based browser). Isn't this sort of what ChromeOS does already.
The obvious answer is "because ChromeOS is spyware."
But the really fun possibility is having an OS where "Web" and "Posix" are equally-placed personalities that the OS ran, not only preventing rogue web pages from touching the posix system, but also preventing rogue posix processes from touching the browser (except where the end-user intentionally joins them through the system-provided Open File dialog or by opening the case and removing the debug pin to unlock cross-VM debugging). ChromeOS sort of implements that today, by running custom Linux environments in containers, but I'd rather trust Xen than Docker as the underlying isolation layer.
I think that now is the time for not only new system level programming languages, but now is also the time for new OS implementations using said programming languages. That being said, "now" actually refers to a period of time that will be anywhere from 5 to 25 years long (and you might want to weight that towards the long end).
I wonder how that effects the time horizon for maturity. I've always just assumed that a filesystem takes a good 10 years to be really stable. Maybe my assumptions are way off? Or the facts that its a reimplementation makes that matter much less? Didn't it take BTRFS around this length of be considered production stable?
Is that Rust OS going to experience "success" by traditional metrics, such as taking a significant chunk of Linux's marketshare away, and becoming a viable thing you can run on some real piece of hardware for some real purpose? I won't say "no" but it will be at least a decade before that will happen. Not because Rust is bad, or the resulting OS will be bad, but all the entrenched advantages existing OSes have are just staggeringly huge. If a perfect OS jewel of perfection appeared today, but with no other support for it (no software, drivers, applications that can only run on it, etc.) it would be a long, long time for it to get any traction.