erik@sra.co.jp (Erik M. van der Poel) (06/20/91)
On the Macintosh, it is possible to double click on the icon that represents a file to invoke the application associated with that file. It is difficult to build a GUI (graphical user interface) to do the same for Unix systems, since Unix does not offer a standard way of attaching an application name to a file. It is almost possible to create a Mac-like interface on Unix, but this involves incredibly convoluted methods such as keying off of the name of the file, or checking the contents of the file for certain known properties of an application's files. Again, there are no standards in this area. Unix needs to be extended to allow attaching all sorts of attributes to files. The inode is not extensible. The attributes could be stored within the file itself, for example at the beginning. However, this would upset lots of programs that assume that the file is the data itself, just a stream of bytes, with no standard attributes attached. So we need a new system call, say, mopen(), which opens a file that contains attributes such as the application name. This would allow old programs to continue to use open() to access the data itself. The stat() call would also be left unchanged. The size of the attributes file could be determined by calling fstat() on the file descriptor returned by mopen(). This means that we need two inode structures to be associated with each file. This could be implemented by assigning two adjacent inodes to each file. E.g. the odd one always points to the data itself, while the even one points to the attributes. In order to make good use of such an attributes file, however, we need to standardize its contents. We could use object identifiers that are registered internationally for this purpose. Comments? - -- Erik M. van der Poel erik@sra.co.jp Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692
jmason2@gpu.utcs.utoronto.ca (Jamie Mason) (06/20/91)
No. You don't need a new system call. exec() does just fine. You just need smarter applications. Unix already has the facility you mention. Let's say you have a shell script. You want it to be run by the Bourne shell. So you put as the first line: #!/bin/sh Let's say you have a mailbox, and you want it to be read by /usr/ucb/mail. You put as the first line: #!/usr/ucb/mail -f Then you chmod them to be executable. When you exec() them, the Kernel gets the message, and starts the right program. Unfortunately, in the second case, Mail does not understand what the #! is doing at the begining of its file, and it gets pissed off. Mush, on the other hand, quietly ignores it, and works fine. Mush, however, does not write this line back out at the beginning of the file, so you end up with an executable file with no #!. So you see, we *don't* need a new system call, we just need utilties which consider an initial #! line to be sacred. It is ignored on input, even if # is NOT a comment character, and it is rewritten intact on output. Mail programs might even GENERATE a #! with their own name when they write NEW mailboxes, etc... *Please* don't bloat the kernel with features that belong in user mode. Jamie ... Lurker in the Process Table Written On Wednesday, June 19, 1991 at 10:14:52pm EDT
dpassage@soda.berkeley.edu (David G. Paschich) (06/20/91)
In article <1743@sranha.sra.co.jp> erik@sra.co.jp, (Erik M. van der Poel) writes: It is almost possible to create a Mac-like interface on Unix, but this involves incredibly convoluted methods such as keying off of the name of the file, or checking the contents of the file for certain known properties of an application's files. Again, there are no standards in this area. Unix needs to be extended to allow attaching all sorts of attributes to files. The inode is not extensible. [stuff removed by dgp] So we need a new system call, say, mopen(), which opens a file that contains attributes such as the application name. This would allow old programs to continue to use open() to access the data itself. The stat() call would also be left unchanged. The size of the attributes file could be determined by calling fstat() on the file descriptor returned by mopen(). I think a better solution than extending the Unix file system in this way would be to create a file, named say .desktop (or something more clever to avoid lawsuits :) which would contain this information, and then writing some library calls which would maintain this information and make it available to programs. This also makes the code a lot more portable since it doesn't rely on the particular Unix providing the facilities you describe. -- David G. Paschich Open Computing Facility UC Berkeley dpassage@ocf.berkeley.edu "Can Spam increase sexual potency? `No!' say scientists!" -- Trygve Lode
boyd@prl.dec.com (Boyd Roberts) (06/20/91)
In article <1743@sranha.sra.co.jp>, erik@sra.co.jp (Erik M. van der Poel) writes: > On the Macintosh, it is possible to double click on the icon that > represents a file to invoke the application associated with that file. > It is difficult to build a GUI (graphical user interface) to do the > same for Unix systems, since Unix does not offer a standard way of > attaching an application name to a file. > Uh... Haven't you seen SCO's Open Desktop? It does just this, but without (I hope) any gruesome kernel hacks. The last thing we need is more system calls. Boyd Roberts boyd@prl.dec.com ``When the going gets wierd, the weird turn pro...''
jpe1@PL118f.pl118g.cc.lehigh.edu (This space 4 rent) (06/20/91)
In article <1743@sranha.sra.co.jp> erik@sra.co.jp (Erik M. van der Poel) writes:
On the Macintosh, it is possible to double click on the icon that
represents a file to invoke the application associated with that file.
It is difficult to build a GUI (graphical user interface) to do the
same for Unix systems, since Unix does not offer a standard way of
attaching an application name to a file.
[unnecessary new system call discussion deleted]
Comments?
-
--
Erik M. van der Poel erik@sra.co.jp
Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692
Um, I think that many GUIs have this already. For example, under the Sun
Openwindows (version 2) filemanager, data files can be typed using the output
from file(1) or by the name of the file itself, and then the proper application
is called. In my environment, files ending in .c, when double-clicked, bring
up emacs in c-mode, file in buffer. Files that file(1) reports as being
postscript, when double-clicked, bring up the postscript previewer. The
file command has all the power to extend this to work on, say, RMAIL files.
John.
----------------------------------------
John Early |
JPE1@PL118a.cc.lehigh.edu | I was just a child then;
JPE1@Lehigh.Bitnet | now I'm only a man. [pf]
JPE1@ns.cc.lehigh.edu |
jearly@lehi3b15.csee.lehigh.edu |
LUJPE@VAX1.cc.lehigh.edu |gwyn@smoke.brl.mil (Doug Gwyn) (06/21/91)
In article <1991Jun20.085530.24353@prl.dec.com> boyd@prl.dec.com (Boyd Roberts) writes: >In article <1743@sranha.sra.co.jp>, erik@sra.co.jp (Erik M. van der Poel) writes: >> On the Macintosh, it is possible to double click on the icon that >> represents a file to invoke the application associated with that file. "THE" application associated with that file? That is so totally wrong that you should be ashamed for mentioning it in the UNIX WIZARDS group.
klaus@cnix.uucp (klaus u schallhorn) (06/21/91)
In article <DPASSAGE.91Jun20001100@soda.berkeley.edu> dpassage@soda.berkeley.edu (David G. Paschich) writes: >In article <1743@sranha.sra.co.jp> erik@sra.co.jp, > (Erik M. van der Poel) writes: > > It is almost possible to create a Mac-like interface on Unix, but this > involves incredibly convoluted methods such as keying off of the name > of the file, or checking the contents of the file for certain known > properties of an application's files. Again, there are no standards in > this area. Unix needs to be extended to allow attaching all sorts of > attributes to files. The inode is not extensible. > >[stuff removed by dgp] > >I think a better solution than extending the Unix file system in this >way would be to create a file, named say .desktop (or something more >clever to avoid lawsuits :) which would contain this information, and >then writing some library calls which would maintain this information >and make it available to programs. This also makes the code a lot >more portable since it doesn't rely on the particular Unix providing >the facilities you describe. > What's wrong with file(1) and a proper /etc/magic table? mine is 111 lines and recognises all the file types I care about. As an aside, a system's usefulness will be highly impaired by forcing users to use program x with files of type y. That may be permissible on MacChickenBurger Boxes but not on my systems. klaus schallhorn -- George Orwell was an Optimist
scotts@qsp.COM (Scott Simpers) (06/21/91)
In article <1991Jun20.085530.24353@prl.dec.com> boyd@prl.dec.com (Boyd Roberts) writes: >In article <1743@sranha.sra.co.jp>, erik@sra.co.jp (Erik M. van der Poel) writes: >> On the Macintosh, it is possible to double click on the icon that >> represents a file to invoke the application associated with that file. >> It is difficult to build a GUI (graphical user interface) to do the >> same for Unix systems, since Unix does not offer a standard way of >> attaching an application name to a file. >> > >Uh... > >Haven't you seen SCO's Open Desktop? It does just this, but without (I hope) >any gruesome kernel hacks. The last thing we need is more system calls. > > >Boyd Roberts boyd@prl.dec.com > >``When the going gets wierd, the weird turn pro...'' I hate to disappoint folks, but SCO's open desktop is really IXI's X.desktop. It and Looking Glass both provide UNIX GUI's which do what you want. There's absolutely nothing wrong with checking magic numbers, etc. to find out the type of a file. I believe X.desktop does this on the fly. Looking Glass, on the other hand, uses the previously mentioned ".desktop" method by creating a .lgdb file in each directory it visits. This contains info on all the files in the directory. So, if you have an eXclaim! worksheet, you can double click on the icon representing the file, and it will run eXclaim! on that file. Same thing for Frame Maker. So, please, no kernel hacks and no "smart files". The problem has already been solved in 2 fairly reasonable ways. -- Scott Simpers | All my opinions are my own, nobody else Quality Software Products | wants them! 5711 W Slauson Avenue Suite 240 +---------------------------------------- Culver City, CA 90230 scotts@qsp.com
erik@srava.sra.co.jp (Erik M. van der Poel) (06/21/91)
> Let's say you have a mailbox, and you want it to be read by > /usr/ucb/mail. You put as the first line: > #!/usr/ucb/mail -f What if I have an ordinary text file (say, a README)? Some people like to use `less', some people use `vi', and yet other people use `emacs'. The README file may be accessed by many different people, since Unix is a multi-user system. In this case (i.e. README), it might be better to just say that this is a text file, in the file attributes (i.e. the metadata (the data is the file itself)). Then the `user agent' can look at the metadata, and do the right thing, which may depend on the user's preferences. > Unfortunately, in the second case, Mail does not understand what > the #! is doing at the begining of its file, and it gets pissed off. Indeed. Many programs will suddenly stop working if we start adding standardized metadata to the files themselves. That's why we need the new system call. - -- Erik M. van der Poel erik@sra.co.jp Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (06/21/91)
erik@sra.co.jp (Erik M. van der Poel) writes: | On the Macintosh, it is possible to double click on the icon that | represents a file to invoke the application associated with that file. | It is difficult to build a GUI (graphical user interface) to do the | same for Unix systems, since Unix does not offer a standard way of | attaching an application name to a file. I don't think this is the right solution; quick, what application name should be attached to a Makefile? What happens if I decide I prefer to use sam instead of GNU Emacs to edit files suddenly? Operations that I want to do on Unix files are heavily context-dependant; sometimes I want to edit my Makefiles, sometimes I want to run make on them. How do application names get attached to files? Other people have already proposed good mechanisms for doing this in particular programs or particular environments without kernel changes. I think that's sufficient until we understand the problem better. People interested in a novel look at how to build an integrated user interface to the system should look at Rob Pike's paper on his "help" program from the Summer 1991 Usenix ("A Minimalist Global User Interface"). -- > 2 does not equal something, but something may in fact be equal to 2. "2 does not equal 3. Not even for very large values of 2." - Roy Smith in a comp.lang.c article cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
erik@srava.sra.co.jp (Erik M. van der Poel) (06/21/91)
> I think a better solution than extending the Unix file system in this > way would be to create a file, named say .desktop (or something more > clever to avoid lawsuits :) which would contain this information, and > then writing some library calls which would maintain this information > and make it available to programs. There are a couple of problems with this approach: If you put the metadata for several files in one file called .desktop or whatever, the program that reads this data will be more complex. Please remember the KISS principle (Keep It Simple, <censored>). If you have a file called .desktop or whatever that contains the metadata, where do you put the metametadata for this metadata .desktop file? It would be cleaner to hide the metadata from open(). > This also makes the code a lot > more portable since it doesn't rely on the particular Unix providing > the facilities you describe. This brings up another important point. If the user agent goes ahead and defines all sorts of file attributes and decides on the names for these attributes, users will not be able to switch user agents. So we need to create a metadata standard, and we need to register file attribute names and values with some international authority so that everyone agrees on their meaning. For example, for an ordinary European text file, you might put the following in the metadata: Content-Type: text Char-Encoding: latin-1 (`Latin-1' is the name of a text encoding standard.) - -- Erik M. van der Poel erik@sra.co.jp Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692
erik@srava.sra.co.jp (Erik M. van der Poel) (06/21/91)
> Haven't you seen SCO's Open Desktop? It does just this, but without > (I hope) any gruesome kernel hacks. But does SCO's product allow you to click on the icon that represents the 1/4 inch cartridge tape drive, to automatically select tar or cpio (or whatever) for reading the tape? - -- Erik M. van der Poel erik@sra.co.jp Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692
erik@srava.sra.co.jp (Erik M. van der Poel) (06/21/91)
> sometimes I > want to edit my Makefiles, sometimes I want to run make on them. That's a good point. I guess one could set it up to have a reasonable default action for the double click, e.g. edit it using the user's favorite editor. The user can, of course, change this action to something else, e.g. running `make'. If the current action is to edit, but the user wants to `make', the Makefile icon could be dragged to the `make' icon and dropped, or a secondary action could be set up for double clicking while the shift key is depressed, or ... - -- Erik M. van der Poel erik@sra.co.jp Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692
boyd@prl.dec.com (Boyd Roberts) (06/21/91)
In article <1753@sranha.sra.co.jp>, erik@srava.sra.co.jp (Erik M. van der Poel) writes: > But does SCO's product allow you to click on the icon that represents > the 1/4 inch cartridge tape drive, to automatically select tar or cpio > (or whatever) for reading the tape? No, neither does an axe wielding psychopath appear when you click on an icon, of a person with an axe, and hack the machine apart, leaving the users unharmed. This, however, could be considered a feature. Boyd Roberts boyd@prl.dec.com ``When the going gets wierd, the weird turn pro...''
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (06/22/91)
erik@srava.sra.co.jp (Erik M. van der Poel) writes: >If you put the metadata for several files in one file called .desktop >or whatever, the program that reads this data will be more complex. >Please remember the KISS principle (Keep It Simple, <censored>). You're trying to tell me that changing the semantics of the filesystem, and implementing new system calls to deal with that is SIMPLER than writing a couple of C callable library routines? Yow! >If you have a file called .desktop or whatever that contains the >metadata, where do you put the metametadata for this metadata .desktop >file? It would be cleaner to hide the metadata from open(). What sort of metadata would be required for .desktop? -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6mc.ab.can.noam As a math atheist, I should be excused from this. --Calvin
john@sco.COM (John R. MacMillan) (06/22/91)
| Unix already has the facility you mention. Let's say you have a |shell script. You want it to be run by the Bourne shell. So you put as |the first line: |#!/bin/sh | | [...] | | *Please* don't bloat the kernel with features that belong in |user mode. You mean like the #! hack? [ Dives for flame-retardant suit... ]
andrew@alice.att.com (Andrew Hume) (06/22/91)
I think maybe Jamie Mason was a bit quick in dismissing Erik's suggestion for mopen. The problem is that the Unix file system interface has no standardised way of accessing a file's attributes other than those stored in the stat buffer. Erik mentioned the preferred application name as an example and Jamie jumped all over that but the general problem remains. For example, how can I access resources from a Macintosh file acessed through a network file system? This is a serious problem and worthy of at least some thought. andrew hume
erik@srava.sra.co.jp (Erik M. van der Poel) (06/22/91)
> There's absolutely nothing wrong with checking magic numbers, etc. to > find out the type of a file. There are no magic numbers in ordinary text files. Also, Unix is being used in many different countries, and people use their local character encodings for text files. We are now seeing increased networking of computer systems, even on a global scale, and I think this will only increase. In order to deal intelligently with files encoded in "other" codesets, we need to label the files. This sort of labeling is really metadata (as opposed to data), and it seems to me to be cleaner to put it somewhere else (i.e. not in the file itself). The character encoding example given above is just that -- an example. There are many other pieces of information that we need to attach to data, so that the data may be operated upon intelligently. "Ordinary" people (not the wizards that read this newsgroup) don't care whether a tape is in tar format or cpio format. They just want the computer to do the right thing, preferably without typing cryptic commands. "Ordinary" people are also getting tired of all these compatibility problems. We need labeling of all types of data, not just Unix files and cartridges. If the computer cannot understand the labels, then the user should be able to look at them, to see which application is needed. > You're trying to tell me that changing the semantics of the filesystem, > and implementing new system calls to deal with that is SIMPLER than > writing a couple of C callable library routines? I think we should add standard headers to data, e.g. cartridges. Old programs that call open() will have problems with these headers if the system does not hide them. Of course, we could just leave open() as it is, and change lots of user-level programs to deal with the headers. I feel, however, that this would be more work than changing the system. How do others feel about this? > What sort of metadata would be required for .desktop? Well, according to the KISS principle, *all* files should have metadata. So the metadata for .desktop would simply say what kind of file it is. By the way, why is it that every time someone tries to start a discussion, the replies are negative (and often sharp) criticism? Could we try to see the positive side of these ideas, and then try to develop them? The extension I'm proposing would allow Unix hackers to continue doing whatever they do. That includes me, by the way. I also like writing long command lines with powerful Unix idioms and pipes, etc. You all know what I'm talking about. I'm trying to propose an extension that would allow "ordinary" people to use Unix (also, POSIX) and computers in general more easily. We (as hardware and software providers) need to think carefully about the needs and the frustrations of the non-computer types. Let's set up a general system that works across the whole information technology industry, without stifling innovation. (If any of you are interested in the migration aspects of this, you might like to take a look at the article I posted to comp.std.internat.) - -- Erik M. van der Poel erik@sra.co.jp Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692
andrew@alice.att.com (Andrew Hume) (06/22/91)
I would be the last person to kill a heated discussion by trying to clarify what is being said but i feel strongly enough about file attributes that i want people to understand what is going on. (at least, as far as i am concerned.) In Unix, files are a byte stream plus a small number of attributes. These latter are stored in the inode and made available to the user by a small number of system calls (stat, fstat). Erik raised the issue of attributes and mentioned an example, the application identifier used by the Macintosh Finder to execute a file. As has been pointed out, most strongly by Doug Gwyn, it is simply not Unix to mandate processing of a file by a particular application. But if we change this to being the preferred application, instead of the mandatory application, then it is much more reasonable idea. And this is a much better solution than the Unix hack of the first line being #application-binary args (what if the application doesn't use # as a comment?). In this way, you can still od or whatever the file, but if the shell (or whatever) wants to launch it, it can ask the best choice of program to run. If this were the only attribute, then the pitiful solutions of .desktop etc would be tolerable; after all, they only need everyone to follow a convention and need no new system calls. But the simple fact is, it isn't the only attribute. What about ACLs for a file? What about storing author and processing information? Sure enough, if you whine enough about new system calls, you will develop systems involving either multiple files or ascii/binary headers. Both of these are problematic. Why can't I rename a dbm database by saying mv old new ?? Why do i have to say mv old.T new.T && mv old.F new.F (or similar). And who polices, documents and maintains the arbitrary system of mapping filename suffixes to properties? As for headers, sure, file can recognise a whole bunch. And it gets it wrong, too, a fair bit of the time. ascii headers have some nice properties; tom duff's graphics code has ascii headers in front of all his pictures (terminated by \n\n). They record a bunch of stuff about the picture and even how it was made (what programs were run to generate it). BUT, every program that looks at these files, has to know how to skip a variable sized amount of goo before starting. what should wc do? what should sort do? Unix has always tried to be more honest than most OSs about this sort of thing. Why not add one more system call (if you really hate this, then standardise a way in via fcntl), say getattr, that is analogous to stat and returns the value of an ascii attribute name? Then the files can go back to being byte streams and for the people who need them, attributes are available with no impact to people who don't use them. Of course, some programs, such as mv, cp, tar etc, will need training to cope with this, but it seems manageable. At least, the user is relatively unimpacted. Of course, as peaple have been discussing for years now, supporting typed data with general Unix tools has many problems, but they seem cleaner and more manageable than the hacky solutions mentioned above.
mjr@hussar.dco.dec.com (Marcus J. Ranum) (06/23/91)
erik@srava.sra.co.jp (Erik M. van der Poel) writes: >Indeed. Many programs will suddenly stop working if we start adding >standardized metadata to the files themselves. That's why we need the >new system call. What's this "when" stuff? Don't hold your breath. Remember, a Mac is not a multiuser machine. If I go through my filesystem on my UNIX machine and set all my file colors to an attractive shade of blue, and the default application to "/bin/rm", that may not be the same color/application mix desired by someone else. Simplistic desktop models like Mac's aren't going to cut it for multiuser systems where you might have fifty users looking at the same file, each wanting a *different* set of options, and maybe a shared global default or two. You don't need a new system call - you need a system that keeps a global database of file information and local customized per-user file information. There are loads of nice databases around that can easily handle a simple index->attribute map like you'd need. A new system call would not only be inelegant, but it wouldn't provide half as much functionality. Another problem with the system call idea is that you'd then need to make every vendor support it, and use the same attributes and so forth for your application to work right. Using a database would give you an application that could even work on non UNIX machines. I realize that Macs do thier attribute stuff in the kernel, but there is only one vendor that makes Macs, and it's easy to standardize in that case. Don't junk up the already bloated kernel - write your application right. Besides - I don't see how you can say UNIX doesn't have good facilities for doing this kind of stuff - have you ever looked at Visix' "Looking Glass" or something like that? It works fine, and since they are producing a commercial product, they didn't have time to wait for everyone to see the light and ram some useless new system call into their kernel. mjr. -- Hell is owning a *diskless* Cray Y-MP.
mjr@hussar.dco.dec.com (Marcus J. Ranum) (06/23/91)
erik@srava.sra.co.jp (Erik M. van der Poel) writes: >> Haven't you seen SCO's Open Desktop? It does just this, but without >> (I hope) any gruesome kernel hacks. > >But does SCO's product allow you to click on the icon that represents >the 1/4 inch cartridge tape drive, to automatically select tar or cpio >(or whatever) for reading the tape? You're joking, I assume! How dare you even assume I *WANT* to read the tape? That's the problem with all this GUI GLOP - it makes a lot of really stupid assumptions. First off, any user who knows enough about UNIX to understand what tar/cpio/dd/grep/whatever is, is probably not going to waste time with a GUI anyhow. You throw away too much of the nice abilities UNIX has - how do you do a pipe with a point and click user interface? (and are you patient enough to do whatever mouse contortions would be necessary to set the pipe up, when you can just type it?) What about multiple files passed to something as a parameter? Suppose I have 16 C source files I want to shove into cc. It is *NOT* sufficient to set their default execution to be "cc file" because I may want to pass compiler flags. So I have to edit the damn attributes and then, joy and bliss, I can *click* and they compile. Where does my error text go? (yes, I sometimes make errors) Do I then have to completely reset the attributes when I want to pump them through lint? No thanks. I'll just have to keep crawling along typing "make", "make clean", or "make lint" instead. FYI, I don't use tar *or* cpio every time I want to do something to a tape. Sometimes I use cat, grep, zcat, and so forth. For a GUI to be half useful, it'd have to know which I wanted when - let me guess, the data on the tape should have meta-data at the tape header, too, right? ioctl(tapefd,TIOCWTFAREYOU,&buf); I second Chris Siebenmann's suggestion that people read Pike's paper on "help" in the latest USENIX. It, in a nutshell, has the grace to assume you know what you're doing, yet tries to facilitate your work by keeping as much quickly re-usable information about your working context around - information which can be quickly used to cut and paste commands and basically save you typing. mjr. PS - As an aside, I realized years ago that GUIs were an utterly stupid idea the day when I completed a complex click-drag-drop operation and it asked me "are you sure?" as if I had *ACCIDENTALLY* grunted and sweated to manipulate the silly mouse to drop the icon into the bloody flaming trashcan!!!!!
bzs@world.std.com (Barry Shein) (06/23/91)
Although the original motivation for the request might be questioned
there are perfectly good reasons to extend the inode/file structure to
allow for the storage of file attributes.
One common reason this comes up is to implement access list protection
(where we store a list of pairs, user/permissions.) This is required
(or the accepted way to meet standards) by one of the Orange Book
classifications (B2 I believe.)
The obvious way to do this is to have a secondary inode for a file
pointed to by the primary (data) inode, basically an anonymous file
with a new file type. This anonymous inode is otherwise like a regular
file, but can not be linked to a directory name and is freed when the
file is freed. It should be optional with some typical convention
(e.g. if the anonymous inode is zero then there is no anonymous inode
for this file.)
So from the file system's point of view it requires the addition of an
integer (ino_t) to the inode struct (probably available as an unused
in many implementations), and a few checks here and there to enforce
policy (e.g. link() returns EANOM or some such.)
A reasonable convention might be one echoing the environment variable
conventions (NAME=VALUE) although admittedly it's difficult to store
lists (arrays) of values in that format, other than simply storing
them in the value and using string processing software to unpack them,
not entirely unreasonable.
Given this it would be straightforward enough to implement any desired
operations, I believe all you really need is a flag to open(2) telling
it to return a file descriptor for the anonymous inode rather than the
data file. From then on standard file ops should be sufficient
(read(), write(), close(), fchmod(), etc.) to use the new feature. A
few library (3) routines would help maintain conventions.
There are many other uses of such files beyond GUI's. This
conversation got a little side-tracked by the original request topic
(it would be like someone first suggesting environment variables, but
citing a questionable reason for needing them.)
I know of at least one large unix vendor who was implementing this
idea a year or two ago.
If a process can have environment variables I don't find it completely
peculiar that a file might also.
--
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLDtchrist@convex.COM (Tom Christiansen) (06/23/91)
From the keyboard of mjr@hussar.dco.dec.com (Marcus J. Ranum): : I realize that Macs do thier attribute stuff in the kernel, but :there is only one vendor that makes Macs, and it's easy to standardize :in that case. Don't junk up the already bloated kernel - write your :application right. Besides - I don't see how you can say UNIX doesn't :have good facilities for doing this kind of stuff - have you ever looked :at Visix' "Looking Glass" or something like that? It works fine, and :since they are producing a commercial product, they didn't have time to :wait for everyone to see the light and ram some useless new system :call into their kernel. You'll find that a non-zero portion of the users running under UNIX today are what we'd call technically unsophisticated users, ones whose principal prior experience with interactive computers is with a Mac. Some of these wish that there were a Mac-like interface for UNIX. I've looked at the Looking Glass product and was not particularly impressed. I don't really think this is what they want: to me, it wasn't configurable enough and way too clumsy. Now maybe it really is cumbersome, but maybe I'm just the wrong person to evaluate this stuff. Has anyone had any experience with a system of this nature that non-UNIX gurus like to use? Or do you just buy them Macs and be done with it? --tom -- Tom Christiansen tchrist@convex.com convex!tchrist "So much mail, so little time."
gwyn@smoke.brl.mil (Doug Gwyn) (06/23/91)
In article <1991Jun22.174141.10152@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: >PS - As an aside, I realized years ago that GUIs were an utterly stupid idea >the day when I completed a complex click-drag-drop operation and it asked me >"are you sure?" as if I had *ACCIDENTALLY* grunted and sweated to manipulate >the silly mouse to drop the icon into the bloody flaming trashcan!!!!! GUIs normally make it simple to accomplish simple actions and impossible to accomplish complex actions. This stems directly from the "user model"; the Macintosh was intended to be an "appliance", and its GUI evolved from the Xerox Star's, which was aimed at replacing the physical office desktop with an electronic analogue. UNIX, on the other hand, was developed by people who wanted to be able to perform interesting actions without them having to all have been anticipated in the system software implementation. You see the same GUI trend in computer adventure games, where text-based parsers have been almost totally supplanted by point-and-click interfaces. This detracts a lot from the games, as only a few actions are possible at any juncture, and they must all have been anticipated by the game designer. Gone is the ability to try clever actions like: "Light the fuse, then withdraw to the previous room and wait for the explosion." Instead, you click on the fuse and the whole scenario plays itself out without any real thought on your part. Very passive, just like the television that Roberta Williams used to so decry before Sierra started cranking out prescripted adventures.
bzs@world.std.com (Barry Shein) (06/23/91)
The problem with most of these arguments is that they make the best
the enemy of the good. Even the Mac often pops up that familiar
"Application busy or missing" (something like that) error when you
click a generic or unidentified file. So what?
I agree that stricter adherence to the conventions of /etc/magic would
do about 95% what these gui's need (add in file extensions and we get
about 98%, particularly if we write off common cases like a plain text
file just popping up whatever is in your EDITOR environment variable
as a solved case.) If you don't want the default thing to happen then
you have to know something, it's no worse than now.
Actually, I'd be less interested in automatically launching the
application than just being able to display reasonably accurate icons.
Even sophisticated users look at directories scratching their heads
mumbling a Letterman-esque "might be meat, might be cake...". The file
command is critical, but it wouldn't be that awful to follow the
low-resistance path of iconifying the file command.
Anyhow, given the right design it could be made mostly harmless and
optional, which is important.
But, as I said in another note, there's more to file attributes than
gui's, which is probably one of the weaker excuses to get into them.
ACLs, compound documents, and other applications could benefit from a
very simple implementation which effectively adds environment
variables to files or something similar.
--
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLDlewis@tramp.Colorado.EDU (LEWIS WILLIAM M JR) (06/23/91)
>>But does SCO's product allow you to click on the icon that represents >>the 1/4 inch cartridge tape drive, to automatically select tar or cpio >>(or whatever) for reading the tape? Whoever wrote this forgot the fundamental theorem of programming: "Programs designed to do things FOR the user inevitably will do things TO the user." See some of the "helpful" features in BSD (csh, vi, ls, etc.) for examples.
gwyn@smoke.brl.mil (Doug Gwyn) (06/23/91)
In article <20438@alice.att.com> andrew@alice.att.com (Andrew Hume) writes: >For example, how can I access resources from a Macintosh file acessed through >a network file system? This is a serious problem and worthy of at least some >thought. As little as possible, however. <pathname>/resource and <pathname>/data immediately spring to mind as solutions for the "forked file" problem that Apple invented.
bzs@world.std.com (Barry Shein) (06/23/91)
From: gwyn@smoke.brl.mil (Doug Gwyn) >GUIs normally make it simple to accomplish simple actions and impossible >to accomplish complex actions. This stems directly from the "user model"; >the Macintosh was intended to be an "appliance", and its GUI evolved from >the Xerox Star's, which was aimed at replacing the physical office desktop >with an electronic analogue. UNIX, on the other hand, was developed by >people who wanted to be able to perform interesting actions without them >having to all have been anticipated in the system software implementation. Doug, I agree with you 1000%. In fact, I'd even go further and have wished for more than a decade that there were an even more robust programmatic interface to Unix (something more like lisp rather than the shells, the shells are full of warts, particularly once something large is to be built and tend to constrain solutions to only those things they were designed for, eg, very little string processing), but I wander... On the other hand, one of the strong points of Unix has always been the notion of a replaceable shell (command interface.) In theory even VMS has this, although I don't believe anyone has really produced the second example (I suppose one could argue that this is precisely what EUNICE was, and there are probably some other minor examples by now.) Although there are indeed several, perhaps a dozen, different command interfaces in common use for Unix (sh, csh, bash, ksh, vsh), their actual variance is very tiny. In fact, they can often run each others' scripts if one needs to be convinced of their similarity (and that's by design.) So, someone comes along with an idea for a radically different "shell", namely a GUI, fine, we should simply consider it a confirmation of the original claim. Unix's flexibility wins again (put another way, lots of rope...) and those who believe they want such a thing are free to do so without disturbing the rest of us in the slightest (other than the GB of disk they need because somehow the value of what they do tends to rest heavily on font choices and color icon images, but again I wander...) Let a thousand flowers bloom, and all that, even if some of us find daffodils quite boring or even weedious. However, I think the real lesson is not to expect accollades for these primitive, Sunday morning comic-strip interfaces from the Unix community at large because many of us are still convinced we're better off with what we have, for reasons Doug just argued. I am generally awe-struck at the small-mindedness of some of these concerns, choosing the correct icon or whatever. Now, if someone could show me how to develop something shell-like in expressiveness and power but could operate on multi-media and networked objects as blossomfully as Unix has on text files, now there would be something! % find /share/images \( -image dog -o -sound bark \) -clipsave dog.out % subtitle -lang spanish | vcroff -mfoley -Tvhs120 -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
dpassage@soda.berkeley.edu (David G. Paschich) (06/23/91)
In article <16508@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: In article <20438@alice.att.com> andrew@alice.att.com (Andrew Hume) writes: >For example, how can I access resources from a Macintosh file acessed >through a network file system? This is a serious problem and worthy of at >least some thought. As little as possible, however. <pathname>/resource and <pathname>/data immediately spring to mind as solutions for the "forked file" problem that Apple invented. A/UX, Apple's Unix variant, solves this by making the Mac file MacFoo appear in the Unix tree as "MacFoo" for the resource fork and "*MacFoo" (yes, *) for the data fork. You can also always store Mac files in MacBinary format, a standard format which encodes all the file typing and like information in the front of the file. All this discussion of making Unix work like a Mac seems silly. If you want a Mac, then buy a Mac. It would seem to me to be more productive in the long run to come up with a new GUI paradigm to deal with Unix's generality and power, rather than to retrofit an established interface to fit the Unix semantics. -- David G. Paschich Open Computing Facility UC Berkeley dpassage@ocf.berkeley.edu Go Colorado Rockies -- Opening Day, Mile High Statium, April 1991
erik@srava.sra.co.jp (Erik M. van der Poel) (06/24/91)
> A new system call would not only be inelegant, but it wouldn't provide > half as much functionality. A new system call could provide access to a series of name-value pairs such as those found in email headers. The `functionality' here is unlimited. Name-value pairs offer infinite extensibility. > Another problem with the system call idea is > that you'd then need to make every vendor support it, and use the same > attributes and so forth for your application to work right. Exactly. I have no hidden agendas here, so let me spell it out. One of my aims is to get something like this into POSIX. This way, many vendors will feel obliged to support it. Also, we need to officially register names and values, so that everyone agrees on their meaning (even in the non-Unix world). > Besides - I don't see how you can say UNIX doesn't > have good facilities for doing this kind of stuff - have you ever looked > at Visix' "Looking Glass" or something like that? It works fine, and ... It does not "work fine". It cannot tell what has been stored in a cartridge tape. None of the GUIs can do this (yet). - -- Erik M. van der Poel erik@sra.co.jp Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692
erik@srava.sra.co.jp (Erik M. van der Poel) (06/24/91)
> >But does SCO's product allow you to click on the icon that represents > >the 1/4 inch cartridge tape drive, to automatically select tar or cpio > >(or whatever) for reading the tape? > > You're joking, I assume! How dare you even assume I *WANT* to > read the tape? Well, if I tell the computer to read the tape into disk, it had better do just that. If it warns me beforehand that there is not enough disk space for this tape, then I'd be even happier. And if it can warn me before overwriting existing files, that's also good. Remember: Computers are our tools, not our masters. > I second Chris Siebenmann's suggestion that people read Pike's > paper on "help" in the latest USENIX. I just read the first and last parts of Rob's paper. Excellent paper, as always. But this discussion is rapidly turning into one about user interfaces. This was not my intention. I am proposing the addition of metadata to any series of bits (floppies, network messages, etc). This metadata should be written according to a standard, that applies across the whole information technology industry. The end-users have had more than enough of the incompatible proprietary stuff. The reason I brought this up in comp.unix.wizards, is because I want to discuss how we could integrate this metadata idea into Unix. - -- Erik M. van der Poel erik@sra.co.jp Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692
erik@srava.sra.co.jp (Erik M. van der Poel) (06/24/91)
> Or do you just buy them Macs and be done with it?
Well, yes, if that's what the user wants. But if the user wants to
connect to a network of heterogeneous systems, or the user wants to
exchange floppies with the user of a different system, you're going to
need industry-wide standards.
We won't be able to do this metadata thing immediately, but I think it
is time to start discussing this, at least.
-
--
Erik M. van der Poel erik@sra.co.jp
Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/24/91)
In article <1780@sranha.sra.co.jp> erik@srava.sra.co.jp (Erik M. van der Poel) writes: > Exactly. I have no hidden agendas here, so let me spell it out. One of > my aims is to get something like this into POSIX. This way, many > vendors will feel obliged to support it. I find this attitude sickening. Where there is no implementation there should never be a standard. If enough vendors see the value of a feature or (equivalently) believe that the market demands that feature, that feature becomes a de facto standard. The other direction is exemplified by POSIX: rather than waiting to see what consensus appears in the real world, a bunch of people sit down, define interfaces to operations that they've hardly even used and that at most one vendor supports, and call the result a ``standard.'' Before the people working on *good* solutions to the same problems have a chance to test their ideas, they find an overspecified yet woefully incomplete ``standard'' shoved down their throats. Fortunately, there are a few parts of POSIX actually based on the real world rather than somebody's imagination. Now if only the people ``standardizing'' asynchronous I/O and threads and high-level network applications would stop gloating over how much power they think they have and start paying some attention to reality, the rest of us might just get some work done. ---Dan
erik@srava.sra.co.jp (Erik M. van der Poel) (06/24/91)
> Even the Mac often pops up that familiar > "Application busy or missing" (something like that) error when you > click a generic or unidentified file. If the computer cannot handle a particular piece of data, the human should be able to find out what the data is, in order to take appropriate action (e.g. buy a copy of the application). That is why we need human-readable metadata. The magic number scheme was designed at a time when computer nerds were excessively worried about disk space and efficiency. Disk prices are coming down, and shared libraries are becoming universal. We don't need to worry about disk space and efficiency that much. Let's give the ordinary humans some readable metadata. And let's give the programmers some metadata that is extremely easy to parse, and very extensible. - -- Erik M. van der Poel erik@sra.co.jp Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692
klaus@cnix.uucp (klaus u schallhorn) (06/24/91)
In article <1767@sranha.sra.co.jp> erik@srava.sra.co.jp (Erik M. van der Poel) writes: >> There's absolutely nothing wrong with checking magic numbers, etc. to >> find out the type of a file. > [ ... ] > >I think we should add standard headers to data, e.g. cartridges. Old >programs that call open() will have problems with these headers if the >system does not hide them. Of course, we could just leave open() as it >is, and change lots of user-level programs to deal with the headers. [ ... ] >I'm trying to propose an extension that would allow "ordinary" people >to use Unix (also, POSIX) and computers in general more easily. [ ... ] Wouldn't an extension to the knowledge of these people be more efficient than library mods or kernel hacks. Contrary to the movies very few people die of knowing too much. klaus schallhorn -- George Orwell was an Optimist
jfh@rpp386.cactus.org (John F Haugh II) (06/24/91)
In article <1781@sranha.sra.co.jp> erik@srava.sra.co.jp (Erik M. van der Poel) writes: >The reason I brought this up in comp.unix.wizards, is because I want >to discuss how we could integrate this metadata idea into Unix. To steal a quote from Dennis Ritchie, "if you want metadata, you know where to find it." UNIX is not the place to stuff every little idea you think there is a market for. If the market really wanted what you are proposing, the Mac operating system would be running on as many systems as UNIX currently does. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "UNIX signals are not interrupts. Worse, SIGCHLD/SIGCLD is not even a UNIX signal, it's an abomination." -- Doug Gwyn
guy@auspex.auspex.com (Guy Harris) (06/25/91)
>| *Please* don't bloat the kernel with features that belong in >|user mode. > >You mean like the #! hack? Heh. Well, for the benefit of those who haven't figured it out yet, "bloat", when used in software discussions, is pretty much a noise-word these days, used only in ritual denunciations of "bloat". I recommend its retirement.... However, depending on what meaning (if any) you'd assign to "bloat", "the #! hack" may or may not "bloat" the kernel; by my count, it adds 60 lines to "kern_exec.c" in 4.3BSD, for example. Presumably, your user-mode version would be done in the "execve()" library routine - i.e., instead of just being a wrapper around the "execve()" trap, as it is in most existing UNIX implementations, it'd check for ENOEXEC and, if that was the error, it'd check for a "#!" line, shuffle the argument list, and invoke the program specified by the "#!" line? (That'd lose the set-UID/set-GID capability, but it's not clear whether that's really a loss or not - even if you fix the known bugs with the set-UID shell script mechanism, would *you* trust some arbitrary shell, or the "awk"/"perl"/whatever interpreter, and the language it implements sufficiently that you'd want to write set-UID scripts in that language?) If not, it's not interesting, because it's not transparent. The reason for a "#!" mechanism is to allow scripts to be executed *just like programs*. And no, it's not at all clear that all uses of the "execv" or "execl" family of calls would want to be replaced by "execvp" or "execlp" calls, and those calls only understand Bourne shell scripts in any case....
rcd@ico.isc.com (Dick Dunn) (06/25/91)
I'd been following the "file attributes" discussion from a safe distance... until this came by... erik@srava.sra.co.jp (Erik M. van der Poel), who is advocating the general idea of "file attributes", writes: > ...I have no hidden agendas here, so let me spell it out. One of > my aims is to get something like this into POSIX. This way, many > vendors will feel obliged to support it. Hasn't this game of politics-before-technology been played out enough times--failing every time--for us to reject it? Sure, you're not the first person to try to use a standards effort to advance a personal agenda, but it's still nothing to be proud of. Look: FIRST figure out what you're trying to do. NEXT figure out how to do it. THEN implement it. It won't be right the first time, so go through some cycles of refinement. Get other people to try it out, or to try their own approaches. See what works best. Only AFTER you've got it pretty much right is it time to think about standardization. This business of pouring the concrete, then trying to lay the forms before it sets up, has got to stop. Anyway, making vendors "feel obliged to support it" because of a standard is a sure sign you've done a bad job. If you get it right technically, they'll support it because it benefits their product to do so. We get enough gratuitous baggage loaded into commercial systems as it is, without trying to force more. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...Simpler is better.
mjr@hussar.dco.dec.com (Marcus J. Ranum) (06/25/91)
erik@srava.sra.co.jp (Erik M. van der Poel) writes: >The reason I brought this up in comp.unix.wizards, is because I want >to discuss how we could integrate this metadata idea into Unix. The first step is to discuss possible options, and to try to abstract a general solution. It's not a question of "how we could[...]" it's a question of "should we[...]?" and whether it needs to be integrated into UNIX or application layer, or whatnot. I don't think the justifications you've given for why we *need* a new system call are very clear or very solid. The "how" and the "getting it into POSIX" part come later. (Unless you're one of the increasing population that seems to feel that standards should be set in concrete without a decent set of trial implementations and some discussion - if you are, I can't help you). Barry Shein's idea of environment variables for files is extremely elegant and would probably be useful in a lot of ways - it would rightly require that the application have "brains" about file types, rather than the kernel, but would make it a lot easier for them to do so. mjr.
mjr@hussar.dco.dec.com (Marcus J. Ranum) (06/25/91)
erik@srava.sra.co.jp (Erik M. van der Poel) writes: >[...] We don't >need to worry about disk space and efficiency that much. Let's give >the ordinary humans some readable metadata. Isn't it funny how people keep saying "we don't need to worry about efficiency" and then they complain when their windowing system makes their expensive hardware obsolete in 4 years? Saying "we don't need to worry about efficiency" is like a government that says "we don't need to worry about a budget, we can just run into debt" and then they wonder why, uh, urr... I guess this example's not so funny after all, is it? mjr.
bzs@world.std.com (Barry Shein) (06/25/91)
But what scares me about environment variables for files is the
prospect of the day I see a user type:
grep foo < 'LRECL=80,RECFM=V,DISP=(OLD,KEEP,DELETE),DSN=data'
then I shall know that we are done.
--
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLDerik@srava.sra.co.jp (Erik M. van der Poel) (06/25/91)
> Where there is no implementation there should never be a standard. I agree that, in some cases, it is highly desirable to implement prototypes before attempting to put specs in a draft standard. In particular, if it's very complex, one should implement it first to prove that it's feasible. It seems to me, however, that this is not the case with my metadata proposal. It is extremely simple, and any IT professional should be able to see that it is implementable. One possible syntax is a number of lines (Name: value) followed by an empty line. This is both simple and extensible. Don't forget that the *system* software does not need to recognize the names and values. Only user software does. (Access control lists were mentioned by someone else, not me. We probably want to put ACLs in an extended inode, under the control of the system for security purposes.) Also, in the case of this metadata proposal, it does not make sense for only a small number of organizations to implement it. A large number of implementations should exist if it is to be truly useful and simple for the end-user. Again, migration is covered in my comp.std.internat article. Finally, this implement-before-standard approach needs to be used with considerable care. In the past, many hardware and software implementors did their own thing, without regard for the end-user, who must live in a world of heterogeneous systems, and would like to exchange data with peers. We need industry-wide de facto and de jure standards that don't obstruct innovation. > If enough vendors see the value of a feature > or (equivalently) believe that the market demands that feature, that > feature becomes a de facto standard. Exactly. I am currently trying to get the vendors to see the value of this extension. # Anyway, making vendors "feel obliged to support it" because of a standard # is a sure sign you've done a bad job. I agree with this, actually. I shouldn't have said it the way I did. : But what scares me about environment variables for files is the : prospect of the day I see a user type: : : grep foo < 'LRECL=80,RECFM=V,DISP=(OLD,KEEP,DELETE),DSN=data' If metadata is added to Unix files, we will grep this way: grep foo data - -- Erik M. van der Poel erik@sra.co.jp Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692
boyd@prl.dec.com (Boyd Roberts) (06/25/91)
In article <1783@sranha.sra.co.jp>, erik@srava.sra.co.jp (Erik M. van der Poel) writes: > If the computer cannot handle a particular piece of data, the human > should be able to find out what the data is, in order to take > appropriate action (e.g. buy a copy of the application). That is why > we need human-readable metadata. `human readable'? So what language are you going to choose? Binary data and text are no different. They are a terminology, a subset of a language. So, are we going to use Esparanto to describe our data? Just look at Esparanto. It's an object lesson in how _not_ to do things. They said, `we need an international language'. They built one. Does anyone use it? Does it server any useful purpose? Another solution looking for a problem. Exactly the path you want to take. There isn't even a problem, and you have a `solution', lashed together with supposition and ignorance. > The magic number scheme was designed at a time when computer nerds > were excessively worried about disk space and efficiency. That's outrageous. You understand nothing. > Disk prices > are coming down, and shared libraries are becoming universal. We don't > need to worry about disk space and efficiency that much. Let's give > the ordinary humans some readable metadata. And let's give the > programmers some metadata that is extremely easy to parse, and very > extensible. I see you work in Japan. The last sentence mentions `shared libraries' and `efficiency'. So tell me you're not just a parody of `Ohta'? Boyd Roberts boyd@prl.dec.com ``When the going gets wierd, the weird turn pro...''
martin@minster.york.ac.uk (06/25/91)
Andrew Hume said: > ... Why not add one more system call (if you really hate this, > then standardise a way in via fcntl), say getattr, that is analogous to > stat and returns the value of an ascii attribute name? Then the files ... I implemented a filing system (for storing sampled, CD-quality sounds) which implements something like this - we call them `properties' not attributes - a null-terminated textual key, is mapped to an arbitrary binary value (with a stored length). In practice many values turn out to be textual, but the flexibility of binary values has been useful. A single `getattr'-like call is not enough - one also needs to be able to remove properties (we allow `binary properties' that have no value, and whose significance is their presence or absence in the file, so a zero value length cannot be used to remove a property. I suppose a negative length could be used, but this sounds like a hack to me :-). More interestingly one needs to be able to find out the keys of all the properties defined for a file, so the copy program can perserve them, and other more interesting manipulations can be carried out. In my system this also returns the size of the key's value, so that the application knows how much space to allocate if it has to read the property. Having done all this, properties/attributes are something of a mixed blessing. Managing the namespace, and standardizing the properties that are stored with files is a nightmare! Centralized administration is out of the question (no resources to support this, it is too awkward for developers and totally unenforceable) while locally defined property names quickly lead to chaos! At other times properties can be quite useful :-)! In a new version of the system that I am currently designing/thinking about I would prefer to use a perfectly good data agregation mechanism that is already in Unix, MSDOS, TOS, etc. I am of course refering to directories! Changes to allow directories to be moved and copied more freely seem to be enough to make this a better solution than attaching properties directly to the files. This would also allow `properties' that were hard or symbolic links, and other obvious generalizations. It also makes it much easier to avoid horrible restrictions/implementation problems on the size (and the changes in size) of properties. Martin usenet: ...!mcsun!ukc!minster!martin JANET: martin@uk.ac.york.minster INTERNET: martin%minster.york.ac.uk@nsfnet-relay.ac.uk surface: Dr. Martin C. Atkins Dept. of Computer Science University of York Heslington York YO1 5DD ENGLAND
sef@kithrup.COM (Sean Eric Fagan) (06/26/91)
In article <1792@sranha.sra.co.jp> erik@srava.sra.co.jp (Erik M. van der Poel) writes: >It seems to me, however, that this is not the case with my metadata >proposal. It is extremely simple, and any IT professional should be >able to see that it is implementable. It's *wrong*. Understand? 1. It has no need to go into the kernel. 2. A *much* better way to do what you are trying to do, that *has* been done before, that is much more general, elegant, etc., is to use watchdogs. If you don't know about them, then you have not researched the area of filesystem enhancements well enough, and should realize that it is time to do so. >One possible syntax is a number >of lines (Name: value) followed by an empty line. What do people in, oh, Japan, Spain, Germany, China, Russia, Brazil, etc., do? Do you have a different one for each file? Where do you *put* this information? >This is both simple >and extensible. Don't forget that the *system* software does not need >to recognize the names and values. Only user software does. Wait... let me get this straight: system software never needs to see it, only user software. So we have to add a system call. Real bright. -- Sean Eric Fagan | "What *does* that 33 do? I have no idea." sef@kithrup.COM | -- Chris Torek -----------------+ (torek@ee.lbl.gov) Any opinions expressed are my own, and generally unpopular with others.
john@sco.COM (John R. MacMillan) (06/26/91)
|However, depending on what meaning (if any) you'd assign to "bloat", |"the #! hack" may or may not "bloat" the kernel; by my count, it adds 60 |lines to "kern_exec.c" in 4.3BSD, for example. Like you, I'm not a fan of the term ``bloat''. My reason for mentioning #! was that I felt it belonged in user code, not because it's big, but because there's no particularly good reason to put it in the kernel. |Presumably, your user-mode version would be done in the "execve()" |library routine - i.e., instead of just being a wrapper around the |"execve()" trap, as it is in most existing UNIX implementations, it'd |check for ENOEXEC and, if that was the error, it'd check for a "#!" |line, shuffle the argument list, and invoke the program specified by the |"#!" line? Actually, if I were about to change the semantics of a prominent UNIX call, I would probably have given it a new name, but it's a little late for that (not meaning to signal, I mean single, out the exec calls :-) ). Now that the use is widespread, I would do it the way you suggest. You could also get rid of the ugly hard-coded limits that are in kern_exec.c; after all, dynamic sizing is easier in user code. |(That'd lose the set-UID/set-GID capability, but it's not |clear whether that's really a loss or not - even if you fix the known |bugs with the set-UID shell script mechanism, would *you* trust some |arbitrary shell, or the "awk"/"perl"/whatever interpreter, and the |language it implements sufficiently that you'd want to write set-UID |scripts in that language?) I don't consider it a loss. If you really REALLY need setuid scripts, that too can be done without kernel support (ksh has an suid_exec program to do this). This has the added advantage that it gives the sysadmin control over setuid scripts. Just to be safe, I should say that I (obviously) do not claim to represent my employer's views.
stripes@eng.umd.edu (Joshua Osborne) (06/26/91)
In article <1792@sranha.sra.co.jp> erik@srava.sra.co.jp (Erik M. van der Poel) writes: >> Where there is no implementation there should never be a standard. > >I agree that, in some cases, it is highly desirable to implement >prototypes before attempting to put specs in a draft standard. In >particular, if it's very complex, one should implement it first to >prove that it's feasible. > >It seems to me, however, that this is not the case with my metadata >proposal. It is extremely simple, and any IT professional should be >able to see that it is implementable. One possible syntax is a number >of lines (Name: value) followed by an empty line. This is both simple >and extensible. Don't forget that the *system* software does not need >to recognize the names and values. Only user software does. (Access >control lists were mentioned by someone else, not me. We probably want >to put ACLs in an extended inode, under the control of the system for >security purposes.) So what happens after some POSIX-meta-data compliant systems come out, we attach great huge festering gobs of meta-data to our files, then can't process the meta-data fast 'nuf because we can't sift through the keys quickly? We get a new spec: hashed meta-data, new sys-calls, and an obsolete spec that needs to be implemented by everyone (rather then just one vender for a few years), and may never die out (newbie programmers will use it, people may never port old programs to the hashed way since the "old way" will be around forever (it's POSIX standard now)). Then what happens when people decide that some meta-data is a per-user toy and other a per-group, and others a plain item (the default action for Makefiles for me is make, secondary is vi; other people may want them to be pmake & emacs for the same file). New spec: user dependent meta-data. 2 old formats to support until the end of time. What happens when I want some meta-data to chain off of environment variables? (secondary action for Makefile is the value of PAGER...)? New spec, 3 old ones to support 'till Sol goes nova. What happens when I want meta-data to be hot-linked from one file's m-d to another? New spec: 4 to support, one to use... (What if I want fast wild card support, or somthing like X's resources?) >Also, in the case of this metadata proposal, it does not make sense >for only a small number of organizations to implement it. A large >number of implementations should exist if it is to be truly useful and >simple for the end-user. Again, migration is covered in my >comp.std.internat article. Do it once, fall on your face. Do it again, learn to walk. Do it again, learn to run. Do it again, fly. Don't make us all fall down with you. Invite us to fly. >Finally, this implement-before-standard approach needs to be used with >considerable care. In the past, many hardware and software >implementors did their own thing, without regard for the end-user, who >must live in a world of heterogeneous systems, and would like to >exchange data with peers. We need industry-wide de facto and de jure >standards that don't obstruct innovation. Would it be better if Sun had made SunView (or SunTools?) the "standard" before they learned that NeWS was way better? (never mind that we chose X, or even if X is better; I don't know much about NeWS, I know lots about X; I like X. NeWS may or may not be better. This is the wrong place to argue.) If so you wouldn't have a networked window system. You would have (if you are lucky) a network kludge (I don't think SunView would work well over a network). What about Network File Systems? I may not like NFS, AFS may be better, or RFS for all I care. All 3 beat the hell out of ND. That's what we would have if we "standardize first", then test. >> If enough vendors see the value of a feature >> or (equivalently) believe that the market demands that feature, that >> feature becomes a de facto standard. > >Exactly. I am currently trying to get the vendors to see the value of >this extension. Fine. Make it work then make them believe. Hell, make it work then make it POSIX. ># Anyway, making vendors "feel obliged to support it" because of a standard ># is a sure sign you've done a bad job. > >I agree with this, actually. I shouldn't have said it the way I did. Then we don't understand what you want. Just a design, then a standard? Or a design, an implmentation, a (at least) few months use, then a standard? Go the RFC route? Lots of good "standards" started that way. >: But what scares me about environment variables for files is the >: prospect of the day I see a user type: >: >: grep foo < 'LRECL=80,RECFM=V,DISP=(OLD,KEEP,DELETE),DSN=data' > >If metadata is added to Unix files, we will grep this way: > > grep foo data How do we grep for a meta-value ("any files that set the FOO variable" or "any files that set FOO to GOO" or "any files that set anything to GOO" or...). How do we use the power of the standard (and non-standard) Unix tools on meta-data? A new shell syntax (grep "FOO=.*BAZ.*BAR" <# foo)? New versions of all the standard (and non-standard, mperl...) programs? [[Please don't think this message endorses meta-data support from the kernel, I think it belongs outside; but I am willing to change my mind, bring me a working version, I've got an open mind... 'till then I think it belongs in another file, or all in one huge database, or...]] -- stripes@eng.umd.edu "Security for Unix is like Josh_Osborne@Real_World,The Multitasking for MS-DOS" "The dyslexic porgramer" - Kevin Lockwood "CNN is the only nuclear capable news network..." - lbruck@eng.umd.edu (Lewis Bruck)
dhesi@cirrus.com (Rahul Dhesi) (06/26/91)
On the Mac, as I understand it, double-clicking on the filename gives you a certain application program that uses that file... ...Triple-clicking the file gives you another application that uses the same file... ...Quadruple-clicking the file give you yet another application... ...No, wait. My imagination is runing wild here. In fact the Macintosh recognizes exactly one application for each file. When I double-click on a C file, I don't always want to just compile it. Sometimes I want to run lint on it instead. Other times I want to expand tabs in it. Other times I want to enter my favorite editor to edit that file. Other times I want to enter my favorite editor in read-only mode to view that file. Other times I want to enter my *second*-most favorite editor to edit that file, because I just happen to need a feature at that instant that that second-most favorite editor provides. Frankly, I *don't* think UNIX users should revert back to the Dark Ages, when there was One Standard Thing they could do quickly with any file, and everything else took multiple menus and multiple mouse clicks. -- Rahul Dhesi <dhesi@cirrus.COM> UUCP: oliveb!cirrusl!dhesi
erik@srava.sra.co.jp (Erik M. van der Poel) (06/26/91)
Boyd Roberts writes: > `human readable'? So what language are you going to choose? I covered this in my comp.std.internat article: Message-ID: <1719@sranha.sra.co.jp> If there is enough interest I could re-post it, or I could email it. Martin C. Atkins writes: > Managing the namespace, and standardizing the properties that > are stored with files is a nightmare! Well, it certainly isn't trivial to decide upon and register attributes, but some of this is already in place in ISO. Again, the above-mentioned article of mine already covers this. (I realize that the current discussion about X.400 and object management in comp.std.unix may have a lot to do with this. But are they also considering human-readability and all media? This is not intended to be a rhetorical question.) > Centralized administration is out > of the question (no resources to support this, It does not take up very many resources to map registered names to system-specific values. E.g. "FrameMaker" -> "/usr/bin/fm" (or whatever). > it is too awkward for developers Why is it awkward? Developers don't even have to think of their own attribute names. The central registration organization provides a list. And they can add new names. > and totally unenforceable) Yes, well, this has always been the case. Well-intentioned organizations have been producing standards for years, and many vendors simply ignore the process. Look where that got us today. > Changes to allow directories to be moved and copied more > freely seem to be enough to make this a better solution than attaching > properties directly to the files. Yes, this is another alternative. We need to leave the options open. But what do we do about tapes with metadata headers? Do we access the metadata through /dev/cartridge/metadata? > It also makes it much easier to avoid horrible restrictions/implementation > problems on the size (and the changes in size) of properties. The email-like header syntax does not suffer these problems. Sean Eric Fagan writes: > 2. A *much* better way to do what you are trying to do, that *has* been > done before, that is much more general, elegant, etc., is to use watchdogs. What I'm trying to get systems vendors to do has not been done yet. Cartridges are not being written with standard headers containing internationally registered attribute names and values. Thanks for the reminder about watchdogs. I just read a paper on watchdogs starting on page 267 of the Winter 1988 Usenix proceedings. Very interesting, actually, coz it makes good use of a couple of ideas that I'm also trying to use. Namely, (1) that it is transparent, and (2) that it does not allow circumvention by the user, because it is implemented at the system call level. I.e. the user calls open(), close(), read(), write(), etc, but does not realize that a watchdog might actually be controlling all of those operations. So let's suppose (just for the moment) that we are using watchdogs, and we want to implement a GUI that allows applications to be invoked by double clicking on the file's icon. (Remember: we're talking about the user's *preferred* application for that file. If the user wants the GUI to run `od' on files of type `Oracle', sobeit.) Since the open() is supposed to be transparent, the application does not see the metadata, right? Or do we need to update all applications? Assuming the former, how does the GUI itself access the metadata? A new system call? Or is the GUI itself a watchdog? There are various possibilities here. What did you have in mind, Sean? > Wait... let me get this straight: system software never needs to see it, > only user software. So we have to add a system call. ***IF*** we have a system call, mopen(), that accesses metadata, and open() accesses the data itself, ***AND*** we put email-like metadata headers in front of the data in a cartridge, then the system only needs to separate the metadata from the data. It does not need to recognize the name-value pairs themselves, since it only needs to find the end of the headers. By the way, watchdogs require another system call (wdlink()). Another by the way: Have watchdogs been added to POSIX yet? Joshua Osborne writes: > So what happens after some POSIX-meta-data compliant systems come out, > we attach great huge festering gobs of meta-data to our files, then > can't process the meta-data fast 'nuf because we can't sift through > the keys quickly? If you separate the metadata and data on disk, you don't need to sift through the metadata after open(). You need to parse headers in cartridges, etc, but this is not very slow compared to the tape-reading itself, particularly if you pad the metadata to the block size. > We get a new spec: hashed meta-data, new sys-calls, and ... Nope, we don't need to change the specs. > Then what happens when people decide that some meta-data is a per-user > toy ... This has been covered in this newsgroup before. > What happens when I want some meta-data to chain off of environment > variables? (secondary action for Makefile is the value of PAGER...)? This would be a user level change. The system call level spec is unchanged. > Would it be better if Sun had made SunView (or SunTools?) the > "standard" before they learned that NeWS was way better? It seems to me that NeWS is far more complex than the simple system call that I am proposing. Apples and oranges. > A new shell syntax (grep "FOO=.*BAZ.*BAR" <# foo)? Yes, there may be some way to extend the shell syntax. Rahul Dhesi writes: > Frankly, I *don't* think UNIX users should revert back to the Dark > Ages, when there was One Standard Thing they could do quickly with any > file, and everything else took multiple menus and multiple mouse > clicks. I'm not trying to get Unix users to revert to the Dark Ages. I'm trying to allow non-Unix users to use Unix (easily). - -- EvdP
jfh@rpp386.cactus.org (John F Haugh II) (06/26/91)
In article <1792@sranha.sra.co.jp> erik@srava.sra.co.jp (Erik M. van der Poel) writes: >If metadata is added to Unix files, we will grep this way: > > grep foo data What do you propose "grep" do with the infinite number of metadata items that "data" could have associated with it? Your answer had better be "nothing" since it cannot be programmed to deal with all possible permutations of all the possible metadata items that might come and go. What you are suggesting is making something that should be application specific hard wired into the kernel. Every application can't know what to do with every kind of file. Even operating systems, such as VM/CMS which supports file attributes, don't get it right. Programs that only take LRELC=60 text files don't know what to do with an LRECL=80 text file. What makes you think UNIX could ever get it right? -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "UNIX signals are not interrupts. Worse, SIGCHLD/SIGCLD is not even a UNIX signal, it's an abomination." -- Doug Gwyn
jfh@rpp386.cactus.org (John F Haugh II) (06/26/91)
In article <1991Jun25.192743.8968@sco.COM> john@sco.COM (John R. MacMillan) writes: >|However, depending on what meaning (if any) you'd assign to "bloat", >|"the #! hack" may or may not "bloat" the kernel; by my count, it adds 60 >|lines to "kern_exec.c" in 4.3BSD, for example. > >Like you, I'm not a fan of the term ``bloat''. My reason for >mentioning #! was that I felt it belonged in user code, not because >it's big, but because there's no particularly good reason to put it in >the kernel. I'm no fan of bloat either, and I rail against it at every oppurtunity. The "#!" "hack" is not "bloat". As Guy (that was Guy Harris, right?) pointed out, the change is really very minimal. It gets made in exactly one place (the kernel) instead of many others (every command that might include a library module which executes another command) and brings with it certain (dubious) advantages (like set-UID scripts ...) >I don't consider it a loss. If you really REALLY need setuid scripts, >that too can be done without kernel support (ksh has an suid_exec >program to do this). This has the added advantage that it gives the >sysadmin control over setuid scripts. This points directly to why it should be handled in the kernel. We know exactly how to execute shell scripts, it isn't that hard, and we can do it right in the kernel with 60 lousey little lines of code. [ Plus a few to close the set-UID holes if you really insist on set-UID scripts ] -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "UNIX signals are not interrupts. Worse, SIGCHLD/SIGCLD is not even a UNIX signal, it's an abomination." -- Doug Gwyn
pww@bnr.ca (Peter Whittaker) (06/26/91)
(It's been awhile since I've used the application discussed herein: advapologiesance for any errors....) dhesi@cirrus.com (Rahul Dhesi) wrote in <1991Jun26.011529.23375@cirrus.com>: >When I double-click on a C file, I don't always want to just compile >it. Sometimes I want to run lint on it instead. Other times I want to >expand tabs in it. Other times I want to enter my favorite editor to >edit that file. Other times I want to enter my favorite editor in >read-only mode to view that file. Other times I want to enter my >*second*-most favorite editor to edit that file, because I just happen >to need a feature at that instant that that second-most favorite editor >provides. OS/2 has an interesting feature that may be worthy of note: file extension associations. Since OS/2 comes out of the PC world, almost all filenames have a one to three character extension (i.e. prog.exe, proc.c, etc...). The OS/2 File System (a PM-based GUI for file system manipulation and exploration) allows you to associate executables with extensions, and vice versa. If you select an executable, and request an association, you will be prompted for a filename extension. Subsequent double clicks on filenames with the given extension will cause that executable to be launched against that file. Multiple associations are fine. In the case of multiple associations, double clicking a file will cause a modal dialog to appear, asking you to select the executable you wish to invoke against the file, i.e. I associate cc, lint, vi, and more, with the .c file extension Next, I double click on prog.c: the File System then asks me to choose which executable I wish to use against prog.c. As for arguments, you can specify default arguments when you make the original association. These can be overridden when you are selecting which executable to invoke, i.e. the modal dialogue presents you with a list of executables and their default arguments - you single the executable, then edit the argument list. Associations can be added, modified, and deleted at any time, and take effect immediately. Since the association information is part of the File System (which is, after all, an OS/2 application sitting on top of the DOS file system - such as it is :->), there is no meta-data in the file: you can safely ftp your source from a PS/2 to a Sun 4/490 without needing any esoteric resource/file discumbobulation. (IMHO) the OS/2 File System's "associations" are useful, workable, and sensible: they do not modify the files (BIG bonus - no new tools needed); they provide a quick and simple way to do default file handling (double click twice); they provide a convenient IF for changing default arguments; and they allow me to drop to the command line as if nothing had changed (since nothing has :->). (IMHO) if you want to put File Attributes into UNIX, do it in an application that sits above the FS: don't you *dare* modify my FS until you know that what you are doing works, works well, and meets my needs! (Let's not forget about backwards compatibility either: it's an ugly issue, but as UNIX begins to make inroads into the business world, and as more and more end users - i.e. not programmers, hackers, etc... - make use of UNIX as a daily tool, backwards compatibility will become more and more important. (IMHO) standards bloat is worse than kernel bloat: at least you can rewite the kernel and provide the same functionality, without disturbing anything that depends on it.... (is a :-> apropos?) -- Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] Open Systems Support pww@bnr.ca [ ] Bell Northern Research Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C FAX:+1 613 763 3283 [__________________________] Ottawa, Ontario, K1Y 4H7
martin@minster.york.ac.uk (06/28/91)
erik@srava.sra.co.jp (Erik M. van der Poel) responds to my message: > Martin C. Atkins writes: > > Managing the namespace, and standardizing the properties that > > are stored with files is a nightmare! > ... > > > Centralized administration is out > > of the question (no resources to support this, > > It does not take up very many resources to map registered names to > system-specific values. E.g. "FrameMaker" -> "/usr/bin/fm" (or > whatever). This is *not* what I meant! I meant good old-fasioned *human* administration! This system was developed by a small organization kept going mostly by voluntary effort. There is *no way* we could have taken on the workload of maintaining the namespace without charging (a disproportionate) fee to do it. > > > it is too awkward for developers > > Why is it awkward? Developers don't even have to think of their own > attribute names. The central registration organization provides a > list. And they can add new names. As I said there *is no* central registration organization for the names I am discussing. Anyway, if I understand your proposal corrently, what is to stop two developers choosing to use the same name, which does not appear on the current list, at the same time? To ensure uniqueness some kind of coordinated registration/allocation procedure is needed. Also developers must have some say over the names of attributes, so they can make sure the name correctly reflects the meaning of the attribute they are defining. Otherwise we would end up with attributes such as `EXXy55' meaning ``secondary application to invoke when double clicked while meta shift left elbow is valid...'' :-) Anyway this again wasn't what I meant! A central register of attributes is `awkward' for developers because it means that when the developer decides he wants a new attribute for something, he has to mail the registrar, and wait for a reply before he can use it. This would mean that many (well meaning) developers would simply allocate their own attributes, for development and testing, while the bureaucracy gets done. Some of these names are bound to get out by accident, or they might forget to register some... are you proposing a new international crime - promolgation of an unregistered file attribute? Many of my end users are also developers, so whatever procedure is adopted must be *very* convenient, and easy for them (they are generally not computer scientists, and are likely to ignore instructions that they don't see the point of, or don't contribute directly to the task at hand - rightly so, in my view). > > > and totally unenforceable) > > Yes, well, this has always been the case. Well-intentioned > organizations have been producing standards for years, and many > vendors simply ignore the process. Look where that got us today. Yes, and many well-intentioned organizations have been producing PERFECTLY DREADFUL standards for years! Such standards deserve to be ignored. > > > Changes to allow directories to be moved and copied more > > freely seem to be enough to make this a better solution than attaching > > properties directly to the files. > > Yes, this is another alternative. We need to leave the options open. > But what do we do about tapes with metadata headers? Do we access the > metadata through /dev/cartridge/metadata? If you like - at least this doesn't involve cludging up the system! > > > It also makes it much easier to avoid horrible restrictions/implementation > > problems on the size (and the changes in size) of properties. > > The email-like header syntax does not suffer these problems. The email-like header has *exactly* the problem to which I'm refering. Please show me how to change one of the header lines to a value longer than the current value (or insert a new header line), WITHOUT having to copy the rest of the file - remember the sound files I'm dealing with are seldom less than 10 Mbytes in size, and are regularly ~100 Mbytes. So what is the solution? We put the `headers' in another file, and attach it in some way to the data - by putting them both in the same directory, say. No new mechanisms are needed. Martin
greywolf@unisoft.UUCP (The Grey Wolf) (06/28/91)
/* <1780@sranha.sra.co.jp> by erik@srava.sra.co.jp (Erik M. van der Poel) * * > Another problem with the system call idea is * > that you'd then need to make every vendor support it, and use the same * > attributes and so forth for your application to work right. * * Exactly. I have no hidden agendas here, so let me spell it out. One of * my aims is to get something like this into POSIX. This way, many * vendors will feel obliged to support it. You're out of your bleeding tree. As I think someone else will probably mention (or may have mentioned already, I don't know -- we have about a four-day inbound propagation delay on news!), writing standards before we even know WTF we're doing is a BIIIIIIIG mistake. Witness POSIX. There are so many braindamaged things in there which shouldn't be (I won't go into them here). And why, oh why, are you trying to turn my UNIX[*] system into a Mac? You said something elsewhere that (paraphrased) "/etc/magic and file(1) were invented by computer nerds who were worried about performance and disk space usage. Disk space is cheap, and nobody worries about performance these days." That remark would be almost enough to get you lynched in the crowd of people I hang out with (they'd probably be holding me back). I, personally, have become quite disgusted with the move to SVR4 (my opinion, not my company's!) and all the bloating that has happened to the UNIX kernel. Admittedly, I'm not an un-sloppy programmer (I just haven't learned how to put hierarchy symbol tables on disk yet!), but I'm so tired of the approach that "Oh, I have PLENTY of (disk space/memory/ CPU), so I can use it all." What happens then is that we spend our technology before we discover it. A GUI isn't necessarily a BAD idea, just one which shouldn't be enforced. (Keep your Mac off *my* desktop.) IF such an animal *does* get implemented, however, there are some ways to do it: - have a field in a disk inode (ino_t acl_fa or some such) which points to another inode which contains such things as ACLs and File Attributes. ACLs are a *much* better premise for introducing such a thing than are GUIs, though both could be addressed in this way. - keep the file information in a file somewhere (at the individual directory level would require less parsing, though if you have a lot of directories it would chew up space and inodes). - make the file command smarter (we have a file command which doesn't know how to read core files, alas). - re-implement the "file" command in a (pseudo-)intelligent manner within the GUI. As has been pointed out, also, how do you know whether we want to edit or compile (in the case of a c program or a roff source file), or worse: In the case of a shell script, how do you know whether or not the user wants to edit it or execute it? If we click on a program, how will this GUI know whether or not we want to execute it or debug it? What happens if we click on an object file? ...from another architecture? (We could almost make a GUI purity test out of this stuff!) [ Are people so against a keyboard? Is it really just "quaint"? I don't find it so. People must *really* hate typing if they start thinking of this stuff... ] * * Also, we need to officially register names and values, so that * everyone agrees on their meaning (even in the non-Unix world). * Let's worry about this after we settle the first issue, hm? Don't bite off more than you can chew. * * It does not "work fine". It cannot tell what has been stored in a * cartridge tape. None of the GUIs can do this (yet). * So what? Neither can file(1)! (:-,). * - * -- * Erik M. van der Poel erik@sra.co.jp * Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692 This whole battle will likely continue for a few years. It'll be interesting to see who "wins"... -- # "Religion is a weapon invented by the sheep to keep the wolves in line." # greywolf@unisoft.com
erik@srava.sra.co.jp (Erik M. van der Poel) (06/28/91)
greywolf@unisoft.com writes: > You said something elsewhere that (paraphrased) "/etc/magic and file(1) > were invented by computer nerds who were worried about performance and > disk space usage. Disk space is cheap, and nobody worries about performance > these days." I pressed some of the "wrong" buttons. Let me explain. Suppose we have a few guys working on a system that can accept either audio or video data. They decide to add headers to the data to identify the type of data. Their first thought is to use "Audio" and "Video", but someone says that they don't need to use so many characters ("It's inefficient!"), so they can just abbreviate to "A" and "V", since audio and video is all they're worried about in *this* system anyway. In another part of the world, we have some guys working on a database that can be used either for addresses or recipes. Guess what. They chose "A" and "R", coz it was sufficient in their own little world. So now we have ambiguity (audio "A" vs address "A"), ***IF*** the data is not cloaked in some outer context (e.g. labelling the tape: "Acme Inc. Audio/Video System, `Jane Goes to Kindergarten - 1995'"). In the real world, this often works well. But sometimes it doesn't. What if the label is glued badly and is lost? What if the human forgot to label it? And what about: "No no no! That's a DOS floppy. You can't use it like a Unix floppy. You need to type this special command: `blah blah blah'." Our mothers have had just about enough of this, thank you very much. Now maybe there is something to be said for compact representation of metadata on disk (or anywhere else), but I think there is also something to be said for keeping the mapping between that representation and the readable stuff that the human sees, simple. KISS. Perhaps we should keep it compact on disk, and readable on tapes? By the way, if people know of other work in this area, I would be grateful if the info could be forwarded. > - make the file command smarter No matter how hard you work on the `file' command, it will not get smart. We have to make the data smarter. > What happens if we click on an object file? > ...from another architecture? Exactly. If we label these things, at least the system can give an intelligent error message. > * Also, we need to officially register names and values, so that > * everyone agrees on their meaning (even in the non-Unix world). > > Let's worry about this after we settle the first issue, hm? Don't bite > off more than you can chew. What I have done is to think of a reasonable goal to shoot for, and to give an outline of the migration steps to get there. I.e. I want the information technology industry to get together to coordinate the plan(s) and write the specifications, *before* we implement. How many times do we have to take this lesson before we learn it? - -- EvdP
erik@srava.sra.co.jp (Erik M. van der Poel) (06/28/91)
Martin C. Atkins writes: > erik@srava.sra.co.jp (Erik M. van der Poel) responds to my message: > > It does not take up very many resources to map registered names to > > system-specific values. E.g. "FrameMaker" -> "/usr/bin/fm" (or > > whatever). > > This is *not* what I meant! I meant good old-fasioned *human* > administration! Oh, OK, I see your point. Yes, we will need human resources. > Otherwise we would end up with attributes such as > `EXXy55' meaning ``secondary application to invoke when double clicked > while meta shift left elbow is valid...'' This is *not* the sort of attribute to attach to a file. This is something to attach to a user. You might attach the attribute "text" to a text file, but not "vi". > This would mean > that many (well meaning) developers would simply allocate their own > attributes, for development and testing, while the bureaucracy gets done. I agree. We will need a flexible system for temporary local allocation of names. > Yes, and many well-intentioned organizations have been producing > PERFECTLY DREADFUL standards for years! Such standards deserve > to be ignored. Some standards deserve to be ignored. The standards process itself should not be ignored (in my view). More people should take part. > Please show me how to change one of the header lines to a value longer > than the current value (or insert a new header line), WITHOUT having to > copy the rest of the file You just read the metadata into a buffer, editing the line you want to change as you do so, then write the buffer out to the file's metadata. If the system implementation keeps the metadata and data separate, no copying of huge sound files is necessary. - -- EvdP
torek@elf.ee.lbl.gov (Chris Torek) (06/28/91)
[NB: I have misdirected followups; if you really need to reply here, edit your headers to put comp.unix.wizards back.] In article <3540@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >[ Are people so against a keyboard? Is it really just "quaint"? I don't > find it so. People must *really* hate typing if they start thinking of > this stuff... ] It occurred to me during Usenix, while listening to Tom Christiansen playing the piano, that the piano keyboard is a distinctly `unfriendly' interface by the `average user's standards'. Look how long people have to train to be able to use it effectively. Should we replace it with a point-and-click interface? (Of course, this analogy, like all analogies, cannot be taken too far before it falls apart. But it gives the right flavor.) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
bzs@world.std.com (Barry Shein) (06/29/91)
From: torek@elf.ee.lbl.gov (Chris Torek) >It occurred to me during Usenix, while listening to Tom Christiansen >playing the piano, that the piano keyboard is a distinctly `unfriendly' >interface by the `average user's standards'. Look how long people have >to train to be able to use it effectively. Should we replace it with a >point-and-click interface? Well, we have, we call them stereo systems. -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
rcd@ico.isc.com (Dick Dunn) (06/29/91)
erik@srava.sra.co.jp (Erik M. van der Poel) writes: > I.e. I want the information technology industry to get together to > coordinate the plan(s) and write the specifications, *before* we > implement. How many times do we have to take this lesson before we > learn it? This really comes down to "how many times do we have to reject the idea of prototyping, and the idea of trying things out *for*real* (rather than just on paper)?" How many times do we have to learn that the "waterfall model" for software development doesn't work, and that the mistakes it causes are dreadfully expensive? I'm sorry, but spec'ing and standardizing something this big, this radical a change, before implementing (i.e., prototyping) and actually using it is just too stupid an idea to be tolerated. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...Simpler is better.
erik@srava.sra.co.jp (Erik M. van der Poel) (06/30/91)
Dick Dunn writes: > How many times do we have to learn that the "waterfall model" for software > development doesn't work, and that the mistakes it causes are dreadfully > expensive? OK, I see your point that it is important to develop software by building prototypes and throwing them away if they are no good. On the other hand, I think it is also important that we do not release software to end-users until we are reasonably sure that the specs won't change. End-users are hit hard by incompatible changes. As always, we need to find a middle-of-the-road compromise. How about trying to spec it out as much as possible, and then implementing a few prototypes without letting end-users get their hands on them? - -- EvdP
erik@srava.sra.co.jp (Erik M. van der Poel) (06/30/91)
Chris Torek writes: > NB: I have misdirected followups Interesting, actually, coz the article didn't make it across to Japan. I had to go to the States to pick it up. (I found out about the article because Barry replied to it.) > It occurred to me during Usenix, while listening to Tom Christiansen > playing the piano, that the piano keyboard is a distinctly `unfriendly' > interface by the `average user's standards'. Note that I'm not trying to abolish keyboards. I just want to add identifiers to data so that it can be handled almost automatically. I say "almost", because the user does have to be in charge. E.g. no overwriting of files, unless the user says so. Even if we add these identifiers, people will probably want to keep using keyboards for, say, writing netnews articles. Even Macs have keyboards, right? - -- EvdP
erik@srava.sra.co.jp (Erik M. van der Poel) (06/30/91)
John F Haugh II writes: > What do you propose "grep" do with the infinite number of metadata items > that "data" could have associated with it? Well, grep won't even see any metadata if it calls open(). > Programs that only take LRELC=60 text files don't know what to do with > an LRECL=80 text file. If you are referring to fixed record length files, you have missed the point completely. > What makes you think UNIX could ever get it right? What makes you think UNIX could ever get anything wrong? - -- EvdP
miles@cogsci.ed.ac.uk (Miles Bader) (07/01/91)
erik@srava.sra.co.jp (Erik M. van der Poel) writes: > > and totally unenforceable) > Yes, well, this has always been the case. Well-intentioned > organizations have been producing standards for years, and many > vendors simply ignore the process. Look where that got us today. "Well-intentioned" isn't enough... (Or shouldn't be!) -Miles -- -- Miles Bader -- HCRC, University of Edinburgh -- Miles.Bader@ed.ac.uk
mjr@hussar.dco.dec.com (Marcus J. Ranum) (07/01/91)
erik@srava.sra.co.jp (Erik M. van der Poel) writes: >On the other hand, I think it is also important that we do not release >software to end-users until we are reasonably sure that the specs >won't change. End-users are hit hard by incompatible changes. Reality check: have you ever actually *WORKED* with end-users? You never get to find out if your software meets their needs until you release it to them and get their reactions. Sometimes you find out that you've totally missed the mark - then you look really silly if you've gone and spent all that time and effort standardizing something useless. Other times, you find that end-users needs change - sometimes requiring the very incompatible changes you decry. When someone gets up on a soapbox and starts yammering about all the Great Things they're going to do for the user community, I tend to react the same way as I do when a politician starts talking about the Great Things *he is going to do for me. Yeah, right. Your arguments would carry a lot more weight if you stopped writing "I think this" and "I want this" and "I want vendors to that" and maybe cited some hard information that indicates you have an idea that users would be willing to pay for - *that* will make vendors and programmers and maybe even UNIX wizards listen. mjr.
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (07/01/91)
In article <1801@sranha.sra.co.jp>, erik@srava.sra.co.jp (Erik M. van der Poel) writes: > But what do we do about tapes with metadata headers? Do we access > the metadata through /dev/cartridge/metadata? There is a valid point lurking here. When we talk about the metadata for the cartridge tape, do we mean the metadata for the /dev/cartridge special device file or the metadata for the data on the tape? > Rahul Dhesi writes: >> Frankly, I *don't* think UNIX users should revert back to the Dark >> Ages, when there was One Standard Thing they could do quickly with >> any file, and everything else took multiple menus and multiple mouse >> clicks. > I'm not trying to get Unix users to revert to the Dark Ages. I'm > trying to allow non-Unix users to use Unix (easily). Isn't that rather contradictory? This takes us off on one of my wonderments: *why* does everyone seem to think that any joe off the street should be able to use a computer with absolutely no training and do sophisticated and useful things within the first, say, hour? This is not true of a car. This is not true of a chainsaw or even a bicycle. Why should it be a cause for complaint when it is not true for a computer? der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu