[TUHS] RFS was: Re: UNIX of choice these days?

[Arthur Krewat]

Where does RFS (AT&T System III) fit in all of this?

I used it for a while between a SunOS 4.1.3 box and a PC running AT&T 
SVR4.2 (Consensys) because the client-side NFS was buggy on the SVR4.2 
side. This was in the days when I ran a UUCP node (kilowatt) in the 
early 90's and needed access from the PC to the "large" (5.25" FH 1GB) 
disk on the SunOS machine. It worked, that I can say.

Eventually, I swapped it around after getting an Adaptec SCSI controller 
for the PC - turned out the server-side NFS on this particular SVR4.2 
was fine.

Just looking for history on RFS if any.

thanks!

On 9/24/2017 1:33 PM, Clem Cole wrote:
>
> ​To me, the really important thing SMI did by giving away NFS, was to 
> start the FS laying argument.   What we ended up with is not perfect, 
> its a compromise (I wish the stacking model was better), but we 
> started to have the discussion.​   But because of NFS, we ended up 
> getting a lot of different file system options; which previously we 
> did not have.   It made us really think through what were 'meta' 
> functions that were FS independant, 'virtual' functions what span all 
> FS implementasions, and what were 'physical' (implementation) specific 
> file system functions.
>
> NFS really should be credited for forcing that clean up.
>
> Similarly, a few of us tried (and failed) to have the process layer 
> discussion -- consider the Locus vprocs work.   It's really too bad, 
> we don't have that layer in any of the UNIX kernels today, it really 
> make process control, migration, etc a lot cleaner; just as adding a 
> file system layer did.
>
> But that's a war, I fought and lost....
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170924/feb02688/attachment.html>