A successful lisp machine?

Harvey J. Stein abel@netvision.net.il
Tue, 29 Apr 1997 22:52:16 +0300

Mike McDonald writes:
 >   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.

I'd go even further.  I don't want to only benefit from the hordes
adding hardware support.  I also want to benefit from the hordes
writing programs.  Why should I have to be in the postion of either
relying on a relatively small set of lisp hackers to give me the
applications I need, or having to develop them myself?  Just because
someone chose to write the application in C & it runs on Unix
platforms?  I don't want to have to reboot my lisp machine into native
linux mode just because I want to run xv or xsced or The gimp, or all
the other cool software that others are writing.

I thing the best bet is to:

   1. Start with Linux (or one of the free BSDs for that matter) + a
      lisp or scheme.
   2. Write a loadable kernel module and/or the kernel patches needed
      so that the lisp side doesn't have to fight the operating system.
   3. Keep the system unix compatible so that people can do C hacking
      & can use C apps at the same time as their lisp machine.

If this isn't done, then what I'm afraid will happen is that even if a
wonderful lisp machine is developed, the unwashed masses still won't
be able to use it as their primary operating system.

Remember why Linux/FreeBSD is successful.  There are large numbers of
programmers who would rather use unix than MS Windows.  They have PCs
because that's what they could afford, and they had to use MS Windows
on them.  Then high quality free versions of unix appeared.  The task
of generating these versions was relatively small because the FSF had
already written all the unix tools *and* the C library *and* the
compiler.  And, MIT gave away the source code for X.  And, tons of
programmers all over the world gave away the source code to all sorts
of cool programs.

All that was needed really was the kernel.  Not that this wasn't a lot
of work, but it was a *hell* of a lot *less* work than writing
everything from scratch.  And, because so much was already available,
a lot of people became excited about the whole endeavor, and added
device drivers for their hardware, and other hardware, etc.

For this whole LispOS project to succeed, I think it should leverage
as much as possible off of existing systems.  This would mean that it
should run on top of Linux or FreeBSD (preferably both) as much as
possible, and it should run on top of MS Windows if possible.  It'd be
great if it could also run on Java systems, since they're becoming so

But in any case, I think the worst thing one could possibly do is make
it a LispOS only system.  No one aside from die-hard Lispers will use
it.  No one will use all the great LispOS applications because they
can't afford to reboot every time they need to run TeX.  Trying to
recreate in Lisp all the programs that everyone wants to use just so
they don't have to reboot is a gargantuan task.  And there will always
be cool new programs for unix (or MS Windows) that need to be ported
and/or need LispOS equivalents.

So, start with a stock Linux and/or FreeBSD system.  Add the kernel
hooks necessary to make lisp run well.  Keep the interoperability.
Then, when some killer LispOS applications come around, people will be
able to run them without converting there systems to LispOS.

Of course, this doesn't preclude rewriting some of the uglier user
space programs to run under LispOS.  As Martin Cracauer pointed out,
the LispOS environment could do a much better job of running some of
the standard unix apps than unix.  Sendmail, startup configuration,
and httpd all come to mind.

Harvey J. Stein
Berger Financial Research