...but it’s in no way a departure from the status quo, even referring to itself as kernel + GNU/BSD style ecosystem.
I wonder if we will see a new paradigm anytime soon. The Hurd?
In isolation it might be superior and have laudable attributes, but you're maybe a millionth the way towards competing with current automobiles for a general purpose solution in any fairly densely populated country.
I'd like to see something like a self-hosting library OS. The entire OS is a single giant application, software is installed by adding the source code and recompiling the whole thing, and security is done using language-level and package management constructs.
MirageOS is a library operating system ...
What I find interesting is these two projects are using a similar approach but targeting opposite ends of the spectrum. Atomic is intended as a cutting edge server OS for enterprises that want an integrated stack for running containerized infrastructure (they also started publicizing Atomic Workstation as of the last release, although I found it painful to use due to a lack of docs). Endless is targeting emerging markets, composed primarily of first-time computer users. OSTree+Flatpak allows the desktop to run similarly to a mobile OS, and there’s minimal chance of users breaking the system itself.
[1] https://www.projectatomic.io [2] https://ostree.readthedocs.io [3] https://flatpak.org [4] https://endlessos.com/for-developers
Specifically 'Managed code: Memory protection on object level, rather than on process level'
and then again a year ago https://news.ycombinator.com/item?id=12232385
This isn't even remotely true, but we're in the age of short memories. There have been several operating systems built in Java within our (careers') lifetimes.
And dozens of operating systems that predate C. https://en.wikipedia.org/wiki/Timeline_of_operating_systems
There's nothing preventing other operating systems from being written in a safe way -- they just aren't. There are also multiple definitions of the word "safe". As in, "BSD or Linux are safe to bet the software architecture of my multi-million systems budget".
No new ideas mean no reason for me to even consider adoption until it reaches critical mass. Maybe in a decade I'll give it a look.
Edit: Multics was written in PL/I, which itself just had a new stable release this past September...
Edit2: Redox isn't really that safe even. It's pretty cavalier and leaves a lot up to the application. It uses the unsafe parts of Rust a bit. An application can still malloc and forget to free -- so aren't you right where you started? Really every time this comes up, I would like to posit that "people evangelizing Redox don't even know what the f* they're talking about", but I honestly don't have time outside of my real work to dig into the thing. jackpot51 is fantastic at PR for his project though, and I don't want to discourage anyone from working on. It's good that it has an active community, I just don't need to hear about it.
Edit3: Checking Redox' source shows that about 1.5% of the code invokes 'unsafe' and they cite this in their documentation, but what I really want to know is how frequently those lines of code are called.
I never used Rust but looked at it several times over the past years. Doesn't the 'unsafe' classification allow for future automated tools/theorem provers to challenge those specific lines? Looking for vulnerabilities/bugs in only 1.5% of the code instead of the entire code base sounds like a nice improvement.
The upside of invoking unsafe means that you were able to find out that 1.5% of the code is unsafe and you are able to focus in on it.
Put another way, it makes the haystack significantly smaller.
That was in 1961 at Burroughs, using ESPOL.
There were plenty of OS being built in Algol and PL/I variants outside AT&T walls since the 60's.
History is full of OS written in other languages that weren't either C or C++, including Apple's Lisa OS and the first editions of Mac OS.