[auvrw]

yes, files in plan 9 can be viewed as a way to "make objects look like files."

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.

[scroot]

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

In the Smalltalk world, processes are just instances of the class `Process` and `Processor` is a singleton that manages all processes. You can create new processes several different ways, the most common being to send the message `fork` to a block closure.

Because everything is so late bound in a Smalltalk system, and because the objects are running and executing live all the time, it comes to resemble an OS in a lot of ways. I think the key lesson here is not just about which language is better or good for X or Y, but about how holistic computing environments are more important than languages alone. I go on a lot about Hypercard and how that was a real missed opportunity, as well as being an excellent environment. But it's Hypertalk language was only a part of that environment and cannot really be evaluated on its own, for example.