Symbolics prices (not only in Europe)

[Reti@STONY-BROOK.SCRC.Symbolics.COM (Kalman Reti)]

    Date: Wed, 28 Aug 1991 17:16 EDT
    From: Barry Margolin <barmar@Think.COM>

	Date: Wed, 28 Aug 1991 14:52 EDT
	From: Kalman Reti <Reti@STONY-BROOK.SCRC.Symbolics.COM>

	My point is that you can't compare a workstation where you can't do the types of
	things you can do on a Lispm based only on the things that you can do on both,
	i.e. the lowest common denominator isn't a valid basis of comparison.

    One problem that is routinely dismissed is that there are many things
    you can do on the cheap workstations that you *can't* do on a Lispm.
    Thus, it is often necessary to have both (I spend a good deal of my time
    using the Lispm's X server to interact with Unix programs), and it can
    frequently be quite difficult to convince a bean-counter that two
    workstations are more cost-effective than one.

    What can't a Lispm do, you ask?  It can't run the thousands of
    commercial and publicly-available programs that are available for Unix
    systems, Macs and PC's.  
Yes, but there is no single workstation that can run the thousands of
commercial and publicly-available programs that are available for Unix
systems, Macs AND PC's.  If you have a Mac-only program, you need a Mac
to run it (or a Mac emulation package).  Ditto for a PC-only program. 
Only for Unix programs do you have a choice of workstations, and even their
there are often problems (albeit minor) of big-endian vs little-endian,
System V vs BSD vs vendor-specific Unices, etc.

In fact, often the most cost-effective solution IS to have multiple workstations,
one for each type of incompatible program you are trying to run.

(My facetious suggestion of porting Unix to run under Genera would allow for
solve the Unix-system part of the problem.  This isn't as bad an idea as it
sounds; when we ported several VLSI tools to the Symbolics C the type-checking
found several unitialized variable-style bugs which would have caused wrong
answers on traditional architecture machines.)

			     The embedded Lispms solve this problem to some
    extent, but there's still a $30K price tag on top of the cost of the
    original workstation.  There's quite a bit of value in standard OSes,
    even de facto standards.
I don't contest that.

    Also, some of the things it can do, it doesn't do very well.  Genera
    includes file system and server software, but I've spent quite a bit of
    effort moving as much stuff as I can off my 3650's disks.  LMFS has some
    nice features (it's great being able to put the file server process into
    the debugger, or to install patches to the LMFS or file server
    software), but they don't make up for the robustness and performance of
    a Sun, even ones of comparable vintage (we installed some Sun-4/280 file
    servers the same year we upgraded our Lispm file server from a 3600 to a
    3650).
Actually, I'd had much greater success recovering data on LMFS file systems
than on Unix file system in the face of hardware errors or crashes.  I recently
had a system where, occasionally, if you asked for block N from the disk you got
block X, without any error indication.  Not only did LMFS survive this
broken hardware without loss of data, it prevented every and all application
programs reading data from getting erroneous bits.  I have never seen another
file system for which you can say the same.

I admit, there are performance problems and there could be improvements in
reliability and robustness in many of the I/O related aspects of the Lisp
machine, that's been one of my hobby horses ever since I arrived at the
company.  But things HAVE gotten better, and the level of awareness of
the importance of mundane things like I/O has never been higher within the
company, so I expect even further improvements.

						    barmar