HN Explorer

Google Chrome SVP says Portable NaCl will ship "in six weeks" (news.cnet.com)

43 points by potkor ↗ HN
It's in the context of the Chromebook but probably it will be a general Chrome feature if it's to be useful.

This is great news for NaCl fans who have been mourning its limited potential due to its previously x86-bound nature.

The PNaCl project has been around for a while, but AFAIK this is the first time Google have actually announced it's going to be productized.

35 comments

[ 7.6 ms ] story [ 74.6 ms ] thread
kevingadd
Nice to see Google delivering on their promises here. I look forward to trying out PNaCl apps on Android in Chrome!
[deleted]
(comment deleted)
willvarfar
This is a very big deal for that new $249 ARM Chromebook they just announced, right?

This means apps!?!

TazeTSchnitzel
No, Chrome already has Apps.

It means faster, native apps.

cliffbean
No, Chrome already has native apps -- NaCl. This headline is about PNaCl, the attempt to make native apps portable.
daeken
NaCl for ARM isn't shipping, is it? Last I heard, there were some serious issues with it, but that may have changed (I hope!).
OldSchool
I wonder if Apple will selectively sue Samsung because it's a thin, rectangular, silver clamshell with black keys and a screen? (I like the Macbook Air btw)
ams6110
Samsung can claim they didn't copy Apple because their design has a big ugly hinge visible on the top.
batgaijin
Can someone enlighten me about the Pepper API? Could I run a server with it? What would sort of limits does the network connection have? How many requests per second could it handle? How many simultaneous connections? What about bandwidth? etc. etc.
majke
Pepper is a new Plugin API for browsers proposed by Chrome: https://code.google.com/p/ppapi/

Plugin API is the magic responsible for Java or Flash in your browser. A plugin once installed on your PC may run in a number of browsers, as all use the same API - currently it is NPAPI.

NPAPI (Netscape Plugin API) is very old and Chrome with Pepper wants replace it.

Mozilla doesn't like Pepper, so at least for now Pepper is a Chrome-specific thing: https://wiki.mozilla.org/NPAPI:Pepper

Tomdarkness
Do you know why Mozilla does not seem interested in Pepper?
apetrovic
Both Google and Mozilla wants to obsolete your OS and move general computing in the browser; Google is more pragmatic and sees the need for native code apps on the client side (like games, image processing, etc) so they wants to transform the browser into distribution platform for such apps. Mozilla crew, on the other hand, holds high moral ground and lives in imaginary world where everything can be made with Web technologies, and if something isn't possible right now, we should just wait couple of processor iterations and couple of Web standard iterations.

If companies are people, Google would be someone like Linus, and Mozilla would hang with RMS.

pcwalton
I don't speak for Mozilla, but the position of the non-Google browser vendors in plugin-futures made sense to me: it's simpler to just call the Web APIs from native code. Less code, smaller surface area, fewer APIs for folks to learn.
mccr8
"Mozilla doesn't like Pepper" is a bit of an unfair characterization. A better description would be "only Google likes Pepper", because as far as I am aware Microsoft, Apple and Opera have not expressed any interest in implementing Pepper either. You just see more about Mozilla's thoughts on Pepper because it is a more open organization.
majke
True, and that's why I mentioned only Mozilla - I have no clue what others are saying. Any references to position of Opera, Microsoft and Apple?
vetinari
Microsoft never used NSAPI (API that Mozilla, Apple and Opera use) either. They always used ActiveX. After all, the 'N' in 'NSAPI' means 'Netscape'.
ephemient
Not true. Internet Explorer used to work with both NSAPI and ActiveX plugins, until they pulled support for the former.

"""Netscape-style plug-ins are supported in Internet Explorer 5.5 Service Pack 1 (SP1) and earlier, but are not supported in Internet Explorer 5.5 Service Pack 2 (SP2) and Internet Explorer 6.""" -- http://support.microsoft.com/kb/306790

vetinari
Thanks, I stand corrected.

I just remember, that there were two versions of Flash - ActiveX for IE and NPAPI for all the others.

planckscnst
Up until IE6, they did; after that, there was an ActiveX control that could load NPAPI plugins.
cmccabe
Apple wants people to write iOS applications. Microsoft wants people to write Windows 8 applications.

It's possible that Mozilla will come around, if Chrome gives them a big enough kick in the pants. Then again, it's equally possible that PNaCL / PPAPI will remain simply an app distribution mechanism for ChromeOS.

batgaijin
But what are the limits? Are there any? What system API does the implementation map to? Epoll on Linux automatically, kqueue on Mac OS X, and whatever on Windows?
wmf
NaCl and JavaScript have the same sandbox rules because they're both foreign code. Extensions have access to some APIs that normal code doesn't, but again those APIs are the same between NaCl and JS.
mccr8
That's neat, but an odd thing to incidentally mention.
justinschuh
The announcement is about the new ARM-based Chromebooks, and PNaCl is the way to write performant native apps that run on all architectures supported by Chrome.
mccr8
Of course, but surely this really cool project that Google has been working on for years and years deserves a bigger announcement than an aside in a netbook preview. Hopefully one will be coming along soon.
justinschuh
PNaCl was announced quite a while ago, and is a publicly developed open source project. The new detail here is just when it should start shipping to stable for use in Apps and Extensions.
potkor
Agreed. Maybe they're testing the waters with the Chromebook and not updating the Android Chrome yet.

BTW is there a dev channel for Android Chrome?

bcks
Does anyone know how these work without an active internet connection? Is there an offline / synch option? I think the folks who most need cheap computers are also the ones with the spottiest access...
phaet0n
I'm sure Google's PNaCl ARM solution took this long only because they were waiting to have an easier technical time of it with A15 cores and hardware virtualization. My bet is that they've saved themselves a lot of hassle and gone with implementing a lightweight hypervisor for untrusted native code.
zurn
PNaCl is quite well documented. It involves LLVM bitcode and a verifier to prove it doesn't do anything naughty.

Requiring HW virtualization would defeat the purpouse of portability. It wouldn't fly on desktop or Android because of the HW and OS requirements.