Lisp Operating System (2015)

Really, address spaces are just a hardware implementation of a more general concept: Namespace-based security. Application code wouldn't even be able to know the names of privileged objects, and if someone told that code the right names, it wouldn't be able to use them, because resolution of names to things is, itself, privileged.

In a simple example, assuming a Common Lisp-like system: Everything which handles raw pointers is in the SYSTEM package. Application code can't inspect the SYSTEM package, and, even if you told an application that the function SYSTEM:WRITE-DATA-TO-DISK was a thing, it couldn't call that function because the real evaluation code, which can see into the SYSTEM namespace, knows not to let application code call anything in SYSTEM; only the functions in SYSTEM and SYSCALL can do that.

It may matter to the author of the article. That's fine. To the users? I'm pretty sure that hardtoreason correctly reflects their attitude.

And if you're writing an OS, but don't care about the users? Well, write it however matters to you, because you aren't likely to have users who care, because you aren't likely to have users at all.

Counterpoint: Windows 10.

http://doc.cat-v.org/plan_9/4th_edition/papers/names

note that the filesystem interface isn't totally durable across all operations: a syscall is still necessary to create processes, for instance. cp /proc/... doesn't do what one might think it does.

http://doc.cat-v.org/plan_9/4th_edition/papers/9

i appreciate that the original article similarly acknowledges that lisp is an "all the things (except for some things)" solution in the Single address space section. synchronization libraries (and perhaps other libs as well?) in C-based OSs need to drop into assembly to get at test-and-set kinds of operations. addressing these special cases one-by-one is something that'll need to be ramified in source in order to get any real insight, although (perhaps just from the inertia of familiarizing with the original bell labs warp) it's difficult to imagine the kernel as a "all the things, seriously everything" abstraction away from the machine.

----

overall, the original article and discussion here was a bright spot in my day. it gives me hope that there's some actual thought and discussion about how to evolve operating systems intended for commodity hardware, not just generalized, "yea, that's something we could do," one-offs. i'm not as familiar with the xerox heritage mentioned elsewhere in the comments, and the view that, in some sense, linguistic abstraction might cover OSs is something to think about.

i've heard the smalltalkers catch some flak about not actually writing an os because there was (apparently) the equivalent of exec(), no fork()

http://bitsavers.org/pdf/xerox/alto/memos_1975/Alto_Operatin...

this criticism of the alto OS could be due to cognitive bias as much as anything else. the concept of processes is by now deeply ingrained in the way we conceptualize operating systems. so i have to ask: is leading with eschewing processes a clean-sheet rethink, informed by history's mistakes as well as its successes, or is limiting the number of OS primitives at the expense of less-rich interfaces actually a desirable tradeoff?

like, although everything i've heard about multics in particular seems well thought-out, thomson and ritchie were doing something substantially different by opting for bytestreams as much of the interface rather than making strict decisions about arities and so on. every rule system makes is bound to be a rule a user will eventually want to break. i suppose the operating system's main job is to safely lift off of the hardware, not to impose further unnecessary artifice (of which hierarchical file systems AKA namespaces could be viewed as one) on the user. adding further icing onto this core objective is so much the better, so long as it's possible to scrape away and redecorate.