2.4, The Kernel and Forking

darthcamaro writes "We all assume that the kernel is the kernel that is maintained by kernel.org and that Linux won't fork the way UNIX did..right? There's a great story at internetnews.com about the SuSe CTO taking issue with Red Hat backporting features of the 2.6 Kernel into its own version of the 2.4 kernel. "I think it's a mistake, I think it's a big mistake," he said. "It's a big mistake because of one reason, this work is not going to be supported by the open source community because it's not interesting anymore because everyone else is working on 2.6." My read on this is a thinly veiled attack on Red Hat for 'forking' the kernel. The article also give a bit of background on SuSe's recent decision to GPL their setup tool YAST, which they hope other distros will adopt too."

Comments

RHEL Backporting, fine by me.

[Erik_]

I *might* agree with the CTO of SUSE if Red Hat backported features, but didn't support them. Yet that is not the case. Red Hat promises a 5 year support for their Enterprise Linux releases, and I'm willing to pay for such a support. For my company's systems, I don't need to stay on the edge of new features, tools and other improvements. I NEED a stable operating system, requirering low change management (expect for security issues).

yeah .. and..

[josepha48]

Redhat has done their own thing as far as kernels go for the past I don't know how many years.

There 2.4 kernel has support for lmsensors, which is not in 2.4 default. They have support for more drivers to. So what. Redhat will support these features if they put them in their kernel. They have to, especially since there new business modle is selling redhat OS for a pretty penny.

I would think that Fedora would just make their system 2.6 asnd 2.4 compatible when Fedora core 2 comes out.

I've had issues with Redhat doing things like this in the past, and you can still use the default kernel with Redhat, you just have to know what you are doing.

SuSE has their own kernel too. They are just upset cause they didn't think of it first. Some people will not want to upgrade to 2.6 because of its newness, but they will want the features. If these can be ported back, and supported by Redhat then what is the big deal? Its open source people and as long as Redhat gives the source code away also they are well within their rights under the GPL. Remeber the GPL says something about "use and modify as long as you give the source ...". They always have done this and always will. So what!

Re:Damn redhat

[dougmc]

like xinetd, on regular systems, it was just inetd, then redhat had to be all different and put an x in front of it. *shakes head*

Xinetd was a replacement inetd that was created many many years ago, and used by some systems administrators who wanted more control over inetd than the standard inetd gave. It gives you what tcp_wrappers does, plus a lot more. It worked on most *nix platforms -- not just Linux. (in fact, I think it's even slightly older than Linux.)

Xinetd wasn't just something that Red Hat threw together to upset you -- it was a well tested, established package that they decided Red Hat would benefit from.

And Red Hat didn't just put the x in there -- it was there long before Red Hat existed :)

Kernel API changes

[_Eric]

As a kernel module developer, I saw that those backports included API changes in the kernel. The API seen from a module is not the same in RH's kernel and the vanilla one (with the same version number). This is not something that one cannot overcome, but code gets bloated by this kind of constructs:

#if LINUX_VERSION_CODE > KERNEL_VERSION(2,4,18) && RED_HAT_LINUX_KERNEL
if (remap_page_range (vma, start, offset, len, vma_page_prot)) {
return -EAGAIN;
}
#else
if (remap_page_range (start, offset, len, vma_page_prot)) {
return -EAGAIN;
}
#endif

And it got even worse with RHEL3.

Re:Oh, please

[ivan256]

Backporting 2.6 features helps everyone because it subjects those features to more testing, meaning that 2.6 will be better as a result.

Unlikely. Testing of features that have been hacked back into an older kernel won't provide representative results. You'll only find the most glaring of bugs through that kind of testing, and the hope typically is you find those before you put them into production anyway.

The real effect of backporting features is that it scares off third party developers. Companies that want linux drivers for their devices have to pick a version to work with. RedHat's backports are notorious for changing things in the driver interfaces. That means a vendor, who may not be informed as to the dynamics of the kernel development process, may choose to support only RedHat's version of the kernel, to speciffically not support RedHat's version, or worst and most likely, to not support linux at all.

I've done consulting and contracting for all three types of companies, as well as one who tried to support both RedHat's tree and Linus' tree from the same code base, and believe me when I say that it's a mess. Let's just hope that somewhere along the way RedHat decides to pick a versioning scheme that makes it easy to tell their features are in there at compile time, and starts providing change logs so you can figure out what they've done. As of right now their stuff is a nightmare.

2.4 vs 2.6.. Yes, real work is still being done

[marz007]

Folks,

2.4 Kernals are still being widely used in applications that are doing real work for real world applications. Just because the bleeding edge is well into 2.6 doesn't mean the rest of us who have better things to do besides compile kernals on a nightly basis need to upgrade. A lot of applications require stability, long periods of time that you can't make major changes so as to not upset the development or even production envionment.

RedHat is just trying to keep their Enterprise customers happy and patched with security fixes and some minor feature enhancements. Like it or not, they are a real company and have to make real $$ which means they have to listen to their customers who pay that $$$. The customers can't or won't upgrade to the new 2.6 kernals right away, they need to bring it in-house, test and redo their programs that are running production databases, programs,etc.

Hell, RedHat 8.0 to RedHat 9.0 is painful enough for most folks. Now going to RedHat Enterprise or SUSE or Mandrake..etc. That's painful, read expensive in time and money.

Get over yourselves.. I can compile customer kernals, but frankly I have a lot more better things to do with my time. RedHat knows this..and they're helping their customers do the job of actually getting business done.

I'm thinking of starting the process of going to a 2.6 based distro probably sometime in the Fall. This means it probably won't be in any production server until after New Years at the earliest.

-=TekMage

Re:The fear

[leandrod]

> If you are serious about Oracle + Linux, then you will run it under RedHat.

Not true. UnitedLinux and SuSE are also certified. In fact Oracle is compiled not on Red Hat, but on SuSE.

Backporting != Forking

[jaylee7877]

RedHat backports 2.6 features (actually they'd be 2.5 features) to provide the most powerful kernel that they can support (i.e. make it run stable). If RedHat was planning on taking 2.4 and moving in a different direction that would be a fork and it would be a problem. But RedHat has already announced that RHEL 4 will use the 2.6 kernel. Any vendor who builds an app that depends on backport patches and won't run on 2.4 or 2.6 vanilla is just plain stupid. Yeah, it can be done, heck you can lock yourself into pretty much any platform you want as a developer, but why? RedHat has made it clear that 2.6 is the future. That's good enough for me

Re:slackware

[gl4ss]

slackware is 'major' and it's 'commercial' to boot.

so it's a major commercial distro shipping vanilla kernel.

(however small in terms of people working, it's still regarded 'commercial' even by themselfs iirc).

Re:Vendor adds lots of patches to kernel

[Anna Merikin]

It is almost never trivial to install a new major version of a kernel on a distro not designed for it -- and RH9 was not designed for 2.6. That's why backporting of newer features can be a Good Thing.

Until three months ago, I used RH-6.2 with many features backported from 2.4 including USB support. I also have successfully installed plain jane kernels from kernel.org and custom kernels of my own. No probs that can be traced to incompatibilities -- just nincompooperies on my part.