Google Chrome SVP says Portable NaCl will ship "in six weeks" | Hacker News Reader

Google Chrome SVP says Portable NaCl will ship "in six weeks"

news.cnet.com

43 pointspotkor34 comments

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.

Open articleView on HN

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.

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

Do you know why Mozilla does not seem interested in Pepper?

All I could find. https://mail.mozilla.org/pipermail/plugin-futures/2010-April...

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.

Brendan Eich posted some thoughts on Pepper recently in this comment and many followups:

http://news.ycombinator.com/item?id=4632410

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.

"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.

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?

Here's a comment from Maciej (Apple): http://news.ycombinator.com/item?id=2057611

Apple very rarely takes positions on technologies that we don't currently support. Here is a past comment conveying a personal opinion from a WebKit engineer though: https://mail.mozilla.org/pipermail/plugin-futures/2010-April...

Microsoft never used NSAPI (API that Mozilla, Apple and Opera use) either. They always used ActiveX. After all, the 'N' in 'NSAPI' means 'Netscape'.

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

Thanks, I stand corrected.

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

Up until IE6, they did; after that, there was an ActiveX control that could load NPAPI plugins.

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.

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?

There aren't probably any PNaCl specific aspects to these. This is untrusted code so naturally there will be limits.

You could start at http://src.chromium.org/viewvc/chrome/trunk/src/ppapi/api/

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.

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)

Samsung can claim they didn't copy Apple because their design has a big ugly hinge visible on the top.

Nice to see Google delivering on their promises here. I look forward to trying out PNaCl apps on Android in Chrome!

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.

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.

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...

This is a very big deal for that new $249 ARM Chromebook they just announced, right?

This means apps!?!

No, Chrome already has Apps.

It means faster, native apps.

No, Chrome already has native apps -- NaCl. This headline is about PNaCl, the attempt to make native apps portable.

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!).

That's neat, but an odd thing to incidentally mention.

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.

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.

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.

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?

Reply on news.ycombinator.com