2.4, The Kernel and Forking 384
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."
Vendor adds lots of patches to kernel (Score:4, Funny)
Re:Vendor adds lots of patches to kernel (Score:5, Interesting)
Re:Vendor adds lots of patches to kernel (Score:5, Insightful)
I am not against vendors making custom kernels at all, it's really a good idea. They make kernels that are designed for a specific purpose, Red Hat aims more for the server support/performance and SUSE has been focusing more on the Desktop install. There are optimizations done for servers that would be silly, or even degrading, for a desktop.
I agree that this is not a matter of 'forking' the kernel, but packaging.
Re:Vendor adds lots of patches to kernel (Score:3, Insightful)
Re:Vendor adds lots of patches to kernel (Score:5, Insightful)
Re:Vendor adds lots of patches to kernel (Score:3, Interesting)
I had a problem trying to get RH9 to work on an Athlon64 system a few months ago. I downloaded the vanilla 2.6 kernel as I've done with other distros, followed the directions and did everything I was supposed to, and then it wouldn't compile, needed special extensions to work with RH... then X was screwed for some reason. In general RH9 is just not made for the 2.6 kernel. I didn't try the 2.4 vanilla kernel because I didn't think it would add the functionality I needed.
-JemRe:Vendor adds lots of patches to kernel (Score:5, Informative)
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.
Re:Vendor adds lots of patches to kernel (Score:4, Interesting)
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. RH9 is really not meant to be upgraded; it is designed to be replaced by RHEL.
-JemRe:Vendor adds lots of patches to kernel (Score:5, Informative)
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 [thomer.com] 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.
2.6 on RH9 is not hard at all! (Score:4, Informative)
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).
Re:Vendor adds lots of patches to kernel (Score:5, Insightful)
you still have source. you can still release patches. the fact that they'll only work with one distribution is a minor deal, if what you're really after is fixing some problem with that distribution or adding some feature to it. patches are seldom valid across version of the same code line, either. this is not any form of vendor lock in. i'm not stuck with Red Hat here. in the MS world, you nobody else is able to produce these patches. that's vendor lock-in.
Re:Vendor adds lots of patches to kernel (Score:3, Informative)
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 ce
Since When? (Score:5, Informative)
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.
Re:Vendor adds lots of patches to kernel (Score:4, Funny)
For example, in this comment you seem to suggest that you believe RH/FEdora is alone in shipping with a heavily patched and customized kernel.
Yes and no (Score:3, Informative)
Well, yes and no.
Patrick Volkerding's notes on building the Linux kernel for Slackware [slackware.com] says: See the URL for Patrick's procedures on how he builds the kernel.
Re:Forget Forking (Score:4, Funny)
And since there is no spoon:
"Use the forks, Luke!"
It happens all the time (Score:5, Informative)
Re:It happens all the time (Score:5, Informative)
Re:It happens all the time (Score:3, Insightful)
Move along, nothing to see here.
Re:It happens all the time (Score:5, Insightful)
If the competition has it, and you don't, its because it is not reliable enough, will cause potential problems, not fully compatible or affects performance/comfort/durability in a negative way.
If you have it and the competition doesn't, it is because they are technologically behind, outdated, incapable of incorporating change, or they just don't care about you.
If you both have it, yours is better tested, proven, the correct version, or better documented.
If they got it before you did, it was because you care enough about your customers to fully test it to prevent any potential problems. If you got it before they did, it is because you have better facilities/personel for testing so you can get it to market faster.
Steel is stronger than plastic, unless mine is plastic. Then plastic is lighter than steel, and stronger, pound for pound. Bigger is better, unless mine is smaller. Then we use more modern parts, instead of old technology, so ours is smaller.
Any feature my product has or doesn't have, I can give you a very good explanation that will demonstrate why we are better for having it / not have it. No matter the circumstances, we did it on purpose, and we did it because we care more than the evil/incompetent/small competition. If you give me at least 30 minutes, I will also produce graphs and charts that clearly demonstrate this point.
As to what the magical "it" I keep referring to, it doesn't matter. What ever "it" is, we have a reason for having / not having "it" and why we implimented it first / last. (please refer to the image for obvious proof.)
You don't have to be evil to be in Marketing, but it really does help
Since when? (Score:5, Insightful)
2.4 can have new things added to it, there's now law that says it can't.
And if the 2.4 maintainers have found some good additions, well, all the better for users of 2.4
Re:Since when? (Score:5, Insightful)
I don't know much about RedHat's backporting efforts specifically, although some people seem to think they've done a cob job of it. Perhaps that's the point the SUSE guy was trying to make? Not so much chiding RedHat for backporting, but for doing a crappy job of it.
Re:Since when? (Score:5, Insightful)
I think you've summed it up, right there.
It isn't safer, but it's something open-source gives YOU the ability to determine.
CAN you fork when the source is open?
If a fork springs to life and has more adoption than the unforked branch, doesn't that mean that it suits users' needs better?
Any change to your kernel involves risks, but at least you get to choose.
Re:Since when? (Score:3, Insightful)
Guess where all the talent went?
And guess which X subsystem is being used in virtually all of the newer versions of the more popular distros?
Open Source software development is a particularly Darwinian environment. Which, in my opinion, is a good thing.
Re:Since when? (Score:4, Insightful)
Red Hat isn't doing what they are doing for the benefit of the Linux community, they are doing this for the benefit of their customers. Consider this; Solaris 8, despite being released a couple of years ago is just now starting to gain widespread acceptance as a "Stable" operating system for use by many corporations for critical systems. Solaris 9 is largely considered too new for critical systems at some of the world's largest financial institutions. In large corporate datacenters, products under 2 years old are rarely considered "stable". Ask a Fortune 500 CTO whether or not you can apply a kernel patch to the Oracle Financials server or upgrade it to a whole new kernel to get a much needed feature and see what response you get. As a result, the only way Red Hat can bring some of these features to their customers is through backporting.
Re:Since when? (Score:3, Insightful)
Not so hypothetical as you think. There was an article in Linux Journal (IIRC) recently that shows how RHEL kernel development is done.
Note that maintaining hundreds of patches (and growing the pile) is a lot of work and would take up a lot of full-time employees; not something any business could justify if the
Who cares? (Score:5, Insightful)
Re:Uhh, they do, sort of... (Score:3, Interesting)
> use it. It's also much faster.
2.6 wasn't here last summer when RHEL3 was being built. But RH wanted several of the features for the new version, since it was going to be around for five years and all that jazz.
RHEL4 is looking like it will be 2.6 based, but they are adding in SELINUX. RedHat is usually out near the bleeding edge, but just far enough back that they don't get cut up too bad.
Re:Uhh, they do, sort of... (Score:5, Insightful)
I can't fathom how so many people fail to grasp...
a.) Red Hat isn't doing anything that hasn't been done before.
b.) Its still open source, so if you don't like it don't use it.
c.) Red Hat is doing the right thing for their customers.
Re:Uhh, they do, sort of... (Score:4, Informative)
Yesterday's news? (Score:5, Insightful)
Kernel forks don't kill the kernel.
Re:Yesterday's news? (Score:3, Informative)
Re:Yesterday's news? (Score:5, Interesting)
Re:Yesterday's news? (Score:3, Interesting)
Oh, please (Score:5, Insightful)
Things have always been this way. None of the major distributors ship a pure Linus kernel, including SUSE. Everyone includes patches. Backporting 2.6 features helps everyone because it subjects those features to more testing, meaning that 2.6 will be better as a result.
Red Hat has more kernel hackers than anyone else, which means that they have the ability to support kernels with more hacks. So what SUSE is really saying is "How dare Red Hat use its competitive advantage?"
Finally, it's not true that "everyone else is working on 2.6". People in the "open source community" are still maintaining 2.2, remember. Future 2.4 releases may well include some of the backported stuff developed by Red Hat and others.
Re:Oh, please; But is it a useful test? (Score:3, Informative)
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?
Re:Oh, please; But is it a useful test? (Score:4, Insightful)
I'd think it's more useful to test it in 2.4 as well as 2.6 rather than only testing in 2.6. Sure, it's more work (work that RedHat is willing to do) but it may turn up bugs in conditions that do not occur in 2.6 yet (or not reproducibly, etc.)
Re:Oh, please (Score:5, Informative)
actually, slackware does ship vanilla kernel.
slackware (Score:5, Funny)
In the grandparent's defense, they did say none of the major distributors.
Re:slackware (Score:5, Informative)
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:slackware (Score:4, Funny)
Gentoo (Score:5, Insightful)
emerge vanilla-sources
disc 3 of your Redhat install... (Score:3, Insightful)
Re:Oh, please (Score:5, Informative)
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.
And gentoo is not a major distro? (Score:3, Insightful)
RedHat's kernels = more like dev kernels (Score:5, Interesting)
Re:RedHat's kernels = more like dev kernels (Score:3, Insightful)
Forget Forking (Score:5, Funny)
You know you have all seen this happen a million times before.
There is no meaningful "fork" here. (Score:5, Informative)
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.
Re:There is no meaningful "fork" here. (Score:5, Informative)
Whatever gave you that idea? Redhat has created kernels in the past with threading features that nobody else had. Software using those features would not run on a kernel without those nonstandard patches. That's binary incompatibility.
Redhat has a history of doing stuff like this, as with their GCC 2.96 fiasco.
Re:There is no meaningful "fork" here. (Score:3, Insightful)
I don't see how it's anyone else's buisness what compiler redhat uses. I know some project maintainer
Damned if you do, damned if you don't (Score:5, Insightful)
The worst thing they could do is drop support for 2.4.x entirely and mandate everyone upgrades to 2.6.x. Why make such a major change to something that works?
RHEL Backporting, fine by me. (Score:5, Informative)
.. and we like it. (Score:4, Insightful)
GMAFB!!! (Score:4, Insightful)
This is a very dangerous attitude from a company that is supposed to be steeped in the GPL. "Work it our way or don't work it" is not an attitude that helps the open source movement. "Let a thousand flowers bloom" should be the theme.
Sounds to me like SuSe is upset that they will have to either duplicate this work or use Red Hat's work in order to stay competitive.
Re:GMAFB!!! (Score:3, Insightful)
You may or may not agree with that, but don't go stretching his argument to an extreme. That's just false.
It's just an opinion, not a revocation of right (Score:3, Interesting)
He merely said it wasn't a good idea to be backporting. Freedom also includes having opinions on the choices people make.
I love when someone criticizes something, and people jump on it claiming, "but they have the RIGHT to do that!" Nobody was saying they didn't have the right--they were just criticizing the choice they made with that right. Free opinion, man.
The fear (Score:5, Interesting)
--Dan
Re:The fear (Score:5, Informative)
When its something like Oracle, you choose the application, then the OS to match.
Re:The fear (Score:5, Informative)
Not true. UnitedLinux and SuSE are also certified. In fact Oracle is compiled not on Red Hat, but on SuSE.
Re:The fear (Score:3, Interesting)
Really? Why? Works fine with Slackware here.
Re:The fear (Score:3, Informative)
And for the record here are the Linux distributions which Oracle will support;
http://otn.oracle.com/tech/linux/htdocs/linux_t
Not only that, but they did it wrong... (Score:3, Interesting)
1417c1417
real_parent; p != &init_task; p = p->real_parent)
---
> for (p = current->p_opptr; p != &init_task; p = p->p_opptr)
It seems that RedHat's testing methods weren't so good, and they neglected to see that certain things had had their names changed. Since they didn't test their kernel, it made it difficult to track down that particular error when trying to recompile the kernel.
USB (Score:5, Interesting)
Was that different or are they the most recent victims of marketing doublespeak?
Chasing versions numbers. (Score:3, Insightful)
yeah .. and.. (Score:5, Informative)
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!
Not a fork (Score:3, Insightful)
I'd see this mostly as SuSe posturing.
Way too many assumptions (Score:5, Insightful)
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?
First of all, some of us assume "the kernel" is /kernel/genunix or something else, because we're working on Solaris or something. (There's one assumption on you're part that was unspoken: we're not all Linux users.) Secondly, I don't assume the kernel will never fork. Forking has often been very productive for Free Software programs, and the right to fork is one of the most valuable incentives for development. The kernel has forked all the time (remember the -ac tree from Alan Cox? how about uCLinux?), and that's a good thing.
So your explicit assumptions that "we" "all" have, that the kernel will never fork, are wrong, as well as your implicit assumptions that we all use Linux and that forking is a bad thing. Thus I'm not sure what the big deal is.
2.6 features backported to 2.4 (Score:5, Interesting)
features from 2.6, I love the fact that Red Hat
went the extra mile to provide this feature.
We have been using NPTL extensively in the Mono
debugger. Without it, it would be much harder
to write the debugger for Mono.
Miguel.
Ximian/SuSE (Score:3, Insightful)
Is it just me, or does Novell really have a problem with the images of these two companies? It seems to me they're trying to give the impression that Ximian and SuSE are in competition....
First that weird article about adopting QT across the board, now this. And I'm sure I'm forgetting some other such issues too. It gives me the impression that SuSE people and Ximian people have never even had a conversation with each other.
Re:Ximian/SuSE (Score:4, Interesting)
I might say that Slashdot also bears a lot of responsbility for publishing a summary that miscasts the SuSE CEO's argument -- he's more concerned about an extreme level of backporting (and discouraging adoption of 2.6 to stay on 2.4 with backported features) than about backporting in general. SuSE backports stuff too.
Not sure if I agree with him or not, but that's a separate issue.
Customers refuse to run Red Hat's kernel (Score:5, Interesting)
If you have a problem and you bring it to the kernel hacker who made the subsystem you're using, it's really very difficult for them to support Red Hat's thread. Generally they just say to look to the vanilla 2.6 kernel.
Bruce
Re:Customers refuse to run Red Hat's kernel (Score:3, Informative)
That does not mean that I will be running redhat any time soon.
Re:Customers refuse to run Red Hat's kernel (Score:3, Interesting)
That doesn't work very well for my customer. But I agree that it should work that way. But today you have a better assurance of service if you stick with the main kernel thread.
Bruce
This is how it's SUPPOSED to work! (Score:5, Insightful)
This is one of the things that makes debian's stable tree live up to it's name. It isn't a bug in opensource, it's a feature. Now, of course, this puts additional pressure on debian to ensure that their stable branch continues to work as expected considering that the stable software is patched in a way that's unique to debian. But if they want to do that, good for them. It's up to their users to decide if this is a good practice. And historically, it's been an excellent practice.
Is SuSe saying that they don't do this? Are they saying that if you're using a piece of software that they distribute that's slightly older than current and a patch comes out for current, that they won't patch the old software? If so, that leaves SuSe customers with a horrible choice:
I wouldn't think that'd be good for business. legacy piece of software on their distro, and a patch for a current version comes out, that they won't support it? I would think that'd be bad for business.
Re:This is how it's SUPPOSED to work! (Score:3, Informative)
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:
Re:This is how it's SUPPOSED to work! (Score:5, Insightful)
I think you are looking at it the wrong way. Debian has made a commitment to supporting their stable branch, specifically to fix known security vulnerabilities. There are two ways to do this:
When I do a 'perl -v', I expect the stated version to actually be the version listed, not the version + some unknown patches.
I don't understand this. These are not "some unknown patches." If you download the source .deb you will see that it is packaged as the original sources plus a number of patches which are applied at compile time. If you don't want these patches (or you want different ones) it is a simple matter to make your own changes and make your own custom package. Furthermore every package has a changelog.Debian.gz file in /usr/share/doc/$packagename/ which describes pretty well these mysterious patches with cross-references to the debian bug tracker no less!
Kernel API changes (Score:5, Informative)
Stability (Score:5, Insightful)
Distributions elect to use a given kernel version every once in a while. By not keeping up to date with the latest kernel.org tree, they gain the advantage that their codebase is much slower moving and they are less likely to have new bugs introduced from outside sources. Doing so also gives them the ability to accrue intimate knowledge of the inner workings of that specific kernel revision.
As distributions support a kernel, new bugs, vulnerabilities, hardware incompatibilities, and scalability issues arise. By selectively culling those single bits and pieces and patching their supported kernel, they are able to easily test the fixes without the larger risk of regressing in other areas.
At first, this practice may appear to make the distributions look 'unfriendly' towards the opensource development nature of the Linux kernel, however this is far from the truth. As issues arise in the distro-supported kernel, fixes are also created which are later pushed upstream to the Linux kernel proper (as long as they aren't considered gross hacks that is).
In essence, distributions settling on supporting specific kernel versions and patching them is very much in the open source spirit. OSS has the advantage that you may use any code drop you want, and if you fix something, the neighborly thing to do is to share the fix (which under certain license is enforced by law under some conditions).
using RedHat fails security audits (Score:4, Interesting)
Now that I'm off-site and PT the responsible thing was to use a package system that was commercially supported. Enter Redhat. We run v2.1AS and v3ES/WS.
This backporting stuff in kernel-land is nothing. It's WAY WORSE when it's userland stuff. eg. Apache. RedHat updates to 1.3.29 because of a security bug but they don't actually upgrade to
Naturally all the security check software is looking at banners and falls all over itself giving me warnings about vulnerable software when I know it's all patched. It makes a lot of work for me when our network minders run probes against our boxes and come up with all the errors and they run screaming to the dept heads with "hundreds of vulnerabilities!" and I have to go PROVE my boxes are up to date.
THANKS a FREAKIN' LOT Redhat!!! How come the rest of your enterprise customers haven't tarred and feathered you over this STUPID practice? Track the damn source revisions, would you? It's one thing to want to provide "stability" but point releases are just that, fixes for broken features or security updates. The damn package should be clearly labeled 1.3.29 everywhere. It's one thing to force customers to go from 1.3 family to say 1.4 family (yes, I know, doesn't exist) and I can appreciate not being put down that path, but the current setup is just a disaster.
According to my machines I'm runing OpenSSL 0.6.9b though the code is actually 9m.
And they want to make Java open source? (Score:3, Interesting)
I have to say, the uproar over this doesn't make any of the "oh, it'll be fine" arguments that pro-OSS Java folks have been throwing around sound all that great.
I mean, if the Linux kernel itself has this happening to it, what sort of chance does Java have from preventing it, if it goes OSS?
inevitable (Score:3, Interesting)
This is something the SuSE does as well. And so will IBM - just wait until a patch they write for mainframes isn't accepted by linus for some reason.
2.4 vs 2.6.. Yes, real work is still being done (Score:5, Informative)
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
This is what their customers want. (Score:5, Insightful)
So, RedHat backports desired pieces from the 2.6 kernel, so they can give their customers a more manageable update process.
While fast paced updates are great from the hobbyist perspective, enterprise customers have a whole different set of prioritites. This is one of the big things they touted for the RH Enterprise Edition.. it is supposed to have a more manageable update process, sticking with the same core kernel for longer periods of time to ease support and management.
This is a good thing (Score:3, Informative)
RedHat explain it here [redhat.com], 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.
Backporting != Forking (Score:5, Informative)
FUD (Score:5, Insightful)
First of all, forking is not a bad thing per se. In fact, it sometimes leads to better code. In this case, Red Hat is not doing anything divisive. They're merely maintaining their old code.
As for interfering with standardization, RedHat has done nothing but push for standardizing on the latest stable code to come out. They pushed gcc 3 back when people were bullish about it. They pushed for kernel 2.4 when people were saying nothing's wrong with 2.2. Even now in their Fedora product, they're pushing 2.6 early in the game.
If anything, they're bringing the 2.4 crowd slowly into the 2.6 world by backporting features.
Who is this CTO of SuSE? Sounds old-school to me.
That said, I also noticed that there were no quotes in the article from Juergen Geck. I've become wary of news articles that try to capitalize on sensationalizing news stories. Perhaps this is just the author's interpration, eh?
Forking RedHat (Score:3, Funny)
Redhat backports what's already accepted upstream (Score:3, Informative)
Re:Red Hat?` (Score:5, Insightful)
Lots, I expect. But they don't get to be as pretentious as the less popular distro users.
Re:Red Hat?` (Score:5, Interesting)
If datacentres and hosting companies are deploying this widely, then you can be sure that there are many sysadmins out there who are creeping up the learning curve and are unaware of precisely what they run on or what it means (2.6 kernel performance with MySql should prompt many to upgrade, but it doesn't).
So the 2.4 kernel is far more widely deployed than you may initially suspect. This is where Red Hat are making their money and why it matters to use.
Re:Red Hat?` (Score:5, Insightful)
That's because a lot of us enterprise users frankly dont really care that much if there's improved preformance with MySql. One doesnt get called in to work in the middle of the night because they need a speed increase. One gets called in to work because the server is down. That means we tend to have as priority that the server is up. Which tends to cause a certain reluctance as far as installing 'new' code goes. If there's a performance problem on the scale where a new kernel might make a difference, I'd suggest throwing hardware at the problem. It's much easier, far cheaper, and offers much more peaceful sleeptime.
2.6 will get deployed in production when hardware is certified with it, when distributions are certified with it, when Oracle is certified with those distributions, when backup and monitoring software are certified with them, when we've run it ourselves in labs, and internal utilities are ported and/or recompiled and ready for deployment.
That'll take at least a year. Until then I'll play with it on my free time, and on my workstation. But hell, while I might be running my own driver code in my kernel at home, I wouldnt even be compiling a new kernel for a production machine unless there were _serious_ issues with the one from the vendor. It's just not worth the potential hassle.
Re:Red Hat?` (Score:5, Interesting)
Its not like they're closing the source to the kernel and preventing others from either removing them or copying them. In my opinion this is a non-story.
Re:So what? (Score:5, Interesting)
Red Hat Enterprise Linux is pretty much the standard at this point for electronic design automation (EDA) tools. This means that it will be used in the design of most chips produced this year and in the next several years. It's 2.4 based, and will remain so for some time.
Many RH Enterprise Linux users (Score:5, Informative)
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 [redhat.com].
Re:So what? (Score:3, Interesting)
Re:Do we need to keep discussing this? (Score:5, Funny)
Actually, the concept of fork(2) really just requires a simple system call. Copy-on-write pages help a lot too, though.
Re:Do we need to keep discussing this? (Score:5, Insightful)
(Not that I consider the redhat kernels to be a fork)
Re:Do we need to keep discussing this? (Score:3, Interesting)
I think I understand the problem here -- your definition of `fork' doesn't match with the defintion of `fork' used by most everybody else here. To everybody else, it means that one package/program/group of code/whatever becomes two or more, each diverging more as time goes on.
You want some examples of open source forks? How about ssh -> openss
Re:Damn redhat (Score:5, Informative)
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 :)