Linked by Thom Holwerda on Fri 14th May 2010 18:28 UTC
Google "Today, we're happy to make available a developer preview of the Native Client SDK - an important first step in making Native Client more accessible as a tool for developing real web applications. When we released the research version of Native Client a year ago, we offered a snapshot of our source tree that developers could download and tinker with, but the download was big and cumbersome to use. The Native Client SDK preview, in contrast, includes just the basics you need to get started writing an app in minutes."
Thread beginning with comment 424648
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

Binary format and system calls are heavily OS-dependent. Hence someone, somewhere, has to choose which OSs are being supported. And less-common operating systems like Haiku can die. This is not the case with interpreted languages like Java, Python, and ECMAscript, where any new OS can easily read the spec and implement it. Here the people writing the web app or the spec choose which OSs are supported. And if you're a newcomer in the OS world, you've got to set up a full emulation/translation layer for another OS. We all know how well Wine performs...

I really don't think you understand this... Right now, NaCl is just dependent on x86, which is what OSs like Haiku run on. And its APIs are so much smaller than Java, for example, that it would be much easier for an OS like Haiku to implement. And there would be no emulation layer like Wine.

I'd prefer to see some real platform-independent open technology like Python or a better performing Java in use.

PNaCl is just as platform independent as Java or Python. In fact, it's probably even easier for an OS like Haiku to implement because the APIs are much smaller.

Reply Parent Score: 2

Neolander Member since:

Oh, okay ! I thought that the whole thing was about using native code, but if it's just some glorified interpreter then why not ^^

Reply Parent Score: 1

umccullough Member since:

but if it's just some glorified interpreter then why not ^^

It's not really an interpreter... not really.

Basically, it's a sandboxed environment that inspects the machine code of the NaCl app before allowing it to run, making sure it doesn't make any "dangerous" x86 calls that would allow it to affect other code or resources outside the sandbox. It is then allowed to run natively on the processor once it passes all the checks. It is allowed to link and call other NaCl libs, and is allowed to access host OS resources that the NaCl environment provides.

Reply Parent Score: 2