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).
But is this testing in a different context or enviroment -- i.e., of a patch or feature in 2.4 instead of 2.6 -- useful? More precisely, is such testing as useful as the testing of the patch or feature in the enviroment for which it was designed, i.e., 2.6?
Only Women Bleed (Sex, Sharia remix)
"None of the major distributors ship a pure Linus kernel"
actually, slackware does ship vanilla kernel.
--- d'oh
uCLinux has been merged back into 2.6.
-73, de n1ywb
www.n1ywb.com
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.
" If you are serious about Oracle + Linux, then you will run it under RedHat."
/proc AND skipped an error during the install it came up just fine. The install error was a mistake in one of makefiles during linking. I had to run it after the fact after tweaking it.
Actually I've had problems with RedHat and Oracle (8 and 9). RedHat 7-9 and the RHAS 2.1 distro's. RH 9 actually turned out to be the easiest to setup with Oracle. Once I modified the memory settings in
Haven't tried it with SuSE yet. I've been told it works great and doesn't require any makefile tweaking. I've setup quite a number of these with RedHat for the military. You would be surprised how many of these they want to install under Linux.
Has anyone tried it with RHAS 3? I understand it hasn't been certified yet by Oracle.
Has Comcast disconnected your Internet account? Same here. You can read about it at http://comcastissue.blogspot.com
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
Gentoo has the option for vanilla source also
...Also supplies a kernel-linus package as an option.
Because if you are using Oracle, you are generally doing something serious, which means that product support is critical. If Oracle does not support your Oracle/OS combination that means you don't get support.
e ch supp_faq.html#Linux_Distributions
And for the record here are the Linux distributions which Oracle will support;
http://otn.oracle.com/tech/linux/htdocs/linux_t
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
RedHat explain it here, and as a paying user of RHES3.0 in an enterprise environment, I think this is a good approach for them to have. The features they have left out feel to me to be the more risky sounding things that aren't essential like the new IO sub-system and scheduler tuning, while the things they have taken seem to be more applicable to the apps they may expect users to run e.g. O(1) scheduler, native POSIX library and Huge TLBFS
Interestingly on their page they also list 2.6 as not having Hyperthreading support, while their 2.4 does.
-- Mike
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.
This does have advantages. In particular, when a backport is done, small bugs tend to get found. Basically, if redhat takes the time to backport and they find bugs, who cares.
That does not mean that I will be running redhat any time soon.
I prefer the "u" in honour as it seems to be missing these days.
This is not new by any stretch. Redhat has been dicking with the kernel and almost every package they ship for nearly a decade (possibly longer.) That's why it has always been a matter of policy on my part to build my own kernel from the "blessed" tree the instant a redhat machine is installed. Never, EVER, use the hacked-to-hell Redhat kernel. Kernel developers will generally ignore your bug reports, and redhat will ignore them too without a support contract.
See, I consider this to be a perfect example of providing you an additional choice. Without debian backporting the patches, you only have the first two choices below. Debian provides you the third:
- Upgrade to the most recent software and possibly change features that you rely on
- Live with the vulnerability
- Use the old software with debian's backported patch
There are risks to each of these choices, but IMHO, 3 choices are better than 2. You choose #2, which is fine. You just take on the risks associated with that choice. I choose #3 so I take on the risks associated with that choice. We are each able to pick our own set of acceptable risks. Which makes my point: this isn't a failure of opensource. It demonstrates that it works.That's too bad. I've had much better responsiveness from debian developers. Of course, I had to learn to the balance between providing too many details and not enough details. I don't always get it right. But generally, I've had good response from developers. Sorry you haven't.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
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.
Wha?
I've been installing kernels based on vanilla source since I started with Red Hat 6.0. From my experience, they work fine. In fact, the second thing I do after installing a new version of Red Hat/Fedora, after closing all the really obvious security holes (why the hell is sendmail running by default???!!!???), is build a kernel to my own specifications and needs.
It runs fine.
Having not tried Fedora Core yet, I don't know if that project did something to tie a successful bootup to the presence of certain modules or a certain kernel version (which would be mind-bendingly dumb). Maybe the Enterprise version freaks out if the default RAID configuration calls for a certain set of modules, I don't know. However, I don't think I've ever had a problem dropping a vanilla kernel into Red Hat.
Someday, you're going to die. Get over it.
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.
... and those are the ones I use.
In the beginning ofcourse I HAD to try all those patched mm/ck/gaming/gentoo/...-kernels coz they'd be all this wack and such, but after my occasional kernel panics I gravitated to the dev-sources.
No problems with the development-kernel whatsoever.
(ah no, I'm gonna be honest: 2.6.6_rc1 (i think) won't load my nvidia driver, so I using the 2.6.5 until I find some time to find out why).
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.
Well, yes and no.
Patrick Volkerding's notes on building the Linux kernel for Slackware says:See the URL for Patrick's procedures on how he builds the kernel.
This would create such a big maintenance hassle for everybody that changes like this aren't made. If new system calls are needed, they are first merged into the vanilla kernel, before being backported into a Red Hat kernel.
NPTL would be a good example. Red Hat customers requested a good threading system, so NPTL was developed. However, something that invasive can't be done in a distribution kernel, so it was developed for the 2.5/2.6 kernel first and only ported to 2.4 later.
Believe it or not, but people have actually thought about all the implications. ;)
This is my personal opinions. Other people may have different opinions. Please check the facts and come up with your own opinion.
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
I am an avid SuSE users. SuSE rules!
SuSE however, has also back-ported a number of features from later kernels. like the i2c stuff from 2.5 in SuSE 9.0
He is right in that it makes it much more dificult to deviate from stock install
Hope they can take some of their own medicine
A friend will come and bail you out of jail, a true friend will be sitting next to you saying, "damn that was fun!"