On Sat, 10 Mar 2001, Lord Isildur wrote:

# Date: Sat, 10 Mar 2001 15:00:23 -0500 (EST)
# From: Lord Isildur <mrfusion@umbar.vaxpower.org>
# To: Robert Elz <kre@munnari.OZ.AU>
# Cc: Todd Vierling <tv@wasabisystems.com>,
#      der Mouse <mouse@rodents.montreal.qc.ca>, tech-kern@netbsd.org
# Subject: Re: Support for ACLs
#
# what?
#
# On Fri, 9 Mar 2001, Robert Elz wrote:
# > I am going to ignore all the noise from the past day on this issue,
# > and concentrate only on the technical issues.
#
# um, that 'noise' was the sound of opinions that differ (evidently) from
# your own.

This "noise", actually, if you want to be constructive about it, is called
"discussion", which is what we're all about.

To summarise, I agree that ACLs would be useful to some degree, and I have
a suggestion:  Does anything exist that still uses inode #1?  Do we *still*
have bad sector forwarding that does that?  We could put the ACL information
there.  Of course, fsck seems to want to link anything it finds with links
and size, but no name, into lost+found...

Summary of "The BSD Way":  On one side, we have the people who believe that
progress is essential.  On the other side, we have the people who believe
that progress is fatal.

At the risk of sounding paradoxical, you're both right, and you're both
generating quite a discussion.  The problem is that neither side wants to
listen to the other, and that's quite a schism to have created and for
which to have taken responsibility.

Pure UNIX has been debated for years and years and is still being debated.
For all intents and purposes, the last "pure UNIX" was, I hate to say,
SVR3.  The last pure BSD was, for all intents and purposes, 4.3.  I never
saw 4.4 make near the wide distribution that 4.3 did, because most
educational facilities were switching away from the hardware that 4.4
was to run on.  But the white paper was evidently enticing enough and
ripe with features (and there was Net2/Lite and 4.4/Lite) to draw the
people in and spur the progress.  The unsigned short end result was,
well, here we are, along with the GNU folks, and Linux (who are not
necessarily the same camp, I might add).

At this point, I'm probably degenerating into noise, trying to get back
on track.

I don't like the idea of file associations.  I, too, think it smacks too
much of Windoze, and I consider it one of the primary abominations thereof.
Of course, they do it purely by extension registration, but this kind of
information has no place in a filesystem layer.

The other offence which Windoesn't has is that everything conceivable has
been black-boxed and dumbed down to the lowest common denominator.  I use
something besides windows because I don't FIT in the LCD.  I have a brain.
I make use of it on a semi-regular basis.  I *don't want everything to be
a black box*.

Now if this disagreement on the further metadata extensions is taken to
be noise because it's a disagreement, well, we've a one-sided discussion,
then, which is nothing more than mass mental masturbation with the do-wants
sitting there wanking off against a brick wall.  I think if you look at
what's being said and why, you may find some insight as to why file
application metatyping and the like are not truly important to this crowd.
If you really want something like that, it belongs at the user interface
level, not in the kernel.

Back to ACLs, now I think those are actually more important.  I don't use
them.  I have never used them.  I have suffered through them on WindoesN'T
because I've had to.  Does this mean they're not useful to anyone?  No.
To me?  Yes.  Permanently?  Probably not.

The trick is to do it correctly, which means that it gets done such that
those of us who elect not to use them can disable them without a performance
penalty favouring those who elect to have them enabled.  "Correctly" also
means that a fs with and a fs without ACLs will not have "BAD/DUP BLOCK
(I=2112)" notices showing up on the console, or (worse) "panic: ialloc:
dup ialloc()" crashes.

After all this noise is said and done, it is going to boil down to:

	Can this be done correctly as it stands?

	If so, which fs layer(s) are we going to need to modify?  Since
	we're doing vfs->(every_other_fs), some vfs hooks will need to
	be put in, possibly returning EINVAL if ACL is not compiled
	into the kernel, for example.  We'll probably need hooks into
	ffs/ufs and nfs, as well; likely others.

	If not, how much will fsck, newfs, dump and restore
	need to be modified to make this work, and how badly would
	this mangle the existing filesystem format?  Would it be to
	the extent that we'd need to invent a new filesystem to replace
	ffs?

	[in fact, both sets of questions will probably have to be asked
	 anyway.]


I see that ACLs will make it in at some point.  It will happen.  Iff it's
done right, the ones who fear change will have aught to fear, and the
ones who propose change will have a feather in their cap.  If it's NOT
done right, we've just cut off our middle digit at the fifth joint.

Regarding version numbers:
	No, we're not Linux.  No, we're not Windows.  Version numbers
	right now only indicate decided stable placeholders, it seems,
	as I don't see a lot of extra functionality dropping in.
	Version number updates really ought to indicate some serious
	progress.

	But the trick is who decides serious progress?  Something small
	to one may mean that a whole slough of programs works, suddenly,
	for someone else.

Regarding features:  See above.

Personally, I think there's a lot of stuff we really might consider
deprecating.  How far back do we REALLY need to keep the compat stuff,
for example?  Do we really need compatibility with 1.2, 1.1, 1.0, 0.9,
NOMID and 4.3 anymore?  [Just say yes, provide me an example, and I'll shut
up, then.]  We could, for example, reclaim some of our syscall space
(setdomainname, uname, getdomainname have not been in use since 0.9 --
 about 10 years ago!  How legacy can we get?).

#define NOISE
"I mean, I'm all for BSD, but we might ferioufly confider trimming the
cruft."

Well, I'm done for now.  Apologies for anything irrelevant I may have
contributed.

				--*greywolf;
--
*BSD: Beyond Windows