[TUHS] RFS (was: Tracing origins of errno names/numbers)
Greg 'groggy' Lehey
grog at lemis.com
Fri Apr 1 15:59:38 AEST 2011
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
>>>> 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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
More information about the TUHS