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."
News at 11.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
There are tons of kernel patchsets out there. some (ck-sources for example) include 2.6 code as well.
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.
before 2.6 existed, their 2.4.x kernels looked WAY more like 2.5.x kernels. I always thought this was dangerous, as what they were effectively doing was dressing up "alpha" 2.5.x code as "stable" 2.4.x code and letting it run riot on people's production servers.
... What happens when the Linux kernel starts spooning? We will never see him again, because he will be spending all his time with his new girlfriend. That is until she kicks him to the curb, and he comes crawling back looking for his old friends again.
You know you have all seen this happen a million times before.
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
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?
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).
Redhat backporting features into 2.4 for their own customers is a win for everyone and yet another victory for open source. Case closed.
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.
Actually, the concept of fork(2) really just requires a simple system call. Copy-on-write pages help a lot too, though.
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
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.
The fear is that a version of Oracle will come out that depends on 2.6-ish kernel features but doesn't actually work on 2.6 proper (i.e. it has dependencies on 2.4-era semantics). At that point, the only way to run Oracle -- no matter your toolchain -- is to use the Redhat kernel.
--Dan
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)
Was that different or are they the most recent victims of marketing doublespeak?
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
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 :)
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.
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.
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
As a happy user of a 2.4 kernel with backported
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.
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
Bruce Perens.
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.
In the grandparent's defense, they did say none of the major distributors.
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
I work for the Dept of Defense. 3 years after I say we should go Linux, the shop has abandoned Windoze for our production (web, jakarta, Oracle) sites. Before we were running OpenBSD for firewalls and such but I was FT then and we could get away with patching and recompiling stuff.
.29. They backport the changes to .26 and leave all their package information, banners, the whole kit-kaboodle the SAME! Just a very minor build number gets cranked. Not even the Changelog bothers to specify what CVN was addressed or that it's even a security update. Ditto OpenSSL, Mod_SSL and everything else. The *ONLY* way I have of confirming the security patch is there is to download the SRPM and diff it against .29 and see if it's there.
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.
yet anothing redhat kernel war? don't get me wrong, but I never liked redhats patchparty really much. there gcc 2.96 compiler used to segfault the hell out of my redhat distro, and the kernel itself was the biggest patch pile I have ever seen in my entire live. I never was never succesful in compiling it. (not to mention compiling non-kernel.org modules.) there "performence" patches also gave me lots of trouble with more advanced code. (wine emulator anyone?) in short: I hope this fork will be soon forgotten, and redhat will spend its time in sending patches to linus for inclusion in the linux 2.6 kernel instead.
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.
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
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.
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
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?
I think Slashdot holds a lot of responsibility in this case for publishing unverified sources like the Qt article (and others).
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.
DNA just wants to be free...
I always favored Red Hat over all other distros for a very long time. I tried Debian, Slackware, and Mandrake, but always found myself back with Red Hat. Not to long ago, I upgraded to an AMD64 CPU and heard that SuSE 9 for AMD64 was the best for that platform and gave it a shot. I liked it so much that I went with SuSE on my other systems. Recently, our company FINALLY started to replace some Sun systems with Linux machines and RH Enterprise was the chosen distro. So far, I am very satisfied with RH EL and see nothing wrong with backporting features.
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.
"The words of the prophets are written on the Slashdot walls."
We've used forking RedHat here for quite a while, but things just keep getting more and more forked up. If this doesn't forking stop soon, we're going to switch to some other, less forked-up distro.
Interested in a Flash-based MAME front end? Visit mame.danzbb.com
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
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
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.
"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.
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