CMUCL and LispOS

[Mike McDonald]

>From: "Vassili Bykov" <vbykov@cam.org>
>To: <lispos@math.gatech.edu>
>Subject: Re: CMUCL and LispOS
>Date: Tue, 29 Apr 1997 14:02:46 -0400
>
>> From: Peter.VanEynde <s950045@uia.ua.ac.be>
>> I see people running around proclaiming that salvation will come from
>a
>> new VM for Lisp. Imagine that we work 2 years on CL (or EuLisp) on
>this
>> VM. Then we would be at the same place at now (maybe worse off): we
>would
>> have a working Lisp on all major systems. So what? The key to success
>> isn't perfection but infiltration. I see CMUCL as the basis for a
>LispOS
>> on the foundation of Linux, _making_ _it_ _easy_ to use old software.
>
>I think Peter is making an excellent point here.  I may even throw in
>some pessimism: look at the zoo of all the peripheral stuff out there
>and think if it is feasible (cool as it sounds) to put an all-new
>all-Lisp OS + window system straight on the raw hardware on at least
>two platforms (x86 and PPC) and support it for all the new devices that
>keep popping up? Linux and XFree86 crowd are doing just that, why not
>use that effort?  And that's a heck of a lot of effort--just look at
>EIDE stuff as an example and all the idiosyncrasies of individual
>chipsets (secondary interface problems of CMD640, for one).  The
>question is not even whether this is doable, the question is whether
>all this effort can go into doing something not yet done.

  This is why this project has always died in the past. The shear
number of broken pieces of hardware is daunting. That's also why I'm
not in a big hurry to throw Linux out from underneath a LispOS. I kind
of look at Linux (or Flux) as the Hardware Abstraction Layer. Let it
supply the common device drivers and let it deal with the buggy
hardware. We start by building on them and adding value, not redoing
what they've already done. Eventually, if enough other things get
accomplished and people are interested, then start rewriting the
drivers in Lisp. But that's a long time from now. That's not to
preclude someone who feels they really need a lisp based driver from
doing it. But let's not start by attempting to rewrite IDE and SCSI
and serial drivers.

  Mike McDonald
  mikemac@engr.sgi.com