Slashdot Mirror
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."
There are tons of kernel patchsets out there. some (ck-sources for example) include 2.6 code as well.
Red Hat's applying a few patches.
.config files are compatible (i.e. make oldconfig). The config/menuconfig/xconfig interfaces are the same. Red Hat's kernels track kernel.org version numbers, but just apply extra patches.
I use Red Hat's distribution.
I don't, however, use their kernel; instead, I use a kernel.org kernel that I compile myself.
The fact that this isn't just possible, but is easily (i.e. drop-in) possible, indicates that There Is No Problem Here.
The kernel is binary compatible. The
This is not a "fork" of the kernel in any meaningful way.
STOP . AMERICA . NOW
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).
"None of the major distributors ship a pure Linus kernel"
actually, slackware does ship vanilla kernel.
--- d'oh
If you are serious about Oracle + Linux, then you will run it under RedHat.
When its something like Oracle, you choose the application, then the OS to match.
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
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!
Only 'flamers' flame!
Does slashdot hate my posts?
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 :)
My company sells product to large enterprises, and most of them run one of the RedHat expensive-support options. We've seen few instances of other commercial or custom distributions.
For a list of the 2.6 features that have and have not been back-ported into 2.4 for the current RH Enterprise Linux release, look here.
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.
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
Not true. UnitedLinux and SuSE are also certified. In fact Oracle is compiled not on Red Hat, but on SuSE.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
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
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).
world was created 5 seconds before this post as it is.
RHEL is designed for enterprise use. RH just can't go and change the kernel. There are tons of software like Oracle and Peoplesoft that were coded against the 2.4.x kernel. Back porting allows Red Hat to add features without breaking those large enterprise packages. Even backporting has issues. Oracle had some install issues when NPTL came into REHL. Red Hat is using Fedora for testing. So the next version of Fedora Cora (2) will have the 2.6 kernel. Then Red Hat can take what they learned and put that into RHEL 4. RHEL is a much slower moving target then your typical Linux distro and that is exactly what the big enterprise software developers need/want.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
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.
You don't have to take my word for it. There are plenty of posts already that claim there is compatibility between distributed RPMs and the vanillia kernel found straight from places like kernel.org.
So where is the lock in? You can choose to abandon the prepackaged (and tested) build and build your own version of the 2.4 on your RHE system. You just have to patch it by hand when you come across a piece of software that needs a kernel feature. If this isn't what FOSS is supposed to give customers I don't know what FOSS is supposed to be doing for buisnesses!
It would be one thing if Red Hat was just dumping kernels out there but this is far from the truth. They back port and support it. This is entirely misleading: it isn't forking but kernel customizing.
One cannot fork unless the upstream kernel is will not contain the backported functionality... Redhat claims they verify that the backports are accepted upstream before they backport. However, managing this could be complicated.
Going from 2.4 to 2.6 worked great on Debian and Gentoo, but they automatically download the proper extras for you whereas RedHat only distributes single RPMs for everything. I see where my mistakes were, but the problem lies with RedHat and the way they distribute software.
I think that your problem is understanding how RedHat distributes software. Your upgrade worked ok on Debian or Gentoo because the version you were using supported being upgraded to a 2.6 kernel.
RedHat does not support RH9 upgrading to a 2.6 kernel, but you can do it if you look for instructions.
RH9 is really not meant to be upgraded
Sure it is. Grab yum and pull RH9 up to FC1. Then use yum to pull FC1 up to FC2 test - voila, a RedHat distribution that supports a 2.6 kernel.
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
It's not trivial, but it's not all that hard either. After all, the Red Hat file structure hasn't changed and each version of Red Hat or Fedora Core is closely related to the last.
;-)
/dev/psaux to /dev/input/mice, but this is now well-documented (i.e. search for "kernel 2.6 mouse" in google and you'll get the same answer).
I'm using kernel-2.6.3-1.116 (from Fedora Core) in RH9. Here's how to do it:
1. Download a 2.6.x kernel RPM from the Fedora repository. Try to install in in RH9 with rpm -U. You'll get a list of failed dependencies.
2. Download the needed/depended-upon RPMs from the same Fedora repository.
3. rpm -U *.rpm.
4. Reboot.
I think I had to download/upgrade maybe a total 12 packages or so to get a 2.6.x kernel package to install into Red Hat 9. Then, once I had confirmed that I had a working 2.6.x-ready system, I proceeded to immediately download vanilla 2.6.5 and roll my own.
The only speed bumps that I ran into were:
1. The X config, in which I had to change my mouse from
2. My own hack-ugly kludge to sr_mod.c to enable my USB DVD-RAM drive no longer works in 2.6.x. I haven't yet dug into sr_mod.c to fix it in 2.6. But most people won't have this problem (i.e. their own patches that will need to be rewritten).
STOP . AMERICA . NOW