As Herbert already said
> It seems that the community likes those patches, so
> the only folks you would hurt are those who use the
> patches ...
and it would be great to have a patch for the recent 2.6.32.25. I just wanted
to let you know that there are folks eagerly waiting for that and really
appreciate your work (oh I'm hijacking the thread a little ;-) )
And for the other part of the discussion Herbert is doing great work and lot's
of support - and every upstream support asks people to go to the recent
(unmodified) patchset to reproduce problems - and that is even with payed
support. Getting such a good and free support brought by volunteers I would
do anything they ask for - well almost ;-)
It is my own responisbility to test and approve the patches before taking
them in production environments - as it is the same with official distro
updates. So far, I had less problems with those experimental patchsets than I
had with official distro approved stuff.
So both of you, please keep up the good work, and thanks for the last years.
bye,
Oliver
Am Donnerstag, 21. Oktober 2010, um 15:15:38 schrieb Rik Bobbaers:
> 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
Received on Mon Nov 1 12:36:52 2010