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.'"
A lot of people stated they didn't like the idea of back porting. How many of you have changed now that Linus has stated his favor?
Then more power to them. My fear is always that development/new stuff backported to a "stable" kernel is going to cause system unstability and weird stuff.
Having a list of what exactly is backported would be optimal, that way when device X b0rks after 3 months of uptime, you know its possibly related to the newest version of that rock "stable" kernel you put into production.
When 2.4 wasn't stable, I was glad to take advantage of USB with my 2.2 kernels using the 2.2.16 USB backport (no longer available from linux-usb.org apparently).
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
My understanding of people's main complaint about the backporting that companies were doing was that it forks kernel development.
But that's nothing new. The kernel has forks in it anyway. The PowerPC kernel, for instance, exists as its own set of patches to the main kernel tree. Linux can't be everything to everyone so this is an inevitable development.
I think that's the point of open-sourcing your code. If someone else can write a better (more appropriate) one, more power to them!
Craig Steffen
http://www.craigsteffen.net
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.
We tried, but seeing how Linus likes to keep a low profile and NEVER gives out his email address to anyone, we where unable to.
Perhaps one day people will be able to understand his thoughts and passions but, sadly, today isn't that day.
What are people bitching about? It's OPEN SOURCE. Redhat has made a business decision to backport functionality/fixes to an older kernel. They feel their customers need those fixes/features and they're supporting their customers. They're also making those fixes/features available to anyone else who wants to download them.
You don't want them? FINE. Download and build a vanilla kernel at any time. It only takes a few minutes. Talk about a tempest in a teapot....
can be good in specific instances.
I believe Linus touched on this point pretty eloquently.
The basic issue that I believe is the root of the problem is that at the end of the day, the majority of Linux users and developers are generally in synch and moving along at a brisk pace, while the backported and modified kernels are effectively not supported except by the specific vendor that created the fork. This basically will always either lock the customer in or make it more difficult to integrate new features if the customer wishes to switch vendors. This is like turning forks into a mini Windows.
Just my $.02
1f u c4n r34d th1s u r34lly n33d t0 g37 l41d Capitalization really works: i helped my uncle jack off a horse
"The basic issue"
"I believe"
"root of the problem"
"at the end of the day"
At the beginning of one sentence, you used four of the most overused means of beginning a sentence that I know of - impressive!
I love it when all the Linux drones bitch and moan as they follow Torvalds down the primrose path. Now us Mac users, for instance, think diff...hold on...Steve's doing another keynote...be right back...
Linus' opinion appears to be much more balanced than your selected excerpts and comments portray. The article is quite even handed, and you appear to have completely misrepresented or perhaps misunderstood the complex ideas in it.
His final comments are in fact: "So you win some, you lose some, so far I suspect it's been mostly positive."
Here are some extracts from the article that illustrate this in a more even handed light:
"And even Torvalds' support of the practice comes with some caveats. "There are parts of it that worry me logistically," Torvalds wrote in the e-mail to internetnews.com. "What usually ends up happening is that the back-ported patches aren't being very cleanly maintained, and that ends up making it harder for people to do a good job of maintaining a coherent base for the stable kernel." "
"Although kernel 'coherency' is a victim of backported features, according to Torvalds, its impact is not long lived. "That lack of 'coherency' makes long-term maintenance harder (and is probably why the SuSE people aren't thrilled, because it also makes it harder to keep different trees reasonably well in sync)," Torvalds continued."
""But as long as the long-term goal ends up to drop the old stable kernel in favour of the development kernel anyway, the pain is likely to be fairly temporary.""
Bruce Perens also contributes some fairly even handed comments:
"However, Bruce Perens, a former Debian Project Leader and author of the Open Source Definition, wasn't as quick to compliment Red Hat.
"In a public post, Perens wrote, "I have a large customer who refuses to run Red Hat's kernel even when they run Red Hat's distribution. And it's just for the reason that [SUSE] talks about. The kernel is so far diverged from the main thread of Linux that it's a dead-end, and there's no hope of getting it supported from anyone but Red Hat. I don't know if they meant it as a lock-in play, but it works out that way. And my customer doesn't have patience for Red Hat's support.""
"Despite his comments, Perens told internetnews.com he didn't think the issue was that big a deal and hoped the community wouldn't over-react."
Si tacuisses philosophus mansisses. If you had kept quiet, you would have remained a philosopher.
First of all, speaking as a professional software developer, forking is bad. Forking inevitably involves extra work integrating changes from branch to branch, and can be justified only by some technical or business need. Forking also multiplies testing requirements.
I think we're talking about unnecessary forking as bad. For example, if vendor R backports features A, B, C, and D, while vendor S backports features A, C, D, and E, and vendor D backports features A, B, and E, writing software that'll work on "Linux" can already become complicated. In my example, you can only count on feature A being present, despite the collective effort of distros to backport 5 features 11 times!
The Linux software market, particularly on the desktop, is small enough as it is. If the market demand for backporting comes mainly from the desktop, then it might be better to establish a common "desktop branch" somewhere between the development and stable branches.
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.