Reply to post:

[Author here]

> Atheos, especially the early years

Kurt Skauen, a Norwegian developer. He is still around, working in videogames these days.

http://kavionic.com/blog/kavionic/

It was an amazing achievement, but I think he did what he wanted to do and moved on.

Syllable OS was the project that tried to pick it up and move on, but that's even harder for something of this size and complexity.

I ran it in VirtualPC, I think, and it was amazingly impressive.

But getting from there to something of general applicability is an even bigger effort. You need tonnes of drivers and apps and testing and vast amounts of error checking, logging, reporting, and so on.

I feel that at this point, with the huge breadth of capabilities of modern OSes, the way forward is really radical simplicity.

It's basically impossible to compete with Linux by taking it head-on as a general purpose OS.

But there are tiny OSes out there that do amazing stuff that conventional 1970s-style Unix can't even approach. Inferno is one example.

As I wrote in my piece about Optane, I would like to see someone confront PMEM -- persistent memory -- and tackle it the hard way. It is doable, today, to build a computer with, say, 16GB of normal volatile RAM and the rest of the memory map filled with say 1TB of nonvolatile RAM. Directly-accessible storage on the memory bus, no indirection, no blocks to fetch and write: just memory, but memory that keeps its contents when you turn the computer off.

Let's see an OS that uses that as its basic abstraction. No disks, no files, no filesystem, no directories: it's all just RAM, but 99.99% of your RAM is nonvolatile. Throw away everything since the invention of hard disks and start afresh.

Throw away C and compilers at the same time. They are legacy tech. They take an input file in one format, translate it into another format, and write that into a new file. It's all just RAM. You JIT compile something then leave it there in RAM for the next 10 years.

The first time you boot, the OS is loaded into memory over the network, then it just stays there. Updates mean just loading new code.

You can reboot if you need, no problem. Zero a few counters, start running again from address zero.

We don't need the entire filesystem model any more. That's 20th century legacy tech. Throw it away.

Lisp is too hard, but Lisp Machines and Smalltalk boxes showed some of the way: the entire live runtime environment is the workspace.

Some Forths had an elegant model: enter code at the REPL, it's interpreted. Put it in a function definition, give it a name, and it's compiled and kept. That could still fly.

Maybe a friendlier wrapper around Lisp, like Apple's Dylan. That's still out there.

There's a lot of stuff that nobody is trying. Rewriting a 1980s design on 202Xs hardware is not the way forward.