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
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
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.