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

51–60 of 94 posts

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

#51

Post by comex »

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…

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

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

#52

Post by hardboiled »

peterwwillis wrote: post #39

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.

Steve Ballmer.

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

#53

Post by est »

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.

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

#54

Post by est »

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.

> when it's easy to convert an NaCl app into a native app that can be downloaded and run at will.

In theory .NET JIT can emit native image code. But have you ever seen any framework-free .NET apps?

The dependences, libraries, ecosystem will lock you in.

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

#55

Post by forgotusername »

nl wrote: post #49
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…

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/

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.

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

#56

Post by wickedchicken »

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

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

#57

Post by cpeterso »

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…

> Android has already shipped on at least two (ARM, MIPS), and been ported to at least one more (x86).

Google shipped Android on Google TV devices with Intel Atom processors.

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

#58

Post by getsat »

forgotusername wrote: post #3
avree wrote: post #2

Is this site designed to be read from across the room?

Implemented a partial compromise, but IMHO all sites should be designed to be read from across the room. Comments on the article text welcome.

I think this is the first site I've never had to zoom in on to actually read. (2560x1440)

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

#59

Post by djmdjm »

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…

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.
Post reply on HN