latest kernel? [General Linux]

From: Greg Russell on 16 Mar 2010 00:07

In news:kua377x8db.ln2(a)goaway.wombat.san-francisco.ca.us,
Keith Keller <kkeller-usenet(a)wombat.san-francisco.ca.us> typed:

> On the other side of that, yes, RH still does patch their kernel, and
> have in the past produced kernels that were not very high quality
> compared to the main line. (But I haven't had any problems with
> CentOS 5 kernels, so perhaps this situation is improving, or perhaps
> I'm simply not using it in a way that exposes the RH kernel's flaws.)

Bear in mind that the current CentOS 5.4 kernel is 2.6.18-164.11.1.el5,
substantially older (about 1-1/2 years?) than the "kernel-2.6.29.6-1.xxxxx"
that you state for RH.

From: Keith Keller on 16 Mar 2010 00:38

On 2010-03-16, Greg Russell <grussell(a)invalid.com> wrote:
>
> Bear in mind that the current CentOS 5.4 kernel is 2.6.18-164.11.1.el5,
> substantially older (about 1-1/2 years?) than the "kernel-2.6.29.6-1.xxxxx"
> that you state for RH.

That was for Fedora, not for RedHat; I apologize for the lack of
clarity. Yes, the RHEL kernel is pretty old by now, so if you need a
newish feature you will need to get a newer kernel through outside
sources.

--keith

--
kkeller-usenet(a)wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

From: Moe Trin on 16 Mar 2010 15:29

On Mon, 15 Mar 2010, in the Usenet newsgroup comp.os.linux.misc, in article
<kua377x8db.ln2(a)goaway.wombat.san-francisco.ca.us>, Keith Keller wrote:

>Moe Trin <ibuprofin(a)painkiller.example.tld.invalid> wrote:

>> _A_ solution to that is to grab the source rpm that corresponds to
>> the kernel you are using. I don't have a listing handy, but this
>>(from an old Fedora 11 listing) is representative:
>>
>> kernel-2.6.29.6-217.2.8.fc11.i586.rpm
>> kernel-PAE-2.6.29.6-217.2.8.fc11.i686.rpm
>> kernel-2.6.29.6-217.2.8.fc11.src.rpm

>I take exception to this on two levels. First, Fedora is *supposed*
>to be experimental. To expect its kernel sources to be pristine is
>a bit much.

Please re-read what I wrote here. I am showing filenames and suffixes
and not making a statement that this kernel is representative of
ANY distribution.

>Second, more applicable to RH, some of those patches are security
>backports to the kernel they used at the time, under the basic idea
>that as much should be ''stable'' as possible through the EL lines.

]] and what you want to look at is the .spec file it contains, and
]] the patches - that will give you a clue as to how badly they are
]] ``improving'' the kernel. Even if the kernel isn't the very
]] latest, you will find that it has a lot of stuff cherry-picked from
]] the latest - even from release candidates, as well as up-to-the-moment
]] security fixes.

Ummmm....

>On the other side of that, yes, RH still does patch their kernel, and
>have in the past produced kernels that were not very high quality
>compared to the main line.

Hell, they managed to produce an entire _release_ that was well below
their own standards. Or have you forgotten RH 7.0 'guinness' back in
2000. Hit a search engine for 'rogue compiler' if you've forgotten.

>(But I haven't had any problems with CentOS 5 kernels, so perhaps this
>situation is improving, or perhaps I'm simply not using it in a way
>that exposes the RH kernel's flaws.)

I think they learned a lot from their earlier mis-steps, and are now
producing a much better product. But as Greg Russell notes, this
stability comes at a cost of having base parts (such as the kernel
source) well behind ``today'' and RH is back-porting features and
fixes rather than staying closer to today. This is true of other
'enterprise' or 'stable' distributions as well, and the act of
choosing a distribution should consider all of these implications.
Choosing a distribution/release based on the color of the box, or the
splash-screen, or the name alone probable isn't a reliable solution.

Old guy