Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!amdahl!ames!sri-spam!rutgers!gatech!emory!arnold
From: arnold@emory.uucp (Arnold D. Robbins {EUCC})
Newsgroups: comp.unix.wizards
Subject: Re: named pipes?
Message-ID: <2299@emory.uucp>
Date: Mon, 2-Nov-87 12:30:42 EST
Article-I.D.: emory.2299
Posted: Mon Nov  2 12:30:42 1987
Date-Received: Fri, 6-Nov-87 04:43:10 EST
References: <15973@topaz.rutgers.edu> <507@riddle.UUCP>
Reply-To: arnold@emory.UUCP (Arnold D. Robbins {EUCC})
Organization: Math and Computer Science, Emory University, Atlanta GA
Lines: 22

In article <507@riddle.UUCP> domo@riddle.UUCP (Dominic Dunlop) writes:
>AT&T has made something of a big deal of the fact that RFS supports access
>to FIFOs on remote processors, making them very useful for the simple
>implementation of remote execution daemons and such -- you can even do it
>with shell scripts.  Of course, distributed applications written this way
>won't currently port to the BSD universe...

AT&T aren't the only ones though. Systems with NFS 3.2 and later also support
SVID compatible FIFOs and remote FIFOs.

I don't really wish to start (another) round of NFS vs. RFS wars; RFS has
two major advantages: 1) remote devices, 2) availablity for free on all the
V.3 '386 boxes. NFS is much more widely available on larger Unix machines and
can be supported on non-Unix OS's (c.f. TWG's VMS port).

I can't help but imagine that some future release of NFS will have remote
device support, as well.
-- 
Arnold Robbins
ARPA, CSNET:	arnold@emory.ARPA	BITNET: arnold@emory
UUCP: { decvax, gatech, }!emory!arnold	DOMAIN: arnold@emory.edu (soon)
	``csh: just say NO!''