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: