From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 13 Nov 2008 11:58:19 +0000 From: Eris Discordia To: 9fans@9fans.net Message-ID: <1BE1B1EB4747680F46DBCF43@[192.168.1.2]> In-Reply-To: <9cc55e0ca7b2b480446914487f33b6df@coraid.com> References: <473357B91DA2FB749BBEB805@[192.168.1.2]> <9cc55e0ca7b2b480446914487f33b6df@coraid.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [9fans] Do we have a catalog of 9P servers? Topicbox-Message-UUID: 40b9344a-ead4-11e9-9d60-3106f5b1d025 > you of course know that the big difference in unix and other > systems of the day was that files did not have type. this allowed > a tools-based approach which was popular for many years. Not that type of "types." I gave an example (which Charles Forsyth found to be a bad one) to set the types of "types" apart. I mean "types" as in named pipes ("special" files) versus regular files. In my experience which is limited to "modern" UNIX clones, i.e. Linux and *BSD, you can distinguish between a number of file "types" and decide what to do accordingly. You can tell a directory, from a (character or block) device, from a link, from a regular file. These same "types" could, and have been, be used to represent some details of the underlying resource. --On Wednesday, November 12, 2008 6:11 PM -0500 erik quanstrom wrote: >> Why shouldn't there be file "types" to >> help better represent the details of an underlying resource? > > you of course know that the big difference in unix and other > systems of the day was that files did not have type. this allowed > a tools-based approach which was popular for many years. > > - erik