Forgot your password?
typodupeerror
Red Hat Software Open Source Oracle Linux

Red Hat Stops Shipping Kernel Changes as Patches 184

Posted by Unknown Lamer
from the clearly-the-best-solution dept.
mvar writes to point out a report from h-online about the Red Hat kernel source controversy. From the article: "Red Hat has changed the way it ships the source code for the Linux kernel. Previously, it was released as a standard kernel with a collection of patches which could be applied to create the source code of the kernel Red Hat used. Now though, the company ships a tarball of the source code with the patches already applied. This change, noted by Maxillian Attems and LWN.net, appears to be aimed at Oracle, who like others, repackage Red Hat's source as the basis for its Unbreakable Linux. Although targeted at Oracle, the changes will make work harder for distributions such as CentOS."
This discussion has been archived. No new comments can be posted.

Red Hat Stops Shipping Kernel Changes as Patches

Comments Filter:
  • by Anonymous Coward

    Did they stop shipping diff too?

    • Re: (Score:3, Informative)

      by Josh Triplett (874994)

      You can obviously find out the overall difference, but now Red Hat no longer provides either a git tree or split-out patches for each change, which makes it harder to figure out what individual changes they've made to the kernel.

      • by FunkyELF (609131)

        How does this matter for CentOS who wants to be exactly like Red Hat minus the trademarks? Wouldn't they want to use the same exact source and not pick and choose patches?

        • Wouldn't they want to use the same exact source and not pick and choose patches?

          Except where Red Hat put their logos and trademarks. Now instead of searching the patches for those, they need to search the entire patched source.

          • And since they'll be searching a single diff instead of a lot of patches, it may actually be easier ;-)
          • Now instead of searching the patches for those, they need to search the entire patched source.

            If there are trademarks in the kernel that need to be removed then this is a good change for CentOS. They would need to search BOTH the kernel source AND the patches when they were separate, now they only need to search the kernel source.

        • It effects the kernel devs and other distros that may want to incorporate some of Red Hats changes.

          It also effects red hat users that want to recompile the kernel with only some of the patches from red hat.

          • It effects the kernel devs and other distros that may want to incorporate some of Red Hats changes.

            I doubt this is true, they are only changing how they package the Red Hat kernel source, I am sure they are still submitting changes to the community. It seems the difference here is if you want to use the Red Hat kernel but don't want certain patches, but if you just want to use Red Hat changes in a vanilla kernel I am sure the Red Hat developed patches will still be available.

            • Apparently Red Hat is not making this easy, see the release announcement [indiana.edu] for 2.6.32.30. Not sure if it's related, but it appears it might be.

              Specifically:
              "Many thanks again to Maximilian Attems who dug around in a lot of different distro kernels and forwarded to me the original git commit ids that should be applied to this tree. Red Hat didn't make this very easy due to their "one giant patch" format, and his skill is helping everyone out here. It's much appreciated."
        • It doesn't matter at all for CentOS. It matters for other Linux distributions that want to collaborate with Red Hat and with upstream. Digging a fix out of the Red Hat kernel becomes a lot harder with only a monolithic patch. And without fine-grained patches, any kind of conflict between the megapatch and other kernel patches becomes incredibly difficult to troubleshoot.

      • by guruevi (827432)
        All that is necessary to do then is upload the new RH tree to your own git/svn and see what changed compared to either the last RH kernel or the original. This guy: http://en.wikipedia.org/wiki/File:Larry_Wall_YAPC_2007.jpg [wikipedia.org] can probably quote you a Perl script to walk through and diff the whole tree in his sleep.
  • by Anonymous Coward on Friday March 04, 2011 @12:46PM (#35380674)

    "Although targeted at Oracle, the changes will make work harder for distributions such as CentOS."

    That's not what CENTOS says.

    "This description is accurate. However, as pointed out multiple times by now, it does not affect rebuilding of the kernel itself. The CentOS kernel is just a rebuild, so there is no problem there. In the case of the centosplus kernel, because it may add patches, some extra steps might be needed. But again, that is not a major issue."

    https://www.centos.org/modules/newbb/viewtopic.php?topic_id=29147&start=280

  • Good for them (Score:3, Interesting)

    by Anonymous Coward on Friday March 04, 2011 @12:52PM (#35380748)

    Screw those asshats at oracle who have the nerve to package up rhel and call it their own. Even worse their idiot sales reps go around promoting it as the only thing that will run their db. All they contribute to open source is FUD.

    • by afabbro (33948)

      Screw those asshats at oracle who have the nerve to package up rhel and call it their own. Even worse their idiot sales reps go around promoting it as the only thing that will run their db. All they contribute to open source is FUD.

      They don't say that. You can run Oacle on RHEL or SUSE just fine and it's supported.

      So screw those asshats who post FUD as AC on Slashdot...

      • by rubycodez (864176)
        but Oracle implies their products run *well* only on Oracle Linux. (from oracle.com) Oracle Linux combined with Oracle's Unbreakable Enterprise Kernel brings the latest Linux innovations to market, delivering extreme performance, advanced scalability, and reliability for enterprise applications. The combination is: * Fast—Delivers more than 75 percent performance gain in OLTP performance tests over a Red Hat 5 Compatible Kernel; 200 percent speedup of Infiniband messaging; 137 percent faster s
      • by alewar (784204)
        The Lustre file system used to support RedHat, SUSE and vanilla kernels. After the acquisition by Oracle, only RedHat and OEL are supported. I'd say fuck Oracle.
  • CentOS Impact? (Score:5, Insightful)

    by burnin1965 (535071) on Friday March 04, 2011 @12:53PM (#35380758) Homepage

    Since CentOS is basically removing trademarks and recompiling how exactly does this make their work more difficult? Does CentOS not ship the same kernel as Red Hat by using Red Hat source? Wont CentOS simply compile the pre-patched source from the tarball and be good to go?

    • Re:CentOS Impact? (Score:5, Insightful)

      by thatseattleguy (897282) on Friday March 04, 2011 @01:00PM (#35380850) Homepage

      Mod parent up - it's correct.

      The article is completely wrong in relation to CentOS (which aims for 100% binary compatibility to RH). AFAIK, they don't care which patches were applied by RH because they're duplicating the kernel down to the last byte. As you say, they'll just compile the tarball and off she goes.

      The article is correct as far as an entity like Oracle is concerned, which aims to put in its own additions and "improvements".

      I'm of two minds about whether RH is evil or prudent to do this, but on balance I've got no lost love for Larry Ellison, so I give RH the benefit of the doubt on this one.

      • Re:CentOS Impact? (Score:5, Informative)

        by nettdata (88196) on Friday March 04, 2011 @01:25PM (#35381174) Homepage

        The Oracle improvements, for the most part, are actually kernel level modules and services that provide the required functionality to facilitate their database clusters. They basically provide the inter-node communication and shared block access management services among other things.

        I'm a long-time Oracle DBA, and could care less about this little war. I just know that it pays the bills.

        • by gbjbaanb (229885)

          fair enough - but they should either pay RedHat for the product they reuse, or submit their DB modules etc as open source so they can be added to the upstream repository.

          Then everyone can run Oracle on RH (like they do anyway) and Oracle can just drop their own distro and reuse Redhats, directing customers to RH which I'm sure would be cheaper for Oracle and more profitable for RH.

        • Are those modules available in any OSS repository? They can optimize all they wish, but I would like them to be good sports about piggybacking on OSS's braintrust and commit their optimizations back to the community. It's only fair since they're leveraging these mods off a great deal of RH's work.

      • I'm of two minds about whether RH is evil or prudent to do this

        I'm no kernel hacker, but it's at least conceivable that RH's reasons for doing this are not to screw with Oracle or others, but rather because it's most convenient for them. Yes, having changes shipped separately is nice for a lot of people, but maybe RH decided to optimize their workflow, merging code and whatnot, and the end result of this optimization was that it was easier to distribute the merged code rather than distributing their internal toolchain, scripts, etc.

        As others have pointed out, you ca

      • I use both CentOS and RHEL and still rebuild kernels quite often. This actually makes it easier for me to rebuild the *stock* RH kernel. It makes it somewhat more difficult to take those patches and apply them to the vanilla kernel.

      • by devent (1627873)

        It's against the spirit of the GPL, isn't it? To take from the community but to put stumbling blocks in the form of that the community can't see the history of changes or to reapply certain patches. Since Oracle is developing on the Linux kernel they are a part of the community (I didn't read about a case were Oracle is making parts of the kernel propriety).

        If you want to see who is on the evil site, just swap out the names. For Oracle put "Debian" and for Red Hat put "Canonical". So Canonical is developin

        • Canonical is developing patches but they are now making only the complete Kernel as a tar ball available

          I think there is some confusion here. Red Hat is no longer providing separate patches in the Red Hat kernel package. I am pretty sure Red Hat will continue to provide patches back to the kernel development community. I don't think the kernel developer community are downloading the Red Hat source RPM for the kernel and extracting the patches to include in the tree.

    • Re:CentOS Impact? (Score:4, Informative)

      by bill_mcgonigle (4333) * on Friday March 04, 2011 @01:22PM (#35381140) Homepage Journal

      Wont CentOS simply compile the pre-patched source from the tarball and be good to go?

      Yes, CentOS will be fine. There's been some interesting discussion on the CentOS-devel list lately about how CentOS is positioning itself w/r/t Redhat. They're reluctant to share an automated build process with the community (so the process can be independently verified) because that would help Redhat's competition (seemingly Oracle). The trouble is, it also slows progress (no CentOS 6 builds yet) and makes forks difficult (something that ought to be encouraged, if needed, in the Open Source ethos).

      The CentOS team does awesome work, but it's a tricky situation they're in.

      • The CentOS team does awesome work, but it's a tricky situation they're in.

        Agreed, and I hope my comment did not make it sound like the CentOS team has an easy job. I am not in a position right now to pay for a full blown Red Hat Network license for home use so I've been using Fedora and CentOS since Red Hat dropped the $60 / year RHN subscriptions. I am very appreciative of the work the CentOS team does.

        But I also think it is a big mis-representation to put what Oracle is doing into the same realm as what C

      • by JamesP (688957)

        Doesn't matter much. CentOs would benefit from having its own build system.

        RHs build system is very old and based on CVS (ya rly)

        • CentOs would benefit from having its own build system.

          It does have its own build system, it's just that you (as the end user, auditor, or forker) can't download a ready-to-run copy of it from CentOS.

          • by JamesP (688957)

            Yes, interesting

            Some distributions allow their build system to be downloaded as part of the distribution. Of course CentOS can't have it as part of the distribution because it's not from the 'preeminent Linux vendor'

      • by fnj (64210)

        CentOS may be slogging away slowly to bring out CentOS 6, but Scientific Linux 6 went live yesterday, and their pre-releases have been easily accessible to anyone since December.

  • diff(1) (Score:5, Informative)

    by LizardKing (5245) on Friday March 04, 2011 @12:54PM (#35380770)

    $ tar xzvf linux-2.6.nn.tar.gz
    $ tar xzvf linux-redhat-2.6.nn-02.tar.gz
    $ diff -Naur linux-2.6.nn linux-2.6.nn-02 > redhat-02.patch
    $ diff -U redhat-01.patch redhat-02.patch | more

    • by Andy Dodd (701)

      I think the issue is that previously, RedHat shipped a bunch of independent patch files, split by "issue fixed/function added"

      Your method generates a single "megapatch" file.

    • by Kjella (173770)

      That'll give you one giant patch of everything Red Hat has done. Now, what changes in what files go together and implement a patch? The point would be to look at the patches one by one to see they've been applied, and now if you want to do this you must break it down yourself.

      • by idontgno (624372)

        All the changes go together and implement one big patch. What "patch identifiers" RH used in their own patching process are is irrelevant as it gets.

        Since the objective is a kernel identical to RH's, there's no need to obsessively worry about which of RH's patches were applied or not, because the correct answer is "all of them".

        This approach has absolutely no downside as long as RH continues to honor their GPL obligations and actually releases all code changes, whether by diff or full source.

        • 'Since the objective is a kernel identical to RH's, there's no need to obsessively worry about which of RH's patches were applied or not, because the correct answer is "all of them".'

          Ah, but for Oracle, that's not necessarily the aim. They may want to apply some patches and not others. That makes them able to say that their version is different from Red Hat's, and thus the right one to run for Oracle. Now they either have to do their own patching or rework their own patches on top of every new Red Hat pa

          • by idontgno (624372)
            No sane human being gives a metric rat's ass about what Oracle wants, except possible for the purposes of impeding it more efficiently. Frankly, if this is RH's goal, more power to 'em.
        • What about the CentOS plus [centos.org] kernels? Wouldn't It make it trickier to create those as it's necessary to avoid munging stuff that's already there but the devs don't know what or where it is?

  • Bad (Score:3, Insightful)

    by Anonymous Coward on Friday March 04, 2011 @12:59PM (#35380836)

    It also makes life much harder for us downstream engineers who actually have to troubleshoot problems in the Redhat kernel. More often than not, it's a vendor-applied patch responsible for creating the problem in the first place. Now I guess it's up to Redhat Support to come up with a solution, which often reads "in 3 major versions time, if ever"

  • I don't see why it would make anything harder for centos or oracle, I doubt they check the code of every redhat patches before applying them. Redhat sells a product so the patches must be good and if they are good for them they are fine for centos and oracle too
    On the contrary it might be harder for other distro not based on rh to get a single patch out of the kernel
    • by idontgno (624372)

      Well, if they're not based on RH, they're going to have their own pipeline to the kernel patches. If nothing else, those patches should find their way back into the primary kernel repository. (Maybe. I dunno. Do Linus and company routinely freeze out distro-provided kernel changes?)

      The only "risk" is if there's some earthshakingly novel patch that RH comes up with and releases in-channel, but other distro mainainers (and the keepers of All Kernel Goodness) choose not to accept even after RH releases it to t

  • by mounthood (993037) on Friday March 04, 2011 @01:12PM (#35381034)
    Oracle wants to obey the GPL license for Java, but not the spirit of the GPL. As you sow, so shall you reap.
  • Precisely CENTOS is not going to be bit by this. The problems arise if you try to take RedHat's patches and apply them in other distributions (Attems is in the Debian kernel team, so he is among the most affected people), or if you are among the breed of people still patching and rolling their own kernels.

    So far, off-the-mainlain Linux kernel development has been a collaborative effort with people from different backgrounds joining in. Of course, RedHat –as a business– has to keep a competitive advantage. And that advantage can stem from saying here is a megapatch with all of our improvements, with no distinction between feature lines, with no documentation on what does what besides the code itself".

    I understand their point, but am deeply saddened by it. And yes, it is legal and sound, although goes against _collective_ Linux state-of-the-art advancement, beyond each company's interests.

    • The problems arise if you try to take RedHat's patches and apply them in other distributions (Attems is in the Debian kernel team, so he is among the most affected people), or if you are among the breed of people still patching and rolling their own kernels.

      Is this factual? From what I've read this change is distribution affects Red Hat's kernel source used in the Red Hat distro, this does not mean that Red Hat's kernel patches are not fed back into the kernel development process as individual patches.

      I'm n

  • I don't see how this affects anyone, even Oracle.

    To be honest, I wonder why it took them that long. I have been doing RPM packages for quite some time and have always hated 1000+-patches source RPMs such as Red Hat's kernel source package. This is a welcome change.

    I guess they use git internally, so that would just be a git archive --prefix=linux/ | gzip >linux-src.tar.gz. I haven't looked at the package yet, but the really good stuff would be if they provided a link to the git repos and the SHA1 for the

  • So what? (Score:4, Insightful)

    by 93 Escort Wagon (326346) on Friday March 04, 2011 @03:33PM (#35382872)

    Red Hat's job isn't to make things easier for CentOS, or Oracle for that matter - how is that even relevant? Red Hat isn't doing anything that's disallowed by the GPL. They're not even doing anything that could be reasonably interpreted as "contrary to the spirit of the GPL".

    They're still releasing the source. They're still paying their coders to do substantial work on the kernel. How big of a twit do you have to be to complain about how they release their kernel updates?

    • by fnj (64210)

      And how big of a twit do you have to be completely misinterpret the observations and make completely off topic charges?

  • Coincidentally enough, this state of affairs has been in place for 6 months, but this slashdot/lwn note comes the morning after I discovered the fact myself while trying (still as yet unsuccessfully) to rebuild the kernel with support for one odd driver enabled instead of disabled.

    What strikes me as missing from the current set of comments, is how this move by RH seems at odds with their laudable history of 'upstream upstream upstream'. I.e., it seems to me that each of those hundred(s) of patches will now

The sooner you fall behind, the more time you have to catch up.

Working...