From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Thu 17 Feb 2005 - 19:18:29 GMT
On Thu, Feb 17, 2005 at 01:55:10PM -0500, Stephen Frost wrote:
> * Herbert Poetzl (herbert_at_13thfloor.at) wrote:
> > On Thu, Feb 17, 2005 at 12:18:31PM -0500, Stephen Frost wrote:
> > > Actually, a bad choice.
> >
> > well _in your opinion_ that is ;)
>
> I don't believe there's really any serious question about the usability
> of 2.6.10 (which I believe is what Lars was referring to when he was
> talking about a 'vanilla' kernel- please correct me if I was wrong on
> that) on a machine running iptables/conntrack.
>
> > > > - mainline (vanilla) kernels get more testing
> > >
> > > But continue to have bugs in them, hope you're not doing much 'net
> > > traffic w/ that 2.6.10 kernel and iptables- it's got a bug wrt handling
> > > RST packets, as in, it doesn't handle them well and your conntrack table
> > > will get filled up. This is fixed in the Debian kernels.
> >
> > it is also fixed in the prepatches for the stable
> > kernel release (2.6.11-rc4)
>
> Yes, but I don't think that's what the discussion was about.
>
> > > The Debian kernels also get a fair bit of testing themselves, I don't
> > > know if it's more than vanilla kernels or not, but it's probably less
> > > than RedHat kernels.
> >
> > nobody said that debian kernels are untested, and
> > maybe they get more testing than the mainline kernels
> > but for sure more feedback happens on lkml for mainline
> > than for debian ... no?
>
> Debian kernels get quite a bit of feedback.
>
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=kernel-source-2.6.10
> http://lists.debian.org/debian-kernel/2005/02/threads.html
>
> Perhaps not as much as lkml, but Debian isn't developing the kernel,
> just trying to maintain it. A better comparison would be to the
> feedback RedHat or Suse gets.
yes, and if you sum up all the distros feedback regarding
the kernel then you might compare it to the feedback the
mainline kernels get ... which IMHO is superior to any
distribution specific feedback ...
> > > > - linux-vserver patches for vanilla kernels get more testing
> > > > - issues and bugs are easier resolved with more feedback
> > >
> > > Debian's kernel team is actually rather responsive to handling bugs and
> > > getting updates into their kernels to fix the problems in the vanilla
> > > kernels (of which there's been more and more lately...).
> >
> > which isn't the point here, as I was talking about
> > linux-vserver issues and bugs, which AFAIK are not
> > resolved by Debian's kernel team but by the linux-
> > vserver's kernel team ;)
> >
> > anyway, I never did and never will disencourage
> > anybody willing to provide quality support for some
> > distribution or spezialized patchset, on the contrary
> > I'll support anybody doing so, as best as I can, and
> > you should know that by now ;)
>
> My only issue is with you appearing to recommend kernels with serious
> known bugs over Debian kernels with a claim about more testing and
> because vserver patches patch cleanly with 'vanilla' (ie: released, imv)
> kernels.
90% of all 'supposed to be' linux-vserver issues are
debian issues (I'm still confident that this will change
in the near future), but all linux-vserver testing is
currently done with the mainline kernels and patches, so
it is natural that I recommend them over 'self' patching
them ontop of vendor specific patches, especially if they
tend to release newer kernels with older versions ;)
> If people are really interested I'll provide a vserver patch
> which patches cleanly against Debian sources.
would be great, just make sure that the following is true:
- folks know where to get them, and do not adapt the
mainline patches themselves
- 'your' patches keep up with 'our' development/bugfix
cycle (i.e. you track the prereleases and rcs too)
- you get some decent testing on the 'adapted' debian
version before you put them in the wild
this has worked before, so I'm pretty sure it is possible
again, and as I said, I have absolutely no problem with
a debian kernel patch, if it is maintained and tested ...
best,
Herbert
> Stephen
> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver