Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What I suspect Google is up to with Native Client

hackerspews.com

Post reply on HN
Print view View original

71–80 of 94 posts

Re: What I suspect Google is up to with Native Client

#71

Post by Angostura »

ootachi wrote: post #40
nknight wrote: post #38

Earlier quoted context omitted.

> 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 ever…

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.

"Engineers "revolt" by quitting" - and then blogging about it.

Re: What I suspect Google is up to with Native Client

#72

Post by bad_user »

drivebyacct2 wrote: post #10

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…

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

Re: What I suspect Google is up to with Native Client

#73

Post by icebraining »

It's funny, because what came to mind as the platform for apps that would be streamed from HTTP wasn't Chrome, but Mozilla!

After all, that was the promise of remote XUL+JS, which provided the user gave it the permissions, could access the XPCOM components to access the filesystem, run external applications and more.

Nevertheless it didn't caught on.

Re: What I suspect Google is up to with Native Client

#74

Post by dextorious »

nknight wrote: post #38
drivebyacct2 wrote: post #10

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…

> 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 ever…

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

Re: What I suspect Google is up to with Native Client

#75

Post by dextorious »

icebraining wrote: post #73

It's funny, because what came to mind as the platform for apps that would be streamed from HTTP wasn't Chrome, but Mozilla! After all, that was the promise of remote XUL+JS, which provided the user gave it the permissions, could access the XPCOM components to access the filesystem, run external applications and more. Nevertheless it didn't caught on.

"""Nevertheless it didn't caught on."""

Well, I was kinda hoping it would, but for one thing, the Mozilla guys:

1) never documented it properly 2) never made any usable developer tools, IDEs, etc 3) never delivered on their initial XUL/XULRunner promises 4) never tried to build a community around them

Re: What I suspect Google is up to with Native Client

#76

Post by MatthewPhillips »

bad_user wrote: post #72
drivebyacct2 wrote: post #10

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…

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

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.

Re: What I suspect Google is up to with Native Client

#77

Post by bzbarsky »

petegrif wrote: post #36
twoodfin wrote: post #14

I think Microsoft really missed a good bet by not embracing NaCl years ago. They have a huge preexisting native codebase. Probably a plurality of their development teams are native code-focused. Their customers employ hundreds of thousands of native developers and probably billions of lines of native code. C/C++ is such an inescapable part of their ecosystem that after almost a decade of selling C#/.NET as the future…

Agreed. And I still don't understand Mozilla's problem with NaCl. They argue that js is now nearly as fast as native. Well...even if that were true it ignores the fact that as you point out there is huge investment in legacy code that NaCl unlocks AND it ignores the fact that js makes it easy to copy what may be valuable IP.

Mozilla's problem with NaCl is that Mozilla believes in open access to the web for everyone, while NaCl at the moment is tied to particular hardware architectures. The two seem to be fundamentally incompatible.

If PNaCl ever happens, that might change the situation, maybe.

As far as legacy code, emscripten unlocks it as well. Not with the performance of NaCl (and unlikely to get there), but it has the benefit of running cross-browser right now and not forcing people onto particular hardware platforms.

And copying "valuable IP" out of an emscripten-compiled program is just as easy as copying it out of a binary, of course.

Re: What I suspect Google is up to with Native Client

#78

Post by zobzu »

tree_of_item wrote: post #25

NaCl may have a large role to play in the future, but I don't think this is a bad thing, or "dystopian". NaCl, Android, Dart, and Chromium are all open source and can be forked by the free software and open source communities and retooled for whatever ends should Google begin to play nasty. The big issue here is control of user data, which is orthogonal to the choice of software anyway. You can use all of the softwar…

Yeah, for example, Android Google devs do not take patches from other devs, and do not open Android til "its ready". Other devs, mainly CM do not submit patches (its useless) and it takes a long time to support devices because you need a lot of proprietary code that needs to be available, or specs,that also needs to be available.

So yeah, but no, you definitely can lock stuff in with "open source", no problem with that.

Re: What I suspect Google is up to with Native Client

#80

Post by winthrowe »

scriptproof wrote: post #69

I am not really favorable to the all-in-the-cloud trend at Google. NaCl seems to be the exact opposite to that and I am as other users (as expressed in a comment above) happy with that. Another point is that it is not a replacement to DirectX. WebGl is this replacement, and WebGL is a common initiative, not a Google's invention.

WebGL is not a replacement for DirectX, it's just a replacement for Direct3D. What's the rest of the stack?
Post reply on HN