Earlier quoted context omitted.
Then they have bigger problems that they should be getting on top of urgently.
I agree, but simply telling user to download a better browser could be a pretty condescending attitude. Falling back to a css-less html 4 would be more responsible for everyone.
Goodbye PNaCl, Hello WebAssembly
251–260 of 352 posts
Re: Goodbye PNaCl, Hello WebAssembly
#252Earlier quoted context omitted.
> 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
#253Earlier 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.
Re: Goodbye PNaCl, Hello WebAssembly
#254Earlier quoted context omitted.
On windows, you no longer need either with bash for windows you can have a near complete linux experience while running inside windows natively.
If you can assure me that is the case, fantastic! Do you know of a way to test the UX of ssh from bash for windows for less than $5 ?
Cygwin has ssh as an optional install.
Msys2 too.
Of course, you need to have windows first. MS give away 30-day win 10 trial VM images with git bash installed, or at least they did.
Re: Goodbye PNaCl, Hello WebAssembly
#255Earlier quoted context omitted.
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.
Were you around in the 90s when people actually did try to use the JVM for this? Do you remember the part where everyone started using JavaScript instead because of all the deficiencies of Java Applets? (Slow to load, resource intensive, no interaction with the surrounding page)
Re: Goodbye PNaCl, Hello WebAssembly
#256Earlier quoted context omitted.
I think that's what parent commenter was implying. (However, I don't agree. I remember the horrible Java applets and I am thankful that I pretty much never encounter any of them these days.)
> I remember the horrible Java applets and I am thankful that I pretty much never encounter any of them these days.) Yeah, yay for progress and horrible Electron apps..
I much prefer the latter (HTML5 + CSS3 + JS + WebAsm).
Re: Goodbye PNaCl, Hello WebAssembly
#257Earlier quoted context omitted.
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?
That'd make it even possible to reuse old applets with just a tiny shim around them.
And it'd keep compatibility with a huge environment of libraries and languages.
Re: Goodbye PNaCl, Hello WebAssembly
#258Earlier 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.
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.
Re: Goodbye PNaCl, Hello WebAssembly
#259Earlier 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.
Reminds me of Cunnigham's Law: "the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."
Re: Goodbye PNaCl, Hello WebAssembly
#260This 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.)