Earlier quoted context omitted.
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 runn…
What I suspect Google is up to with Native Client
81–90 of 94 posts
Re: What I suspect Google is up to with Native Client
#82NaCl 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 th…
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.
Re: What I suspect Google is up to with Native Client
#83What'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.
Sounds more like plain old X forwarding.
Re: What I suspect Google is up to with Native Client
#84I 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?
Re: What I suspect Google is up to with Native Client
#85Earlier quoted context omitted.
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. ;) http://www.hackerspews.com/
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.
Re: What I suspect Google is up to with Native Client
#86Wait, 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…
When we're talking about a company what's the difference between a "conspiracy" and a "plan" or "strategy"? (Serious question.)
Re: What I suspect Google is up to with Native Client
#87Earlier quoted context omitted.
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.
Re: What I suspect Google is up to with Native Client
#88"in particular, it lacks the elegance necessary to lend credence that this was ever a research project" How does one judge this subjectively?
Re: What I suspect Google is up to with Native Client
#89There'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 permis…
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 th…
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?
Re: What I suspect Google is up to with Native Client
#90Earlier quoted context omitted.
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…
[1] http://hacks.mozilla.org/2010/06/beyond-html5-database-apis-...