What I suspect Google is up to with Native Client • Hacker News Board

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

#21

Post by losethos » Wed, Dec 07, 2011, 4:57 AM UTC

I do my part and leave it in God's hands. I was pretty lucky, all things considered. I can think of nothing I would rather have done. I've run out of ideas. In the past 12 months I've just made cosmetic clean-up stuff. That's it. My reality is insane. That's it.

God says... C:\LoseThos\www.losethos.com\text\BIBLE.TXT

their groaning, and am come down to deliver them. And now come, I will send thee into Egypt.

7:35 This Moses whom they refused, saying, Who made thee a ruler and a judge? the same did God send to be a ruler and a deliverer by the hand of the angel which appeared to him in the bush.

7:36 He brought them out, after that he had shewed wonders and signs in the land of Egypt, and in the Red sea, and in the wilderness forty years.

7:37 This is that Moses, which said unto the children of Israel, A

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

#22

Post by forgotusername » Wed, Dec 07, 2011, 4:58 AM UTC

drivebyacct2 wrote: post #20

forgotusername wrote: post #17

Earlier quoted context omitted.

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…

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.

Views of your personal data come via their APIs, and never the raw data itself; Microsoft only ever owned the code.

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

#23

Post by forgotusername » Wed, Dec 07, 2011, 5:05 AM UTC

barrybe wrote: post #12

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.

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

#24

Post by smosher » Wed, Dec 07, 2011, 5:05 AM UTC

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?

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

#25

Post by tree_of_item » Wed, Dec 07, 2011, 5:07 AM UTC

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.

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

#26

Post by rst » Wed, Dec 07, 2011, 5:09 AM UTC

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

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

#27

Post by DarkShikari » Wed, Dec 07, 2011, 5:10 AM UTC

smosher wrote: post #24

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

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.

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

#28

Post by jmesserly » Wed, Dec 07, 2011, 5:13 AM UTC

smosher wrote: post #24

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

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.

More info here: http://en.wikipedia.org/wiki/Java_Virtual_Machine#Bytecode_v...

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

#29

Post by nextparadigms » Wed, Dec 07, 2011, 5:15 AM UTC

rst wrote: post #26

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

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.

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

#30

Post by forgotusername » Wed, Dec 07, 2011, 5:17 AM UTC

rst wrote: post #26

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 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 the Contacts UI represents, which ultimately backs on to some class library that ultimately is controlled by the platform (as I understand it).