“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.”
basically, if this catches on, it will almost completely remove the need for desktop OSs, given that software written for it will run natively in any browser, regardless of the platform and it will simply not exist apps that can’t be ported. The next step is pnacl, which will make everything written for this portable to any processor or device..
Just like ActiveX ran natively in a browser.
ActiveX was completely un-sandboxed. That’s why it was such a horrible mistake.
There are two working approaches to the problem of native code in the browser:
1. Don’t let sites push native code to you and let them pick what functionality they want, not what specific code they want. (This is how NPAPI and Konqueror’s KParts-based plugin API work)
2. Let sites push you stuff, but sandbox it. (This is how Flash, Java Applets, and Native Client work, though Native Client is the first to try it with native machine code)
Native Client focuses more heavily on designing a failsafe sandbox than Flash and Java though, since the potential harm from a breach is higher. (It also helps that Native Client can just reuse existing libraries rather than having to cook up a new set the way Flash and Java did)
Edited 2010-05-14 21:18 UTC
Not only native client is sandboxed, what you compile
runs on any platform , even your cellphone (given you compile an ARM target together with the x86 one). ActiveX used the windows API, this uses a portable, HTML5-friendly api. In the future, pNaCl will add an extra layer to ensure that you compile it one and runs on any platform/
Welcome to the platform-dependent web !
If this is as open as Android or the Flash spec, Google can get from it the power to decide which platform has the right to access contents on the web and which doesn’t.
This reminds of ActiveX. The difference ? They’re Google. They’re smart enough to do this so that no one understand the threats until it’s too late, as an example by avoiding making it a gigantic security flaw.
Goodbye indie OS developers ! We’ll miss you…
Edited 2010-05-15 08:42 UTC
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.
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.
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…
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
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
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.
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.
Oh, okay ! I thought that the whole thing was about using native code, 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.
Yes, but since NaCl takes care of the loading job and since NaCl and its libraries take care of the system calls, we end up using an interpreter-like behavior : code cannot run directly on the computer and must be analyzed and translated to native code by an external program.
PNaCl code cannot just be loaded by the OS and handed to the processor with a “good luck !”. It’s some kind of bytecode that must be translated to something the local architecture and the local OS understand prior execution, just like in Java apps.
However, we all know about Java’s startup performance. It’s an inherent drawback of AOT compilation. So I suppose Google have something behind their back if they want to put this sodium chloride thing everywhere on the web. Maybe some kind of cloud compilation services ?
Edited 2010-05-16 07:28 UTC
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.
.
Edited 2010-05-15 09:44 UTC