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

53 of 232 comments (clear)

  1. 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 YOU+LIKEWISE+FAIL+IT · · Score: 5, Informative

      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.
    2. Re:So does this become the party line? by Surazal · · Score: 4, Funny

      Something like this happened to me once. It was a comical chain of events, and admittedly the most embarrassing moment of my early career in things Unix-related.

      I was charged with upgrading a kernel, remotely, over the weekend, at a customer site. I did so, and I even remembered to ask first if there was anything special I should consider before going through with the task. No, just use the old configuration file, upgrade and let her rip.

      Ok, while I was kinda nervous about doing this, I felt balls-ey enough to do it anyways. I took the proper precautions. I reconfigured lilo to boot off the copied off old kernel by typing in "emergency" at the lilo prompt. Worse case scenario, I could call in, ask the local operator to walk over to the machine, hit Ctrl-Alt-Del, type "emergency" at the promt, and all would be well. Remember the words "worst case scenario".

      It happened. All went well during compilation, and I went ahead and hit "shutdown -r now" at the root prompt over my ssh connection. The connection was subsequently reset by peer. Ok, I expected that. I'll go grab a beer and wait for the ping to start responding again.

      I waited, waited... um, okay it's still not responding over the internet. Okay, where's that number... um, where did I put that number?

      You can see where this goes from here.

      Two hours later, I had no way of reaching the operator. The number I had in hand disappeared somewhere, and I had no idea where it went. To this day, I have no idea where I put that little slip of paper. Did it get folded into the infinite nooks that existed in my old, torn up wallet? Did it go to the same place where half of a good number of pairs of socks have disappeared to over the years? Where, where, where, where, where?

      Fortunately, all ended well. They had our number at least, and I apologized, gave them the emergency procedure, and everything was working again. Hooray for the forces of good!

      To this day, my heart still skips a beat whenever I reboot a server remotely.

      ------

      P.S. as it turned out I wasn't told that the kernel module for the network card being used wasn't officially supported by the official Linux kernel at the time, and that needed to be downloaded separately and recompiled along with the new kernel. It did boot successfully. It just did so without network support. D'oh!

      --
      --- Journals are boring; Go to my web page instead
    3. Re:So does this become the party line? by psychosis · · Score: 4, Insightful

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

    4. 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.
    5. Re:So does this become the party line? by mtvsucks · · Score: 3, Informative

      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
    6. Re:So does this become the party line? by moon-monster · · Score: 5, Informative

      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."
    7. Re:So does this become the party line? by minus9 · · Score: 3, Funny

      You recompile your Windows NT kernel?

  2. 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 Lehk228 · · Score: 4, Insightful

      well if you switch kernels and a device fails you should at least suspect the new kernel

      --
      Snowden and Manning are heroes.
    2. Re:As long as it doesnt b0rk my boxen.. by GlassHeart · · Score: 4, Insightful
      My fear is always that development/new stuff backported to a "stable" kernel is going to cause system unstability and weird stuff.

      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.

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

  3. 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
    1. Re:It really is a good thing by EmbeddedJanitor · · Score: 5, Insightful

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

  6. Quit idolizing Linus Torvalds by Anonymous Coward · · Score: 5, Insightful

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

    1. Re:Quit idolizing Linus Torvalds by xoran99 · · Score: 5, Insightful

      People seek leadership. It's simply a part of human nature. I can understand where people might develop a "What Linus says goes" mentality when he's already done so much.

      --

      Karma: Bad (mostly due to all those "In Soviet Russia" jokes)

    2. Re:Quit idolizing Linus Torvalds by Laser+Lou · · Score: 4, Funny
      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...

      I bet you're not Catholic.

      --
      No data, no cry
    3. 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
  7. SCO fixes by the+MaD+HuNGaRIaN · · Score: 4, Funny

    Then perhaps someone should back-port the fixes that remove the SCO code.

    (ducks to avoid flying objects)

    1. Re:SCO fixes by Rosco+P.+Coltrane · · Score: 4, Funny

      Here's the fix:

      cd /usr/src/linux/
      echo "" > ./sco_ip.patch
      patch -p1 < ./sco_ip.patch
      Do this and you'll have a kernel free of any SCO code.

      --
      "A door is what a dog is perpetually on the wrong side of" - Ogden Nash
  8. Backporting a Good Thing (TM) by Eberlin · · Score: 5, Insightful

    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.

  9. Suse by augustz · · Score: 5, Insightful

    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.

    1. Re:Suse by ImpTech · · Score: 3, Insightful

      Umm... the BSD's use, :shock:, the BSD license! That proves nothing with regard to GPL'd Linux. Even so, there's nothing stopping the BSDs from becoming compatible if they want to, all the code is there. They just philosophically decided to go off in different directions. When acutual UNIX was forked back in the day, it was with proprietary implementations, which means no going back. RedHat can't try to force SuSe out of the market with kernel patches, because theres nothing stopping Suse from applying those same patches if they want.

  10. 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
  11. No. by DAldredge · · Score: 5, Funny

    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.

  12. The beauty of Open Source. by ron_ivi · · Score: 4, Insightful
    We don't need a consensus. If RedHat has the means to support backports and the customers who want them, more power to them. If Debian Stable picks only the security patches and has an audience who likes that, awesome.

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

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

    2. Re:The beauty of Open Source. by dmaxwell · · Score: 4, Informative

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

  13. Re:why the fuck should we care by Anonymous Coward · · Score: 3, Funny

    His skills are on the hello world level anyway

    Actually no, his skills are much below the "hello world level". Pretty much right under the libc6 layer in fact.

    You, on the other hand, seem like you couldn't even pass a urine test...

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

  15. 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
    1. Re:BackPorting is a bad thing in general, but ... by CrackHappy · · Score: 4, Insightful

      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
  16. I have to disagree on a few grounds by Alan+Hicks · · Score: 4, Insightful

    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?
    1. 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?
    2. Re:I have to disagree on a few grounds by DA-MAN · · Score: 4, Insightful

      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

      That's what the errata pages are for. One quick stop at redhat.com/errata will answer all your questions.

      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?

      Again, errata pages

      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.

      Let's just think about Apache as an example. Say a bug comes out in Apache 1.3.26, theres a fix in 1.3.29. Now let's say that you also bought an apache mod ala Chilisoft to handle ASP, but it only works with 1.3.26. Would you feel good about RH updating to 1.3.29, instead of moving over those 2 or 3 lines that fix some buffer overflow in some .c file on an older version?

      In addition there are open source modules. Imagine a problem with Apache 1.3.26 so RH puts out a fix for 1.3.29 in addition you'd have to release errata for php + all it's modules, mod_ssl, mod_perl, mod_python, and more...

      Backporting is the best way to run a stable and secure system. Micro changes to known good subsystems. In fact if you notice, Debian Stable is secure and stable because of the backporting of fixes and those releases last for decades.

      --
      Can I get an eye poke?
      Dog House Forum
  17. Linus is the human voice of the kernel by darthcamaro · · Score: 3, Insightful

    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.

  18. Wow, four by Anonymous Coward · · Score: 5, Funny

    "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!

    1. Re:Wow, four by CrackHappy · · Score: 3, Funny

      Oh gawd, you're right.

      I've been consumed by the corporate lingo machine. Comes from talking to the CEO too much.

      --
      1f u c4n r34d th1s u r34lly n33d t0 g37 l41d Capitalization really works: i helped my uncle jack off a horse
  19. Suckers! by Anonymous Coward · · Score: 5, Funny

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

  20. TRFA - instead of going for the big headline by Magickcat · · Score: 5, Informative

    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.

  21. Re:So says God! by Zoko+Siman · · Score: 3, Insightful

    If you are going to say something, at least tell us why. It's one thing to get on your soap box, it's another to defend yourself and explain on your soap box.

  22. Seems everybody agrees now... by greppling · · Score: 4, Insightful
    ...so while I am not completely against lots of forking, it seems worthwile to reexplain the problems with it:

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

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

  24. Obligatory by cpu_fusion · · Score: 3, Funny
    Looks like we don't need to speculate [..]

    You must be new here...

  25. Forking is almost always ugly by spagetti_code · · Score: 5, Insightful

    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.

    1. Re:Forking is almost always ugly by sw155kn1f3 · · Score: 3, Funny

      > 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

      LOL man :) You just described GNU autoconf.
      What's wrong with it ?

      --
      - Arwen, I'm your father, Agent Smith.
      - Well, you're just Smith, but my father is Aerosmith!
  26. Re:Yup by DA-MAN · · Score: 3, Informative

    Yea, RedHat ships everything GPL (or compatible) with the exception of their artwork.

    try rpm -qi redhat-artwork and you'll see the following:

    Name: redhat-artwork
    License: GPL
    Description: redhat-artwork contains the themes and icons that make up the Red Hat default look and feel.

    --
    Can I get an eye poke?
    Dog House Forum
  27. Just Like This by SomeOtherGuy · · Score: 3, Insightful

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

  29. 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
  30. MFC by Anonymous Coward · · Score: 3, Informative

    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.