Some heretic thoughts
Sat, 7 Jun 1997 20:00:38 +0200
Here are some general thoughts on the project. If you find them heretic,
well, so do I.
* We have to support X.
A networked computer is much less useful if it can't handle X;
look, there are X servers for all common OS' around, for good
reasons. Not having X on a LISP machine would be an extreme
restriction. So, if we need X anyway, why not make it the native
Some people argue that X is a rather ugly monster, too bloated and hard
to understand. But hey, it is a wide-spread industry standard, and has
proven its worth. By the way, LISP also is bloated and ugly, but we use
it anyway. Because it's something like a "common base". And it's
useful. Same with X. (In my view.)
* We cannot re-implement X from scratch.
Ever had a look at XFree code? No, we certainly should not do this
again. Way too much effort and too distracting. So better use XFree.
This certainly would require nearly a full Unix kernel.
But why not? One obvious advantage would be that whoever wants to
do so could use a commercial X server as well, e.g. AcceleratedX.
* Build it on top of a Unix kernel?
So what if we take an existing Unix kernel and modify some things
so that a LISP process may run as a "second init"?
Don't know enough about Mach to say how it would look like on top of
Pro: such a machine could also run Unix stuff.
Con: hybrid approach; Unix trouble + LISP trouble + interaction trouble?
Of course, this would imply not to set up a second preemptive
multitasking for LISP processes, but use that of the Unix kernel.
(Threads are an entirely different issue, however.)
Certainly, some things would have to be changed to suit the needs of
* Unix processes + LISP processes?
It certainly sounds extremely mad at first, but as a starting point
for further considerations, how would it be to have Unix processes,
which are derived from process 1, "init", as well as LISP processes,
which are dreived from "process 2", "master-lisp". Modify fork() so
that new LISP processes receive special treatment and can be created
efficiently, move packages to shared libraries.
Unix process IPC is mostly pipes and sockets; that does well for
bytestreams. For LISP processes, something SysV-IPC based should
be more useful. (But at least sockets have to be supported as well.)
Interaction of LISP and Unix is an issue, of course. It must be
possible to create Unix processes from within LISP and vice versa.
This would be well-suited for implementing something very similar to
scsh, I think.
Yes, such a hybrid system would be rather bloated, no doubt, but since
there would still be a Unix, you could be productive from the beginning.
Later on, more and more Unix stuff will be replaced by LISP.
Thomas Fischbacher email@example.com