Can someone get opencv running on it?
Webasm doesn't currently have access to SIMD instructions or the gpu. So that kind of intensive matrix math stuff might not benefit too much from webasm.
Goodbye PNaCl, Hello WebAssembly
331–340 of 352 posts
Re: Goodbye PNaCl, Hello WebAssembly
#332Earlier quoted context omitted.
The p in pNaCL stands for "portable". The basic tech behind it is LLVM IR, which is the same tech Apple Store now uses to target the Watch and future devices.
So if I understand correct, they didn't like LLVM because it wasn't really designed for this purpose. Webasm has some advantages over it like being designed from the ground up to be a secure sandbox and fit in with existing javascript JITs. LLVM also isn't a fixed open standard and doesn't guarantee backwards compatibility (I think.) You can also compile LLVM code to webasm even today, so it isn't that much of an iss…
I work on off-tree LLVM and have been following NaCL from the beginning. I think it's mostly nobody wanted to adopt googles solution or even admit that browsers needed sandboxing. Hell, Firefox only recently got serious about putting different sites in different processes. It took them years to accept they needed a pNaCL, and by then they couldn't really stomach using something already tried and tested by political opponents. Browsers and LLVM are both too political.
Re: Goodbye PNaCl, Hello WebAssembly
#333This 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…
> require a native app otherwise Oh, the tragedy /s
I'm extremely hesitant about installing random non-sandboxed applications. A Chrome app comes sandboxed with well-defined permissions. It's rare for native apps outside of mobile to come sandboxed or be easy to sandbox.
Re: Goodbye PNaCl, Hello WebAssembly
#334This 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…
Have you tried simply avoiding Electron and the bloatware it encourages?
Wasn't his post arguing in favor of Chrome apps over Electron? He'd prefer to keep using Chrome apps and avoid Electron.
Re: Goodbye PNaCl, Hello WebAssembly
#335Earlier quoted context omitted.
Signal Desktop and Cleanflight are open source. And sometimes, you have no choice - there's no FOSS alternative to TeamViewer, and thanks to it running inside Chrome, I no longer have to run a Windows VM. The web based SSH client is published by Google themselves and they use it internally. > The teams working on Debian, Ubuntu, Arch, etc. have much better security track records than some random web developers who've…
> 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.
Re: Goodbye PNaCl, Hello WebAssembly
#336Earlier quoted context omitted.
Sure but the asm.js/Wasm approach was always an option. They didn't have to go down the path they did.
Was it an obvious option? I don't think I'd give the asm.js and WebAssembly developers so little credit.
Mozilla people and Google people talked to each other long before those releases.
Re: Goodbye PNaCl, Hello WebAssembly
#337>We will remove support for PNaCl in the first quarter of 2018 While the new Google Earth with PNaCl was just introduced, a large engineering cost for a semester-lived technology! Too bad
Plenty of people were left scratching their heads when the new Google Earth was introduced, precisely because it was clear that PNaCl's days were numbered.
I think the likely explanation is that Google is a large company with numerous departments and those departments don't always pull in the same direction. I imagine some people within Google weren't happy with the Google Earth announcement.
Re: Goodbye PNaCl, Hello WebAssembly
#338Earlier quoted context omitted.
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 solu…
Actually a commitment to Web standards does mean a commitment to not launching nonstandard extensions to the Web platform, usually. Many of Chrome's own Web standards people would tell you this. For PNaCl and some other features Google's official excuse was to designate them "not part of the Web platform" ... which doesn't really make sense from anyone's point of view other than Google's.
In this case, the desirability and feasibility of running C/C++ code on the Web was not something that needed to be demonstrated by enabling PNaCl for Web content. In fact, uptake of Web-PNaCl has been extremely low --- fortunately. If significant Web-PNaCl uptake had been a prerequisite for WebAssembly, then WebAssembly probably wouldn't have happened!
Re: Goodbye PNaCl, Hello WebAssembly
#339Am I in the minority that I think it is a positive development, when Google is discarding proprietary ideas in favour of open developments? Not perfect but the direction looks good so far.
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?
Re: Goodbye PNaCl, Hello WebAssembly
#340Earlier quoted context omitted.
So if I understand correct, they didn't like LLVM because it wasn't really designed for this purpose. Webasm has some advantages over it like being designed from the ground up to be a secure sandbox and fit in with existing javascript JITs. LLVM also isn't a fixed open standard and doesn't guarantee backwards compatibility (I think.) You can also compile LLVM code to webasm even today, so it isn't that much of an iss…
I work on off-tree LLVM and have been following NaCL from the beginning. I think it's mostly nobody wanted to adopt googles solution or even admit that browsers needed sandboxing. Hell, Firefox only recently got serious about putting different sites in different processes. It took them years to accept they needed a pNaCL, and by then they couldn't really stomach using something already tried and tested by political o…
Supporting pNaCL and whether or not the browser's own code is sandboxed seem like very different issues; I'm not sure why you're conflating them.
>Hell, Firefox only recently got serious about putting different sites in different processes.
A multi-process architecture is a huge thing to try to bolt on later, and Firefox was also held back because many of its add-on APIs were incompatible with a multi-process architecture. They are finally making progress at least.