>>> Please come back when you have a real technical reason for why ACLs
>>> will be detrimental to ffs and/or NetBSD as a whole.
>> It is cruft that is too specialized to be put in all the FFS code.
> Take your crusade elsewhere and go read ACL implementations instead
> of babbling your rants against them.  You [...] aren't open to the
> idea of doing an ACL implementation correctly, the way NetBSD
> projects are done.

I think isildur's point is that putting ACLs into the main FFS code
cannot be "doing [it] correctly", regardless of how good an
implementation of ACLs it may be.  (But see below.)

Since "correct" is not a thing that can be settled as a question of
fact, here, this will always remain opinion.  It won't help anything to
treat it otherwise - such as by asking for "a real technical reason"
and then calling the offered opinion a "crusade" and using words like
"rant", for no visible reason except your disagreement with the offered
opinion.

Your (tv's) opinion on this matter may have enough of the NetBSD
community behind it to ram it through in spite of our (isildur's, mine,
possibly others') disagreement.  That doesn't make our opinion any more
of a rant or crusade than yours.

As for technical merits...I can't see any way an ACLified FFS
filesystem could possibly interoperate with a completely non-ACLified
FFS kernel; almost by definition, the non-ACLified kernel won't know
about however it is that the ACLs are stored and hence won't, for
example, be able to free it when an object with ACLs is destroyed.
You'll have to either bloat the mainline or lose interoperability.

I'd rather see the "attached files" suggestion implemented (mechanism,
not policy, y'know); using an attached file to implement ACLs could be
a (truly optional) "feature".  (An attached-file filesystem will not be
compatible with a current FFS kernel, for similar reasons, but as I
sketched, I can't see any way around that.  For compatability reasons,
I'd rather see an extended filesystem called something other than FFS,
even though it may share much of its code with FFS.  (This can be done;
ext2fs is an example.)

> We'd like to return to discussing the technical aspects of ACLs now,
> so please take your nonsense somewhere else.

I don't know what "we" you think you're speaking for here (I don't
think I've seen more than one voice raised, besides yours, in support
of doing ACLs), but this *is* discussing the technical aspects of ACLs
- specifically, whether (not how) they should be added to the main
NetBSD tree.  It sounds to me as though you've already made up your
mind that they should be and are not interested in any possible
arguments that disagree with that, preferring instead to use words like
"nonsense" and "rant" to attack any such arguments.

It may work, in that you may get your way; it wouldn't be the first
time objections have been ignored.  But calling the objections invalid
doesn't make them so.

Since it appears the decision that ACLs will go in has already been
made, somehow, apparently without any public discussion and debate (in
that all arguments advanced for the "con" side have been dismissed as
rants and nonsense, even though the whole discussion boils down to "I
like it" and "I want it" versus "I don't like it" and "I don't want
it" - the onus seems to have somehow been shifted from those who want
to make a change to those who want to prevent it), I don't expect to be
saying much more on the subject.  But I can't let this sort of
"argument" pass without pointing out what it really is.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B