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

241–250 of 352 posts

Re: Goodbye PNaCl, Hello WebAssembly

#241

Post by amelius »

eeZi wrote: post #21

This one I'm fine with since WebAssembly is a worthy replacement, but I'm still annoyed at Google discontinuing Chrome Apps. Some examples of specialized apps I use all the time that would require a native app otherwise: - Signal Desktop - TeamViewer - Postman - SSH client - Cleanflight drone configuration tool It was one of the best things that happened to Linux desktops in a long time and removing it hurts users an…

> instead of one Chrome instance, I'm now running five which use more than one GB of RAM each

Is that true? Executables and shared object files are supposed to share (code) memory.

So what big data structures does Chrome use that it can share between tabs (which are processes) and that it can't share between different instances of Chrome?

Re: Goodbye PNaCl, Hello WebAssembly

#242

Post by bonzini »

Sanddancer wrote: post #204
jsjohnst wrote: post #200

Earlier quoted context omitted.

> GNU's an increasingly irrelevant portion of Unix Say what? Do you know what GNU means or what it includes? Here's a link so you can learn more: https://www.gnu.org/software/software.html

Yes, I know what it means and includes. Android, which is one of the biggest unixes right now, doesn't use GNU. iOS, which is another one of the biggest unixes right now, doesn't use GNU. Most embedded linuxes don't use GNU. So yes, for the parts of unix which are visible to most people, the gnu parts are not very relevant at all.

But they are for the "Linux Desktop", hence the joke.

Re: Goodbye PNaCl, Hello WebAssembly

#243

Post by jholman »

wyldfire wrote: post #122
bitmapbrother wrote: post #117

Earlier quoted context omitted.

That you can run asm.js code on wasm.

I suppose I should have asked "what does polyfill mean in this context?" Does that term really alias "run [it] on" or is there something more subtle about this term's meaning?

Web developers, bless their hearts, feel uncomfortable with the word "emulate", so they use "polyfill", or sometimes the more general "shim". To some degree, "polyfill" implies that the functionality being emulated/shimmed is functionality that is under some other circumstances is expected to be provided by the browser itself.

Re: Goodbye PNaCl, Hello WebAssembly

#244

Post by _pmf_ »

amelius wrote: post #241
eeZi wrote: post #21

This one I'm fine with since WebAssembly is a worthy replacement, but I'm still annoyed at Google discontinuing Chrome Apps. Some examples of specialized apps I use all the time that would require a native app otherwise: - Signal Desktop - TeamViewer - Postman - SSH client - Cleanflight drone configuration tool It was one of the best things that happened to Linux desktops in a long time and removing it hurts users an…

> instead of one Chrome instance, I'm now running five which use more than one GB of RAM each Is that true? Executables and shared object files are supposed to share (code) memory. So what big data structures does Chrome use that it can share between tabs (which are processes) and that it can't share between different instances of Chrome?

> Is that true? Executables and shared object files are supposed to share (code) memory.

Different version - different DLLs

Re: Goodbye PNaCl, Hello WebAssembly

#246

Post by quadrupleslap »

3131s wrote: post #173
quickben wrote: post #126

Earlier quoted context omitted.

Add to that list: - unblockable advertising - stronger DRM - Bitcoin mining that regular user can't detect - etc.. It will be good and bad, but, more bad than good. We could choose not to run .exe .bat and the rest So far, webassbly doesn't look optional.

> Bitcoin mining that regular user can't detect That's actually a great idea for funding content creation online. If a site is open source, then it would even be possible to prove that only a reasonable share of the client's resources are being utilized. I'd take that funding model over the advertising-driven model that exists now.

That's actually pretty clever, but wouldn't the resource usage be insane?

Re: Goodbye PNaCl, Hello WebAssembly

#247

Post by _0w8t »

Vinnl wrote: post #238
eeZi wrote: post #21

This one I'm fine with since WebAssembly is a worthy replacement, but I'm still annoyed at Google discontinuing Chrome Apps. Some examples of specialized apps I use all the time that would require a native app otherwise: - Signal Desktop - TeamViewer - Postman - SSH client - Cleanflight drone configuration tool It was one of the best things that happened to Linux desktops in a long time and removing it hurts users an…

I always wonder what it is that these apps need that cannot be done as regular web apps, as the web platform has provided more and more controlled ways to break out of the browser sandbox. (This is not rethorical by the way.)

PNaCl is (or should I use "was") not limited to HTTP and can use UDP/TCP directly. So things like SSH clients are possible.

Re: Goodbye PNaCl, Hello WebAssembly

#248

Post by hawski »

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?

Because people prefer something broken now then something good later.

Re: Goodbye PNaCl, Hello WebAssembly

#249

Post by roca »

zurn wrote: post #189

Say hello to memory-unsafe languages and resulting vulnerabilities in web apps?

To some extent yes, but not nearly as bad. One feature Wasm has (shared with asm.js, but NOT PNaCl) is that the stack of return addresses lives outside addressable memory, and therefore can't be corrupted by an arbitrary-write primitive, so no ROP attacks. Likewise Wasm memory is entirely non-executable so you can't return or jump to exploit code. Function pointers are quite restricted; you can only make an indirect call to a function that's explicitly listed as indirectly-callable.

Wasm applications can have type confusion bugs, use-after-free bugs, and array overflow bugs, etc, but this is inevitable for any realistic C/C++ compilation target.

Re: Goodbye PNaCl, Hello WebAssembly

#250

Post by lukechilds »

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…

Unless I'm misunderstanding something, an Electron app also has direct unchecked access to users' files by using the Node.js 'fs' core module.
Post reply on HN