Some heretic thoughts

[Dwight Hughes]

| From: Thomas Fischbacher <tf@another.gun.de>
| 
| Here are some general thoughts on the project. If you find them heretic,
| well, so do I.
| 

Note: my comments below are in the context of creating the "true"
LispOS (Lisp-to-the-metal, or something reasonably close to that).
 
| * We have to support X.

I would like to be able to interact with LispOS thru X-terminal software,
but this does not mean LispOS would have to use X as its native GUI. I
do not find the idea of using X as the native GUI for LispOS appealing.

| * We cannot re-implement X from scratch.

I wouldn't want to. Yuck! Consider your stance however - if we must use
it and not reimplement it, what will we have? Why call it LispOS if
we must drag 98% of Unix along with us? Better to start thinking
about creating a clean, elegant GUI. The choice of GUI has a huge
impact on the complexity, usability, and programmability of your
system - almost every application you create will have to carry
the burden of a complex, hideous, inflexible GUI. You also lose the
advantage of having the GUI in Lisp to be manipulated as desired.

| * Build it on top of a Unix kernel?

>From the point of view of an initial beginning this might be ok, and it
has a number of possible advantages. My view is that trying to work
within the framework of a Unix kernel to create the processes we need
to support the LispOS well *and* keep the Unix side happy will be
*much* harder and more time consuming than starting from something
like the Flux toolkit (perhaps with a few added drivers and modules)
and growing what we need as we need it. Note that this is not
something we will be doing once for a well-defined set of processes,
but again and again as we develop LispOS. Once we define in a stable
way what we need to efficiently support the LispOS, then we can
explore how to fit it back into a Unix kernel framework. (I should
note that I have swapped back and forth on this issue several times,
since both paths have many advantages, but the more I learn the
more I favor the Flux route.)

| * Unix processes + LISP processes?

Your comments are good, but I still think getting the LispOS out
into its own simplified environment to develop its necessary
processes, then bringing what we can back into a Unix environment
would be far less hairy overall.

I think we should definitely be concerned with interoperability with
Unix environments and eventually with running (most of) the LispEnv
on Unix OSs, but I think it complicates the picture in the beginning
too much.

-- Dwight