Because a platform is near-native performance, is cross platform and may run in a virtual machine, they are becoming Microsoft and locking people in? WHAT? (Beyond the absurdity of leaping to that conclusion, it's an open spec and the main implementation is open source. I understand that alternative implementations are needed for "open spec" to have significant meaning, but still).
That and the last set of bullet points are all true. Just like Google... except without the near native performance of NaCl. Which is why it was created. To be just like the rest of the HTML/JS stack. They're trying to get to actual "Web 2.0" (bleck), where Dart and NaCl are viable additions to the traditional stack. I see no reason why this is nefarious.
RE this whole conspiracy (not mocking it by calling it that...) and the Android connection especially... that's what I've been assuming and hoping for from day one. Portable LLVM bytecode is another step in that direction as well. I'm excited.
For the purposes of this discussion, please consider "open spec" to mean "committee and community controlled by interests ultimately subsisting of more than one share pool.", if you follow this definition the majority of Google's "open" efforts fall apart.
For the PNacl bit, I think the tech sounds great, I just think the reason this "arrow" survived Page's recent cull is because they have significant interests in it, and that's what the article is about.
Yes, Google is the only one championing NaCl right now. I don't see how they get from their current position to some sort of lock in ala Microsoft though.
What does NaCL have to do with Google APIs? It's a client side technology. You can talk to whatever server(s) you want. (Presumably subject to same origin policy like JS, which if anything means it's easier to talk to your servers rather than Google's or someone else's).
it's an open spec and the main implementation
is open source
Actually, the implementation is so complicated that whatever spec exists is completely useless. And the existence of an open-source implementation does not guarantee a spec, quite the contrary, the spec will be the implementation itself.
You may think that the lack of a complete spec is not a problem, however I disagree. It hinders other implementations from scratch, which you may want because you disagree with the license or because you want to make it a lot better than it is (like what Google did with V8, when they could have gone with SpiderMonkey or with Nitro or whatever). Also, ask yourself why nobody could implement an alternative Perl interpreter and it wasn't because there was no need for it ;)
It's also a problem because the potential for abuse (embrace, extend) is huge. Suddenly the spec will contain implementation bugs that you cannot fix as long as the reference implementation doesn't. This even happens with Javascript, which is severely fragmented and holden back with concerns over backwards compatibility of scripts that are using the broken behavior. And do note that the ECMAScript standard is properly defined and quite simple to implement by comparison.
except without the near native performance of NaCl.
Which is why it was created
People have only scratched the surface of optimizing Javascript VMs and performance was never Javascript's biggest problem - there are other more pressing concerns, like freaking security, which is still inadequate and I have my doubts that NaCL will ever be secure, no matter how well it is sandboxed.
I see no reason why this is nefarious.
We have fought for years against the death grip IExplorer had on web standards. If other browser implementors don't want to implement NaCL, then Google should not try to push it down on people's throats. People could very well argue that ActiveX was a good thing. It gave birth to AJAX after all. That doesn't mean it wasn't an awful idea (even if it was done with good intentions).
Slightly off-topic, but I've been hacking IndexedDB lately, and while I'm grateful to Mozilla from saving us a future of writing SQL in the browser, IndexedDB is not what I would call friendly. Anything you do against it requires 4 or 5 callbacks. The first thing a JavaScript programmer will do is write an abstraction layer around it. That's a sign an API is too complex. Why on earth a transaction is required to do a get (or even a put, for that matter) is something I don't understand.
To my knowledge, IndexedDB is specifically intended as a low-level B-tree API that most developers will access via a high-level library of some sort [1].
The article goes too far in my opinion in speculation and attribution of ill will. (Unless the author has inside information there, but without any substantial reason to believe that, I won't.)
However, there are very serious and likely unaddressable concerns about Native Client, even if this article is a bit much (we have already debated this at length here on HN several times in the past).
> RE this whole conspiracy (not mocking it by calling it that...)
Then I will. It's a conspiracy theory, worthy of all the mocking typically associated with such a thing.
Anyone who's been watching Google long enough, closely enough, knows how out of character this would be. Such efforts, not to mention the purported motivation, is not in their nature.
Google employees start hundreds (thousands?) of new projects every year with little coordination. Some of these end up becoming big, official things, and we end up with Gmail. They throw stuff at the wall and see what sticks.
There might be some group inside Google thinking along the lines this guy is. I doubt it, but it's possible. It might even be the native client guys. What there isn't, is a massive internal conspiracy crossing every product team up and down the chain of command, aimed at making Google the sole arbiter of what can run on your device.
Even if the executives wanted it to happen, it couldn't. How do I know this?
Because Google is full of hackers who would instantly revolt. They've had enough problems with things like their real name policy and the handful of places they've had to acquiesce to DRM.
A coordinated effort to make Google into The One True Gatekeeper into your electronic life on a scale unmatched even by 1990s Microsoft? I await the flying pigs.
Speaking of conspiracy theories, from the footnotes:
I'm strongly of the belief that Google's internal strategy has long surpassed "organising the world's information", and is now something like "become the world's biggest private intelligence agency.", but that's a paranoid side-note.. ask me more on this at your peril. ;)
To clarify, they appear to have a strong focus on mass analytics, data collection, acquisitions of facial biometrics companies, and most recently a push towards a "real ID" policy on their services, that to some extent sets me on edge (I'm not certain any single company should be doing all these things).
Regardless, I wouldn't have written any of this if I didn't have a certain love for the company, and desire to follow their movements with some level of intimacy. I just don't agree with everything I suspect they'll be doing 20 years from now.
Well, they certainly have become the world's largest adware vendor, and that is hard to deny. The problem is that they want to aggregate more and more information from each of us in order to sell more ads. This makes them the world's largest spyware vendor too.
So I think that comment is just a little over the top, it's not that far beyond what the undisputed reality is.
But via things like Android, they tend to lock tou into their SaaS offerings. The goal is the same adware/spyware system that has long plagued Windows. Maybe not to the same extent or with the same OS implications, but I wouldn't discount the problems that this can cause in the future as Google expands into more areas.
For example it recently occurred to me: Google Voice transcribes your voice mail to text. I wonder to what extent they index that and use this as a sample of your telephone conversations as a way of better targetting ads to you. That strikes me as very scary because at that point I have no control over the retention of this information and then it becomes something the government can easily subpoena via something like the Stored Communications Act.
There is not a single company in history that failed to get away with malicious behavior due to being "full of hackers that would instantly revolt". Engineers do not have executive power within companies. Executives do. Engineers "revolt" by quitting, and at Google they are easy to replace.
You're right, they do revolt by quitting. I don't see a big exodus. I have several friends there I know would be out the door in a heartbeat, and 5 years ago I knew one of the guys who is now one of the most senior on the Chrome team. Unless his character has been very fundamentally altered, there's not a snowball's chance in hell he would aid such an effort.
Conspiracies usually involve some kind of illegal or immoral activity, on the other hand what is described seems a perfectly natural growth strategy for a company of Google's size, wishing to grow larger (as dictated by its very existence), and to root itself more firmly in the areas it's most interested in (data interchange).
"""Even if the executives wanted it to happen, it couldn't. How do I know this? Because Google is full of hackers who would instantly revolt. They've had enough problems with things like their real name policy and the handful of places they've had to acquiesce to DRM."""
Your argument about the "google hacker's revolt" is is even more laughable that the conspiracy theory.
Because a platform is near-native performance, is cross platform and may run in a virtual machine, they are becoming Microsoft and locking people in? WHAT? (Beyond the absurdity of leaping to that conclusion, it's an open spec and the main implementation is open source. I understand that alternative implementations are needed for "open spec" to have significant meaning, but still).
That and the last set of bullet points are all true. Just like Google... except without the near native performance of NaCl. Which is why it was created. To be just like the rest of the HTML/JS stack. They're trying to get to actual "Web 2.0" (bleck), where Dart and NaCl are viable additions to the traditional stack. I see no reason why this is nefarious.
RE this whole conspiracy (not mocking it by calling it that...) and the Android connection especially... that's what I've been assuming and hoping for from day one. Portable LLVM bytecode is another step in that direction as well. I'm excited.