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

191–200 of 352 posts

Re: Goodbye PNaCl, Hello WebAssembly

#191

Post by i336_ »

dragonwriter wrote: post #36
cbhl wrote: post #32

Earlier quoted context omitted.

Yes, because non-portable NaCl has higher usage inside Chrome Apps and Extensions, but I don't for a minute believe that Google is going to continue investing eng resources in maintaining (non-portable) NaCl now that pNaCl is dead, so I'd expect that to get deprecated sometime in 2019 or 2020. Disclaimer: My opinion, not that of my employer.

> Yes, because non-portable NaCl has higher usage inside Chrome Apps and Extensions, but I don't for a minute believe that Google is going to continue investing eng resources in maintaining (non-portable) NaCl now that pNaCl is dead, so I'd expect that to get deprecated sometime in 2019 or 2020. Sure, it is deprecated and will be deactivated eventually (but maybe not soon; consider WebSQL). Google's got every incenti…

WebSQL is so sad.

https://stackoverflow.com/questions/42288596/websql-has-incr...

Re: Goodbye PNaCl, Hello WebAssembly

#192

Post by [deleted] »

bas wrote: post #170
ehnto wrote: post #166

Earlier quoted context omitted.

I doubt a regular user would notice 100% CPU usage and even less certain that they would know what to do about it or what was causing it. Most OSes operate chrome just fine when another process is asking for 100% as well.

Their fans running at max (or a very warm device) would let them know. This has been the experience among the non/less-technical users in my company.

[deleted]

Re: Goodbye PNaCl, Hello WebAssembly

#193

Post by spc476 »

ehnto wrote: post #187
bas wrote: post #170

Earlier quoted context omitted.

Their fans running at max (or a very warm device) would let them know. This has been the experience among the non/less-technical users in my company.

Right, they might notice it, but why would they care? They don't know that they should care, it is just a computer being a computer and it probably spins up the fans for other tasks too. They would be right to not care unless told otherwise, sys ops isn't their job. I think it would be smart to educate people as part of a regular security briefing for non technical staff though. But if it's something that high of con…

They would care when their laptop shuts down. [1]

[1] I was running a test today when the program being tested ran into a very tight loop and the fan really kicked in. I was curious if it would finish and let it run for several minutes until all went quiet and the screen went dark. It had shutdown to prevent heat damage.

Re: Goodbye PNaCl, Hello WebAssembly

#194

Post by pcwalton »

kuschku wrote: post #48
marcosdumay wrote: post #45

Earlier quoted context omitted.

Yeah. Wouldn't it be great if they just created a simple VM with well specified bytecode so that we could push the complexity into our tooling and just compile into the standard target?

And if that VM ran on over 2 billion devices, on every toaster out there? In the end, this all is just reinventing the JVM, in slower, but more secure.

It's reinventing the good part of the JVM (the JIT and the bytecode), better than the JVM (unsigned ints and value types are supported), without the bad parts of the JVM on the Web (the libraries, including the slow graphics stack, etc.)

What's not to like?

Re: Goodbye PNaCl, Hello WebAssembly

#195

Post by dragonwriter »

roca wrote: post #190
dragonwriter wrote: post #186

Earlier quoted context omitted.

There's no blunder: Google had a goal, threw out something, stimulated competition over the precise implementation, and now there is a universally (among browser vendors) accepted solution moving the web in the direction Google wanted. That's a strategic victory for Google.

Google wasted huge resources on an approach which it was obvious from the beginning would never lead to a Web standard. Mozilla people, including me, told Google people even before PNaCl appeared that introducing the whole new non-standard Pepper API was unacceptable.

> 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 quite a few times. So what? Unacceptable nonstandard moves are a big part of what stimulates standards progress.

Re: Goodbye PNaCl, Hello WebAssembly

#196

Post by yorwba »

nol13 wrote: post #169
AsyncAwait wrote: post #28

Earlier quoted context omitted.

Every piece of technology can be abused, that doesn't mean the technology itself is bad and shouldn't be adopted.

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.

Re: Goodbye PNaCl, Hello WebAssembly

#197

Post by witty_username »

spc476 wrote: post #193
ehnto wrote: post #187

Earlier quoted context omitted.

Right, they might notice it, but why would they care? They don't know that they should care, it is just a computer being a computer and it probably spins up the fans for other tasks too. They would be right to not care unless told otherwise, sys ops isn't their job. I think it would be smart to educate people as part of a regular security briefing for non technical staff though. But if it's something that high of con…

They would care when their laptop shuts down. [1] [1] I was running a test today when the program being tested ran into a very tight loop and the fan really kicked in. I was curious if it would finish and let it run for several minutes until all went quiet and the screen went dark. It had shutdown to prevent heat damage.

That means the fans need to be cleaned of dust.

A laptop overheating from few minutes of 100% CPU is not normal.

Re: Goodbye PNaCl, Hello WebAssembly

#198

Post by willvarfar »

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 other OS, each app in a little sandbox... It ought just be another compiler target and automated.

Oh to what could have been! :(

Re: Goodbye PNaCl, Hello WebAssembly

#199

Post by roca »

dragonwriter wrote: post #195
roca wrote: post #190

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. Mozilla people, including me, told Google people even before PNaCl appeared that introducing the whole new non-standard Pepper API was unacceptable.

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

If spending any amount of resources to get any amount of utility counts as success, then there is no such thing as failure.

Re: Goodbye PNaCl, Hello WebAssembly

#200

Post by jsjohnst »

Sanddancer wrote: post #183
mikekchar wrote: post #114

Earlier quoted context omitted.

I've got this crazy idea. Since "Linux Desktops" are generally running GNU under the hood for providing user land services, why don't we call those systems... I don't know... "GNU/Linux"? That way we can distinguish them from systems that use the Linux kernel, but have a completely different user land infrastructure. I know, I know. It's crazy talk....

How many of them actually intimately use the GNU userland as opposed to Xorg and whatever libc's installed? GNU's an increasingly irrelevant portion of unix and unixlike systems -- most of the actually important userland portions are python, ruby, the aforementioned Xorg, etc.

> 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

Post reply on HN