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."
Is anybody really still paying attention to RedHat's 2.4 offerings? Does it look like they'll keep up the backporting practice?
- To err is human; but to really screw up, you need a computer
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.
Who ever moderated you as a Troll obviously still does. But, I suspect that fewer and fewer are.
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.
How many times have we argued this issue? At this point it has been resolved hundreds of times here on Slashdot, and many thousands of times in editorial write-ups elsewhere.
YOU CANNOT FORK OPEN-SOURCE CODE, people can do whatever the hell they want to with it, including back-porting features... BECAUSE YOU HAVE TO SHARE THE SOURCE.
What is so complicated about that? The entire concept of a "FORK" requires secret proprietary source code and copyrighted functions and pantented methods.
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
And I'm willing to pay for the long-term support of my company's systems.
Slackware does. The whole idea is that if you have a *good* reason to patch your kernel, you can do it yourself.
This just goes to show that SUSE is relying on a full steam ahead adoption of any new version rather than a more carefully planned transition between versions. I still run 2.4 (conversion is set for a couple of months from now) and appreciate backported stable features. Providing the latest and greatest is a good thing I guess if you are a in this individually or as a hobby, but I'm not interested in upgrading until a product matures and I have regression tested everything. SUSE seems to not understand that, which would disqualify it for me as an enterprise vendor.
Sig under construction since 1998.
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
I'd see this mostly as SuSe posturing.
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.
What I have a problem with is when you try to install a Vanilla kernel on a RedHat system, it still goes berserk. Commercial GNU/Linux vendors have found new and unusual ways to make their software proprietary. It's just a different kind of vendor lock-in, because if you've got RedHat you're stuck with RedHat Inc. for patches and updates.
-JemI'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."
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.
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?
You are missing the point. The reason people buy RH is because they don't want to spend time finding the person who did XYZ. They just go to RH because they have a support contract, and make RH fix the problem.
Companies don't really care who or what caused the problem. They just want a fix NOW. That is the value -add that RH brings to the table.
Yes, redhat backported tons of code from development 2.5 series, and later from 2.6, into their 2.4 kernels. And as far as I am concerned, it was a good thing. For example, for a long time RedHat kernel supported USB2 hard disks reliably, while stock and -ac kernels would hang after transferring few hundred megabytes. USB1 worked fine, USB2 would hang the machine. Yes, I could move to 2.5 kernels, but I don't want to. I want a stable kernel on a production system. And I'm not moving to 2.6 yet for the same reason, too many changes. Just the last version changed the API and broke all drivers except the in-tree ones. But RedHat ports most of the stuff I want back into their kernel, so I don't have to choose between not having the features I want and getting more features than I bargained for.
Of course he is. I really don't think he even cares about the practice. He's just trying to drum up more business for SuSE and take some away from Red Hat. Nothing more than capitalism at work.
Move along, nothing to see here.
"The words of the prophets are written on the Slashdot walls."
Another reason I like debian....
"Personal ownership is a hallmark of conservative capitalism. And I don't believe I am entitled to anything that I did n
What is the point in modding up an Anonymous Coward with no proof to back up his or hers claim? Red Hat does not put out beta code an call it production. In fact, RH has 6 of the top 10 Linux kernel developers working for them. They know what they are doing. I personally don't care if RH puts 16,000 patches in their kernel and calls it Red Hat's super duper kernel 99.7. What matters is that RHEL is stable, and in my experience, RHEL is damn stable.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
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.
GCC may not have been really GCC but it its g++ was much more of a c++ compiler than 2.95. All they did was branch from the development tree. Things that didn't compile with it didn't compile because of broken code not because of a broken compiler. Furthermore as far as compiled c++ binaries goes, due to the magic of versioned libraries, c++ binaries compiled with all recent "real" gcc releases worked fine.
I don't see how it's anyone else's buisness what compiler redhat uses. I know some project maintainers complained that they didn't want to support this compiler version but they had the option of not supporting it and letting redhat or a redhat user contribute a patch or they could just plain let it be, and continue to ship broken code.
Furthermore, redhat shipped a secend compiler with that release compat-egcs-6.2 (egcs-1.1.2) just in case code was tied to specific existing gcc behaviors).
So next time lets save the complaints for when redhat commits an attrocity like changing the default theme.
"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.
Gentoo has vanilla 2.4 and 2.6 kernels.
You might want to remind everyone that Bruce Perens is competing directly with RedHat in the enterprise support consulting business, and therefore has a financial interest in the matter.
Given that, your message comes off an awful lot like FUD. How much of your customer's opinion came right from you?
It must be tough wearing the "Independant Linux Advocate" hat and the "UserLinux/Debian" hat at the same time, but at least try. Otherwise y'all look like asses. Thanks.
Every try to install a SUSE kernel on a Red Hat install? Maybe I'm ignorant but why would anyone try this? Just to see if it could be done? I liken this to installing a Ford motor in a Chevy car or vice versa... you may get the motor to fit but the transmission won't bolt up without some modifications or an adapter kit... and in the end, what do you have? Is there a good reason for wanting to have a SUSE kernel on an RH install?
How is it that one careless match can start a forest fire, but it takes a whole box to start a campfire?
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!
You're full of shit Bruce..and I think you've done yourself a major dis-service by posting such libelous comments in such a public forum. I'm going to start an online petition to get your publisher to stop publishing the excellent open source series under you name as you are now a dis-credit to the Linux community. This and of course your complicitness in the pseudo racketering scam that you've got set up at OSRM. Rattle a few swords, scare a few people and then get them to sign up for your service. Tony Soprano would be very proud.