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."
Since when is it OK to develop a new kernel and abandon one that many users are still betting on?
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
I don't know the meaning of the word 'don't' - J
Lots, I expect. But they don't get to be as pretentious as the less popular distro users.
Why is this really interesting? Open Source / Free software is designed for forking. Why dont they just call it "RedHat kernel" or something?
RedHat has been backporting patches forever. That doesn't make it a fork any more than the actual kernel forks. Look at the LinuxPPC tree for an example of a real fork. Look at rtLinux, uClinux, and all the other actual kernel forks before crying wolf.
Kernel forks don't kill the kernel.
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.
Redhat is supporting a kernel they've used for some time now, by backporting patches. What's the big deal? *Lots* of people are going to be running 2.4.x for a long time, and having vendor support still available is great. We should be supportive of Redhat here.
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?
Redhat backporting features into 2.4 for their own customers is a win for everyone and yet another victory for open source. Case closed.
This is insane. What is the GPL about if not the freedom for an individual or business to make changes to the kernel and distribute those changes? If Linus wanted to maintain a single point of control, which is what this guy is indirectly advocating, he would have used a different license.
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.
"It is our blasphemy which has made us great, and will sustain us, and which the gods secretly admire in us." - Zelazny
Eh? A fork in a road is where a road splits into two; each going in different directions. A fork in a software project is the same. I don't see why a fork in software "requires secret proprietary source code and copyrighted functions and pantented methods".
(Not that I consider the redhat kernels to be a fork)
You can say their kernels are patched, but from what I've seen they are more customized then patched. Most of their patches do not apply very well to other vendors kernels or even systems. Every try to install a SUSE kernel on a Red Hat install? Sure they are both RPM based, but their systems are truely unique and you will get many boot errors at the least.
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.
"Some things have to be believed to be seen." - Ralph Hodgson
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.
Secession is the right of all sentient beings.
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?
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.)
SCO employee? Check out the bounty
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.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
Both Red Hat and SuSE have been backporting fixes into older kernel versions and shipping 'older' versions of kernels is primarily due to stability requirements.
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).
emerge vanilla-sources
Overrated / Underrated : Moderation
Enterprise customers are generally very careful about making significant upgrades to their servers. Security patches and application fixes are expected, but a new kernel throws them into a huge process of integration, compatibility, and stability testing that they don't want to be forced into. The same thing applies to application vendors.
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.
I've never had a problem with a vanilla kernel on a RH system without any tweaking. Granted, I haven't done it in a while, but it has always worked the 30+ times I have. I'm sure that there are problems for some setups, I don't doubt you in that, but to imply it can't be done or isn't easy isn't quite accurate either.
"The words of the prophets are written on the Slashdot walls."
I'm surprised that someone from an opensource-supporting company would sling FUD like that. This statement sounds something an old-school business practitioner would say to sell their product and discredit their competition.
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?
Furthermore, Oracle and IBM will not support their RDBMS's on the 2.6 kernel. Therefore, RH customers running either Oracle or DB2 on RHEL3 will not be moving to 2.6 until Oracle and IBM give it the green light for their products.
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.
"The words of the prophets are written on the Slashdot walls."
contains the kernel-blahblah.src.rpm. The vanilla sources are in there and end up in /usr/src/redhat/SOURCES after installing.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
i call nonsense!
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.
i speak for myself and those who like what i say.
"2.6 kernel performance with MySql should prompt many to upgrade, but it doesn't."
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.
As a fellow capitalist (20 years in marketing), I can verify your statement. This applies to durable products in my case, but could apply to software as well.
;)
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
Tequila: It's not just for breakfast anymore!