[TUHS] Tracing origins of errno names/numbers

[TUHS] Tracing origins of errno names/numbers

[Michael Davidson]

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.

On Thu Mar 31st, 2011 7:51 PM PDT Nick Downing wrote:

>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?
>cheers, Nick
>
>On Fri, Apr 1, 2011 at 1:23 PM, Michael Davidson <
>michael_davidson at pacbell.net> wrote:
>
>> --- On *Thu, 3/31/11, Random832 <random832 at fastmail.us>* 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.
>>
>> Michael Davidson
>>
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>
>>

[TUHS] Tracing origins of errno names/numbers

[John Cowan]

Michael Davidson scripsit:

> 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.

A familiar tale: NeWS vs. X was exactly the same story, only with the players
reversed.

-- 
John Cowan  cowan at ccil.org   http://www.ccil.org/~cowan
Dievas dave dantis; Dievas duos duonos          --Lithuanian proverb
Deus dedit dentes; deus dabit panem             --Latin version thereof
Deity donated dentition;
  deity'll donate doughnuts                     --English version by Muke Tever
God gave gums; God'll give granary              --Version by Mat McVeagh

[TUHS] Tracing origins of errno names/numbers

[Larry McVoy]

If people wish to discuss RFS vs NFS, I was there are Sun when all this 
happened.

On Thu, Mar 31, 2011 at 08:26:04PM -0700, Michael Davidson wrote:
> 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.
> 
> On Thu Mar 31st, 2011 7:51 PM PDT Nick Downing wrote:
> 
> >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?
> >cheers, Nick
> >
> >On Fri, Apr 1, 2011 at 1:23 PM, Michael Davidson <
> >michael_davidson at pacbell.net> wrote:
> >
> >> --- On *Thu, 3/31/11, Random832 <random832 at fastmail.us>* 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.
> >>
> >> Michael Davidson
> >>
> >> _______________________________________________
> >> TUHS mailing list
> >> TUHS at minnie.tuhs.org
> >> https://minnie.tuhs.org/mailman/listinfo/tuhs
> >>
> >>
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

[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>