Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!SAPSUCKER.SCRC.SYMBOLICS.COM!Margulies From: Margulies@SAPSUCKER.SCRC.SYMBOLICS.COM.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: Need information on NFS Message-ID: <861225195214.5.MARGULIES@REDWING.SCRC.Symbolics.COM> Date: Thu, 25-Dec-86 19:52:00 EST Article-I.D.: REDWING.861225195214.5.MARGULIES Posted: Thu Dec 25 19:52:00 1986 Date-Received: Fri, 26-Dec-86 02:37:47 EST References: <8612250637.AA05517@seismo.CSS.GOV> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 90 Approved: tcp-ip@sri-nic.arpa Date: Thu, 25 Dec 86 17:26:30 EST From: munnari!kre@seismo.CSS.GOV (Robert Elz) In <861224142645.6.SNED@MEADOWLARK.SCRC.Symbolics.COM> sned@PEGASUS.SCRC.Symbolics.COM wrote a lot of nonsense, followed by one seemingly correct statement... I'll leave it to steve to comment on the ad hominem nature of this little flame, save to point out that it is offensive in the extreme. Too bad we don't have politeness police. Slander and libel do exist, and electronic mail is no license for them. I'll concentrate on technical aspects. However, I will warn Mr. Elz of this: Steve worked on UN*X for quite a while in his career, and is eminently qualified to comment. > As I see it, the problem is really the lack > of support for anything but UN*X filesystem syntax in UN*X. Since Unix filename syntax is a sequence of chars terminated by a null (some systems have a maximum length, generally not less than about 1024 bytes), its hard to see how this is much of a problem. Consider TOPS-20 directory structure, VM/CMS mini-disks, file system that permit "/" characters in their filenames, or especially file systems (like VMS and VM/CMS) that have structured (non-byte stream) files. None of them map very quietly into a hierarchical set of directories separated by "/" characters, and there are more and harder where they came from. This is my-file-system-centrism. Why should a workstation impose a single model of a file system on all of the machines it talks to over the network? If I am a workstation users, and a user of a VMS system sends me mail with a pathname in it, why is it good that I have to know how to translate it into UN*X ese? The only good that I know is that it allows existing UN*X applications, born and bred in a homogeneous environment, to access files on foreign systems. I'm not opposed to this. Steve isn't opposed to this. Symbolics isn't opposed to this. We just note that it imposes some limitations, like the ones reported by Kasdan. > By the way, it's interesting that Lisp Machines, which were designed > from the beginning to be used as workstations on a network, adopted the > pathname syntax of host:string-for-host for 'open'. UN*X, which was > designed as a self-contained system, has to indirectly chop a local > pathname, in UN*X pathname syntax, into host and string-for-host via > Special Files and Mount Tables. What a load of rubbish. There have been mny RFS's for Unix at various times. Many early ones adopted some form of "host:string" syntax for remote file names, they ALL died (or have been forgotten), because that's a REVOLTING method for naming remote files. That means that someone has to know that the files is remote to build that filename, and what's worse has to know which host the file lives on. Unix implementations don't use mount tables, etc, because that's the only way it can be done, or even because its the easiest way it can be done. Just the opposite, its MUCH easier on unix to implement a "host:string" syntax - an average unix kernel programmer could do one of those (clients) (given existing network code) in an easy afternoon. The mount table mechanism is used because it gives the right semantics - host names aren't built as a part of the syntax of a filename, they're derived by a level of indirection that makes it easy to alter the configuration (you can move local files to a remote host without having to change any uses of the filenames at all). This paragraph neatly details my point above: mapping everything to UN*X syntax is a lot easier on UN*X applications than changing them all to handle a pathname representation designed to facilitate operations in a heterogeneous environment. As it happens, the Symbolics environment represents pathnames and file system operations in a way that is optimized to heterogeneous environments. That was a design goal of ours, it wasn't of UN*X. I'm not going to comment on Lisp machines, as I've never used one. From all reports they have a lot of nice attributes, but if Symbolics standard of employees is confined to "we're right, nothing else comes close" parrots then I don't have much hope for their continued success. Mr. Elz, please note the history of this conversation. Someone from DEC sent mail criticizing NFS for, in a manner of speaking, UN*X-centrism. Steve \DEFENDED/ NFS, pointing out that the problem was merely the small funnel of the pathname syntax (and the lack of semantics for structured files), and not a fundamental flaw in the protocol as compared to NFILE. I hardly call that corporate chauvinism. If you are going to run about tossing tomatoes like that one, best to be sure you read your from lines. Benson I. Margulies