[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


   Why doesn't vendor X support Symbolics's protocol is another question?

Because Symbolics is completely insignificant, as far as they are
concerned.  And Symbolics doesn't document many of their proprietary
protocols (for instance, I don't think there's documentation for the
CONVERSE protocol).  Vendors generally support their own protocols and
industry (or de facto) standard protocols; Symbolics's protocols are
rarely standardized (ARP is the notable counterexample -- it was
developed by David Plummer et al at Symbolics).

   Is it too hard to write the code on their system to talk to Symbolics

In general -- yes.  Symbolics's network programming interfaces are
probably one of the easiest to use.  Certainly better than sockets.

   If "The network is the computer", then why are some vendor's machines
   so buggy in security against the network?

Because network security is a hard problem to solve, and most computer
vendors aren't very interested in security in general.

Don't forget, Zmail used to parse some parts of mail headers using
READ, before they had a simple facility for turning off "#.".  This
was the ultimate trap door -- you could send someone mail that would
cause them to execute arbitrary Lisp code when they read it.

Sure, they fixed it eventually.

By the way, the "Secure Subnets" feature of Symbolics software isn't
safe against attacks from insecure workstations (e.g. Lispms or
personal computers).  It depends on the veracity of the source address
in received packets, but forging source addresses is easy (this is
generally only useful for one-way protocols, because responses will be
sent to the true owner of the address).