file attributes
Erik M. van der Poel
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 er...@sra.co.jp
Software Research Associates, Inc., Tokyo, Japan TEL +81-3-3234-2692
Jamie Mason
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
Boyd Roberts
> 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 bo...@prl.dec.com
``When the going gets wierd, the weird turn pro...''
David G. Paschich
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
dpas...@ocf.berkeley.edu
"Can Spam increase sexual potency? `No!' say scientists!" -- Trygve Lode
This space 4 rent
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 er...@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 |
JP...@PL118a.cc.lehigh.edu | I was just a child then;
JP...@Lehigh.Bitnet | now I'm only a man. [pf]
JP...@ns.cc.lehigh.edu |
jea...@lehi3b15.csee.lehigh.edu |
LU...@VAX1.cc.lehigh.edu |
Erik M. van der Poel
> 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.)
Scott Simpers
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 sco...@qsp.com
Chris Siebenmann
| 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
c...@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
Erik M. van der Poel
> (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
> 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 ...
Doug Gwyn
>> 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.
Erik M. van der Poel
> /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.
klaus u schallhorn
>In article <17...@sranha.sra.co.jp> er...@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]
>
>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
Boyd Roberts
> 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.
Lyndon Nerenberg
>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 || lyn...@cs.athabascau.ca
Packet: ve6...@ve6mc.ab.can.noam
As a math atheist, I should be excused from this. --Calvin
Erik M. van der Poel
> 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.)
Barry Shein
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 | b...@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
Marcus J. Ranum
>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.
Marcus J. Ranum
>> 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!!!!!
Tom Christiansen
: 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 tch...@convex.com convex!tchrist
"So much mail, so little time."
Barry Shein
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.
Andrew Hume
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.
Andrew Hume
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
LEWIS WILLIAM M JR
>>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.
Doug Gwyn
>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.
John R. MacMillan
|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... ]
Barry Shein
From: gw...@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
Doug Gwyn
>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.
David G. Paschich
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
dpas...@ocf.berkeley.edu
Go Colorado Rockies -- Opening Day, Mile High Statium, April 1991
John Curran
as an output filter. I tried the following code segment:
pager = popen("{PAGER-more}","w");
for (...) {
putc(ch++,pager)
}
This works, except that when more displays the output, it is not
possible to stop the display via the "q" command. I added a SIGPIPE
handler to longjmp and close the pipe, but that did not change the
results. I reduced the amount of buffered data by switching to
write(fileno(pager),ch,1), but it still does not stop for files
over 8K. Am I right in assuming that this is a result of the
internal buffering in pipes? Is there a method to force a
smaller pipe buffer?
Thanks,
/John
Erik M. van der Poel
> >the 1/4 inch cartridge tape drive, to automatically select tar or cpio
> >(or whatever) for reading the tape?
>
> 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
> 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).
Dan Bernstein
> 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 M. van der Poel
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
> "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.
Jim Burns
> 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.)
I rather liked the IDEA of ACL lists, being first exposed (briefly) to
them in VMS. The one implementation of them I saw, tho', HP-UX 7.0's, had
a flaw that any time you use 'chmod', it wipes out the ACL list. Seems to
me that chmod should just change the base permissions in the ACL list, not
wipe them out. Chmod permissions and ACL permissions should be more
closely integrated, possibly wiping out conflicting ACL requirements, but
not wiping them out altogether. I hope this practice is NOT 'an accepted
way to meet standards', and not part of POSIX, etc. Any comments?
--
BURNS,JIM (returned student)
Georgia Institute of Technology, 30178 Georgia Tech Station,
Atlanta Georgia, 30332 | Internet: gt0...@prism.gatech.edu
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a
John F Haugh II
>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: j...@rpp386.cactus.org
"UNIX signals are not interrupts. Worse, SIGCHLD/SIGCLD is not even a UNIX
signal, it's an abomination." -- Doug Gwyn
klaus u schallhorn
>> 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.
Guy Harris
>|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....
Dick Dunn
until this came by...
er...@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 r...@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870
...Simpler is better.
Marcus J. Ranum
>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.
Marcus J. Ranum
>[...] 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.
Barry Shein
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.
Erik M. van der Poel
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
Boyd Roberts
> 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 bo...@prl.dec.com
``When the going gets wierd, the weird turn pro...''
Sean Eric Fagan
>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."
s...@kithrup.COM | -- Chris Torek
-----------------+ (to...@ee.lbl.gov)
Any opinions expressed are my own, and generally unpopular with others.
Joshua Osborne
>
>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...]]
--
str...@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..."
- lbr...@eng.umd.edu (Lewis Bruck)
John R. MacMillan
|"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.
Rahul Dhesi
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 <dh...@cirrus.COM>
UUCP: oliveb!cirrusl!dhesi
Erik M. van der Poel
> `human readable'? So what language are you going to choose?
I covered this in my comp.std.internat article:
Message-ID: <17...@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
Peter Whittaker
advapologiesance for any errors....)
dh...@cirrus.com (Rahul Dhesi) wrote in <1991Jun26.0...@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
p...@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
John F Haugh II
>
> 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
>|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 ]
Guy Harris
>call, I would probably have given it a new name,
The whole *point* of the change was to make it *transparent* to existing
programs!
If you decide they're different calls and give them different names, all
the programs out there that use the old calls won't be able to run
scripts. I don't *want* to have to change every single program that
calls one of the exec-family routines just so that it can automatically
run shell/awk/perl/whatever scripts.
>You could also get rid of the ugly hard-coded limits that
>are in kern_exec.c;
E.g., the 1MB hard-coded limit on number of characters passed as
arguments to a program? :-) (Yes, there *are* systems with limits that
large. I hope I don't have to spend very much time ever again on
systems with tiny limits such as 20480 characters....)
Shankar Unni
In comp.unix.wizards, gt0...@prism.gatech.EDU (Jim Burns) writes:
> The one implementation of them I saw, tho', HP-UX 7.0's, had
> a flaw that any time you use 'chmod', it wipes out the ACL list.
Check the -A option to chmod. "preserves the ACL list". It doesn't actually
modify the ACLs, because there is no simple mapping between ACLs and
ordinary Unix permissions. Instead, there is chacl(1).
BACK TO THE FEATURE FLAMES...
-----
Shankar Unni E-Mail:
HP India Software Operation, Bangalore Internet: sha...@india.hp.com
Phone : +91-812-261254 x417 UUCP: ...!hplabs!hpda!shankar
Paul Goldsmith
Are you sure that you are talking about a HP product? Last time I
looked, ACL were part of the APOLLO operating system that HP has been
killing for the last two years. I would be surprised that HP was
supporting a non-mainstream (non-POSIX) feature, and based on their
treatment of Apollo DOMAIN-OS, they wouldn't know what to do with a
good idea if it fell in their laps (which it did, and they didn't)
--
-- Paul Goldsmith
<gold...@concour.cs.concordia.ca> (514) 848-3031
(Shirley Maclaine told me there would be LIFETIMES like this)
the future isn't what it used to be; and possibly, never was (ao)
John R. MacMillan
important one at that) which I've been through many times, so I won't
say anything more after this unless someone says something new.
Guy Harris <g...@auspex.auspex.com> writes:
|>Actually, if I were about to change the semantics of a prominent UNIX
|>call, I would probably have given it a new name,
|
|The whole *point* of the change was to make it *transparent* to existing
|programs!
You left out the part where I said that *now* I would indeed make it
transparent. At the time it was done, I don't think the existing
software base was so large that changing those cases that wanted to be
able to run shell scripts would have been unreasonable, and it would
have given programmers a choice of whether they wanted to exec objects
or run programs (see Statement of Religion, below). This is unrelated
to whether or not it belongs in the kernel.
|>You could also get rid of the ugly hard-coded limits that
|>are in kern_exec.c;
|
|E.g., the 1MB hard-coded limit on number of characters passed as
|arguments to a program? :-)
I didn't say you could fix *all* the ugly hard-coded limits, :-) just
the 29 (32 - 3 for #! and \n) bytes for shell + 1 arg (and the just one
arg, if you wanted to). This is also largely unrelated to whether or
not it belongs in the kernel, although the more complex the
implementation, the less likely you are to want it in the kernel.
Elsewhere, in <19...@rpp386.cactus.org>, John F Haugh II
<j...@rpp386.cactus.org> writes:
|I'm no fan of bloat either, and I rail against it at every oppurtunity.
Well, obviously not *every* opportunity. :-)
|The "#!" "hack" is not "bloat". As Guy (that was Guy Harris, right?)
|pointed out, the change is really very minimal.
I don't think it's big, I just think it's in the wrong place, whether
it's one line or one thousand.
[ Flameproof suit on ]
I wasn't going to say anything on this, but since everyone keeps
quoting the word ``hack'':
I called it a ``hack'' because I felt that it was a feature motivated
by wanting new functionality with minimal code change (ie. work), not
thought out very clearly (were the security problems with setuid
scripts considered?), and as such the code is certainly not something
of which I would be proud, and is not a complete solution. I'm
obviously guessing at the motivation and depth of design, but all I
have to judge is the end result (security problems, incomplete
solution, and ugly code).
Why do I not consider it a complete solution? It only works with
interpreters that ignore the magic line themselves (most do, so it's
convenient), it requires an explicit path be provided in the script
for the interpreter (makes it easy for a 60 line kernel
implementation), and it does not allow flexibility in how the
interpreter is invoked (again makes for easy implementation).
Wouldn't it be nice to have been able to say something like:
/* #! myrexx -v -f !0 -lmylib !*
*/
where /* and */ are the REXX comment delimiters, #! still signifies an
``exec'' like string, and the ! substitutions are csh-like? I
haven't thought this out completely myself, but it seems possible and
not that difficult. This is getting _way_ off topic.
As to why I think the code is ugly, consider the 32 char buffer which
limits you to 29 characters for shell plus one arg, unless the byte
following the ex_shell[] array happens to be '\0', in which case you
get 30 characters, but maybe only part of your shell name or argument
with no error. Besides, it uses a goto. :-) I know there's lots of
ugly code in everybody's kernel but ``everybody's doing it'' is rarely
if ever a good reason for anything.
There are valuable hacks, useful hacks, ugly hacks, even brilliant
hacks, but they're all hacks. I'm not against ``good'' hacks, but I do
like to recognize them for what they are.
[ Flameproof suit off ]
|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 also think it should be made in exactly one place (the library).
Since, as both of you have noted, it is quite small, it does not
``bloat'' every command that might want to execute another command in
pre-shared library systems, and with shared libraries, takes exactly
as much space as it does in the kernel.
Stdio adds much more bulk, including code to format floating point
numbers, into every program that uses printf(3). I don't think anyone
would suggest that it belongs in the kernel to avoid ``bloating''
applications.
|> [ getting around setuid scripts with an auxiliary program ]
|
|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 ]
Above you noted that this was a ``dubious'' advantage. Also, to my
knowledge, the holes exists, and there's nothing a sysadmin can do
about it. That is, not only is it dubious, it's unavoidable. With an
auxiliary program to run setuid scripts, the situation is under
control of the sysadmin. Statement of Religion: New features,
particularly those of dubious merit and/or with security concerns,
should be optional.
Actually, I'm not convinced a few lines would close the security
holes. They would, I presume, fix any problems in the kernel (I've
never really looked at what these might be), but some of the problems
are related to the fact that scripts are difficult to control. Not
only must you have faith in the interpreter, but in every program it
invokes (this is less of an issue in largely self-contained
interpreters such as awk and perl than in ones such as sh and csh).
This, however, is getting off topic (again :-) ).
I'll give you some more ammunition, though: with the kernel
implementation you can exec a script that you don't have read
permission on. This is, presumably a fairly rare case, since in order
for the *interpreter* to open and read the script, it would need
appropriate permissions. If you really wanted to handle this case in
the library, you could presumably use the same auxiliary program that
handles setuid scripts.
To reiterate, I know no *clear* reason why #! should be in the
kernel. It needn't be there for transparency (put it in the library),
or size considerations (it's not big), or even the far-from-clear for
need for setuid scripts. I'd be happy to hear other new reasons, or
carry on ranting by email if anyone is interested.
mar...@minster.york.ac.uk
> 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
Paul Davey
>>>>> On 24 Jun 91 10:28:05 GMT, gt0...@prism.gatech.EDU (Jim Burns) said:
Jim> in article <BZS.91Ju...@world.std.com>, b...@world.std.com (Barry Shein) says:
Jim> I rather liked the IDEA of ACL lists, being first exposed (briefly) to
Jim> them in VMS. The one implementation of them I saw, tho', HP-UX 7.0's, had
Jim> a flaw that any time you use 'chmod', it wipes out the ACL list. Seems to
Jim> me that chmod should just change the base permissions in the ACL list, not
Jim> wipe them out. Chmod permissions and ACL permissions should be more
Jim> closely integrated, possibly wiping out conflicting ACL requirements, but
Jim> not wiping them out altogether. I hope this practice is NOT 'an accepted
Jim> way to meet standards', and not part of POSIX, etc. Any comments?
The best implementation I've seen of ACLs under Unix is in Apollo's
DomainOS (after SR10). Extended permissions could be masked out by a
chmod a-w, but the information was stored and could be recalculated
via an option to the `chacl' command. (There is also an `lsacl').
The ACL schemes I've seen in HP-UX and AIX do not seem as well designed
to me in both concept and ease of use.
The Apollo method also allowed keep and protect permission (required
by Aegis) to be specified for file objects, keep being the inability
to delete a file, protect being the right to change the permsisions.
The other major change was that Apollos have a super-group called
organisation, which is a level of grouping between group and world.
This was hidden from the unix tools, but visible via the ACLs.
Apollos pre SR10 Unix permissions (in Domain-IX were a scream however.
Unix mode was implemented in terms of ACLs in an ACL-cache which could
get corrupted with *bizzare* results. At SR10 key ACLs (basically
those synonymous with the unix permissions) were moved into the
equivalent of the inode (Domain file systems are distributed over all
Apollo nodes) , which can hold a pointer to a block of extended
(normal style) ACLs.
ACLs are very good for security (Unix permissions are too wide for the
higher orange book levels), but in my experience they are too much
trouble to administer on a day to day level for most files. They allow
very great control of permissions on specific files and users or
groups.
--
Regards, p...@x.co.uk IXI Limited
Paul Davey p...@ixi.uucp 62-74 Burleigh St.
...!uunet!ixi!pd Cambridge U.K.
"These are interesting times" +44 223 462 131 CB1 1OJ
USA: 1 800 XDESK 57
Doug Gwyn
>To reiterate, I know no *clear* reason why #! should be in the kernel.
The article was a good summary of arguments against the #! implementation.
While useful, the hack indeed doesn't provide a clean solution to a
general problem; practically by definition, then, it is not properly part
of the system kernel.
Scott Schwartz
In article <PD.91Jun...@powys.x.co.uk> p...@x.co.uk (Paul Davey) writes:
| ACLs are very good for security ... but in my experience they are
| too much trouble to administer on a day to day level for most files.
I had just the opposite experience with Primos, where objects use the
ACL of the directory they are in unless you specifically set one.
File protections were no trouble at all -- much easier than in Unix,
especially if you were sharing things.
The Grey Wolf
*
* > 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 er...@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."
# grey...@unisoft.com
Chris Torek
your headers to put comp.unix.wizards back.]
In article <35...@unisoft.UUCP> grey...@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: to...@ee.lbl.gov
Erik M. van der Poel
> er...@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
Erik M. van der Poel
> 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
John F Haugh II
> I would be surprised that HP was
>supporting a non-mainstream (non-POSIX) feature, and based on their
>treatment of Apollo DOMAIN-OS, they wouldn't know what to do with a
>good idea if it fell in their laps (which it did, and they didn't)
There are POSIX ACLs. Please refer to 1003.6 for more details.
I'm not saying that HP-UX or DOMAIN-OS uses POSIX ACLs, but there
is an emerging standard that will one day give us ACLs ...
Jochen M. Fritz
different manner--a Virtual File System (VFS). Each file in this FS would
contain two links--one for the data, and another a driver program that can
the file. The driver program is the only way that the data can be gotten
at (except a possible failsafe). An open operation would cause the kernal
to run the driver task (as the file owner). The driver would then set
any number of pipes (or sockets) and inform the kernal. If no pipe at
all is set up, this is a denied permission, the read(2) or write(2) system
calls read or write the first pipe, and either another call or a varient
of read and write would read the other pipes (which could contain other
data including attributes if that was provided by the driver.
Aside from allowing the user to maintain his own ACL, this would anyone
(not just root) to add any data that is available in any manner (ie floppy,
FTP, etc) into the file system, thus making mounts obsolete, and special
device drivers unnecessary.
This does require some major changes to the system, but the result would
be an object-oriented OS with files as objects. This archetcture may
well be the next generation of operating systems.
--
Jochen Fritz | There's no way i can say the words more clearly
joef...@rpi.edu | There's no one left to point at anymore
noah (peace monger) | Just you and i and we must make the Choice now.
<>< | And not destroy the life we're living for. (P. Yarrow)
Paul Davey
-> Are you sure that you are talking about a HP product? Last time I
-> looked, ACL were part of the APOLLO operating system that HP has been
-> killing for the last two years. I would be surprised that HP was
-> supporting a non-mainstream (non-POSIX) feature, and based on their
-> treatment of Apollo DOMAIN-OS, they wouldn't know what to do with a
-> good idea if it fell in their laps (which it did, and they didn't)
HP-UX has a different implementation of ACLs to DomainOS. As I said in
a previous posting the ACLs in DomainOS are IHMO superior to those in
HP-UX. Of course Apollo Domain is an HP product now anyway...
Anybody know what OSF/1 has in it? Different again?
Barry Shein
From: to...@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 | b...@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
Sean Eric Fagan
>Each file in this FS would
>contain two links--one for the data, and another a driver program that can
>the file.
It's been done before, as I've mentioned earlier in this thread. Watchdogs.
When the FSF comes out with the GNU OS, watchdogs (or their moral
equivalent) should be relatively easy to add (they've got the trappings in
the filesystem already).
Marcus J. Ranum
>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.
I believe that if you look around you, you'll find that the
intolerable is being tolerated and even supported all over the place. :-P
Is pre-standardizing worse than pre-optimizing, or is it a
solution to pre-optimizing? Set the design flaws in concrete and then
you don't *HAVE* to fix them ever. Hmmm... Maybe that's the dodge. If
it's pre-standardized, you don't have to worry about getting it right.
mjr.
Dick Dunn
> 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 r...@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870
...Simpler is better.
Paul Hite
< In article <4911...@hpcupt3.cup.hp.com> sha...@hpcupt3.cup.hp.com (Shankar Unni) writes:
< |Check the -A option to chmod. "preserves the ACL list". It doesn't actually
< |modify the ACLs, because there is no simple mapping between ACLs and
< |ordinary Unix permissions. Instead, there is chacl(1).
<
< looked, ACL were part of the APOLLO operating system that HP has been
< killing for the last two years. I would be surprised that HP was
< supporting a non-mainstream (non-POSIX) feature,
Well, SURPRISE! ACL's are indeed in HP-UX 7.0 and HP-UX 8.0. It must be
*quite* a while since you've looked...
Paul Hite PRC Realty Systems McLean,Va pa...@prcrs.prc.com (703) 556-2243
"We are trying to bring up an Air Traffic Control display on an X window
terminal and there seems to be some problems." -- from comp.windows.x
Guy Harris
>transparent.
I left it out because it was irrelevant - I would have wanted it done
transparently at *any* time, no matter how few programs would allegedly
have to have been changed.
>At the time it was done, I don't think the existing
>software base was so large that changing those cases that wanted to be
>able to run shell scripts would have been unreasonable, and it would
>have given programmers a choice of whether they wanted to exec objects
>or run programs (see Statement of Religion, below).
I follow a different faith, I guess. I don't *want* to give programmers
that choice; they might make the wrong choice and, for me, the wrong
choice is always "only run executables". I don't want some programmer
trying to second-guess me - or even *forgetting* to update their program
to use the new call. Consider how many bits of SVR3.x came out without
being converted to use the directory library, and fell flat on their
faces when used over NFS; those probably weren't deliberate choices,
somebody just forgot to update the program.
(I also don't like the convention implemented by some shells, wherein
they treat anything that they got an ENOEXEC error from as if it were a
shell script. Fine back in the days when a file system was unlikely to
have executable images on it other than images for the machine to which
the disk containing the file system was directly attached; not so nice
if you can access VAX and SPARC and i386 and 68K and MIPS and...
binaries via some distributed file system.
Some scheme by which interpreted scripts could be explicitly designated
would have been better.)
Larry McVoy
> different manner--a Virtual File System (VFS).
Sort of. SunOS, at least, has a VFS layer (UFS, RFS, TMPFS, NFS, etc,
are all abide by the VFS interface). Unfortunately, there is no
interface in the (current) VFS that allows for extended attributes. As
far as I can tell, this thread has been wandering around mindlessly.
Add an interface that lets you add <name, value> attributes to a file
and another which allows you to query (might want a "*" name to give
back a list) and be done with it. All the normal Unix commands will
ignore this gunk, they'll never know it is there (the exceptions are
things that try to be file systems, like tar, cpio, shar, etc).
Stuff that wants to know, can. What's the big deal? As far as I can
tell, the only interesting part is how you migrate the attributes around.
---
Larry McVoy (415) 821-5758 l...@sunburn.stanford.edu
Erik M. van der Poel
> Stuff that wants to know, can. What's the big deal?
Finally, someone who understands what I'm getting at.
-
--
EvdP
Erik M. van der Poel
> 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 M. van der Poel
> 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 M. van der Poel
> 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 Bader
> 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...@ed.ac.uk
Marcus J. Ranum
>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.
der Mouse
> 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: mo...@larry.mcrcim.mcgill.edu
Erik M. van der Poel
> 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?
When you call open(), the data comes from the tape, right? So metadata
should come from the tape too.
When you `stat' /dev/cartridge, the size field of the returned struct
doesn't indicate the amount of data on any cartridge, does it?
> 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.
Just because some people like stick-shifts doesn't mean that car
manufacturers shouldn't sell automatics, right?
-
--
EvdP
Erik M. van der Poel
> Reality check: have you ever actually *WORKED* with end-users?
Actually, I don't think I've ever *MET* an end-user. What do they look like?
-
--
EvdP
Dick Dunn
to build a prototype before we standardize:
> 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.
There's two ways to read this:
- Don't stuff it in a product and start selling it until it's
been worked out. That's fine--it's an obvious good idea (most
honored in the breach, unfortunately).
- Don't try it out with the people who will use it. That won't
fly; it makes the prototyping a useless academic exercise.
Marek Telgarsky
> 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).
I havent seen the entire message, but I can patch together its meaning
from the replies it has been getting. I have a question for the person
who originally wrote the message. Why make unix what it is not? Unix
was not designed for the user that wants to learn everything in an
hour. Macintoshes were made specifically for that purpose. The user
friendly environment. I personally enjoy working in unix because of
the incredible diversity in commands and the environment. On what
other machine will you find manual pages PAGES long? I think it is
great that you can do so many things. So please, don't think up a new
standard (although im sure all those unix users will *hate* it) for
unix, the old one suits me just fine.
Marek
-*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-
Our thoughts surround us, and there is no escape.
So be weary, traveller...
Marek Telgarsky
mtel...@nmsu.edu
*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*
Marek Telgarsky
What IS an end user? *grin*
Marek
Marcus J. Ranum
Hell if I know - they're the guys that Mr. Van Der Poel was saying
this file attribute system call was going to help. Maybe he has a clearer
idea...
When I think "end user" I think "the person out there who will buy
and use a computer or its software, and will base future purchases on h*
experiences with what they get" - in other words, the "end user" is the
individual who, by a roundabout path, pays for me to sit here in the
evenings and read news in my spare time, so I don't have to wait tables
or dance in a topless compu-geek joint, or something. :)
In past jobs, I've done research in which the "end user" was my
direct funding source - IE: I was a consultant, and if the "end user" didn't
like my product, I got to go hungry. "End users" are just *terrible* when
they can make you go hungry. That's why it's a waste of time to produce
something that will make the "end user"'s life a lot easier without ASKING
them and TESTING a few prototypes FIRST! One of the applications I developed
was slick, and powerful, and the "end user" bless their furry little hearts
wanted something much simpler in mind, and asked me to start over from
scratch - despite the fact that when they hired me to start, they asked for
what I gave them - they changed their MINDS.
Just going and developing a standard and expecting vendors to
invest a penny in supporting it, unless it can be tied into some real world
benefit (IE: sales) is a joke. Stuff like POSIX and whatnot work because
you can't land lucrative government contracts without them.
mjr.
Erik M. van der Poel
> - Don't try it out with the people who will use it. That won't
> fly; it makes the prototyping a useless academic exercise.
OK, how about a further concession? (I'm in the mood. :-)
How about "releasing" it to some of the users that we think will like
this, but telling them clearly that the stuff may change in the
future, and that they cannot exchange e.g. floppies with "other"
users (unless they write floppies in compatibility mode)?
-
--
EvdP
J. Horsmeier
They're green, yeah sure. They're not very tall (4ft). They speak backwards.
They've a trumpet shaped nose and originally they're from outer space.
Jos
+----------------------------------------------------------------------+
|O J.A. Horsmeier AND Software B.V. phone : +31 10 4367100 O|
|O Westersingel 106/108 fax : +31 10 4367110 O|
|O 3015 LD Rotterdam NL e-mail: j...@and.nl O|
|O--------------------------------------------------------------------O|
|O I am a Hamburger (F. Zappa 1974) O|
+----------------------------------------------------------------------+
Constance S. Murphy
I'm 5'7", 135#, green-eyes, brunette, 38 years old,
have some of the best "wheels" around here. Kind
of average-looking, but I do try to do my best with
what I have. Oh...I have a few freckles too! Is
this helpful to you? Maybe now you can spot a "user"
a mile away. ;) Oh yeah...I'm single.
****************************************************************************
I may not be totally perfect, | Internet: cmu...@dcsc.dla.mil
but parts of me are excellent! | UUCP: dsac!dcsc!cmurphy
-Standard Disclaimer Applies- | A/V 850-1031 / (614)238-1031
****************************************************************************
Theo de Raadt
>In article <18...@sranha.sra.co.jp> er...@srava.sra.co.jp (Erik M. van der Poel) writes:
>>Marcus J. Ranum writes:
>>> Reality check: have you ever actually *WORKED* with end-users?
>>
>>Actually, I don't think I've ever *MET* an end-user. What do they look like?
>>--
>>EvdP
>They're green, yeah sure. They're not very tall (4ft). They speak backwards.
>They've a trumpet shaped nose and originally they're from outer space.
Don't forget the fangs. Trust me, you don't want to deal with end users.
<tdr.
--
SunOS 4.1.1: /usr/include/vm/as.h, Line 49 | Theo de Raadt
typo? Should the '_' be an 's'?? | der...@cpsc.ucalgary.ca
J. Horsmeier
>In article <10...@baby.and.nl> j...@and.nl (J. Horsmeier) writes:
>>In article <18...@sranha.sra.co.jp> er...@srava.sra.co.jp (Erik M. van der Poel) writes:
>>>Marcus J. Ranum writes:
>>>> Reality check: have you ever actually *WORKED* with end-users?
>>>Actually, I don't think I've ever *MET* an end-user. What do they look like?
>
>>They're green, yeah sure. They're not very tall (4ft). They speak backwards.
>>They've a trumpet shaped nose and originally they're from outer space.
>
>Don't forget the fangs. Trust me, you don't want to deal with end users.
> <tdr.
Take my advice for it: eat garlic, loads of garlic. They can't stand garlic.
It makes their feet grow sideways. They're about as evil as a Boogie man
can be... I've met a guy once who actually saw an end user a few years ago.
He's still a bit ga-ga nowadays. ;-)
BTW how do you *work* with an end user? What can you do with them? Cut down
trees or something? Smoke them? Catch herring with them?
J. Horsmeier
>In article <18...@sranha.sra.co.jp> er...@srava.sra.co.jp (Erik M. van der Poel) writes:
>>Marcus J. Ranum writes:
>>> Reality check: have you ever actually *WORKED* with end-users?
>>Actually, I don't think I've ever *MET* an end-user. What do they look like?
> Well, since you've asked....
> I'm 5'7", 135#, green-eyes, brunette, 38 years old,
> have some of the best "wheels" around here. Kind
> of average-looking, but I do try to do my best with
> what I have. Oh...I have a few freckles too! Is
> this helpful to you? Maybe now you can spot a "user"
> a mile away. ;) Oh yeah...I'm single.
Watch it guys, a cleverly disguised end user! End users don't look like that!
They're green, absolutely green, no freckles at all.
They've got fangs, huge fangs! And they're not 5ft7, they're 4ft flat.
And they're not single, never! They come in quartets!
Piled on top of each other, sure!
No offence, but this can't be an end user, noway! ;-)
The Grey Wolf
* 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.
So wean them from DOS :-).
*
* 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?
I don't see what this has to do with your original argument of metadata.
What you are trying to do is give users fish instead of teaching them
how to fish, a principle with which I strongly disagree. We're pampering
everyone and his brother instead of attempting to educate them. Most
of the philosophy is "Well, let's make it easier for them to use" instead
of "let's teach them how to use it", and I think it's been a nightmare.
Most of us who are system administrators work in a quite varied
environment, i.e. a mishmash of wizards, programmers, fledglings, competent
and incompetent users. No matter *how* much we use these visual band-
aids and all these whizbang interfaces, it all comes down to the fact that
if something goes wrong, the user is no less perplexed than (s)he was
before. And, in fact, sometimes these wonderful user-friendly whizbang
interfaces can *get in the way* of actually remedying the situation.
Instead of making it "easier to use", let's not necessarily convolute it,
but let's *educate the people using the machines*. Kind of like driver
training, no?
If people are unwilling to learn, I'm unwilling to make it easier for
them to get by.
*
* > - 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.
Oh, come on. There are distinctive things which most files have in them
which will identify them. They're called "magic numbers", a much smaller
subset of your "metadata". If we use this in the right context, we don't
need all your metadata hanging around. If you want metadata, go use one
of those systems on which you must type
grep AP=FOOM:IR=BAMF:FS=011,012,040:SP="stupidity" D0:SYS:FOOBAR
Those files which don't need magic numbers have the right info in the inode;
most of those which need magic numbers have them.
*
*
* > 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.
*look* *at* *the* *first* *few* *bytes* since *every* *architecture*
*has* *a* *different* *loading* *number*. It's that simple.
If it's a text file, fine. You do things to text files, like edit them
or compile them, depending. If it's not a text file, most (the number is
increasing, at least) of the binary file handlers out there are using a
magic number scheme to handle files which belong to them. Cpio is one of
the earlier examples (so is a filesystem superblock...) of this. What's
wrong with keeping this sort of thing going?
All this labeling and metadata and "editing out" stuff is pointless.
Quit using band-aids for this stuff and get some real knowledge brewing.
* > * 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'll say it again. Keep your macintrash interface off my workstation.
*
* 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?
Well, why don't you get together with some other people who share your
delu^H^H^H^Hdreams and work on getting a spec together, run it, test it,
and *then* present it to The Industry? If you have The Industry get
together and coordinate the plan(s) and write the spec, you will end up
with the nightmare which POSIX has become.
* -
* --
* EvdP
--
# "Religion is a weapon invented by the sheep to keep the wolves in line."
# grey...@unisoft.com
Blair P. Houghton
>> Well, since you've asked....
>> I'm 5'7", 135#, green-eyes, brunette, 38 years old,
>
Still and all, I'd ask her out, but I'd need to know what
sort of extended file attributes she's got on her shared
libraries...
--Blair
"Glazes over their green eyes every time..."
J. Horsmeier
baby:1>ls -l cons*
e--------- 38 Jul 06 1991 constance.sa.1
e--------- 38 Jul 06 1991 constance.sa.2 -> /usr/lib/constance.sa.1
e--------- 38 Jul 06 1991 constance.sa.3 -> /usr/lib/constance.sa.1
e--------- 38 Jul 06 1991 constance.sa.4 -> /usr/lib/constance.sa.1
baby:2>
See that, that's what I'm all about: no bits on, but the end user bit! Can't
read, can't write, can't do nothing! Just the end user bit! And piled on top
of each other in quartets, like I said, beware! :-)
j chapman flack
>Actually, I don't think I've ever *MET* an end-user. What do they look like?
And Constance S. Murphy <cmu...@dcsc.dla.mil> wrote:
> Well, since you've asked....
> ...
> what I have. Oh...I have a few freckles too! Is
> this helpful to you? Maybe now you can spot a "user"
> a mile away. ;) Oh yeah...I'm single.
Is this what you'd call an RFP?
--
Chap Flack Their tanks will rust. Our songs will last.
ch...@art-sy.detroit.mi.us -MIKHS 0EODWPAKHS
Nothing I say represents Appropriate Roles for Technology unless I say it does.
Jay Logue
it shows.
Jay.
Root Boy Jim
In <BZS.91Ju...@world.std.com> b...@world.std.com (Barry Shein) writes:
>
>From: to...@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'
>>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.
AHA! Two with one blow! Funny as usual, Barry.
But back to Chris. Walk thru any suburban mall (do they have
malls out there :-). Sooner or later, you'll pass a music store
selling those fifth-generation organs with built in rhythm
sections that plays everything but the melody for you.
This pleases me as much as all these newfangled interfaces.
Oh, and I wouldn't worry about Tom.
A piano is relatively simple compared to perl.
P.S. I propose renaming the piano pedals `shift', `control', and `meta'.
--
[rbj@uunet 1] stty sane
unknown mode: sane