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.

Maybe, but if you dont't have a POSIX API you'll cut yourself off from a lot of applications. Even Windows is gradually admitting defeat with WSL.

You can only get adoption of a non-POSIX OS if it offers something really unique to the user, or is in a very different market space.

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.

Yeah, it is hard. So what? So is just about everything worth doing.

One thing is for certain: you will not replace the current players by cloning them.

Isn't that how Linux replaced most the UNIX players, by cloning them?

I think that had more to do with the important innovation of being free and open.

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).

IIRC FreeBSD was legally nebulous at the time, and Minix couldn't be modified and redistributed. I don't recall any other significant players.

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.

1: https://en.wikipedia.org/wiki/FreeBSD#Lawsuit

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.

See ATC'13 How to Run POSIX Apps in a Minimal Picoprocess (https://www.usenix.org/system/files/conference/atc13/atc13-h...). I would say it's a POSIX emulator OS.

This was the research that led to WSL.

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 whole point of a desktop PC is that you can produce, not only consume. Otherwise you might as well buy an iPad and browse the web/watch YouTube.

> Most of the action on desktop takes place in a browser though.

Then who cares about the OS? Why even bother. Just use ChromeOS.

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.

This is about the most boring thing I've ever heard. This is trivial to accomplish today, hell, QubesOS does the whole concept much better.

Fully agree.

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).

> a perfect OS jewel of perfection appeared today, but with no other support for it...

Sounds like seL4 to be honest, and yeah, it's taking a while to see adoption.

>"Yes. Projects are already in progress, and even if they all shut down,"

Might you have any recommendations of specific ones worth paying attention to right now?

The most advanced one is Redox https://www.redox-os.org/

Thanks for the link. Interesting it looks like Redox is writing their own filesystem or at least reimplementing ZFS:

https://github.com/redox-os/tfs

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?

TFS is very cool. Too sad that ticki has stopped working on it: http://ticki.github.io/blog/why_im_leaving_open_source/

Due to this, I don't know whether it will be ready at all.