Path: utzoo!attcan!uunet!usenix!jsq From: chip@tct.uucp (Chip Salzenberg) Newsgroups: comp.std.unix Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions Message-ID: <553@usenix.ORG> Date: 27 Sep 90 20:03:39 GMT References: <524@usenix.ORG> <528@usenix.ORG> <540@usenix.ORG> Sender: jsq@usenix.ORG Organization: Teltronics/TCT, Sarasota, FL Lines: 26 Approved: jsq@usenix.org (Moderator, John Quarterman) X-Submissions: std-unix@uunet.uu.net Submitted-by: chip@tct.uucp (Chip Salzenberg) According to brnstnd@kramden.acf.nyu.edu (Dan Bernstein): >On the contrary: Given file descriptors, the filesystem is an almost >useless abstraction. Characterizing the Unix filesystem as "almost useless" is, frankly, hogwash. A hierarchical filesystem with mount points is a simple, yet powerful, organizational tool. To get back to the original point of this thread, one of my primary complaints about the System V IPC facilities is that they all live in a flat namespace. There is no way for me to create a subdirectory for my application, with naturally named IPCs within that directory. Such hierarchical division is "almost useless?" Hardly. >Many of us are convinced that open() and rename() and unlink() and so on >are an extremely poor match for unreliable or dynamic or remote I/O. Given Unix, where devices -- even those with removable media -- are accessed through the filesystem, I can see no reason whatsoever to treat network connections and other IPC facilities differently. -- Chip Salzenberg at Teltronics/TCT , Volume-Number: Volume 21, Number 141