[TUHS] RFS (was: Tracing origins of errno names/numbers)

[Greg 'groggy' Lehey]

On Thursday, 31 March 2011 at 20:40:23 -0700, Larry McVoy wrote:
> On Thu, Mar 31, 2011 at 08:26:04PM -0700, Michael Davidson wrote:
>> On Thu Mar 31st, 2011 7:51 PM PDT Nick Downing wrote:
>>> On Fri, Apr 1, 2011 at 1:23 PM, Michael Davidson wrote:
>>>
>>>> EDOTDOT caught my eye for some reason - maybe because it's the only one
>>>> you attributed to linux in a long list of SVr1 ones... what were 72
>>>> through 76 in SVR1?
>>>>
>>>> As the comment indicates, EDOTDOT came from "RFS" - the almost never used
>>>> "remote file system" that was (optionally, I think) part of System V Release
>>>> 3.
>>>>
>>>> As best I can recall, that is also where several of the other error numbers
>>>> in the 72 - 79 range probably came from.
>>>
>>> I also looked up EDOTDOT and found reference to RFS but not much info about
>>> it.  Why was it not used?  Not reliable enough?  I have often thought that
>>> the stateless, idempotent NFS protocol leaves a lot to be desired due to its
>>> inability to implement unix semantics (as discussed in the wikipedia stub
>>> article on RFS), has this been improved with NFS4?  Should RFS be revived
>>> and used?  Some of its features sounded quite attractive (location
>>> transparency, etc).  It does appear to have the ability to execute a program
>>> remotely??  What happens with regard to PIDs, home directory etc in this
>>> case?  Does anyone know?
>>
>> Regardless of its technical merits (and I suspect that the
>> implementation may have been pretty bad) RFS was doomed by AT&T's
>> licensing policies and general ineptitude at marketing UNIX.
>> Similarly the widespread adoption of NFS was driven by the fact that
>> Sun made it a de facto standard.
>
> If people wish to discuss RFS vs NFS, I was there are Sun when all
> this happened.

Go ahead!  I have always wondered what was wrong with RFS, though I
suppose a Sun employee might have a slightly close perspective.

Greg
--
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  See
http://www.lemis.com/grog/email/signed-mail.php for more details.
If your Microsoft MUA reports problems, please read
http://tinyurl.com/broken-mua
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20110401/a5a24f2a/attachment.sig>