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

281–290 of 352 posts

Re: Goodbye PNaCl, Hello WebAssembly

#281

Post by dragonwriter »

StavrosK wrote: post #278
dragonwriter wrote: post #195

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. But it did lead to a web standard, even if it didn't become one. And in the interim, it provided utility to Google. > Mozilla people, including me, told Google people even before PNaCl appeared that introducing the whole new non-standard Pepper API was unacceptable. Yeah, you've mentioned that qui…

Just so I get your argument straight, you're saying that launching a proprietary competitor to the standard means you're helping the standard? Because then we owe Microsoft and Apple a shitload of thanks.

> Just so I get your argument straight, you're saying that launching a proprietary competitor to the standard means you're helping the standard?

No, I'm saying that launching a nonstandard solution to a problem without a standard solution or where there are discontents with the standard that are not being addressed is the usual way new standards are motivated, whether the new standard is based on the nonstandard solution or developed in reaction to it.

Standards (and even moreso, standards that are actually implemented rather than being mere paper triumphs) somewhat backward-looking rather than out-of-the-blue.

A commitment to standards isn't about not implementing nonstandard things, it's about engaging in the standards process to help get to a robust standard and then implementing it (replacing nonstandard solutions, if any) when it is clear what the consensus standard will be.

(And I use "nonstandard" rather than "proprietary" because standard/nonstandard is a different axis than open/proprietary.)

> Because then we owe Microsoft and Apple a shitload of thanks.

Well, yes, a lot of current web standards were originally either nonstandard solutions from Microsoft or Apple or alternatives developed in response and motivated by such nonstandard solutions, so, sure, they've driven a lot of the progress. I think they've generally been less good about (at last, slower) participating in standardization of an alternative when their original solution isn't acceptable to other players, but they have definitely been change drivers.

Re: Goodbye PNaCl, Hello WebAssembly

#282

Post by CryZe »

flohofwoe wrote: post #224
coolmitch wrote: post #11

As a web developer working primarily in JS, what should I be learning now to stay relevant/up-to-date once WebAssembly is more common? Are we going to see more web stuff built with c++, like the dsp example in this blog post?

You shouldn't have to deal with C++ directly unless you really want to, it's more likely that there will be 'precompiled' WebAssembly modules of existing C/C++ libs which solve computation-heavy tasks (like physics engines, image manipulation, 3d rendering frameworks etc)... and which would offer a Javascript API. The workflow for JS devs would be the same as using a minified Javascript framework now, but instead of…

Without finalizers in JavaScript, WASM Libraries don't work out well, as you need to do manual memory management in your JavaScript code then, as you won't be able to hook the native destructors into the Garbage Collector of JavaScript. So until those are a thing, it'll be extremely ugly to work with WASM Libraries in JavaScript.

Re: Goodbye PNaCl, Hello WebAssembly

#283

Post by roca »

_0w8t wrote: post #275
roca wrote: post #268

Earlier quoted context omitted.

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

This is only for NaCl on ARM or AMD64. The original NaCl for x86 uses the segment registers for isolation allowing to restrict both loads and stores only to the permitted addresses. That, as far as I understand, does allow to embed into 32-bit process without compromising secretes. So as a speculation in an alternative world where Google has not developed Pepper, but bridged web api into x86 NaCl, the latter designs…

https://static.googleusercontent.com/media/research.google.c... shows that the original NaCl-x86 only allowed one sandboxed application per process. So to support pages with more than one plugin, IPC would have been needed.

Sure, (P)NaCl could have been implemented differently in a way that allowed multiple sandboxed applications per process, and then DOM access would have been easier and maybe Pepper wouldn't have been necessary, though there would have been slightly higher overhead I guess.

That's all history now.

Re: Goodbye PNaCl, Hello WebAssembly

#284

Post by Vinnl »

hisyam wrote: post #260
Vinnl wrote: post #238

Earlier quoted context omitted.

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

Some devs want to develop js apps without paying/maintaining a server.

Since they're just static files, that should be pretty easy to do :)

Re: Goodbye PNaCl, Hello WebAssembly

#286

Post by gok »

lawthemi wrote: post #218

It's sad. PNACL is more efficient. Go to lichess.org/analysis, make a few moves, turn on the engine analysis. With firefox and WASM, my machine compute 300 knode/s. With chrome and PNACL, my machine compute 2000 knode/s. That's a big step backward.

I see nothing inherently more efficient about PNaCl. Both it and WASM expose an architecture-agnostic 32-bit virtual instruction set, then rely on the user agent to apply good optimization. WASM’s performance will improve.

Non-portable NaCl did have the advantage that it could specifically target and optimize for one CPU architecture, and it had the beginnings of 64-bit address space support. These were nice, but not widely used. And we both could conceivably make it into WASM in the future.

Re: Goodbye PNaCl, Hello WebAssembly

#287

Post by aargh_aargh »

afarrell wrote: post #207
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.

Yes, but the existence of ssh on chrome makes it much much easier to teach a windows user how to try out the linux command line. PuTTY is annoying as hell to help a new person get working and they might not have enough space for vagrant+virtualbox.

Just curious - why do you think PuTTY is annoying?

Re: Goodbye PNaCl, Hello WebAssembly

#288

Post by cat199 »

afarrell wrote: post #207
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.

Yes, but the existence of ssh on chrome makes it much much easier to teach a windows user how to try out the linux command line. PuTTY is annoying as hell to help a new person get working and they might not have enough space for vagrant+virtualbox.

PuTTY is annoying as hell to help a new person get working

Seriously? There are like 12389127381789 how to guides about how to do it, and it is literally like 3 steps.

Do you really think the person who has problems starting putty is going to thrive in a CLI environment?

Re: Goodbye PNaCl, Hello WebAssembly

#289

Post by cat199 »

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.

While this is true, there is still a unix-like userland typically, at least in the form of busybox or somesuch..

I think there is some value in denoting 'linux the kernel' from 'linux the unix-like system', especially in the face of those systems which mainly use 'linux the kernel' in a non unix-like way, such as here..

e.g.: the 'gnu parts' (e.g. unix-style userland) are hugely important for me in a workstation - I could not do work in a system that doesn't provide the 'gnu(unix) like' user interface. On a phone/consumer/browser device, this is not so much the case

Re: Goodbye PNaCl, Hello WebAssembly

#290

Post by 0x4f3759df »

bad_user wrote: post #160
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.

> unblockable advertising What do you mean?

Turn your website into an interactive canvas, basically an HTML5 Canvas game that functions like a news site, I think it would be much more difficult to block ads in this scenario. One objection is that you can already do this and we don't see it, but a counterpoint is that its a hassle at the moment, and once tooling is advanced C# to WASM compiler or something along those lines, then we'll see frameworks and then it will be pretty simple and possibly compelling... If it gives publishers more control over the experience I don't see how they could pass it up.
Post reply on HN