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

341–350 of 352 posts

Re: Goodbye PNaCl, Hello WebAssembly

#341

Post by AgentME »

TekMol wrote: post #323
johncolanduoni wrote: post #304

Earlier quoted context omitted.

It's a format designed to be a target for static languages that do manual memory management (like C/C++) instead of JavaScript that some engines know how to recognize and optimize. The binaries are smaller and much faster to parse and the sandbox model results in much less overhead. For a concrete example, at least two JavaScript engines (those of Chrome and Firefox) need to emit almost no range checks on regular mem…

target for static languages that do manual memory management So I will have to do all the garbage collection myself? Isn't that a huge burdon on the programmer? And will this lead to lots of apps with memory leaks that needlessly eat up my resources?

That's already the case if you want to do high-performance stuff with C/C++. WebAssembly is primarily about getting that into the web.

Re: Goodbye PNaCl, Hello WebAssembly

#342

Post by jameskegel »

brandon wrote: post #167
_wmd wrote: post #25

The most material result of this is that Chromebooks won't have a working SSH client starting sometime next year, because WebAssembly can't do real sockets without an external proxy.

We're going to make sure that the Secure Shell app for Chrome, in one form or another, continues to be usable on Chrome OS. (I'm one of the current maintainers and we're already all over this transition)

Thank you for your contribution to a great project that I use daily

Re: Goodbye PNaCl, Hello WebAssembly

#343

Post by angry_octet »

roca wrote: post #339
angry_octet wrote: post #274

Earlier quoted context omitted.

If you care about security, performance or having portable offline applications its a sad day. Google just pressed reset and erased your work. The way Google has abrubtly sent PNaCL to the knackery, rather than a gradual transition is just ugly. By removing the PNaCL functionality completely from builds they have broken faith with the development community. They didn't even commit to allowing PNaCL to run in deprecat…

AFAIK the main missing feature in WebAssembly that PNaCl had is shared-memory multithreading and that is implemented and waiting on spec finalization to ship. What else is there?

Security (code signing, timing determinism, large API attack surface, complex javascript interpreter/jit), performance (obvious deficit between an IR bytecode and jit, static analysis vs runtime checks), concurrency (how many cores on your new 2017 box? By 2027?), features (the p/nacl api let you do more, like access devices for video/graphics/audio; instead it will be an implementation specific thing; networking - open sockets to unrelated hosts; same origin is a straight jacket), elegance (wasm/asm.js/js is just hack, hack, hack; thanks Mozilla), maturity (just bugs need time to be sorted).

Re: Goodbye PNaCl, Hello WebAssembly

#344

Post by roca »

angry_octet wrote: post #343
roca wrote: post #339

Earlier quoted context omitted.

AFAIK the main missing feature in WebAssembly that PNaCl had is shared-memory multithreading and that is implemented and waiting on spec finalization to ship. What else is there?

Security (code signing, timing determinism, large API attack surface, complex javascript interpreter/jit), performance (obvious deficit between an IR bytecode and jit, static analysis vs runtime checks), concurrency (how many cores on your new 2017 box? By 2027?), features (the p/nacl api let you do more, like access devices for video/graphics/audio; instead it will be an implementation specific thing; networking - o…

I don't think PNaCl guarantees timing determinism.

Not sure what you mean by "code signing" in this context.

The API attack surface is a non-issue; it's already accessible by any page that serves a PNaCl object.

There's a small performance deficit but it's getting smaller. AOT compilation and caching of compilation results is possible; asm.js did it.

I already mentioned shared-memory parallelism (it's just about done); did you read what I wrote?

Standard cross-browser Web APIs give you access to those devices already.

Same-origin is a strait-jacket --- a necessary one. "Break the Web's security model" isn't a desirable feature.

"Elegance" is just a point of view. From another point of view, "duplicate everything in the Web platform" is not elegant.

As for maturity and bugs --- having multiple interoperating implementations and real specifications is a good way to drive competition on quality ... and to distinguish "this is a bug, fix it" from "hello de-facto standard!"

Re: Goodbye PNaCl, Hello WebAssembly

#345

Post by roca »

angry_octet wrote: post #343
roca wrote: post #339

Earlier quoted context omitted.

AFAIK the main missing feature in WebAssembly that PNaCl had is shared-memory multithreading and that is implemented and waiting on spec finalization to ship. What else is there?

Security (code signing, timing determinism, large API attack surface, complex javascript interpreter/jit), performance (obvious deficit between an IR bytecode and jit, static analysis vs runtime checks), concurrency (how many cores on your new 2017 box? By 2027?), features (the p/nacl api let you do more, like access devices for video/graphics/audio; instead it will be an implementation specific thing; networking - o…

Also "static analysis vs runtime checks" is a red herring --- PNaCl and Wasm are basically identical in those respects.

Re: Goodbye PNaCl, Hello WebAssembly

#346

Post by jsjohnst »

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.

A device using the linux kernel (or Mach kernel in iOS) doesn't make it a "Unix" or "Unix-like" system, despite that same kernel being used in other truly Unix-like systems. The user land (aka GNU in most Linux distros) is what makes it a Unix-like system. That doesn't mean GNU isn't relevant, it means what you considered a "Unix-like" system was overly broad.

This reply is a bit overly pedantic and I apologize, but you kept pushing so I wanted to clarify.

Re: Goodbye PNaCl, Hello WebAssembly

#347

Post by lmm »

camgunz wrote: post #326
lmm wrote: post #299

Earlier quoted context omitted.

You're begging the question, assuming you have to represent a particular unsigned type to start with. What's the problem that you're trying to solve? I appreciate that e.g. particular image formats are defined in terms of unsigned integers of particular sizes, but parsing binary formats seems like a specialized use case that's not worth distorting the whole language over (and it already involves fiddling with endiann…

I don't think this is a "begging the question" fallacy. General purpose programming language often need to deal with binary data. This can be anything from documents, compressed files, images, audio, video, network data, a video framebuffer, and so on. Dealing with binary is in no way a "specialized use case" of programming; I'm honestly a little incredulous at your insinuation. Further, this "distortion" amounts to…

I view extra primitives as very expensive because they add a whole bunch of extra cases in the language itself; I like small languages where as much as possible can be moved into libraries. I just don't see the use cases for unsigned ints as being widespread enough to justify having them in the language; I've worked across a number of industries and I think I've seen them used once (when fixing a bug in ffmpeg), whereas for-in and lambda are used absolutely everywhere. I'm not especially anti-unsigned; if I was designing a JVM-like bytecode I'd remove short, and perhaps even (single-precision) float and int as well.

Re: Goodbye PNaCl, Hello WebAssembly

#348

Post by equalunique »

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…

This is bad news. Wasn't aware.

Re: Goodbye PNaCl, Hello WebAssembly

#349

Post by jlarocco »

kps wrote: post #149
jlarocco wrote: post #131

Earlier quoted context omitted.

> The way things are, right now, Chrome is much better at protecting apps from each other than my Linux desktop is. I have a hard time believing that. With a ton of stuff all running inside of Chrome, it's much easier for them to access each other's data than if they were standalone apps. Further, since Chrome is such a huge attack surface, I would expect it to be less secure than a smaller, more specific application…

> I have a hard time believing that. With a ton of stuff > all running inside of Chrome, it's much easier for them > to access each other's data than if they were standalone > apps. Ah, the argument from incredulity. If you're using X11, every command with access to the display server (which is usually everything you run) can read all keyboard and pointer input and screen output and inject arbitrary input.

And? That doesn't change by running inside of Chrome.

The only reason that's even a concern is because you can't trust Chrome Apps to not be malware.

On the other hand, when I "apt-get install " I know it's not listening to all X keystrokes unless that's a legitimate part of its functionality, because I trust the Debian team to only add trustworthy software to their repos.

Re: Goodbye PNaCl, Hello WebAssembly

#350

Post by jlarocco »

AgentME wrote: post #335
jlarocco wrote: post #131

Earlier quoted context omitted.

> The way things are, right now, Chrome is much better at protecting apps from each other than my Linux desktop is. I have a hard time believing that. With a ton of stuff all running inside of Chrome, it's much easier for them to access each other's data than if they were standalone apps. Further, since Chrome is such a huge attack surface, I would expect it to be less secure than a smaller, more specific application…

>I have a hard time believing that. With a ton of stuff all running inside of Chrome, it's much easier for them to access each other's data than if they were standalone apps. Chrome apps are subject to sandboxing, and regular native desktop apps (besides apps installed through OS X's app store) generally don't have any sandboxing enforced on them at all.

So people just don't understand processes and permissions any more?
Post reply on HN