Re: SUN vs Lisp machine hardware differences?

[Chris Lindblad <CJL@reagan.ai.mit.edu>]

    Date: Thu, 30 Jul 87 12:54 EDT
    From: James Larus <larus%paris.Berkeley.EDU@berkeley>

    ...

    What does the IP/TCP standard say?  Should a machine complain about
    messages on a wire that it does not understand?

I don't know.

	 - Example: 4.2 BSD finger server not accepting requests for whois informat
	ion
	 with the /W following the username, but requiring it to preceed the userna
	me,
	 even though every other operating system allows the /W to follow the name.
	 The
	 Lisp Machine is blamed for not being able to whois people on UNIX machines
	.

    Every other operating system refers to which ones?

TOPS20 handles the /w after the name

WAITS at least recognizes the /w after the name as a switch, and just warns
that the switch is ignored.

ITS handles the /w after the name.

All Lisp Machine implementations descended from MIT system 78 handle the /w
after the name.

I don't know of any VMS implementatiom that I can test this under.

	 -Example: 4.2 BSD FTP server returning bogus response codes. The Lisp Mach
	ine
	 is blamed for complaining about it. Speaking of transparent file access
	 through the Internet standard FTP protocol, does any other operating syste
	m
	 provide this feature, or do you have to rely on a proprietary protocol
	 promoted as a "de-facto standard" by the marketing department of the compa
	ny
	 that came up with the protocol, all as part of their support of "standards
	".

    If I remember correct, the LISPM's way of "complaining" about this
    problem was to dump me into the cold load stream.

Not really. More like just entering the debugger:

  :Delete File 1(file [default WH:/wh/cjl/*]) 0WH:/wh/cjl/loss.rel7.~1~
2Error: Unknown response from foreign host: 200 DELE command okay. (expecting 250).

(DEFUN-IN-FLAVOR FS:TCP-FTP-CHECK-COMMAND-RESPONSE FS:TCP-FTP-CONN)0:
   Arg 0 (SELF): #<TCP-FTP-CONN 31506255>
   Arg 1 (SYS:SELF-MAPPING-TABLE): #<Map to flavor FS:TCP-FTP-CONN 2156645>
   Arg 2 (FS:EXPECTED-VALUE): 250
   Arg 3 (FS:CTL-STRING): "DELE ~A"
   Rest arg (ZL:ARGS): ("/wh/cjl/loss.rel7.~1~")

 From which all you have to do is return from the error with c-r (after
informing the maintainer of the FTP server that it is returning invalid
response codes, of course).  

    I was afraid that my remark quoted above would lead to a discussion of
    this sort.  I really shouldn't have said it, though I guess that most
    everyone with VAXen, Suns, and LISPMs have thought it at one time or another.

We have a variety UNIX boxes and other hardware on our network too, and we
don't have many problems talking to them. I am willing to concede that the
Lisp Machine has bugs in it, but UNIX based network implementations are buggy
too.  Just because the one Lisp Machine you have connected on an ethernet
can't talk to the UNIX running on the VAXen and the Suns, doesn't mean that
the Lisp Machine network implementation is the only one in error.  All it
means is that the Lisp Machine implementation can't talk to the UNIX
implementation.  Just as Symbolics should be testing their code against UNIX
implementations (and ITS, and TOPS-20, and VMS), UNIX vendors should test
their code agains other implementations (like Symbolics).

This seems to me to be pretty much a MIT vs Berkeley argument about which is
the more broken operating system, and it is a healthy discussion, provided
that one takes the other's opinions seriously. I agree with Gumby that the
Symbolics Network implementation is easy for which to program, and has few
bugs.  I concede that in an environment where there aren't as many Lisp
Machine hackers, the lisp machines may be less reliable. But isn't that also
true for UNIX machines?  I will not concede that anyone who suggests that the
Lisp Machine networking system is better than the UNIX networking system must
be joking.  Not everyone agrees that the superiority of UNIX over everything
else is obvious.