3B2/600 questions

[Ross Alexander]

In article <1989Nov15.155346.25197 at eci386.uucp> woods at eci386.uucp (Greg A. Woods) writes:
>In article <367 at ai.etl.army.mil> mike at ai.etl.army.mil (Mike McDonnell) writes:
>> 3. RFS comes with the computer.  Is NFS available from somewhere?
>Why would you want it?  :-)

I see the smiley, so you're somewhat off the hook.  Somewhat.  Could
you name vendors of RFS for (oh, let's see now...) Vax/VMS, SunOS (any
version at all), CDC NOS, or Apple Macintosh?  Dec Ultrix?  HP/Apollo?
IBM AIX or even (shudder) VM/CMS?  I see some real interoperability
problems here :-), not everyone is prepared to chuck their current
hardware after picking up a 3b2/<nnn>.  Of course, there's always BNS
(uucp to the unwashed :-).

I admit that many of these machines don't run un*x.  But as far as I
know, they will all run NFS (not always as servers, mind, and
corrections welcome.)  RFS is no speed daemon :-) either, and has real
problems when the server or client crashes.  I ran one for a while,
and every time we lost a node, I had to shut it down on all the
others, reboot the deader, and then start it up again all around the
net.

	And Now, the "Truth In Flaming" Section!!
	=========================================

I _do_ like the way RFS allows sharing periperals like tape drives.
That's really handy.  RFS does much more correctly support un*x
filesystem semantics.  It does locking without funky locking and
status daemons (lockd and statd).  It doesn't hand little suprise
gotcha's to the sysadmin (howz'about some filenames with '/' in the
the _path components_ :-).  It's just a pain in a multivendor
environment, that's all.  In a purely homogenous environment RFS is
Not A Bad Thing.

	r