Announcement

Collapse
No announcement yet.

Oracle Offers Its Unbreakable Enterprise Kernel On GitHub

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Oracle Offers Its Unbreakable Enterprise Kernel On GitHub

    Phoronix: Oracle Offers Its Unbreakable Enterprise Kernel On GitHub

    While the source to Oracle's "Unbreakable Enterprise Kernel" has been available via the company's own servers, now the organization is publishing their source kernel changes to GitHub in a bid to increase the popularity of their patched version of Linux...

    http://www.phoronix.com/scan.php?pag...cle-UEK-GitHub

  • #2
    What a dumb name. You're basically putting out the call for people to find vulnerabilities. In the context of something like bug bounties this can be a good thing. But if you're a company that's pretty much despised and you call something 'unbreakable' you're basically asking for trouble.

    Comment


    • #3
      Are they too lazy to properly upstream their changes or what?

      Comment


      • #4
        Originally posted by willmore View Post
        Are they too lazy to properly upstream their changes or what?
        They're busy migrating everything from slowlaris.

        Comment


        • #5
          Now that it's on github everyone will use only UEK for sure. Anytime Oracle will die it won't be too soon for me.

          Comment


          • #6
            Originally posted by willmore View Post
            Are they too lazy to properly upstream their changes or what?
            They probably do upstream some of their changes. There are lots of good reasons for why they want to maintain their own separate forks though. Primarily: If upstream have a lower stability standard than Oracle, then they can't really achieve the level of stability they want with upstream, because:

            1. for every fix and stability enhancement they make, other people will be simultaneously pushing new, buggy or less-stable code which will also be committed. It's a moving target that they can never quite hit. If however they maintain their own branch, they can choose to only accept code which meets their quality standards. Every new commit improves the quality of their kernel fork.

            2. some of their changes may involve trade offs which upstream do not accept. For instance: they may drop drivers which are below their stability standards: this would reduce the amount of supported hardware. They may have added code which lowers the performance of the kernel as a by-product of increasing its stability. They may have locked and stabilised an in-kernel API so that their customers can be assured that they can code against it and it will not change. Upstream may not be willing to also stabilise that API.

            Comment


            • #7
              Originally posted by willmore View Post
              Are they too lazy to properly upstream their changes or what?
              Not all code can be upstreamed. Bureaucracy, status quo, and so on. "Freedom of choice", you know...

              Comment


              • #8
                Nothing is "unbreakable".
                But since Oracle have so many lawyers, no one is able to sue them for making false claims.

                Comment


                • #9
                  Originally posted by willmore View Post
                  Are they too lazy to properly upstream their changes or what?
                  If most of their changes are backports (which is the case for any RHEL derivative like theirs), there is no real reason to upstream them, as they come from upstream already.

                  Comment


                  • #10
                    Originally posted by cybertraveler View Post

                    They probably do upstream some of their changes. There are lots of good reasons for why they want to maintain their own separate forks though. Primarily: If upstream have a lower stability standard than Oracle, then they can't really achieve the level of stability they want with upstream, because:

                    1. for every fix and stability enhancement they make, other people will be simultaneously pushing new, buggy or less-stable code which will also be committed. It's a moving target that they can never quite hit. If however they maintain their own branch, they can choose to only accept code which meets their quality standards. Every new commit improves the quality of their kernel fork.

                    2. some of their changes may involve trade offs which upstream do not accept. For instance: they may drop drivers which are below their stability standards: this would reduce the amount of supported hardware. They may have added code which lowers the performance of the kernel as a by-product of increasing its stability. They may have locked and stabilised an in-kernel API so that their customers can be assured that they can code against it and it will not change. Upstream may not be willing to also stabilise that API.
                    Or perhaps their changes are so shitty upstream will never accept. It's awesome you're so blind and believe Oracle have so super kernel engineers. They suck.

                    Comment

                    Working...
                    X