symbolics vlm and other stuff

[DF@GLIDER.MACLAB.LONESTAR.ORG]

[ Apologies if anyone receives this and the next 2 messages twice, I
sent them out very early this morning and apparently they never made
it to the list.  Since I'm gatewaying my mail through a unix machine,
this isn't really much of a surprise.  *sigh* ]

Sadly, I don't have your original message, Andrew, so I had to rip it
bodily out of Mike MacDonald's reply.  Excuse if it is mangled.

    From: "Andrew J. Blumberg" <blumberg@ai.mit.edu>

    3) on the subject of lisp machines, i believe it is extremely important
    that everyone involved in the lispos implementation understand in detail
    why the lisp machine was so cool.  otherwise, you are doomed to rediscover
    the wheel.

I definately agree with this.  Founding a LispOS should not be done from
knowledge only of what AT&T and MicroShaft crocked together.  It is
imperative that we all not only have a good working knowledge of what
SMBX accomplished, but also what they failed to accomplish.
Unfortunately, I see no way for this to happen except actual exposure to
Genera.

Documentation is a big help though, and I know there are dozens of
Genera manual sets laying around unused (many still in shrink-wrap);
Maybe somehow we can locate people with unwanted Genera manuals and get
them, and distribute them to core LispOS people that havn't had any
actual experience with Genera?

Perhaps we can find some more ex-SMBX employees that are interested in
this project?  HBAKER is a good start, but there are hundreds of people
we might be able to draw on.

As a daily user of Genera, I would like to recommend we try and go
beyond what SMBX accomplished.  SMBX's failing was that they developed
many outstanding OS paradigms, but due to time/money constraints never
were able to reimplement many basic OS services using those paradigms.
Half the machine looks and feels like MIT 1980 and the other half like
the year 2036.  Schizophrenia!  (Of course, even MIT 1980 is so far
ahead of Unix 1997 that I want to weep for the computer industry).
        
The variable split-window scrolling of the S-Products Live Window is a
perfect example of something I dream were embedded in a normal Listener.

Back to more solid ground, file systems are an obsolete concept; even
LMFS looks archaic when you imagine a single-level persistent object
store with full rollback and roll-forward, with no difference between
`paging' and `files'.

    why solve problems that have already been solved?  make sure you know your
    history.  the unix folks didn't, and look where it got them.  for you
    virtual machine folks, take a look at the lisp machine microcode that the
    lisp ran on top of; this might provide some inspiration.

Inspiration we all need, but we cannot simply reimplement, we -must- go
beyond.  Not only is it a visionary requirement, but in many cases a
legal one, as much of SMBX's core technology is patented.
        
    to this end, i'll endeavor to see what i can do to make documentation
    available.  getting real machine time is harder; there aren't that many
    working lispm's available these days, although you could certainly buy the
    vlm if you have access to an alpha.

For a mere $18.5k, last I heard.

For as little as a few hundred dollars each, plus shipping expenses,
several L and G machines that I know of could be available to interested
parties.

(Hey you!  Hands off my 3640!  Did you see a for-sale sticker?)

These are just in my immediate area (Dallas, TX).  I'm sure there are
dozens more around the country that could go to good homes.


Yeah, I guess I primarily am interested in the idea of a REAL LispM,
above and beyond what even SMBX created.  I know it'll take a while to
get there, but does anyone disagree that this is the only proper future?
We can implement a kludge LispM on top of Linux or FreeBSD or whatever
for starters, but we should keep a path open for easy migration to a
clean LispM in the future...