[movitz-devel] Re: Lisp OS

mikel evins mikel at evins.net
Wed Feb 4 18:44:42 UTC 2004

On Feb 3, 2004, at 1:04 PM, Frode Vatvedt Fjeld wrote:

> mikel evins <mikel at evins.net> writes:
>> [..] Plan 9 is said to be organized around 3 fundamental concepts:
>> 1 - everything in the system looks like a file
>> 2 - files respond to the same unifying protocol regardless over
>> whether they are local or remote
>> 3 - the namespace of the filesystem is subjective; that is, each
>> process names all the files in the universe using a single namespace,
>> but that namespace is defined relative to the process itself, so two
>> different processes may have very different views of the same set of
>> files.
>> These fundamentals give rise to a system with powerful and elegant
>> abstractions. [..]
> Regarding file-abstractions/pathnames specifically, my perspective is
> that they are (in unix and e.g. plan 9) a solution to a naming problem
> that results from having separate address spaces, and no dynamic
> typing. So my feeling towards this would obviously be to solve that
> problem by not introducing it, so to speak.

What's nice about files and pathnames in Plan 9 is that

1. The basic concepts are easy to grasp

2. They are applied extremely uniformly, so that a single abstraction 
is sufficient to represent the majority of things that programmers and 
users want to use.

3. The namespace is hierarchical, and can uniformly encompass and 
organize every system resource (disk storage, network services, running 
processes, memory, devices...) using a single naming mechanism

4. The namespace is subjective; that is, each user constructs his or 
her own namespace organized for the user's convenience and 
understanding, not for the convenience of the computer. Any system 
resource may be mounted at any node in the namespace, without 

Like Lisp, Plan 9 has advantages that are not immediately obvious until 
you try them out. As an example, a web browser in Plan 9 can be utterly 
trivial--literally a one-line shell script, because every web server on 
the net is just a file somewhere in /net/tcp (or wherever the user 
decides to mount tcp) and windows are just files in /w.

This is not to argue that a Lisp OS should use the same sort of 
abstraction; rather, it is to argue that Plan 9 demonstrates how far 
the uniform application of a simplifying abstraction can get you. What 
I'm interested in, in this context, is this: what are the simplifying 
abstractions that are natural in Lisp? What Lisp features can collapse 
the complexity of a modern OS into something as simple as, or simpler 
than, Plan 9? Closures over streams, perhaps?

>> [..] What are the corresponding small number of powerful
>> fundamentals of a modern Lisp OS? What are the irreducible atoms of
>> which it is constructed? What are the abstractions that make for the
>> most natural expression of OS ideas in Lisp? What would the
>> ultimately Lispy OS look like?
> There are a lot of angles from which to attack this I suppose. But one
> I find interesting is the idea that information should be kept
> carefully in the system. Dynamic typing is the fundamental aspect of
> this, and CLIM etc. a logic extension. And this leads to what is my
> impression that people rave about from the lisp machines: the level of
> integration and resulting user experience. I wonder how this might be
> extended further in a distributed setting, the web, etc.

I agree, but we should keep in mind that one reason LispMs were so 
highly integrated was that no consideration whatsoever was given to 
security. Absolutely everything on the system was completely and 
totally unprotected. Sure, you could stop any process and inspect or 
change any value in any slot, or redefine any function all the way down 
to the metal, and this made for a great development environment. It 
should be kept in mind, though, that anybody else could do the same 
thing to your machine, whether you wanted them to or not.

> Other angles would be such issues as what is a process? An
> application? Safety? Security? Users? As I've probably said before, my
> hope is that Movitz can provide a platform for exploring these things.

I hope so too; that's why I find it appealing.

There's a lot more to talk about on all those subjects, but I don't 
want to write a giant screed on all of them right now. Maybe later. :-)


More information about the movitz-devel mailing list