From lyndon@aupair.cs.athabascau.ca Fri Jun 14 19:45:12 1991 Received: from aupair.cs.athabascau.ca by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA11943; Fri, 14 Jun 91 19:45:12 +0200 Received: by aupair.cs.athabascau.ca (/\==/\ Smail3.1.20.1 #20.30) id ; Fri, 14 Jun 91 11:43 MDT Message-Id: To: erik@sra.co.jp Cc: iso10646@jhuvm.bitnet, ietf-822@dimacs.rutgers.edu, unicode@sun.com, i18n@dkuug.dk Subject: Re: data announcement In-Reply-To: Your message of "Fri, 14 Jun 91 23:08:58 +0900." <9106141409.AA12638@sran8.sra.co.jp> Date: Fri, 14 Jun 91 11:43:57 MDT From: lyndon@cs.athabascau.ca X-Charset: ASCII X-Char-Esc: 29 > > And pray tell, what header lines do you put at the beginning > > of executable files?, > You just put some header lines that indicate that this file is an > executable file, and some information to distinguish it from > executable files for other hardware vendors' machines or even > different versions of the same vendor's systems. But that information is already in the inode - it's called the 'x' bit. And what about magic number (like 403) that tell the kernel not only that this is an executable file, but that it may or may not be demand paged, etc? This is completely re-inventing the wheel. > You just name the database system. You might put "Oracle", together > with the version number. And this too can already be handled by Unix: % cat foo #!/usr/local/bin/oracle . . . What do you propose to put at the head of files like /dev/tty? Nothing? You still have to deal with the "blank line" that seperates the non-existent headers from the "body" of the file. How are you going to explain this one to passwd(1)? Or /dev/tty? Who is going to rewrite every existing application to deal with these new "headers" ? What you are describing is a way to deal with GUI defaults (unless I'm completely mistaken). This sort of thing has no business being added to the file system - it belongs in the GUI. As it stands right now, the file manager application has no problem dealing with this sort of thing - it already understands "magic numbers" in files, is extensible by the end user, and you can tell it about "default" data files in its .rc files. Please don't mess up the most simple and elegant file system around just because your applications software is to lazy to do any work on its own.