Re: Willing to change LSM so secondary defaults correct

crispinat_private

Greg KH wrote:

>On Fri, Dec 27, 2002 at 02:53:03PM -0800, Crispin Cowan wrote:
>  
>
>>Therefore, I conjecture that OWLSM imposes very small overheads at the 
>>micro-level, and no measurable overhead at the macro level.
>>    
>>
><translating>
>  - I haven't even glanced at the OWLSM code, but in theory it should
>    have no overhead at all, anyone want to verify this?
></translating>
>
><summary>
>You can take the professor out of the college, but you can't make him
>stop acting like he's still there.
></summary>
>
Guilty :-)

I don't *think* I keep my role in LSM a secret, but no, I don't write code.

On the other hand, I observe that there are 590 people on this mailing 
list, and a majority of the work is done by 4 people (Greg, Chris, 
Stephen, and James). A majority of the remainder is done by the next 
dozen or so contributors. So there's over 500 people out there with 
interest in LSM and nothing to do :-) and I thought this would make a 
good starter project.

>><stirring up the hornet's nest>
>>
>>   * Greg: what parts of Stacker did you find that looked slow?
>>   * David: assuming Greg comes up with concrete complaints, what is
>>     your rebuttal?
>>    
>>
>Nice try, but honestly, I don't really care about the stacker module.
>
Well, you claimed it had potential to be slow, and I'd like to know if 
that is really an issue or not. Particularly if there are architectural 
issues, which need to be addressed sooner than later.

>Any module that I care about will just use the capabilities code
>directly, just like the current owlsm and root_plug modules do.
>
That's the alternate approach: just force all modules to work with all 
other modules in the sets of modules that "you" care about. The problem 
is that the list of modules may grow large, and it may become 
intractable to go hacking them all to get the combination "you" want, 
especially if some of those modules are under active development by 
someone else.

>But I can see how it would be a neat research project, and as such, do
>not see a problem with it being slow :)
>
I don't see creating a fast MUX as a research problem :)

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX                      http://wirex.com/~crispin/
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
			    Just say ".Nyet"