Subject: Re: Support for ACLs
To: Thor Lancelot Simon <>
From: Lord Isildur <>
List: tech-kern
Date: 03/10/2001 16:09:30
> This has been done -- see the extended flamage on the unix-preservation
> lists over the "Quasijarus" project, which unsurprisingly has managed to
> accomplish ~nothing, since its goals ultimately degenerate to "stay the
> same forever".

There are other efforts less stagnant. The quasijarus project has a 
fanaticism against _everything_ that didnt emanate from CSRG. Not all of 
us share this agenda. I, for one, do preserve old BSD, but i dont have
a problem with keeping it more up to date. I just have a different idea of
how it should be done: my opinion is that focus should be on hardware 
support, correctness, bug fixes, consistency with the themes and original
design methodology of the UNIX system, and perhaps more userland 
diversity or complexity instead of kernel complexity. I see compatibility
with non-BSD systems as not very important, and support for features
of other systems as not very important. I run multiple architectures, 
multiple OS's, and i like the idea of an extremely diverse environment of
systems and hardware. I dont see that any given OS should have to support
the features of all the rest. NetBSD has been aiming for this, and i must
say that i am impressed with the extrent to which we have achieved this while
stil preserving extremely high quality and intelligent design, but i also
think this sort of practice causes us to lose focus and bloat the system
irreperably, in the end. 

> That said, I think we realy *do* have an issue that we add too much
> functionality without thinking about it hard enough, and that even when we
> attempt to do so in a modular way, we can't help penalizing our historical
> platforms for that modularity itself (calls through function pointers are
> NOT free, just as one obvious example applying to the kernel).  There have
> been effective strategies for dealing with this in the past, but sadly they
> have never made it into mainstream kernels or even the toolchains that
> support them, which is a shame; see Synthesis and its use of code overlay
> and the superoptimizer, for example. 

I can only agree with this!