Flux toolkit as LispOS base

[Dwight Hughes]

[snip - my original comment cut out]

|  
|   OK, so now we have neither an OS nor a lisp implementation, since by
| definition, they all are warped by their initial design tradeoffs. So,
| how long before I can see the results of (car '(a b))? (I'm
| intentionally being a "bit" overly dramatic in my arguement.) When we
| find a piece of CMUCL that doesn't suit our purposes, we'll have to
| rip it out and put the better mouse trap in. No big deal! We have to
| start somewhere and I believe that starting from the ground up is a
| fatal mistake. By the time we get far enough along, the world will
| have passed us by again. The only way I can see us having any hope of
| "succeeding", is to follow the two pronged approach. The one prong
| starts writing today using using an available Common Lisp. They start
| writing all of the generic stuff that can be implemented for just
| about any CL implementation. Things like window systems, a generic
| networking system, and apps. The second prong looks into what it would
| take to implement OS services in Lisp. What they use as their basis is
| up to that group, whether it be Linux, *BSD, Flux, Hurd, or DOS. When
| they have an OS working along with the appropriate CL implementation,
| the apps guys port their parts over to it. Then we reexamine what we
| have and redo parts of it. And then do it again. And again. All the
| while building up a really neat system.
| 
|   Mike McDonald
|   mikemac@engr.sgi.com

Well, true enough -- we will just have to rely on those amongst us that
know what
a true LispOS should do and be from their experience on LispMs. Hopefully
they can 
wave large red flags when we unthinkingly incorporate lame aspects of the
kernels
as they presently are.