Announcement

Collapse
No announcement yet.

WebKit Looks To Drop Google Code, V8, Skia

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

  • WebKit Looks To Drop Google Code, V8, Skia

    Phoronix: WebKit Looks To Drop Google Code, V8, Skia

    Following yesterday's announcement of Google forking the WebKit rendering engine to form "Blink" (also with the support of Opera), Apple developers working on WebKit are now looking to strip away Google/Chrome features from upstream WebKit...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    /me wonders if the current WebKit users will switch to blink, as it seems that Apple wants to focus on the MacOS needs.

    Comment


    • #3
      They took our code and dropped our crap. Now we need to drop there?s stuff even though it better that ours.

      What have happened to the open source community latley?
      A fork which previously were a very good thing have now became a declaration of war.

      Comment


      • #4
        Originally posted by Pajn View Post
        They took our code and dropped our crap. Now we need to drop there?s stuff even though it better that ours.

        What have happened to the open source community latley?
        A fork which previously were a very good thing have now became a declaration of war.
        A fork has ALWAYS been "Worst case" for open source. Its good long term, because the better one will survive. But in the short term is almost IS a declaration of war. Pretty sure it was Linus, a few years back, the constant threat of a fork of the kernel is what would help keep them together. Because if they ever got out of hand or started fucking up there was always that threat of "We'll fork it and run." from the community at large.
        All opinions are my own not those of my employer if you know who they are.

        Comment


        • #5
          Originally posted by Pajn View Post
          They took our code and dropped our crap. Now we need to drop there?s stuff even though it better that ours.

          What have happened to the open source community latley?
          A fork which previously were a very good thing have now became a declaration of war.
          Its not.

          Google/Apple code pieces are complex and excluding them selfs.

          Splitting may be good here.

          Also note that Google may no longer support V8 code compatibility with Webkit..

          Comment


          • #6
            Relax people. I'm on Google's side, but this makes complete sense for Apple to do it, for the exact same reasons it made sense for Google to strip it down for what they need it. I believe even Google said it in their blog post that Apple will probably strip down what they don't need from Chrome.

            Comment


            • #7
              Originally posted by Krysto View Post
              Relax people. I'm on Google's side, but this makes complete sense for Apple to do it, for the exact same reasons it made sense for Google to strip it down for what they need it. I believe even Google said it in their blog post that Apple will probably strip down what they don't need from Chrome.
              Exactly. The whole point of Google splitting was that they were doing a bunch of code in webkit that apple wasn't using, and vice versa. If Google isn't using that code anymore, then it makes perfect sense for apple to remove it now.

              Comment


              • #8
                If there was code specific to Safari and Chrome in WebKit, how did it get there in the first place? I mean, if it's browser specific, why have it in mainline Webkit, instead of in the actual browser? Also, in this case they could have left everything the way it was, stripped both parties' specific code, moved them into the browsers themselves and have the same situation as it is now, just with half the maintenance burden.

                Comment


                • #9
                  Originally posted by GreatEmerald View Post
                  If there was code specific to Safari and Chrome in WebKit, how did it get there in the first place? I mean, if it's browser specific, why have it in mainline Webkit, instead of in the actual browser? Also, in this case they could have left everything the way it was, stripped both parties' specific code, moved them into the browsers themselves and have the same situation as it is now, just with half the maintenance burden.
                  Its not so much that it was SPECIFIC to Safari and Chrome, its more that they were the only ones using it. Others were free to use it if they wanted, it was available to them, but no one did.
                  All opinions are my own not those of my employer if you know who they are.

                  Comment


                  • #10
                    Originally posted by Ericg View Post
                    Its not so much that it was SPECIFIC to Safari and Chrome, its more that they were the only ones using it. Others were free to use it if they wanted, it was available to them, but no one did.
                    But if it's just optional, usable code, why would they want to drop it? Hide it behind a compiler flag if more compilation speed is desired, and that's all.

                    Comment

                    Working...
                    X