In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3, Erlang, and the original Lisp machine. The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts.
Now, I'm sure that many of these ideas have already been envisioned within Tunes.org, LLVM, Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway.
Rather than wax philosophical, let me just dump out some ideas:
- Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code." I bet it's written well enough to provide the basis for some fun hacking.
- Run Erlang as a daemon in userland. Erlang has the sort of "ridiculous number of 9s reliability" that I'm looking for.
- Step by step, move everything into Erlang ;)
- Hence, almost everything is interpreted. This is also inspired by Java, .NET, and LLVM. Unlike Java and .NET, the interpreter uses high level P-codes, more like Python.
- Because of this, hardware-based "protected-mode" isn't nearly so important. I'm still debating whether it's even necessary to have more than one context (i.e. hardware-based address space) in userland since the Erlang interpreter provides this on another level.
- Processes are like Erlang "processes": they're dirt cheap, they don't share a common namespace, and they have really nice message passing semantics. After all, if we're going to be dealing with 100s of CPU cores in a few years, it makes sense to get away from the hard way of doing threads (mutexes in C) and embrace the easy way of doing "threads" (a la Erlang).
- Erlang processes have no shared namespace, but they can easily pass data amongst themselves--not just streams of bytes, but full-on data structures. Imagine taking advantage of this between every "program" on your system.
- Due to the nature of Erlang data, passing data between programs is copy on write.
- Like a Palm, every "program" is running at all times. Unlike a Palm, things are running in an interpreter, so you don't need cooperative multitasking. Nor will a single program bring down the whole system. Rather, the interpreter itself can "context switch" after every few instructions. Since the "processes" are super light-weight, context switching is very fast and happens a lot more frequently.
- Since every program is running at all times, that means every program is implicitly started when booting. It's more like turning on a Palm pilot than booting a computer.
- Throw away the filesystem. Every "program" has every "document" implicitly loaded at all times. The documents don't have to be serialized to a stream of bytes. They're always meaningfully structured like Lisp data.
- Don't throw out virtual memory! If everything is in memory, you're going to need really smart virtual memory.
- Unlike object-oriented systems today that have many objects and few threads, unify the concepts of objects, threads, and modules into something I call a "cell".
- That means every object has its own thread.
- "Programs" are constructed from a collection of such objects.
- Since every object is like a module, it can be reloaded independently of everything else. This has been done in both Erlang and in the Lisp machines.
- Since every program is always running and is composed of objects that can be independently reloaded, the objects behave more like biological "cells". Sometimes you get new cells. Sometimes old ones die. However, in general, things are pretty "static". Failures are treated more like a cancer than a stroke.
- These "cells" know how to do continuations that can be journaled to disk. That means that if the system needs to restart, the cells restart at their last "checkpoint".
- Naturally, the message passing in Erlang works seamlessly between machines. Hence, the "N" in "ERNOS".
- Programs that create "documents" for view by other people on other systems do so in an applet-like manner. That is, the code "goes with" the data (a la object oriented programming). The receiver doesn't need to have the same program installed. However, I will assume that non-ERNOS users can install Erlang in the same way most people have a JVM and a Flash player installed. Of course, the normal sandboxing applies.