Some heretic thoughts

[Thomas Fischbacher]

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
  windowing system?
  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
  Mach.
  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
  LISP.


* 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.


Comments?



--
regards,

 Thomas Fischbacher               tf@another.gun.de
                                  fischbac@informatik.tu-muenchen.de