From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Fri 29 Nov 2002 - 08:44:38 GMT
On Fri, Nov 29, 2002 at 09:23:01AM +0100, Jon Bendtsen wrote:
> Justin M Kuntz wrote:
> > Jon,
> > You wrote:
> > JonB
> > ps: i would like if someone tried to get vserver merged with the Linus
> > tree
> > during the next devellopment kernel series. (2.7 ?)
> it would have been nice, and much more easy to see what i wrote and what
> you wrote if you used the standard of setting > infront of what you
> > I agree with this. The technology is getting very good and seems stable to
> > me. I think we need to work toward having Linus include it in the main
> > kernel since it improves the security of Linux tremendously when properly
> > used (or at least it seems to!).
> if it only seems to, then it's not good. It add's extra complexity, so
> the result _MUST_ be extra security. But i believe it does add extra
> > I have no idea to go about getting things integrated, it seems like there
> Well basicaly it's like this:
> Someone makes a small patch to Linus's tree, and email it to him. It
> should be small so he can see what it does. Hopefully he merges it, if
> Keep trying. In the end he'll either complain or include it. It might
> a while though, and _DONT_ try right now, there is a code freeze.
[Linus Explains his Patch Policy]
> > are a few of these inner circle people that do that. I guess what people
> Well, it might help if Cox and others like vserver and merges it with
> their tree. But you dont need to be known to get included, only submit
> good code. You dont need to be the original devellopper, you just need
> to know the code and send Linus small patches.
> > like you and me on the list would like is an update from Jacques on what
> > his plans are to get this stuff merged.
> I think it would be better if Jacques (the vserver main devellopper?)
> does it himself. But it doesnt have to be that way. If he resists, you
> are free to fork() and start Jserver ;-D
I guess there are a lot of loose ends ...
- kbuild kernel config (to enable/disable/configure)
- per server virtual memory limits
- quota/device handling (within servers)
- permission issues (like the chmod 0000 /vservers)
these issues are not realized by vserver people,
because they want the stuff to work (so more tolerance)
but what would the typical linux user think?
maybe Jacques should discuss such issues more often
with the list, or maybe some kind of WikiWiki todo
list would be beneficial ...