[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
exception.
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. :-)
--me
More information about the movitz-devel
mailing list