The creator of the Linux operating system, Linus Torvalds, has weighed in on the issue of backporting features from newer Linux kernels into older ones, calling the practice a good thing for the most part. When asked by e-mail to comment for internetnews.com, Torvalds wrote: “I think it makes sense from a company standpoint to basically ‘cherry-pick’ stuff from the development version that they feel is important to their customers. And in that sense I think the back-porting is actually a very good thing.“
Linux Creator Calls Backporting a ‘Good Thing’
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
But aren’t the Novel whiners complaining about backporting new features from one “production release” to another?
I thought the kernel that shipped with SuSE 9.0 had features from 2.6 before it was released. They complain about stuff that they themselves do.
It makes sense to backport features from development versions when they aren’t availible in the current production release.
But backporting features from a current stable kernel to an older stable kernel would just seem to fragment the community a bit, wouldnt it?
Surprising statement. I have worked in product development for 15 years and it’s accepted practice that backporting is high risk. Generally the tactic is that once a release is out the door, there’s huge reluctance to destablise it unless substantial commercial reasons and thorough QA come along. Few points:
– the stable release is just that: stable! Introducing current generation technologies into it adds risk.
– products are driven forward in totality, the more you put back into older releases the less incentive there is to move forward – you end up dragging your whole forward momentum as you have to cover retrofits into old gunk.
– the new features always requiring ironing out (no one installs the FCS into a production system), and they are going to require just as much ironing out when put back into an old system.
– the fact of doing the last statement introducces additional instability: in that the new feature was designed for the new framework, now you’re putting it back into an older framework, so you expose quality issues in the old framework that you didn’t need to know about.
Novell was talking about backporting from production kernels (IIRC: Linux 2.6 wasn’t out when SuSE 9.0 was released)
surprising …
I know that this will come across as a troll, but I have come to expect this sort of mentality from the head Linux guys. For the longest time Microsoft’s QC was “the worst in the business,” but more and more it seems like the Linux guys are hell bent on taking that “prize.”
I agree with Kingston. Maybe backporting isn’t the best thing. It doesn’t allow compatibility even with other distros. If I want to move over from Red Hat to Debian to Suse to … for whatever reason it will be more difficult not knowing what to expect. It’s just another headache for a company to consider when using Linux.
You have hit upon the key point.
Now when you refer to 2.4.22, do you mean 2.4.22-DEBIAN-CUSTOM, 2.4.22-SUSE-BACKPORT1 (or BACKPORT2?) or one of the other now thousand variants.
Now there will be less of a “well defined linux kernel“ and more of a “various vendorised kernel“. When you hear about some issue in 2.4.22 or a patch to be applied: does the patch apply to your 2.4.22, or someone else ? If it applies to someone elses, do you have to tweak it to fit yours because there’s other custom code in your kernel ?
This is really just a nightmare.
The community should go the other way and focus on making the kernel versions stricter so that everyone knows what they get and any patch for a particular release can work on the same release no matter what distribution it is part of.
You thought fragmentation was bad enough with N x distributions, now welcome to the even worse case, where you can’t even depend upon equivalent kernels.
It would be a different story if Linus himself decided to start backporting 2.6 features into the mainline 2.4 kernel. Red Hat does not run on a mainline 2.4 kernel, their kernel is a highly modified kernel that is tweaked specifically for their customers, it is not as if the main kernel.org tree is affected by what Red Hat is doing. Besides, Red Hat is not bolting on some proprietary APIs onto the kernel, they are using new and useful but standard Linux interfaces. So what’s the big deal, I don’t really see one. I understand the point of view of compatbility purists, but perfect synchronization and compatibility among major software interfaces, no matter how open and standard, can never be achieved. Just look at Java.
So what’s the big deal, I don’t really see one
The big deal is that there is (a running theme in OSS) duplicated effort, with nothing really gained. You’d probably be further ahead just going with the 2.6.x kernels and fixing any problems encountered there instead of incorporating new code into an old release, as doing so only tends to destablize the older kernel.
Unless of course you’re using a microkernel based system in which case there’s really no fear of destablinzing the kernel proper, as it (in most situations) won’t be touched.
Back porting speeds adoption and application compatability. Nuff said.
Back porting speeds adoption and application compatability.
Diving right in to a new (supposedly) stable release speeds adoption and application compatibility.
Nuff said.
What I meant was that the SuSE kernel in 9.0 had features from kernel 2.5x which became then kernel 2.6. So they backported themselves.
kernel 2.5.x was a development kernel (not ment for normal user use) so that is understandable.
It doesn’t create that many compatibility problems – you know, you almost never have to reinstall software when you change your kernel. I have a few kernels on my system, and while there are important changes between the 2.4 and 2.6 series (noticeably with the dev system), applications in general don’t care much about the kernel internals.
Of course, the modified kernel will have to be thorouhgly tested, but the modular nature of the Linux kernel would certainly permit it.
Of course, the modified kernel will have to be thorouhgly tested, but the modular nature of the Linux kernel would certainly permit it.
Come again?
Not modular in a microkernel way, but modular nonetheless. Have you ever compiled the Linux kernel? A lot of components can either be compiled inside the kernel or as modules. Though monolithic, the Linux kernel has a modular inner structure.
…is apparent in this visual representation of the kernel source code:
http://kernelmapper.osdn.com/map.php
Or not to back port, that is the question 😉
I woudl say it depend on what is actually being backported and whether compatibility is broken, for example, if a new driver is available on Linux 2.6, has been available as a patch for 2.4.x but never merged into the main tree, I don’t see any harm in making that driver available.
Problems do, however, start occuring when things are bought in that bring problems. Take NTPL for instance (I must admit, I was a NGPL fan as I prefer the M:N threading model, but hey, life moves on), Red Hat included it, thats nice, however, the other distributors didn’t, the Java runtime environment didn’t support it either; yes, I did try setting the environmental variable to allow it to run, however, I experienced bugginess in terms of running Java applications; Netbeans and Sun Download Manager are two that come to mind.
What there needs to be is a standardised kernel and base, like United Linux then vendors can built upon it; kind of like how there is the FreeBSD mini-iso which has just the core and that is it. That is what need to be defined and set down as a standard. By setting this standard, drive companies can then write drivers to that standard; backporting will be a none-issue as features in the kernel will be consistant through all the distributions.
C’mon, think business. If Company A, B, C all sell a distro with standard kernel and standard KDE and standard GNOME and so on, what is the difference of buying brand A, B, or C ?? Changes introduced by each company “adds value” in some way to their offering (otherwise they w’ont do it).
Someone said something about MS … well remember that drivers in the Win9x’s not were fully compatible between each release … you could not run drivers for WinMe on Win98 … but that’s fine (well maybe it’s fine), because they are different products. IF you would want to move from Suse to RedHat to Debian or something … you are moving probably because some advantage.
But anyway, a big company will stay with a single linux vendor due the high costs of managing multiple platforms/configurations, so it is ok if that vendor introduces new features to their products (or backports them for that matter). Unstability?? that is a QA issue, that same would happen if you just install the current “stable” kernel and a bug is found later. The only reason for such unstability was not enough testing or improper coding.
Linux is OSS for a reason, you can change it whatever you like to fit your needs … you don’t have to run the “official” release to keep someone happy that you haven’t change his code (and even Linus is fine with it).
“I think it makes sense from a company standpoint to basically ‘cherry-pick’ stuff from the development version that they feel is important to their customers. And in that sense I think the back-porting is actually a very good thing.”
So basically despite what the SUSE guy thinks, he’s saying that companies should decide for themselves what if anything to backport. Not that distributors MUST do it. Some of you are in such a hurry to bash Linux… RTFA.
You’re right, but hink about the advantage of backporting new features while no migration is needed, enterprise ( or users ) can take advantage of new technology without needing to upgrade their hardware.
I think such solution will grows the Linux machine park.
Imagine if windows 3.11 had support for USB + long filenames + …etc… do you think so much people would use Windows 9x/NT/2k/XP/2K3 ?
1. People are not mainly talking about consumer distributions, as far as I understand.
2. Using 2.6.0 immediatly after release for mission-critical application is probably a very bad idea.
3. I do not recall that the final 2.6.0 is available when the freeze of Red Hat Enterprise Linux 3 happened (June 2003, I think).
Look guys your all concerned about standards. We don’t want another Windows. We want diversity. If 6 kernel versions were created for custom uses then it only increases linux’ flexibility. The PPC kernel can’t run X86 code so it must not be standards compliant? Just as different cpu architectures require different kernels, flexibility demands different kernels. If linux is to flourish it can not be held to a standard that are not relevant to it’s function. The very nature of linux guarantees all of the standards needed.
> 2. Using 2.6.0 immediatly after release for mission-critical application is probably a very bad idea.
How is backporting things a better solution for “mission-critical” applications? It will surely be less stable than a 2.6 kernel w/o backports.
Actually, the thing is that Redhat had backported a lot of that stuff to Redhat 9.0, then they based RHEL3 on RH9, so those should have the same kernel major version IIRC.
Redhat does not change major kernel version numbers in a release, so they will not jump to kernel 2.6 on RHEL. This is done for stability. The backported stuff is actually tested for regression before they stuff it in, so it is pretty safe.
“How is backporting things a better solution for “mission-critical” applications? It will surely be less stable than a 2.6 kernel w/o backports.”
There’s absolutely no reason this is true. Backporting a few drivers is nowhere near the same as rewriting the virtual machine.
I really don’t think you understand how the kernel works.
-Erwos
Hi
Exactly. People who complain without understanding the real issues are just plain annoying.
Linux journal has an article on RHEL and HP on planet gnome which talks about backporting.
Linus has said that backporting is a very good idea on some cases and he is right. Kingston is just trolling
Linus has said that backporting is a very good idea on some cases and he is right. Kingston is just trolling
Unlike you, I have the ability to think for myself. I damn well am not trolling you smarmy git.
Backporting a few drivers is nowhere near the same as rewriting the virtual machine.
This was never about backporting drivers. This was about backporting features from one stable branch to another, that the twit Linus misinterpreted as backporting features from a DEVELOPMENT branch to the current production release.
It’d be nice if you and Anonymous (IP: 61.95.184.—) would get with the program.
“I think it makes sense from a company standpoint to basically ‘cherry-pick’ stuff from the development version that they feel is important to their customers. And in that sense I think the back-porting is actually a very good thing.” –Linus Torvalds.
He is right in that it’s not very likely to end up becoming a forking problem, not that forks are a bad thing either.
Hi
“Linus has said that backporting is a very good idea on some cases and he is right. Kingston is just trolling
Unlike you, I have the ability to think for myself. I damn w”
I agree with Linus because he is right about backporting being good in some cases. Thats independant thinking. No need for namecalling here. come up with rational arguments
come up with rational arguments
I have. They’re ignored
SuSE’s kernel historically has had a lot of patches, even the VM was patched from the -aa branch at one time when most distros were using Rik’s VM for 2.4, and they used a USB patch and other patches that distinguished their kernel from the vanilla kernel.
If they were like Slackware, using a kernel that is nearly generic, I’d understand their complaint; but otherwise it just looks like SuSE is slinging FUD at Red Hat.
Hi
“come up with rational arguments
I have. They’re ignored
”
asking people to suck others is NOT a rational argument. People ignoring you is a suggestion or hint
You are dim. I was demonstrating an act of trolling, to allow one to compare it to my previous comments. Offensive as it was, I’m sure that everyone else that read it was bright enough to understand the reason for it, regardless of their feelings for it.
You obviously are not.
You are an osnews sanctioned troll, go home.
And you have the emotional maturity of a blueberry scone.