Prev: System with 12 CPUs will not boot
Next: running a bash command with a timeout
From: Grant on 11 Jul 2010 19:27
On Sun, 11 Jul 2010 08:48:45 -0400, Jean-David Beyer <jeandavid8(a)verizon.net> wrote:

>Grant wrote:
>> On Sat, 10 Jul 2010 00:13:35 -0400, Jean-David Beyer <jeandavid8(a)verizon.net> wrote:
>>
>>> Grant wrote:
>>>> On Fri, 09 Jul 2010 14:23:54 -0500, Ignoramus30064 <ignoramus30064(a)NOSPAM.30064.invalid> wrote:
>>>>
>>>>> My default route (if I could not ask here) would be to pick a kernel
>>>>> that the most RHEL is using.
>>>> "
>>>> 2.6.32-stable
>>> I am curious. I run
>>> Red Hat Enterprise Linux Server release 5.5 (Tikanga)
>>> and the kernel it runs is 2.6.18-194.8.1.el5PAE
>>> It was released March 2007 and is supported for 7 years.
>>>
>>> It looks as though RHEL 6 Beta 2 is using kernel-2.6.32-37.el6.i686.rpm
>>> so it is very likely that you will have to wait until RHEL 6 comes out
>>> to get a 2.6.32 kernel in an RHEL release. This will be supported for 7
>>> years after RHEL 6 is released (my guess: sometime in late 2010).
>>
>> What are you curious about? Redhat have always (well, as long as I've
>> known about them, since 1996) run non-standard kernels, one of the
>> reasons I stopped using redhat six years ago.
>
>I was confused when someone posted that the most recent kernel Red Hat
>was using and the reply was 2.6.32 that will not be a RHEL kernel until
>RHEL 6 (not yet current except in Beta 2).
>>
>> GregKH works for Suse. But Suse and Redhat are major supporters of
>> the linux-kernel effort by paying many of the top developers. That
>> doesn't change whatever patchset they choose to add to their own
>> distribution kernels. A Linux company's direction might be a little
>> different from Linus' direction, but it is not a fork of the kernel,
>> simply that some patchsets are not seen as being so useful to the
>> generic linux-kernel.
>>
>> If you're happy with RHEL, don't worry about it. Redhat know what
>> they're doing.
>>
>> I thought OP's query was about which is best kernel to select,
>> disregarding distros.
>>
>> For that, I suggested an extended maintenance release.
>
>OK. I misunderstood and thought that you were replying to the
>immediately preceding poster who was talking about RHEL. RHEL do offer
>extended maintenance (7 years), but that, too, is a different meaning of
>extended maintenance that you seem to mean. (I am not implying that this
>means you are wrong; I am only saying that you and Red Hat mean slightly
>different things by the same term -- a problem that often happens in
>natural languages.)

Sure, I'm not worried about what you're saying, as we are talking apples
and oranges, you stating redhat's, me stating lkml's policies as far as
this goes. Both trying to be correct at differing points of view.

And, at the moment I'm only tenuously following lkml for the -stable
series,I don't think I've put a patch into the kernel for the last
four years :( But others did ask about -stable policy on lkml early
in the year, and I quoted the 'official' lkml response upthread.

Some background:

As times goes by it gets more difficult to backport patches to an old
kernel -- as the very fabric around an issue may have changed so much
it is simply too much work to backport a fix. The rules for -stable
kernel series patches are quite strict in that the patch must be part
of the latest kernel, this keeps the -stable on track, but is also why
they fall off being maintained after a time.

The 2.6 kernel series is a developmental kernel follow an evolutionary
course, that's why there's no 2.7 development kernel, as we had 2.1, 2.3
and 2.5 development series that morphed into the 2.2, 2.4 and 2.6 stable
series.

Too much is changing out there in the real world of drivers and diverse
needs of say ARM SoC at one end through to IBM Z-series big iron at the
other, with the hi volume x86 in the middle.

I guess from Redhat's PoV, a long-term -stable kernel series in the
kernel is likely to have had very close to all bugs found and squashed,
thus a good contender for commercial use. And possibly a lot more
tested than other mainstream OS's out there.

Grant.
First  |  Prev  | 
Pages: 1 2 3
Prev: System with 12 CPUs will not boot
Next: running a bash command with a timeout