Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linus Torvalds: Backporting Is A Good Thing

Posted by timothy on from the martha-agrees dept.

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

20 of 232 comments (clear)

  1. Personally, I find it underrated by (1337)+God · · Score: 2, Interesting

    I'm glad someone prominent like L Torvalds is voicing pro-support of this.

    It's vividely overlooked by pros!

    --

    Background: 28/M/Bi-Sexual; Owner of a Linux company; MBA Harvard 2003; B.S. Comp Sci MIT 2000
  2. So does this become the party line? by Anonymous Coward · · Score: 5, Interesting

    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?

    1. Re:So does this become the party line? by JWSmythe · · Score: 3, Interesting

      Been there, done that. :)

      Well, with our own machines. We have a standing rule, the person that hoses a kernel upgrade is the one that gets to drive down to the colo and fix it. Needless to say, we practice on the machine that are in the nearest colo first, before we do the distant remote ones. No one wants to foot the bill of flying from Florida to New York to fix a mistake they made. :)

      (fingers crossed) we've never hosed a machine too terribly far away. A few times we've forgotten to put in the network driver for particular cards, especially on odd-ball machines.

      On a late-night "we have to have this server up *NOW*" install, I built out the server, threw the kernel together (on the console), and drove the machine to the colo. I plugged it in, and turned it on, with the assumption everything was right (usually at about 2am) to get home and find it isn't on the network. An hour and another kernel compile later, it's working. :)

      Pretty much, our distant remote machines are very redundant, so if we hose one, it's not a big deal. If we hose 5, well someone is in for a plane ride.

      It's usually worth taking the plane ride anyways, there's usually something non-urgent that's waiting to be done that can be done while we're there.

      We did have an urgent one-task plane ride once. One of the facilites we're in had a brown-out. When the power came back, our connectivity didn't. The switch was unhappy. The colo's site tech tried resetting it, but that did nothing for us, so someone (me) took a plane ride carrying a switch and laptop. 20 minutes in the colo, 2 hours in taxi's, and 8 hours on planes before I go t home. That was a long night. Exhausted, I did get to have breakfast in the McDonalds in Times Square though (stopped by to see someone before they went to work).

      --
      Serious? Seriousness is well above my pay grade.
  3. As long as it doesnt b0rk my boxen.. by SCSi · · Score: 5, Interesting

    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.

    1. Re:As long as it doesnt b0rk my boxen.. by Anonymous Coward · · Score: 4, Interesting

      That's incompelete because the original story was about RHEL, which is for heavly-loaded servers (and has the new threading and other 2.6 features backported). I don't think anyone really cares about backporting drivers (eg SATA).

      A bigger problem is that the even numbers from Linus really aren't "stable", in the commercial sense. The early versions aren't bug-free enough and the later versions change too much. Furthermore, Linus' timing isn't the same as RedHat's. Linus doesn't care about 5-year support contracts, so they can't use his tree.

  4. It really is a good thing by Rosco+P.+Coltrane · · Score: 5, Interesting

    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
  5. The Linux kernel is forked anyway by gevmage · · Score: 5, Interesting

    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
  6. Backporting has proven... by chipster · · Score: 4, Interesting
    ...to be very valuable at my company - especially for the servers we have that are connected to SAN with Emulex HBA's. Without backporting, we'd spend lots of time hacking the kernels ourselves - which is fun and all - but not when project owners want their environments built yesterday.

    However, for my own personal systems, I don't favor backporting over a kernel upgrade.

  7. Microsoft does it too sometimes by Rosco+P.+Coltrane · · Score: 4, Interesting

    Microsoft too sometimes care to backport things. For example, IPP support in XP has been backported to Windows 95 and Windows 98 after many requests from companies like Brother and from users.

    Unlike what Linus advocates though, Microsoft doesn't do that routinely and users have to bitch and moan pretty bad to get what they need.

    --
    "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
  8. Welcome to Open Source by Anonymous Coward · · Score: 5, Interesting

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

  9. BackPorting is a bad thing in general, but ... by CrackHappy · · Score: 5, Interesting

    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
  10. Re:The beauty of Open Source. by GlassHeart · · Score: 5, Interesting
    People seem to think of forking as bad.

    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.

  11. Re:Quit idolizing Linus Torvalds by Saeger · · Score: 3, Interesting
    People seek leadership. It's simply a part of human nature.

    Eh. And then there's the mutants like me who reject all authority and don't get the celebrity thing.

    --

    --
    Power to the Peaceful
  12. GPL gives you choice by richard_za · · Score: 4, Interesting

    GPL gives the right to fork/backport the code, nobody is forcing you to use a forked/backported kernel. If your current installation is stable and you only need that feature - what is stopping you?

  13. Re:I have to disagree on a few grounds by Alan+Hicks · · Score: 4, Interesting
    The easy answer is to assume the fix hasn't been backported unless the vendor explicitly says it has. Even then, I personally would upgrade to the "latest" version and eliminate all doubt

    I typically do just that, but it isn't always as easy as it should be. RPM based distributions (of which RedHat by definition is) tend to have obscure, hard to trace dependencies in their packages. Compiling from known good source downloaded from the software project's FTP site isn't always the best solution, particularly if you've let other system updates lapse.

    Case in point. I came across a RedHat machine running a vulnerable version of OpenSSH. It was no longer being supported by RedHat, so I downloaded the latest release of OpenSSH Portable. The configure script complained that zlib was old and possibly insecure. This means I had to go in an compile a new zlib, and then make sure everything worked properly when linked with the new zlib. But now, my entire RPM tree is completely hosed. I might as well not even have RPM, since nearly every damn thing relies on zlib.

    In checking RedHat's FTP sites, they had apparently also back-ported security fixes to the older version of zlib (IIRC), which of course meant OpenSSH would have still complained when I re-compiled, but I could be modestly sure it wouldn't be vulnerable, or could I?

    Of course practicies like that enventually force you upgrade your machine to a new version at some point in time, or hose the RPM database by compiling all new updates and their dependencies from source.

    Thank God and Patrick for Slackware, where these problems are few and far between, and typically MUCH easier to resolve.

    --
    Slackware, what else when it must be secure, stable, and easy?
  14. This is great by ErichTheWebGuy · · Score: 2, Interesting

    Personally, I prefer backporting. I see no reason for me to upgrade my installations of kernel 2.4.x, etc. when the system runs just fine. It adds a lot of value to Linux if (at the very least) patches are backported for at least 2 or 3 major revisions. Look at the outcry when our pals in Redmond said no more Win98 support. That only underscores the need for packporting and supporting software for an extended period after the last "official" release.

    Go Linus!

    --
    bash: rtfm: command not found
  15. Slackware uses the vanilla kernel ... by Anonymous Coward · · Score: 1, Interesting

    ... in something like 98% of all cases. The nice think about that is that there is never any problem with just grabbing the latest kernel from kernel.org and installing it. It *always* just works since there are no additional vendor supplied patches to think about.
    I like it that way.

  16. Source of Bruce Perens Comment by tkittel · · Score: 3, Interesting
    From the article:

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

    The public post mentioned was actually this Slashdot comment here.

  17. Work vs. Home by miffo.swe · · Score: 4, Interesting

    I think many of those who complain about backporting doesnt have to manage many servers as i have to. When i have installed and made the things sparkle i dont want to be forced to upgrade. I want my servers to last some time to keep my work load down. Constant upgrading and installation takes valuable time that i doesnt have away. I suspect RedHat backports for preciely those reasons, too keep the upgrade threadmill at bay. Look at how many poeple still uses NT, last i saw some statistics it was something like 60% still on NT. I presume upgrading those servers would demand much work and labour from the admins.

    We dont want a similar situation for linux users, that they dont upgrade because of possible hassle. Backporting ease upgrading while you still get access to new features.

    At home its a whole different matter for us who love to tinker at our free time. I use gentoo of that very reason. I want the latest and gratest at home but damnit not at work.

    --
    HTTP/1.1 400
  18. Re:Wow, four by golgotha007 · · Score: 2, Interesting

    well if that's the case, then you need to throw in a few 'move forwards' in there.

    i deal with several companies in the states, and email from their CTO and CEO's are always peppered with 'moving forward' and 'move forward'.

    it drives me insane! when Darl McBride kept telling open source folks shit like, 'yes, i know you're all concerned with weather or not our IP is in the kernel, but let's just move forward.'

    how freakin assinine is that?