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 424588
To view parent comment, click here.
To read all comments associated with this story, please click here.
reduz
Member since:
2006-02-25

That's ridiculous.

1) It's completely open spec and open source.
2) Unlike ActiveX It's not tied to windows or linux, Only a platform independent API is provided. You compile, runs everywhere
3) This is actually a huge boost to the indie developer, imagine that you want to make a game and publish it on the web, what are your choices? Flash? Unity? all closed platforms. This lets you use wathever you want and it runs everywhere.

Reply Parent Score: 2

Neolander Member since:
2010-03-08

That's ridiculous.

1) It's completely open spec and open source.

Flash is open spec, though not open source. But Adobe owns the main flash IDE, and they change the spec whenever they want. Hence they've got full control over flash.
Android is theoretically open spec and open source, but practically all phone vendors will license the Google version, and Google decides where development goes. Hence they've got full control over android.
Open spec and open source are nice, but they do not prevent technologies from being inherently proprietary in some cases.

2) Unlike ActiveX It's not tied to windows or linux, Only a platform independent API is provided. You compile, runs everywhere

There is no such thing as "compile&run everywhere". 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...

3) This is actually a huge boost to the indie developer, imagine that you want to make a game and publish it on the web, what are your choices? Flash? Unity? all closed platforms. This lets you use wathever you want and it runs everywhere.

I agree that an open newcomer in the web app area would be interesting, but I'd prefer to see some real platform-independent open technology like Python or a better performing Java in use. In my opinion, this has the potential to worsen the situation, instead of helping it.

Edited 2010-05-15 10:37 UTC

Reply Parent Score: 1

agnus Member since:
2006-05-10

There is no such thing as "compile&run everywhere". 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.


As far as I know, NaCl is OS independent and, in the near future, PNaCl will address the CPU dependence too.

Edited 2010-05-15 11:34 UTC

Reply Parent Score: 2

Zifre Member since:
2009-10-04

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

umccullough Member since:
2006-01-26

And less-common operating systems like Haiku can die.


Actually, since NaCl is open source, it can be compiled for Haiku too.

NaCl is kind of like a sandboxed OS inside an OS... providing native compiled x86 (or ARM) code that can run on any OS that NaCl has already been ported to.

There was already a suggestion to port NaCl to Haiku, but nobody seemed interested at the time, so it hasn't been attempted. In theory, if it was ported to Haiku, then any NaCl apps would be runnable in Haiku without a recompile, assuming they were run on the same architecture (x86 or ARM) that they were compiled for.

Reply Parent Score: 2