Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye PNaCl, Hello WebAssembly

blog.chromium.org

Post reply on HN
Print view View original

261–270 of 352 posts

Re: Goodbye PNaCl, Hello WebAssembly

#261

Post by _0w8t »

roca wrote: post #258
_0w8t wrote: post #253

Earlier quoted context omitted.

The problem was precisely the Pepper, a pile of API that Google thought they could force on everybody, not PNaCl per see. If the initial NaCl implementation just exposed the pre-existing Web API into the native code sandbox without adding anything extra, the story can be rather different and a version of PNaCl could be standardized.

That's true, although NaCl's design made that difficult because the native code sandbox had to be a different process so interacting with the page's DOM would have required IPC.

I am curious what made it necessary to run NaCl in a different process? I thought the main idea behind NaCl was to allow the same-process native sandboxes.

Re: Goodbye PNaCl, Hello WebAssembly

#262

Post by traverseda »

smitherfield wrote: post #208
krzyk wrote: post #203

Earlier quoted context omitted.

How is it better than WebAssembly?

It executes (sandboxed) native code directly, instead of requiring JIT compilation to native.

Have you seen the "the birth and death of javascript"? More interestingly it could vastly reduce the cost of interprocess communication to the point where the idea of a process starts to look a bit weird.

Want to query a database? Upload a function you wrote yourself for complicated queries like GIS, or let the SQL parser generate the raw wasm on your behalf.

Want to authenticate your users, but don't want to deal with all the different permiations on hardare tokens, ssh keys, etc? Just let them upload a wasm function.

Re: Goodbye PNaCl, Hello WebAssembly

#263

Post by _pmf_ »

yorwba wrote: post #196
nol13 wrote: post #169

Earlier quoted context omitted.

Will WASM trackers/ads be harder to block than ECMA Script ones?

ECMA Script trackers/ads are blobs of code that can sometimes be identified based on the requests they make, WASM trackers/ads are blobs of code that can sometimes be identified based on the requests they make. The only real difference is that the WASM variant will probably run faster than obfuscated ECMA Script.

> The only real difference is that the WASM variant will probably run faster than obfuscated ECMA Script.

... which will lead to more ads being served, evening out any advantage.

Re: Goodbye PNaCl, Hello WebAssembly

#264

Post by snakeanus »

Hydraulix989 wrote: post #172
snakeanus wrote: post #168

Earlier quoted context omitted.

> It was one of the best things that happened to Linux desktops in a long time and removing it hurts users and makes them less secure. I will disagree, you can install most of these from the official repository of your distribution, without the use of electron. They are also very secure if you run them as an unprivileged user.

Suppose your JS Chrome App is getting the plug yanked on it, what are your alternatives? 1.) Port it to Electron and keep nearly the same code base 2.) Rewrite the whole thing as a native app in such a language as C++ without the use of Electron You can't possibly tell me that most developers won't choose #1 instead of #2 in a heartbeat (the switching costs are orders of magnitude more for #2, for one thing). Which i…

You can as a user to just use another application.

Re: Goodbye PNaCl, Hello WebAssembly

#265

Post by sangnoir »

a3_nm wrote: post #216
sangnoir wrote: post #212

Earlier quoted context omitted.

> Google wasted huge resources on an approach which it was obvious from the beginning would never lead to a Web standard Google has been doing this for a long time, I doubt it's unintentional. If there is functionality that they want which is not standardized, they go ahead and implement it. When a workable standard is ready or detailed enough, they switch over to it. The earliest instance of this that I can recall w…

> If there is functionality that they want which is not standardized, they go ahead and implement it. ... in a non-standardizable way. Why not try to help create a standard instead? What's the benefit of starting with a dirty approach and deprecating it later?

> Why not try to help create a standard instead?

They do that as well, it's not one or the other. Google had employees working on WebAssembly (along with Mozilla, Apple and Microsoft). Standards take time to be developed and finalized.

Re: Goodbye PNaCl, Hello WebAssembly

#266

Post by patrickaljord »

willvarfar wrote: post #198

This is a sad day. NaCL was excellent tech, and its a shame it didn't get incorporated into LLVM proper, and that it didn't take off. We should be using NaCL/pNaCL for all apps everywhere, and for components within apps... etc. ZeroVM was a desktop/server sandboxing environment that just didn't get any attention and mindshare. Shame! I want a ZeroVM-like system that makes all of the Debian user-space available on any…

> I want a ZeroVM-like system that makes all of the Debian user-space available on any other OS, each app in a little sandbox

You should check linuxkit https://github.com/linuxkit/linuxkit

Re: Goodbye PNaCl, Hello WebAssembly

#268

Post by roca »

_0w8t wrote: post #261
roca wrote: post #258

Earlier quoted context omitted.

That's true, although NaCl's design made that difficult because the native code sandbox had to be a different process so interacting with the page's DOM would have required IPC.

I am curious what made it necessary to run NaCl in a different process? I thought the main idea behind NaCl was to allow the same-process native sandboxes.

According to https://static.googleusercontent.com/media/research.google.c... NaCl does not sandbox loads, relying on address-space separation to ensure secret data is not leaked. Obviously this only works with a single sandboxed application per address space. (And even then you'd have to be pretty careful!)

Re: Goodbye PNaCl, Hello WebAssembly

#269

Post by hueving »

Hydraulix989 wrote: post #172
snakeanus wrote: post #168

Earlier quoted context omitted.

> It was one of the best things that happened to Linux desktops in a long time and removing it hurts users and makes them less secure. I will disagree, you can install most of these from the official repository of your distribution, without the use of electron. They are also very secure if you run them as an unprivileged user.

Suppose your JS Chrome App is getting the plug yanked on it, what are your alternatives? 1.) Port it to Electron and keep nearly the same code base 2.) Rewrite the whole thing as a native app in such a language as C++ without the use of Electron You can't possibly tell me that most developers won't choose #1 instead of #2 in a heartbeat (the switching costs are orders of magnitude more for #2, for one thing). Which i…

Which option works on a chromebook?

Re: Goodbye PNaCl, Hello WebAssembly

#270

Post by willvarfar »

traverseda wrote: post #262
smitherfield wrote: post #208

Earlier quoted context omitted.

It executes (sandboxed) native code directly, instead of requiring JIT compilation to native.

Have you seen the "the birth and death of javascript"? More interestingly it could vastly reduce the cost of interprocess communication to the point where the idea of a process starts to look a bit weird. Want to query a database? Upload a function you wrote yourself for complicated queries like GIS, or let the SQL parser generate the raw wasm on your behalf. Want to authenticate your users, but don't want to deal wi…

cough java was supposed to do all that, right?
Post reply on HN