Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!zephyr!tektronix!percival!parsely!sopwith!snoopy
From: snoopy@sopwith.UUCP (Snoopy)
Newsgroups: comp.unix.wizards
Subject: Re: What kinds of things would you want in the GNU OS?
Keywords: GNU OS features kernel fun!
Message-ID: <208@sopwith.UUCP>
Date: 4 Jun 89 18:01:28 GMT
References: <106326@sun.Eng.Sun.COM> <4315@ficc.uu.net> <338@arc.UUCP>
Reply-To: snoopy@sopwith.UUCP (Snoopy)
Organization: The Daisy Hill Puppy Farm
Lines: 40

In article <338@arc.UUCP> steve@arc.UUCP (Steve Savitzky) writes:

|For networking I rather like the way Apollo handles a networked name
|space (it's about the ONLY thing to like about Apollo :-) -- Root is /
|and the network layer above it is //, so a complete pathname looks
|like (e.g.) //steve/usr/bin
|
|IMHO this is better than the way NFS does it (i.e. mounting
|filesystems in random places) -- everything is in exactly one place in
|the hierarchy.

UTek's DFS also uses the leading // syntax.  I like the idea of the
network being a "superroot" very much.  It's a very nice way of thinking
about it.  The namespace is orthogonal, all machines appear at the same
level.  The conventional absolute pathname can be thought of as a relative
pathname beginning at the local machine.  Rob Pike and others have
advanced arguments that this sort of thing is abuse of the syntax.
These arguments shouldn't be taken lightly.  In practice, the // syntax
works very well, I have run into 0 problems in 4.5 years of using it.
What we *really* need to avoid is a requirement of mounting filesystems
from remote machines in order to access them.  It should be possible to
develop a system using, say the /n/host/ syntax that doesn't require
mounting filesystems all over creation.  Being able to select stateful
or stateless behaviour on a per file descriptor basis ( flag in the open()
call? ioctl()? ) would be nice.  Whatever syntax is chosen, it should be
possible for an unprivileged user to do the equivalent of:

	ln -s //somehost/usr/foo/bar bar

The abilities to allow remote access on a per-account basis, and to
translate hostA,user1 into localhost,user2 on a per-host, per-user
basis are also important.

    _____     						  .-----.
   /_____\    Snoopy					./  RIP	 \.
  /_______\   qiclab!sopwith!snoopy			|  	  |
    |___|     parsely!sopwith!snoopy			| tekecs  |
    |___|     sun!nosun!illian!sopwith!snoopy		|_________|

		"I *am* the next man!"  -Indy