Earlier quoted context omitted.
I agree that Microsoft hasn't been trustworthy historically, but how have they smothered Mono? And a counter-example is Samba.
Mono was banned from Microsoft's development conference (see http://tirania.org/blog/archive/2005/Sep-06.html ), and faced various sorts of legal threats regarding their implementation of .NET libraries not covered by the ECMA standards process (most notably ASP.NET). Samba benefited from Microsoft's documentation because Microsoft was forced to disclose it by court order.
Google going its own way, forking WebKit rendering engine
41–50 of 105 posts
Re: Google going its own way, forking WebKit rendering engine
#42Earlier quoted context omitted.
Does that actually matter? All these are as well: http://msdn.microsoft.com/en-us/library/dd208104.aspx Would you consider building on top of them? No because they are not 100% vendor neutral. They serve the vendor, not the consumers of the technology.
Microsoft has a history of being hostile to the open-source and free-software communities. They release "shared source" code under licenses with onerous terms or encumbered with patents. In the event that an open-source project built on their technology becomes popular, Microsoft attempts to smother it (for example, see their treatment of Mono). I trust Google about as much as I trust Red Hat, Canonical, or any other…
Re: Google going its own way, forking WebKit rendering engine
#43Google just realizes it cannot pretend to be a nice guy when the world no longer spins around it. So much for "do no evil"...
Re: Google going its own way, forking WebKit rendering engine
#44This reads like: "We're not sharing our stuff anymore as it's costing too much". A the risk of sounding like a paranoid nutbag, with stuff like NaCl, SPDY, Dart etc, it sounds like Google have their own agenda.
Re: Google going its own way, forking WebKit rendering engine
#45Earlier quoted context omitted.
> The web is the common project, right? We're all working together to put together powerful and performant windows into the web, and we work together at places like the W3C and WhatWG to construct a common vision of what that means. No, we (the companies) don't. We work to get web features that we can leverage. If we can get away with them being adopted by everybody but solely controlled by us, it's all the merrier.…
Please tell me who the "we" is in your post, so I can take great care to avoid ever working for them.
Re: Google going its own way, forking WebKit rendering engine
#46> Google also argues that the decision will introduce greater diversity into the browser ecosystem and might mitigate concerns that the mobile Web in particular was becoming a WebKit monoculture. Ahah so much hypocrisy condensed in this sentence. Yeah it's constraining to share code and have compile time #defines but if every vendor did the same there wouldn't be any common project.
The web is the common project, right? We're all working together to put together powerful and performant windows into the web, and we work together at places like the W3C and WhatWG to construct a common vision of what that means. Diversity in implementation is a great way of hammering out the exact contours of the standards that govern the common project...
all you have to look at is the history of html5 and even the issues surrounding things like video to see what its like to decide by committee.
WHATWG published the First Public Working Draft of the specification on 22 January 2008
In May 2011, the working group advanced HTML5 to "Last Call
As of May 2012, the specification is back to Working Draft state at the W3C
In September 2012, the W3C proposed a plan[28] to release a stable HTML5 Recommendation by the end of 2014
Re: Google going its own way, forking WebKit rendering engine
#47My understanding is that Dart VM will be in Chrome soon.
http://www.chromium.org/blink#new-features has some detail about how we plan to add features to the platform. We're certainly hoping to be pretty transparent about how things get into Chromium.
1. That you propose a draft specification
2. That you're willing to discuss it with other implementors
3. That you've exhausted all other options
So let's take the example of Dart, and let's say every other browser engine says "no" to Dart. This policy seems to allow you to act unilaterally, against current interoperability, in this case as long as you put some indeterminate amount of effort to convince other implementors.
Is that a correct reading of it? If so, what good is the rest of the policy about striving for compatibility with other engines when you've given yourself an out when consensus doesn't fall your way?
Re: Google going its own way, forking WebKit rendering engine
#48Earlier quoted context omitted.
> The web is the common project, right? We're all working together to put together powerful and performant windows into the web, and we work together at places like the W3C and WhatWG to construct a common vision of what that means. No, we (the companies) don't. We work to get web features that we can leverage. If we can get away with them being adopted by everybody but solely controlled by us, it's all the merrier.…
Please tell me who the "we" is in your post, so I can take great care to avoid ever working for them.
Well, it's not like I haven't added the notice "(the companies)" after "we" twice.
By which "companies" (something also clear from the context), I mean Apple, MS, Google etc, the companies working on rendering engines and browser.
I used "we" to adopt the parent comment's use of "we" and his idea of the web as a common project all those companies share.
>so I can take great care to avoid ever working for them.
Well, since you already work for Google, it's understandable you seeing this as silly and thinking they are all for open and the web's progress.
I don't think that's the general perception people have of Google though -- nor that it is correct.
Re: Google going its own way, forking WebKit rendering engine
#49Earlier quoted context omitted.
Does that actually matter? All these are as well: http://msdn.microsoft.com/en-us/library/dd208104.aspx Would you consider building on top of them? No because they are not 100% vendor neutral. They serve the vendor, not the consumers of the technology.
Microsoft has a history of being hostile to the open-source and free-software communities. They release "shared source" code under licenses with onerous terms or encumbered with patents. In the event that an open-source project built on their technology becomes popular, Microsoft attempts to smother it (for example, see their treatment of Mono). I trust Google about as much as I trust Red Hat, Canonical, or any other…
Yes, but then again you work for Google too. That alone could be basis for bias.
I certainly don't trust Google as much as Red Hat or Canonical (well, the same as Canonical of late, maybe). Still remember the bait-switchy GAE pricing changes, among other things.
Re: Google going its own way, forking WebKit rendering engine
#50To me it sounds like a good thing. We end up with 3 major rendering engines on the desktop; Gecko (Firefox), Trident (IE) and Blink (Opera and Chrome) and 2 major on mobile Blink (Opera and Chrome) and Webkit (Safari). This I think will help shake up some of monoculture. Chrome definitely doesn't have any level of domination over the enterprise market like IE6 on Windows did. That was the problem with IE6 not the bro…