There's some real confusion about Android here. Android already has its own bytecode format (Dalvik), and it's unlikely that NaCL would replace it, if only because NaCL is tightly tied to the underlying processor instruction set, while Android has already shipped on at least two (ARM, MIPS), and been ported to at least one more (x86).
It's also already the case that a third-party app which requests appropriate permissions can replace the standard contacts app --- in fact, there are several alternate contact managers already in the Android Market. Of course, the user must confirm that they want to allow the app to manipulate contacts, and apps that don't request that permission can't ordinarily do that. (Malicious apps can manipulate contacts without asking permission on the customized versions of Android shipped with several recent handsets, per news from the last few days, because the vendors doing the customization screwed up, but that's another rant altogether...)
I think you're focusing too much on the underlying technology, Dalvik is ultimately little more than a layer of indirection, that could easily disappear deeply beneath the covers of a 22nd century OS, hidden by a simple click of a 'Build' button in an IDE, much like Win32 did.
Similarly, Contacts was only used as an example, as it is prominent and simple to understand. The main reference made there was to the data the Contacts UI represents, which ultimately backs on to some class library that ultimately is controlled by the platform (as I understand it).
> "...that could easily disappear deeply beneath the covers of a 22nd century OS..."
So we have a bit of time to form a reaction strategy then. ;-)
Are we even sure Android will run on the quantum-singularity computronium that we will have by then, or that the Google meme-avatar will still be on, or near, Earth?
Maybe they want to start Android from scratch? It might be worth it if this means Google will handle all updates from now on. But it better mean that, because otherwise I don't like the idea of making it impossible to create custom ROM's, while still not getting updates like it happens now.
I don't get how NaCl can be a tool for controlling content, when it's easy to convert an NaCl app into a native app that can be downloaded and run at will. You can't really have Microsoft-style dominance over a platform when users can leave you as soon as they are slightly annoyed.
Not to mention that NaCl is open source BSD-license, so, yeah.
Depending on your definition of control, they have both the page views and ability to create a single-click installer to create an ideal situation wherein most developers are compelled to target their environment, and most users will eventually click their download link. At such a point, both groups will begin to advocate its further use by yet more parties. I'm not familiar with a better word.
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, they're increasingly proselytizing for the benefits of native code and C++11 in particular.
They could have leveraged all of this by buying in to NaCl and putting it into IE. Hard to see how Google says no, and once Microsoft has that level of commitment to the technology, they'd get a strong say in its evolution. As a multi-vendor standard with an open source implementation, NaCl could have gotten real traction, and suddenly every C++ developer inside Microsoft and working for their customers has a path to the web for existing code that's slightly more plausible than rewriting everything in JavaScript and hoping the VMs get faster without also killing your laptop's battery (unlikely, I think).
I think Microsoft refusing to support NaCl is one of the best things they did. For once they pulled their head out of their ass and thought about the benefits of an open web.
I'm seeing a lot of comments here in support for NaCl, so apparently people have forgotten (or never lived) the days of ActiveX. I am not buying the conspiracy theory bits of this article, I also regret waisting time reading it ; however that doesn't mean NaCl isn't a bad idea.
As a multi-vendor standard with an
open source implementation ...
Dude, seriously, don't you think these "vendors" had good reasons to dismiss NaCl?
The whole point of NaCl is the sandbox that blocks access to Microsoft's Windows APIs. Adopting it wouldn't have benefited Microsoft at all. What Microsoft should have done is built the CLR into IE as a JavaScript alternative instead of bolting a crippled version on the side (in the form of Silverlight). They could have controlled the best Web development platform out there, but that opportunity is long gone.
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.
And for some things, "nearly as fast" isn't nearly fast enough, and in some cases (eg. media processing) you still need the very tight control over the CPU that C gives you.
I didn't even read past the third paragraph. It's not even the creepy, conspiratorial way he talks... who the hell puts up a single domain, with a single plain-text page of content, with a font big enough for my grandmother to read it, just to complain about Google? It's weird.
The site is not tailored to readers who search for social proof in a WordPress theme; for multiple reasons this was an intentional choice. I'd suggest starting with the two years of my HN comment history.
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 software above to connect to friendly data stores, perhaps ones you control.
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.
No -- you can't. You can lock people out of your project, but FLOSS doesn't mean everyone gets to play inside your project.
The license guarantees anybody who doesn't like the way Google is doing things can take the code and start their own project around it. The forks may not be easy to keep in sync -- this shouldn't matter if you don't agree with the way Google is doing things because you'll probably stop using their work after you fork anyway.
What you want is to have Google's engineers run their project the way you want, which is NOT what open source is about at all.
Aside: You're wrong about proprietary code -- awesome people like jbq and folks from the AOSP have consistently worked with hardware vendors to open up their binary blobs. They are actively fighting for this, not using it to keep people locked into the official Android project.
May I suggest a rather more innocent possibility wrt Google's intentions? They want us to be able to run high performance apps in the browser. And guess what - most of us would like that.
I'm excited about the potential for NaCl and don't understand a lot of the conclusions that the OP article outlines... but I don't understand what this sentence means or why it would be a bad thing. Isn't LLVM the nonexistent VM? I'm confused as to the context maybe.
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.
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
The main hack done to the compiler is that generated code avoids certain constructs that inhibit perfect static analysis, allowing the NaCL host (i.e. Google Chrome at present) to verify the behaviour of some untrusted binary before ever executing it (just like Java does).
I am having a hard time with this. At first I thought this amounted to a claim that the halting problem had been solved, or else that Java and NaCl are not Turing complete. I'm guessing the problem is with the term "perfect." So something interesting must be going on or it wouldn't be worth mentioning. What's being verified? That the code can't execute data and won't call certain interrupts, or is something more interesting happening?
At first I thought this amounted to a claim that the halting problem had been solved,
That's not what the halting problem means! There is no rule that says you cannot prove a program is safe: the rule is only that you cannot prove any arbitrary program is safe. NaCl gets around that by adding checks to the code (bounds checks, etc) to anywhere that it can't prove is safe.
It's still Turing complete because it can perform arbitary computation; it just can't cause arbitrary behavior at the machine code level. (Indeed, making a VM that's both Turing complete and safe is not generally a hard problem - for example, most Brainfuck interpreters qualify. The hard problems are making safe interfaces to the rest of the system, and speed.)
I don't know exactly what NaCL does, but the JVM/CLR verification is all about making sure you don't write over someone else's memory, jump to some arbitrary address, etc. Essentially the problem is: how do you run untrusted code in the same address space, without it getting all of your process's permissions.
Halting problem is literally that the program will halt. That's not provable, even if you offer it on rentacoder.com.
JVM bytecode, .NET CLR bytecode, NACL bytecode are all verified as containing no illegal API calls. That's completely different. And its completely possible.
It doesn't have to solve the halting problem, just contain the code from interacting with the wider system except through tightly-defined interfaces. "does this code make any far jumps" is an answerable question when you can constrain the machine code generated and ban self-modifying code.
"guys, let's replace javascript with the most advanced modular program distribution and compilation toolkit known to mankind. hell, we could even implement javascript on top of this toolkit to let people have their cake and eat it too. oh wait, nevermind, some person on the internet told us this is evil. my bad"
What's more interesting is the Chrome Remoting technology. It allows you to render webpage/webapp in a desktop chrome process but display it on another remote device, even mobile device. It's like Microsoft 3389 RDP without fullscreen but each individual window.
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.
Why is the performance impact of the sandbox with Intel code only 1% while the AMD and ARM code 7%? Is it just because they haven't focused much on optimizing for those or any other reason? I would expect them to at least focus more on ARM, especially if they are porting it to Android.
Gives Google too much credit, on the one hand, by saying they will create an elegant OS that unifies desktop, web, and mobile (a sort of "holy grail" actually)... then says this is a bad thing.
As a researcher, I was surprised that the author assumed that any of my work was ever elegant. Research projects are ugly and messy because you know that they'll never need to scale. If you can actually make it work, that's when you start on elegance.
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.
It's also already the case that a third-party app which requests appropriate permissions can replace the standard contacts app --- in fact, there are several alternate contact managers already in the Android Market. Of course, the user must confirm that they want to allow the app to manipulate contacts, and apps that don't request that permission can't ordinarily do that. (Malicious apps can manipulate contacts without asking permission on the customized versions of Android shipped with several recent handsets, per news from the last few days, because the vendors doing the customization screwed up, but that's another rant altogether...)