file attributes

[The Grey Wolf]

/* <1780 at sranha.sra.co.jp> by erik at srava.sra.co.jp (Erik M. van der Poel)
 * 
 * > Another problem with the system call idea is
 * > that you'd then need to make every vendor support it, and use the same
 * > attributes and so forth for your application to work right.
 * 
 * Exactly. I have no hidden agendas here, so let me spell it out. One of
 * my aims is to get something like this into POSIX. This way, many
 * vendors will feel obliged to support it.

You're out of your bleeding tree.  As I think someone else will probably
mention (or may have mentioned already, I don't know -- we have about a
four-day inbound propagation delay on news!), writing standards before
we even know WTF we're doing is a BIIIIIIIG mistake.  Witness POSIX.  There
are so many braindamaged things in there which shouldn't be (I won't go
into them here).

And why, oh why, are you trying to turn my UNIX[*] system into a Mac?

You said something elsewhere that (paraphrased) "/etc/magic and file(1)
were invented by computer nerds who were worried about performance and
disk space usage.  Disk space is cheap, and nobody worries about performance
these days."

That remark would be almost enough to get you lynched in the crowd of
people I hang out with (they'd probably be holding me back).  I,
personally, have become quite disgusted with the move to SVR4 (my
opinion, not my company's!)  and all the bloating that has happened to
the UNIX kernel.  Admittedly, I'm not an un-sloppy programmer (I just
haven't learned how to put hierarchy symbol tables on disk yet!), but I'm
so tired of the approach that "Oh, I have PLENTY of (disk space/memory/
CPU), so I can use it all."  What happens then is that we spend our
technology before we discover it.

A GUI isn't necessarily a BAD idea, just one which shouldn't be enforced.
(Keep your Mac off *my* desktop.)

IF such an animal *does* get implemented, however, there are some ways
to do it:

	- have a field in a disk inode (ino_t acl_fa or some such) which
	  points to another inode which contains such things as ACLs
	  and File Attributes.  ACLs are a *much* better premise for
	  introducing such a thing than are GUIs, though both could be
	  addressed in this way.

	- keep the file information in a file somewhere (at the individual
	  directory level would require less parsing, though if you have
	  a lot of directories it would chew up space and inodes).

	- make the file command smarter (we have a file command which
	  doesn't know how to read core files, alas).

	- re-implement the "file" command in a (pseudo-)intelligent manner
	  within the GUI.

As has been pointed out, also, how do you know whether we want to edit or
compile (in the case of a c program or a roff source file), or worse:  In
the case of a shell script, how do you know whether or not the user wants
to edit it or execute it?

If we click on a program, how will this GUI know whether or not we want
to execute it or debug it?

What happens if we click on an object file?
...from another architecture?

(We could almost make a GUI purity test out of this stuff!)

[ Are people so against a keyboard?  Is it really just "quaint"?  I don't
  find it so.   People must *really* hate typing if they start thinking of
  this stuff... ]

 * 
 * Also, we need to officially register names and values, so that
 * everyone agrees on their meaning (even in the non-Unix world).
 *

Let's worry about this after we settle the first issue, hm?  Don't bite
off more than you can chew.

 * 
 * It does not "work fine". It cannot tell what has been stored in a
 * cartridge tape. None of the GUIs can do this (yet).
 *

So what?  Neither can file(1)! (:-,).

 * -
 * -- 
 * Erik M. van der Poel                                      erik at sra.co.jp
 * Software Research Associates, Inc., Tokyo, Japan     TEL +81-3-3234-2692

This whole battle will likely continue for a few years.  It'll be
interesting to see who "wins"...
-- 
# "Religion is a weapon invented by the sheep to keep the wolves in line."
# greywolf at unisoft.com