Chromium Blog: A sneak peek at the Native Client SDK

http://blog.chromium.org/2010/05/sneak-peek-at-native-client-sdk.html

by boundlessdreamz • 16 years ago

54 47 16 years ago

blog.chromium.org

nissimk2• 16 years ago

How does this differ from ActiveX controls in IE, aside from being cross platform?

wmf3• 16 years ago

NaCl is sandboxed; ActiveX is not.

nissimk2• 16 years ago

Will it work in non-chromium browsers?

briansmith9• 16 years ago

ActiveX can be sandboxed pretty strongly, but plugins can opt out of it. NaCl seems to leave no way to get out of the sandbox. I think Microsoft could easily add something very similar to NaCl to ActiveX, and then create a distinction in the UI between these sandboxed plugins and the current kind.

Edit: To clarify, ActiveX plugins cannot really "opt out" of IE's sandbox. There are some things they can do to reduce some of the default restrictions, but the most important ones always remain in place.

tptacek5• 16 years ago

ActiveX itself isn't sandboxed, but modern IE (and it's plugin hosting environment) is. Your comment is misleading.

andreyf• 16 years ago

NaCl hosts hacking contests asking people to break their sandbox: http://code.google.com/contests/nativeclient-security/

ActiveX asked users "are you sure you want to run this native code?".

briansmith9• 16 years ago

What would be the difference if Microsoft disabled the prompts for ActiveX controls?

JeffJenkins• 16 years ago

To what degree does "Embrace and Extend" apply to what Google is doing?

stuntmouse8• 16 years ago

That's pretty vague. How does it apply to this situation?

The code is open; part of the NaCL API is designed around Posix/Linux; the Plugin API is the familiar NPAPI and its extensions.

Which part is proprietary or controlled by Google?

To my mind, some more relevant questions are: Does this tie the web to x86 (and ARM)? Can it be adapted securely to x86-64? Can it be made secure? Can multiple implementations be made secure?

papachito2• 16 years ago

> Can it be adapted securely to x86-64?

FTA: "a GCC-based compiler for creating x86-32 or x86-64 binaries from C or C++ source code"

stuntmouse8• 16 years ago

Done right, this will change the world. I'm currently working on porting an emulator. The major sticking point so far is the audio API, which seems rather primitive, but should be sufficient for my needs.

equark• 16 years ago

This looks horrendous. Watch the video for the hello world example. It's probably 100 lines of unintelligible code.

Miguel de Icaza's CLI for the web idea (http://tirania.org/blog/archive/2010/May-03.html) looks like a much better approach.

valisystem• 16 years ago

You just have to port your CLI to native client and it's done, the ugly code is wrote once and then shared.

weavejester2• 16 years ago

It doesn't really matter that the code is unintelligible. One can use higher-level languages on top.

What isn't so good is that NaCl targets the architecture of the host machine. So you're not going to be able to run a NaCl app compiled on x86 on a browser running under ARM. Someone please correct me if I'm wrong.

Miguel suggesting CLI isn't exactly surprising ;), but personally I'd prefer to use a sandboxed VM based on LLVM. CLI makes too many assumptions about the architecture of your language, whilst LLVM is more low-level.

nimrody• 16 years ago

Regarding LLVM -- See the comment about PNaCl (Portable Native Code Client). This is portable code based on LLVM intermediate representation.

Detrus• 16 years ago

You can compile your binary for multiple architectures, check the type of processor and give it the appropriate binary.

They also have the LLVM option so that old binaries keep working on new architectures without recompiling and rewriting NaCl for them, but it has downsides http://blog.chromium.org/2010/03/native-client-and-web-porta...

The reason they didn't go with LLVM as the main approach was performance. Google wants there to be no distinction between desktop and web apps, and for web apps to have even 60% of desktop performance is still unacceptable. 90+% is more like it.

enneff2• 16 years ago

Go runs under NaCl - check out setting up a rendering context for a simple tetris game: http://golang.org/src/pkg/exp/4s/4s.go It's literally a couple of lines in the main function. Pretty straightforward.

I think the guys here chose a less-than-ideal way of demoing the interface for this video, which is surprising.

aidenn0• 16 years ago

It seems to me that while this would have been interesting a few years ago, it's tied to x86 just as people are starting to browse the web more and more on mobile devices.

wmf3• 16 years ago

PNaCl is "write once, run on x86 and ARM". http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf

papachito2• 16 years ago

FTA: "The Native Client SDK preview, in contrast, includes just the basics you need to get started writing an app in minutes: a GCC-based compiler for creating x86-32 or x86-64 binaries from C or C++ source code"

kixxauth• 16 years ago

Browsers are going to be getting closer and closer to the metal all the time. That's what this is telling us. It's like 1991 all over again.

andywood• 16 years ago

Right. And in 1991, applications achieved much more of the potential performance and capability due to the available hardware than web apps do today. So going back to 1991 is an improvement in that respect. The rise of the web has been a trade-off - well-known and significant benefits have been realized, but at the cost of devolution and dead-ends in areas like the developer experience and UI flexibility. (As an example, think about all the reasons why World of Warcraft is not a web app.)

pinhead• 16 years ago

Also pretty interesting if you haven't read it (PDF): http://nativeclient.googlecode.com/svn/data/docs_tarball/nac...

Chromium Blog: A sneak peek at the Native Client SDK

Related Stories