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.'"
sorry thats wrong.
the BSD's started from common ground, but they are now incompatible (in the sense that code cant just be easily applied)
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.
Technicalty you don't put TM in brackets, and legaly (C) or (c) carries no weight of notice. You must use the actual word copyright or © and you can use ® only when the trademark is actually registered or it has no weight either and won't be considered a notice of trademark. So Bobtech® is not a valid trademark notfication if Bobtech isn't actually a registered trademark but Bobtech TM is.
Have fun
As far as I know RedHat has shipped everything open source for a very long time now.
;-)
Yea, RedHat ships everything GPL (or compatible) with the exception of their artwork. I installed Fedora last week for the first time (had been running mdk 9) and it's great. It's stable, runs great, highly configurable, etc. And, it seems to me to be among the "freer" of the distros.
I was SOOO irritated at RedHat stripping mp3 support at first, until I read why they did it. I gladly bit the bullet (and downloaded the patch for xmms
bash: rtfm: command not found
Hell no. Somewhat tangentially, I was having this discussion the other day with someone:
A machine I work on had been upgraded to 2.4.21-pre5, and I was a bit pissy because anything < -pre6 has the ptrace priv escalation flaw.
It turned out that he was using some kind of kerazy Debian kernel with the fix backported. Without eventually finding him and asking him this, I had no way to know this, because: I wasn't allowed to test it and see if it worked ( I don't know PPC shellcode anyway ), The upgrader had not left his source tree or a changelog handy, the kernel didn't have any indicitative flags in its name, he hadn't installed it from a package.
Now, of course, you should be able to do anything you like, which includes cherry picking features into old releases, but in my opinion, this can create a lot of confusion. It'd be really embarassing if the software you wrote only worked on your customised kernel if you didn't know it had been customised.
Version numbers allow us to identify the patch level and feature set of a piece of software and we use them to specify minimum requirements for packages. I think at the very least, if you're going to backport stuff, change the version number somehow ( private fork ) - your patched software and the original can no longer be treated as the same entity.
Ok, er, rant off. My point is that people not in favour of backports usually have some kind of reason for it, even if it's a crappy one like mine, and you'd need to convince me that my reasoning is bad before I'd drop the point.
One god, one market, one truth, one consumer.
The kernel doesn't make much difference as far as binary compatibility goes. Very few binaries directly interact with the kernel. Going from a 2.4 to 2.6 kernel didn't cause a single piece of software I use to quit functioning. Neither did going from 2.2 to 2.4. I once dropped a RedHat kernel onto a Mandrake machine. Everything worked.
Now the userland libraries on the other hand....
try "rpm -q --changelog |more" If you know what is vuln you will see the changes there.
-- "of course thats just my opinion, I could be wrong." --Dennis Miller
Kernel patches generally won't cause software incompatibility. These "fractures" are generally caused by system libraries, most notably the glibc. New versions of the GCC can also be a major source of headaches.
i'm fairly sure that lilo has somesorta lilo -R command or somthing that will try rebooting once wiht a new config. and if it fails wiht the new config it falls back to the old. if you had anotehr computer hooked up to the machine you are upgrading's ups you could just kill the power the the machine you were upgrading with a new kernel and then you could start over.
1337
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.
FreeBSD has been back-porting stuff from their development branch (CURRENT) into their STABLE branch (which is where FreeBSD releases are forked from) for years. They even have their own TLA for it, "MFC" == Merged From Current. Makes STABLE... well,... stable. Very stable. And secure.
Yep. Lilo -R configname makes it reboot into 'configname' on the next reboot only. - I do this every time I upgrade the kernel on a remote machine.
I *also* set up a cron job to reboot the machine every 20 minutes or so, so if something happens like it comes up without networking, it'll reboot back into the old kernel in 20 min. If it comes up, I can kill the cron job and remove the entry for the old kernel.
Saved my life more than once. Particularly on those pesky cheap co-lo boxes where you have to pay someone to reboot it for you.
"Pokey, are you drunk on love?" "Yes. Also whiskey. But mostly love... and whiskey."
I view things the opposite way than you WRT security fixes.
Each time there is a security fix they issue a new kernel version 2.4.x -> 2.4.(x+1) but I think that there should be an additional number to represent security fixes so that you can have a new version without the security flaw but with the same functionality (hence, less chances to have things break).
Ideally we should have the feature set and the implementation numbers be different.
The feature set would evolve with a new minor number for each feature set change and a new major number for each incompatible change (remove functionality). The middle version number would still denote unstable feature sets vs stable feature sets (unstable ones changing much more) but would not denote the stability of the code.
The implementation number would target a feature set version and reflect the degree of completed implementation and code stability of the implementation vis-a-vis that feature set.
For example when they release Linux 2.6.6 instead of just having that number you would have:
And if there is a security flaw you release Linux RI for 2.6.6 - v1.0.1 Instead of Linux 2.6.7.
If the only way to correct the flaw is by changing some interface then you have to issue Linux 2.6.7 with Linux RI for 2.6.7 - v1.0.0 and deprecate Linux 2.6.6.
That way you can update your system while changing the minimum and not adding new code unnecessarily (after all isn't that one of the problems with Windows Service Packs?).
I'm sure this scheme can be tweaked or has already been proposed (libtool version numbers???) but what good is it if it is not used?
"The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." Bill Gates,