Commitment to Open (Red Hat News)

Having very recently worked for a company that was/is trying to evaluate a reasonable support strategy which included Novell, CentOS, and OEL, I can see what and why RHAT has done what they have done. It both makes sense and does not cause the sky to fall.

This does not affect either CentOS/SL or Fedora. CentOS makes it a point to only rebuild RH SRPMs to be *exactly* binary compatible. They do some patches but only on top of that base and rarely. I just checked the Fedora git and, in fact, things are better now that they have migrated fully to git. We even still get patches that are still swimming upstream.

We have to remember that this applies to these weird things called "enterprise kernels" and to little else. OEL offered a .32 kernel for RHEL5 for good reason. Soon, any new server will only have Intel's Sandybridge parts and backporting full support to a 2.6.18 (RHEL5) kernel would be a nightmare. RH is only offering limited support in RHEL5. The whole "stable" thing is a fig leaf over a basic conflict between an enterprise customer's wanting nothing to change *forever* while at the same time wanting to use the very lastest hardware and have access to *all* its cool features. In the end, this is a "you can't get there from here" and someday, the corporate CIOs (will|may) figure it out. In the meantime, it is hard slogging to keep maintaining ancient "stable" kernels. It makes much more sense to rebase (as OEL has done for 5) but CIOs want the fig leaf of a "stable" RHEL5 kernel (with it's 5000+ patches). BTW, GKH has ranted on this very topic from time to time. Why should RH enable the commercial support under-bidders who leach off them?

If your h/w refresh cycle is measured in small numbers of units over 3-5 years, this is all a non-problem. If you are a large enterprise and have *lots* of machines and the constant refresh cycle that implies, stay closer to mainline kernels and allocate the resources to do it. There ain't no free lunch even if it is GPL.