5 ms·

Wait, wait, wait. Because a platform is near-native performance, is cross platform and may run in a virtual machine, they are becoming Microsoft and locking pe

Wait, wait, wait. 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.

iFire 15y ago
The pc as a webapp!
forgotusername 15y ago
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.
- drivebyacct2 15y ago
  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.
  - forgotusername 15y ago
    Views of your personal data come via their APIs, and never the raw data itself; Microsoft only ever owned the code.
    - jmesserly 15y ago
      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).
nknight 15y ago
> 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.
- ootachi 15y ago
  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.
  - nknight 15y ago
    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.
    - deleted 15y ago
      [deleted]
azakai 15y ago
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).
bad_user 15y ago
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. See for example the rationale behind Mozilla's decision to prefer IndexedDB instead of Web SQL Storage: http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-... (tl;dr - because SQLite doesn't have a spec besides the SQL Manual). 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).
- MatthewPhillips 15y ago
  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.

iFire 15y ago

The pc as a webapp!

forgotusername 15y ago

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.

drivebyacct2 15y ago
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.
- forgotusername 15y ago
  Views of your personal data come via their APIs, and never the raw data itself; Microsoft only ever owned the code.
  - jmesserly 15y ago
    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).

nknight 15y ago

> 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.

ootachi 15y ago
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.
- nknight 15y ago
  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.
  - deleted 15y ago
    [deleted]

azakai 15y ago

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).

bad_user 15y ago

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. See for example the rationale behind Mozilla's decision to prefer IndexedDB instead of Web SQL Storage: http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-... (tl;dr - because SQLite doesn't have a spec besides the SQL Manual). 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).

MatthewPhillips 15y ago
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.