Slashdot Mirror
Linus Torvalds: Backporting Is A Good Thing
darthcamaro writes "Looks like we don't need to speculate on what Linus' opinion is on backporting. Internetnews.com is running a story this morning that includes Linus' comments on the issue which was a /. topic yesterday.
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.'"
Come on guys, stop looking for what Linus has to say to make up your mind, it's ridiculous. Although I think he is right most of the time, many Linux users and developers seem to take his word for some Sacred Truth and that's annoying ! Striving for an alternative OS while letting yourselves be sheparded by some high-tech guru is quite paradoxal...
The argument against backporting is that a lot of wasted time/effort goes to something that could've been taken care of by upgrading to the latest/greatest kernel.
The practicality here is that not everyone needs to upgrade to the latest kernel. Some production systems are stable enough as is and don't need the upgrade. Some may even become unstable as they get upgraded. Thus if some features are needed from the newer versions, backporting allows people to utilize just the features they need.
All part of that Open Source GPL Free as in Freedom thing. Even for those who consider it a waste of time and effort, those are things that the GPL entitles anyone to put effort into. Those who are adamantly against such wasted manpower should probably consider visiting SourceForge for a coronary.
Very few vendors ship a TOTALLY plain kernel. I'm not sure why Suse makes such a big deal of theirs (if they even do ship a clean one, hard to beleive).
The power of the GPL is that you can never truly fork the way Unix was forked. If Suse wanted to be compatible with redhats kernel, they can easily cherry pick the changes necessary, and redistribute them themselves.
All very intresting coming from a company that had a propriatary installer. As far as I know RedHat has shipped everything open source for a very long time now.
well if you switch kernels and a device fails you should at least suspect the new kernel
Snowden and Manning are heroes.
People seem to think of forking as bad. I think of it as "market research" -- whichever distro has the "best" philosophy will get the most users and/or customers (not necessarily the same thing - hense "best" was in quotes).
Well, we all know that Linus is God, and whatever he says goes... right? Well, perhaps not. Although I definitely appreciate his programming skills, and the wonderful donation to society that we know as Linux, I don't think that I agree with him on this issue. Blasphemy?
- Code Dark
While I don't believe that back-porting security fixes, or even new features is a major danger to forking an open source project (be it the kernel or something else doesn't matter), I do find it a danger as a sysadmin.
Often times I've had to administer an older RedHat linux machine that may be running a version two or more years out of date. A vulnerability comes up in a service that hasn't been patched in God knows when, and I have to fix the hole. The security advisory says version a.b.c is vulnerable and that I should upgrade to a.b.d or a.e.X. So I log onto that machine and check to see what version it's running and I see:
a.b.c-g
So is a.b.c-g vulnerable or not? Did RedHat back-port something from the a.e.X branch that fixes this? Now I have to dig through some RedHat mailing lists which I may not be subscribed to to find out. Now I know for a fact that when I see an a.b.c-h version for download from RedHat's site, that I've need to upgrade.
But what if it's the other way around?
What if I hear about a vulnerability in version a.e.X of that same software, but that the a.b.X version is safe. Did the vendor back-port some vulnerable bit of code from a.e.X into their a.b.c-g binaries? How am I to know?
Back-porting things like this makes it hell on a sysadmin who then has to subscribe to lots of different mailing lists, particularly if you're running different distributions.
Slackware, what else when it must be secure, stable, and easy?
One really GoodThing about backporting (or any porting for that matter) is that it beats up on the code in a different way. This is likely to help flush out bugs.
Engineering is the art of compromise.
Way too many voices from anonymous cowards in this discussion dissing Linus. Linus is the voice of the Linus kernel. Period. Sure many,many others contribute, but it's his original creation. He holds the copywrite to the name Linux so he has the 'EARNED' right to the authoritative voice. Nuff said.
The problem is that Linux serves three major customers: developers, desktops, and servers. The developers are well-served by the odd-numbered development branch. The servers need a rock solid branch, but tend to have very little need to support new hardware, so they should be happy with the even-numbered branch. The desktops still need stability, but also have to work with new hardware. Since the kernel developers don't have a formal process for this demographic, it's up to the distro maintainers to backport changes from the cutting edge.
This is not a good thing, though. If each desktop Linux distro picks a slightly different subset of features to backport, desktop Linux can become even more fractured than the Gnome/KDE division. If they can manage to work together, it might be better to establish a new common branch between the two traditional ones.
That's true, but at what expense? Let's say the vendor that a customer is using goes out of business and has done some significant backporting and customization of their kernel. Some of the vendor's applications depend upon this and thus would need some modification to make it work with a vanilla kernel. At that point, there could be significant cost to the customer.
I know that it's a hypothetical situation, but I see it every day at work. The vendor that we are using has built their software and applications in such a way that we cannot migrate any of our applications off of Microsoft platforms because of very specific tie-ins to SQL Server, IIS, and Windows 2000.
The data could move just fine, but all the business logic would be toast.
I just can see this kind of thing happening with a forked and backported kernel. I don't think it is anywhere near as likely, but something to consider.
1f u c4n r34d th1s u r34lly n33d t0 g37 l41d Capitalization really works: i helped my uncle jack off a horse
The more standardized the installed Linux kernels around the world are, the easier it is for application developers to develop and test for all Linux platforms. Why do you think don't we have an Oracle certification for Debian? Because the debian vanilla kernel is different enough from the RedHat kernel that all their testing is invalidated. Also, remember that there is not even a standardized way to test whether a certain feature is available way in an installed kernel.
I think Linus Torvalds himself is always underestimating the importance of his vanilla kernel. His claim is always that it is not very important for a patch to be "in", as everyone who needs it can apply it himself. But as a matter of fact, it doesn't make sense to make an application dependent on a kernel feature, unless this feature is part of the vanilla kernel. Or unless you are willing to develop for "RedHat only", at which point the /. crowd will certainly cry foul.
The other point is, of course, that many forks imply a diversion of kernel development resources. For the record, one of the reasons Andrew Morton has given for accepting the 4G/4G patch into -mm is that he is aware that distributions will need it anyway, and he doesn't want to have distribution kernels diverge from vanilla as quickly as in 2.4. (Actually, now that objrmap is in -mm, it might not be necessary any more.)
You sir, are on (or more) of several things:
*Very new here.
*Very brave--this usually is posted as AC
*Very stupid (note that this is not exclusive of other options.
*A troll (also not exclusive).
*porting balls of steel the size of a semi truck.
*trying to be funny. I really hope this is what it is, because you are going to get flamed.
BTW, care to provide links and or sources? (in case you aren't trying to be funny.
"We don't know what we are doing, but we are doing it very carefully,..." Wherry, R.J. Personnel Psychology (1995)
I worked on a unix product in the late 80's early 90s. We supported 35 different variants/versions of Unix. Each one had a set of #defines throughout the code dealing with slight variations in libraries, in tools, in compilers and so on.
When we ported to a new version of unix, we had scripts that would compile test programs for each of 100s of known features that differentiated these unii (plural of unix?). Results of the test programs would auto-create the config program.
It was a nightmare, one that I have not had to deal with as much in the Windows world. (re-reads sentence, sighs, puts on flame suit). It was one of the early strengths highlighted by the MS marketing dept ("There is only one windows, but hundreds of unixes").
I was hoping Linux wouldn't go down that path. Just the thought of YAST vs RPM etc gives me the willies. Forks can only lead the distros further apart.
You're 100% justified in your frustration with the case you detailed, but the fault lies with your kernel developer/upgrader's kernel compile process.
The whole mess would have been avoided if he had set the EXTRAVERSION variable in the kernel's Makefile to something meaningful (i.e. make the kernel version 2.4.21-pre5_custom_04apr04) and posted his specific notes on that kernel someplace where all can find them (I can personally recommend an internal Wiki for this - it works wonders).
Also, if you release software after testing it on only one kernel, methinks there are some testing procedures to be beefed up!
Don't knock backports for their own sake - knock those who misuse them. (Upside the back of the head, preferably.)
The freedom and power to backport, sideport, crossport, etc...Is the reason why the Linux kernel is now running on everything from Tosters and Parking meters to Rocket Ships and Space Stations. How can that be a bad thing? Millions of devices are running on this stuff...how cool is that?
(+1 Funny) only if I laugh out loud.
The semantical definition of open source is the key. Is LINUX trying to be UNIX? Is LINUX bound by UNIX's history? No! LINUX is free, its open. Its punk rock. I think that's what I like the most. You can do whatever you want with whatever you want and its all good, as long as you follow the GPL, or whichever license.
People get all freaked out on the Red Hat corporate stance (myself sometimes included). But in reality, comparing Red Hat with Microsoft just does not work. I mean, there are so many open source options, and I don't think Linus is close to selling out to Red Hat.
Focus on the fact that LINUX is free. There will always be some dork, even me if I must, who will throw together a distribution for those less inclined to compiling things themselves.
Sorry for the rant.
I have the certificates to prove this, and furthermore they're issued by the biggest software company in existence.
...Reliable companies with tried and tested products, or that bedroom coder Thorwalds who publicly admits that he is in fact A HACKER???
;)
That proves nothing. Actually, it may speak negatively about your skills. I passed an MCSE at age 12, and I sucked at age 12. I was a huge newb who thought that hackers were bad people etc. Reading your post, so do you. Unfortunately, I doubt you have the convenient excuse of being 12.
These are hard numbers and 100% FACTS! There are several more where these came from.
Oh, boo-hoo. Not to mention, these results were all from independent Microsoft examinations.
Since WHEN has Windows been EITHER reliable or tried and tested? Microsoft is a commercial company, making commercial products, for profit - - That Bedroom Hacker made brilliant pieces of code, that have been peer-reviewed by people who are not interested in profit, but software as an art.(And Linus isn't driving a BMW Z3 for nothing!
I know, I know... Feeding the trolls..
toresbe
You've obviously, as most of slashdot it seems, have never heard the two words "supported configuration".
Let me explain. We're running a DB2/WAS installation. We bought all the hardware from IBM down to the IBM branded FC cards and FC switches. We then purchased several RHAS2.1 licenses for this installation.
Why? Enterprise. Pure and simple. We need immediate support from IBM and they have a very specific list of "supported configurations". Deviate and they won't touch you.
RedHat backporting fixes has only been a problem when certain drivers check for a SPECIFIC subrelease in the kernel. This happened with the IBM 3582 LTO robot we have.
RedHat AS2.1 uses kernel 2.4.9 but is constantly backporting security fixes. They rev the kernel RPMS like so:
2.4.9-e25summit, 2.4.9-e38summit and so on. Most driver vendors I've worked with check for RHAS 2.1 running kernel 2.4.9 and leave it at that. For some reason the blasted tape library drive checked for a specific rev number. I can't even download the kernel from RedHat or anywhere on the web that the stupid developer built the kernel against. At some point I was forced to cpio the rpm and force load the tape library driver just to get the damn thing loaded. Guess what? As I expected it worked just fine.
RedHat and SuSe and the gangs that backport do it for a very good reason. They have a kernel that hardware vendors build against. The backports go through some SERIOUS review to make sure they don't break anything existing. This also keeps the kernel version number they check for the same.
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"
Development-stable vs. production-stable.
I keep pointing this out on Slashdot, and for some reason people keep missing it: What comes out of the Linux Kernel Developers is a development release. Just like any development release structure of sufficient size, they have several working branches and several stable branches, but that doesn't mean that what you get from a "stable branch" is a valid production release.
When a vendor releases a Linux system, I expect their kernel to be a valid production release. That is, they are going to support that release for some specified period of time, and it's not going to change in incompatible ways. Take a look at the history of 2.0, 2.2, 2.4 and you'll see large numbers of incompatible changes (scheduling, filesystems, etc.), but they're compatible changes FROM THE DEVELOPER'S STANDPOINT. They don't change API's, but they might make your production installation behave radically differently.
I expect, e.g., Red Hat to release a 2.2.x kernel and continue to support it by back-porting security updates and critical bug-fixes, but otherwise LEAVE IT ALONE. They've not always done this, and part of that is that Linux is still in the late stages of an early adopter market (i.e. the market size is still growing in a logarithmic pattern). I can understand that, but in the future, I expect Red Hat Enterprise Linux 20.0 and Red Hat Enterprise Linux 20.45 to differ very slightly, and possibly be separated by 5 or 10 YEARS. That leaves no room for kernel-of-the-year upgrades.
So, back to the point: backports are fine, as long as it's the developers doing the backporting. If vendors start picking up those backports just because they can, I have a problem with that. I also have a problem with a vendor that releases a kernel version that has been out less than a year....