🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.unix
Article #608

Re: Unified I/O namespace: what's the point?

#608
From: Peter da Silva
Date: Fri, 12 Oct 1990 00:26
56 lines
2967 bytes
Submitted-by: peter@ficc.ferranti.com (Peter da Silva)


In article <13441@cs.utexas.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
> In article <13392@cs.utexas.edu> chip@tct.uucp (Chip Salzenberg) writes:
> > It is true that interactive use of UNIX, especially by programmers,
> > puts a lot of emphasis on the shell interface.  If such an environment
> > were all there were to Unix, then Dan's fd-centric view of the world
> > could possibly be useful.

> The success of UNIX has proven how useful this ``fd-centric'' view is.

Not at all. You can equally argue that it proves how useful the "unified
name space" view is, because *that* is another of the features that marks
UNIX as something new. Or that it proves the "filter" concept, or any of
the other things that *as a whole* go to making UNIX what it is.

UNIX is synergy.

> This is also unfounded. My TCP connectors provide a counterexample to
> your hypothesis (that the shell must handle everything and hence be
> recompiled) and your conclusion (that fd-centric UNIX doesn't work).
> Any programming problem can be solved by adding a level of indirection.

OK, how do you put your TCP connectors into /etc/inittab as terminal
types? Or into /usr/brnstnd/.mailrc as mailbox names? Or into any other
program that expects filenames in configuration scripts (remember, not
all scripts are shell scripts).

> A unified namespace has several great disadvantages: 1. It provides a
> competing abstraction with file descriptors,

No, it adds a complementary abstraction to file descriptors. In fact, a
unified name space and file descriptors together form an abstraction that
is at the heart of UNIX: everything is a file. A file has two states: passive,
as a file name; and active, as a file descriptor.

> This will result in a confused system, where some features are available
> only under one abstraction or the other.

Which is what you seem to be advocating.

> A unified namespace has not been tested on
> a large scale in the real world, and hence is an inappropriate object of
> standardization at this time.

I would like to suggest that UNIX itself proves the success of a unified
namespace.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com



Volume-Number: Volume 21, Number 200
Technical Details
Message-ID: <13505@cs.utexas.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!fletcher
References: <13220@cs.utexas.edu> <13343@cs.utexas.edu> <13390@cs.utexas.edu> <13392@cs.utexas.edu> <13441@cs.utexas.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!fletcher
From: peter@ficc.ferranti.com (Peter da Silva)
Newsgroups: comp.std.unix
Subject: Re: Unified I/O namespace: what's the point?
Message-ID: <13505@cs.utexas.edu>
Date: 12 Oct 90 00:26:19 GMT
References: <13220@cs.utexas.edu> <13343@cs.utexas.edu> <13390@cs.utexas.edu> <13392@cs.utexas.edu> <13441@cs.utexas.edu>
Sender: fletcher@cs.utexas.edu
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 56
Approved: fletcher@cs.utexas.edu (Guest Moderator, Fletcher Mattox)
X-Submissions: std-unix@uunet.uu.net