Interview with Linux-VServer Project Leader (MontanaLinux.org)
ML: How long have you been working on Linux-VServer and how did you get started? Bertl: I started as an simple user back when the project was called 'Linux Security Contexts', maintained by Jacques Gelinas. Everything back then was very rough and edgy, many possible exploits, no resource management, no SMP support. But I liked the idea of the Project and soon I had a bunch of patches sitting on my desk, improving this behavior or adding that feature."
Posted Nov 11, 2007 9:27 UTC (Sun)
by arekm (guest, #4846)
[Link] (11 responses)
Posted Nov 11, 2007 16:31 UTC (Sun)
by maks (guest, #32426)
[Link] (6 responses)
Posted Nov 11, 2007 20:11 UTC (Sun)
by khim (subscriber, #9252)
[Link] (2 responses)
Both VServer and ReiserFS were technically brilliant, both will go "the way of OS/2 and *BSD": some people will continue to use VServer and ReiserFS for years, but "general public" will use something else (probably OpenVZ-based patches plus new code). Numbers matter. Best technology does not always win. Today Vserver is more popular, but if they plan to have their own playground which is protected from mainline kernel developers influence... they should know it's the way to irrelevance... OpenVZ folks are aware of that, VServer developers, sadly, don't... "Political decisions" are PITA, but they trump technical ones 9 times out of 10: most people don't need technically perfect solution, they want "good enough" solution which is easy to use and where users go developers eventually follow...
Posted Nov 11, 2007 20:42 UTC (Sun)
by kolyshkin (guest, #34342)
[Link] (1 responses)
I guess that by "politics" Herbert means that if you want to include something to mainstream, you have to deal with the other developers -- ask them to review your patches, react to their comments, fix your code, adapt to their needs (or change their views by explaining why you did it this or that way) etc. This is what interview calls "useless extra work", but this is how Linux kernel development is working, and you have to deal with it if you want to be a part of the game. As a recent example I can give you a short story of PID namespaces work done by OpenVZ and IBM -- first versions of patches got comments that two-level hierarchy of PID namespaces is not enough -- instead multilevel one is required, so one can create a PID namespace inside another PID namespace (and eventually container inside a container inside a container etc). It is not easy to develop multilevel PID namespace with little overhead (ideally with no overhead at level 0 and very very little at level 1), and neither OpenVZ nor IBM (AFAIK) are interested in multilevel containers (at least as of now). Still, they implemented just that, and after another few iterations PID namespaces were finally accepted into 2.6.24rc1. It looks more like a team work and listening to people requirements that politics. Another (more recent) example of "useless extra work". We are now targeting net namespace, and the plan is to do existing network code review first, to clean it up a bit. Yes, somebody would call that "unneeded extra work", this is not a "sexy" task, and this is not a primary goal of OpenVZ project -- but this is a good thing that needs to be done, because it improves the future maintainability, makes the code easier, cleaner, etc. This is what a couple of OpenVZ guys are doing at the moment (as you can see from linus git) to everyone's benefit.
Posted Nov 12, 2007 16:37 UTC (Mon)
by dowdle (subscriber, #659)
[Link]
Posted Nov 12, 2007 16:19 UTC (Mon)
by dowdle (subscriber, #659)
[Link] (2 responses)
Posted Nov 13, 2007 16:34 UTC (Tue)
by maks (guest, #32426)
[Link] (1 responses)
Posted Nov 13, 2007 17:53 UTC (Tue)
by dowdle (subscriber, #659)
[Link]
Posted Nov 12, 2007 16:10 UTC (Mon)
by dowdle (subscriber, #659)
[Link] (1 responses)
Posted Nov 13, 2007 16:23 UTC (Tue)
by maks (guest, #32426)
[Link]
Posted Nov 13, 2007 18:03 UTC (Tue)
by Bertl (guest, #49022)
[Link] (1 responses)
Posted Nov 13, 2007 23:44 UTC (Tue)
by k8to (guest, #15413)
[Link]
Interview with Linux-VServer Project Leader (MontanaLinux.org)
Fortunately there are other people pushing lightweight containerization to mainline. Too bad
that vserver people are not interested in that. If you are linux server admin and you try some
kind of containerization (openvz or linux-vserver) you never want to go back - it's very
usefull thing.
External patches like vserver are nightmare. Take a current situation as example - there is no
vserver patch for currently supported Linux kernel 2.6.23. vserver team wasn't able to deliver
one (too much changed in mainline I guess).
Interview with Linux-VServer Project Leader (MontanaLinux.org)
2.6.22 is also still stable supported, but yeah latest is more important. ;)
but yeah it kinda really sucks to use "politics" as vague excuse not to submit stuff. also the
asked questions where much too soft, i'd be interested to hear more on critics: as for example
olpc plans to drop vserver (irc their main argument was the staying oot, but there may be
others args too). ipv6 support comes also pretty much late.
on the positive side vserver support in Debian is very easy. vserver team is really responsive
on bug reports and their number is very low although it is quite deployed. the patch also
doesn't fluctuate that much as Xen. Xen is a maintenance nightmare, it really generates a wave
of bugs. Looking forward to takeover by kvm.
VServer will go ReiserFS way...
VServer will go ReiserFS way...
Regarding work being done to go into the mainline
When I get a chance, I plan on writing up an article about how OpenVZ and Linux-VServer are
different... including the technical aspects (well, from a sysadmin's point of view), how the
projects and their developers differ, how their focus differs, and how their userbase differs.
It has been brewing in my head for some time. There isn't a clear winner between the two nor
should there be... both are fantastic but different.
The idea started from this humorous article:
From Zero to Virtualization: Linux-Vserver vs. OpenVZ
http://www.fsfe.org/it/fellows/rca/from_out_there/from_ze...
I'm glad to see the containerization aka control groups code going into the mainline... and I
realize all of the work that involves... and I can certainly understand why the OpenVZ project
would be working in that direction while the Linux-VServer fokls aren't. I can tell you that
the Linux-VServer developers will be keeping an eye on the mainline code that gets added and
then adapt their code to use it where appropriate... so even though they aren't part of the
internal process that is going on in mainline, it will affect their work.
This begs the question, why do some projects continue to maintain external patch sets? I know
many of them have what they consider to be good reasons.
Interview with Linux-VServer Project Leader (MontanaLinux.org)
Well, Bertl gave a concrete example on why he didn't want to get involved with the black-hole
that getting stuff into mainline seems to create but we decided to leave out the example
because it gave the perception that he was bitching at them.
Regarding leaving out harder questions, I wasn't aware of the issues you vaguely mention. I
recommend you go back to the article and leave comments asking your own questions in a clear
manner, and given enough time, you might actually get a response.
Interview with Linux-VServer Project Leader (MontanaLinux.org)
I raised them here as the feedback of the lwn reader is valuable.
it's your business to do sufficient research before interviewing.
your response seems to allude a strange physics understanding. Getting code mainline is the
best way to see them widely deployed and used. The hugest oot patch -rt maintained by ingo
brought lots of interesting feature into vanilla .
Interview with Linux-VServer Project Leader (MontanaLinux.org)
> it's your business to do sufficient research before interviewing
I'm happy with my level of research... and it isn't a "business"... but thank you for caring.
The reason I recommended putting a reply on the site the article is on, is because more people
who read the article would see it... rather than the subset who got there from LWN. Also,
although I've recommended to Bertl that he sign up for an account here (on LWN) and
participate, he doesn't want to dedicate the time. That isn't to say that he'll respond on
montanalinux.org but I think he'd be more likely to. On second thought, join the #vserver IRC
channel on irc.oftc.net and ask the developers directly.
> your response seems to allude a strange physics understanding
I was just relaying what I was told by the project leader. It wasn't my assessment. I'd just
love it to magically show up in mainline. It is easy for people like you to want something...
especially when you don't have to do any of the work.
I'm speaking for myself and my understanding of the Linux-VServer project, so don't think this
is an official statement or anything... because I'm not even a member of the project... but I
think the work that would be required of the Linux-VServer team to get their input into the
control groups process that is going into mainline now... would change the very nature of the
Linux-VServer project and as a result they aren't interested. What do I mean by that... the
Linux-VServer developers do what they do because of some practical reasons... and some less
practical reasons. They use their own code... and they enjoy the team and the community they
have built... and the whole process that exists. It is fun. Switching from their current
state to one of doing all of the things it takes to get into mainline... I would imagine...
change it from being fun to being a complete pain in the ass. They don't have a lot of
developers so I'm sure it would tie them up and the Linux-VServer code would suffer... and
what little scraps they got into the mainline would hardly resemble Linux-VServer.
If you want it in mainline, you can do all of the work required to get it there. What? You
don't want to do that? Well, don't blame them then.
My guess is that the Linux-VServer project will remain like it has been for years now... an
external patch to the mainline that is constantly developed to take advantage of new features
that appear in the mainline (and that'll include all of the control group work going in there
now).
Interview with Linux-VServer Project Leader (MontanaLinux.org)
Why is Linux-VServer not currently being available for 2.6.23 a "nightmare"? No distros,
aside from Fedora 8 (that I know of) are shipping with 2.6.23. I don't believe that the
OpenVZ project has a tree for 2.6.23 yet either.
Interview with Linux-VServer Project Leader (MontanaLinux.org)
oot is a nightmare. not keeping up is just the symptom.
Interview with Linux-VServer Project Leader (MontanaLinux.org)
patch-2.6.23-rc6-vs2.3.0-pre1.diff 18-Sep-2007 17:28 834K
patch-2.6.23-rc9-vs2.3.0-pre2.diff 07-Oct-2007 12:28 833K
Interview with Linux-VServer Project Leader (MontanaLinux.org)
Some context would be good. Are these the diffs of vserver against the mainline kernel? Are
these the diffs of the mainline kernel against itself?
That might help hint at the point you are making. Right now I am baffled.