some strong points there... just 1 thing about the grsec/vserver combo: i do change stuff to make linux-vserver and grsecurity work seamlesly together. It's just that i don't have the time to re-engineer grsecurity, pax AND linux-vserver completely to make a perfectly integrated combo patch. The reason why i don't deem this necessary is that there is just a very small overlap in the functionality they both implement. Since they are not "doing" the same and don't interfere much (except some atomic operations, "selectable kernel parameters" and so on...). I just try to please you in such a way that you would be happy to have this kind of patch in "your project" ;) Greetings, Rik Bobbaers -- http://harry.enzoverder.be linux/unix/system/network/security/hardware admin infrastructure architect > On Thu, Oct 21, 2010 at 02:27:15PM +0200, Rik Bobbaers wrote: >> Just a small question, bertl: > > first, please don't hijack threads, especially closed ones > (I can only consider this trolling :) > >> People that use vserver in production environment want a >> stable environment. > > then they should pay some developers, preferably the > existing ones, to do the testing and code cleanups > >> If you ever want linux-vserver to become something widely >> used and accepted, there should be a stable patch, there >> should be warnings if something is wrong and so on... > > there should also be contributions, this isn't a one > man show. period. > >> You should inform people as much as possible and cooperate >> with people doing packaging for distributions. > > I always cooperate with any distro maintainer and even > volunteered a bunch of times to do the initial port for > a given distro (to ease adoption) > >> As i get it, you hate every distribution in the world and >> don't want to have anything to do with their patches. > > no, I do not want to maintain any distro patches over > a longer period, and that is mainly because I am only > one person, and after all, that's what distro maintainers > are for (maintaining distro specific packages) > >> If you just say: that's a crappy kernel, just upgrade... >> it's fun when you're playing around. > > well, what should I say about a crappy kernel then? > >> not if you 've been doing tests etc for weeks >> before putting stuff in production. > > if you are referring to the debian kernel, I strongly > advised against using the 2.6.26 patches, but despite > my warnings, it was adopted, and of course, it turned > out to be a fiasco ... > >> Right now, what we have is a very clear dev version of >> util-vserver, a 2.3 patch series that's relatively stable >> and testing version of the utilities > > I do not consider the experimental releases 'dev' or > production ready, despite the fact that they work fine > in production for many people out there > >> All the rest is is very old (kernel 2.6.22 and 0.30.215 >> of util-vserver). >> Whenever someone asks a question about a kernel that old >> or version of util-vserver that's that old, you just say: >> upgrade to the latest. > > no, the latest stable release and stable util-vserver as > well as older stable releases will work fine, as they are > thoroughly tested, and given that somebody reports a bug > to that kernel/patch version, it will of course be fixed > > folks come to me with 'obscure' kernel versions, because > their distro or hardware or simply because they randomly > picked a kernel version and complain about issues which > are usually known and already fixed in more recent patches > > there are a few maintained branches (I do that exactly > because those are long term kernels to be used by distros) > like 2.6.27 or now 2.6.31/32 and of course recent kernel > branches to give some choices ... > >> so essentially, you're saying "put the latest >> unstable/testing kernel in production, but don't >> complain if it dies, because i call it dev, so >> you're on your own." > > what I am saying (usually) is, if you want a recent > kernel/patch, you have to live with experimental, because > we do not have the resources to do the required testing > for a stable release ... > >> All that i do for the grsecurity/linux-vserver patch, >> i just do because people want it. >> There are many people that really use it and find it >> useful... > > good, that's why we have the patches linked on the > main page, no? > but I doubt that you do the extensive testing required > to label those patches 'stable' and that doesn't even > relate to the Linux-VServer part :) > >> so here's the question: What is your view on this >> project? do you really hate all the users that want >> this to be production-ready? > > definitely not, all users that want a stable release, > please start testing/reviewing the code/contributing > to the project, so that we can get there eventually > >> do you really hate the grsec/vserver patch? > > I am fairly indifferent about the grsec patch ... > I hate the fact that folks believe that adding the > grsec patch to the mix will increase security out > of the box (without doing proper setups) and I hate > the fact that there is no properly adapted grsec > which handles the special aspects of Linux-VServer > >> if so, just say so, and i will stop doing anything >> all together. > > It seems that the community likes those patches, so > the only folks you would hurt are those who use the > patches ... > >> If you keep saying: you're using a distro kernel, so >> screw you!, i don't want to be involved. > > I'm saying: if you want to use a distro kernel, how > broken it may be, go ahead, be my guest, but if you > encounter known or unknown issues with that kernel, > you have to contact the distribution maintainer and > not me ... > > once again, I cannot fix every distribution kernel > out there, mostly because I do not have the time for > that and in certain cases (debian for example) because > they refuse to fix issues at all ... > >> It's normal that people want something that WORKS. >> If you say: the only thing worth running now is 2.3 >> with the latest util-vserver, then make it stable/ >> support it/whatever! but don't tell people "there > > all recent kernels/patches are 'supported' and well > maintained ... > >> is no reason not to upgrade to the latest version of >> everything", when that version is unstable and not >> working properly > > let me put it this way, why not install linux-2.6.36-rc1 > with the coresponding Linux-VServer pre-release patch? > > probably because -rc2 to -rc7 fixed issues found during > mainline stabilization, and similar happened for Linux- > VServer patches, so AFAICT, there is no reason whatsoever > to use linux-2.6.36-rc1 in production ... > >> Sorry for my rant, but some people here (including me) >> would like something stable that's not almost 3 years >> old. > > then start contributing to the stabilization, it's a > community project after all .... > >> If not, this project can be considered dead and people >> will abandon this project. > > as with Linux-VServer guests, this project will be dead > when the last 'user' dies ... > >> so for me it's time to choose: or, you start making >> it work and start supporting stuff or, this project >> will die because of frustration of all the users that >> just get a : you don't have the latest utils that just >> got out yesterday and you don't use the patch i >> uploaded 2 days ago. > > well, there is no way to travel back in time and fix > issues before they get into a patch, so if somebody > comes to me with a known (and thus fixed) issue, then > I'll advise him/her to use the fixed patch/tools because > that is the easiest way to get the problem solved ... > > I don't think it would be better to advise them to > backport changes to their kernel version, because that > is the job a distro maintainer is supposed to do, given > that they want to stick with an older kernel. > >> just my 2 cents, >> >> KR, >> >> Rik Bobbaers >