Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wasmer 1.0

medium.com

Post reply on HN
Print view View original

101–110 of 168 posts

Re: Wasmer 1.0

#101

Post by kaba0 »

nine_k wrote: post #93
_TA_12_ wrote: post #88

>> We believe that WebAssembly will be a crucial component for the future of software execution and containerization (not only inside the browser but also outside). Why? I don't get that or maybe miss some crucial parts or maybe it's just a too enthusiastic statement. I understand the security issues of running external code. Those security issues can be reduced with a sandboxed environment like a WA runtime. On the…

No need to recompile means you can run the same, guaranteed known, signed, etc code everywhere. Purpose-built sandboxing means you can run untrusted code more safely — e.g. at the network edge, like a Cloudflare worker, a lambda, etc. Same for third-party plugins in apps, etc. An open standard and open implementations gives you some assurance against lock-in, licensing changes, patent suits, etc.

All of it already exists with the JVM.

Re: Wasmer 1.0

#104

Post by dagmx »

reader_mode wrote: post #14
nynx wrote: post #12

Earlier quoted context omitted.

While it's probably true that a full gui ecosystem could be built on top of wasi+webgpu+windowing, it would mean that programs would often reinvent the wheel. Perhaps that's not a bad thing. Speaking of moving complexity into sandboxed code, browsers could potentially run js engines inside the wasm vm, reducing a lot of complexity there.

>While it's probably true that a full gui ecosystem could be built on top of wasi+webgpu+windowing, it would mean that programs would often reinvent the wheel. You can compile existing GUI libraries you just need to port the rendering backend and input. Flutter, Qt, GTK, etc.

For example, Qt already has a port to wasm

Re: Wasmer 1.0

#105

Post by pjmlp »

anderspitman wrote: post #22
hctaw wrote: post #16

Earlier quoted context omitted.

The issue I see is we don't need a sandbox at all for this, we need capability based security models for applications provided by the OS vendors (like iOS, Android). Apple has taken the right steps towards such a model, yet get lambasted by developers for it. We have flatpaks and snaps for Linux, the former isn't really targeted by many and the latter is similarly lambasted by users and developers. I don't even know…

IMO iOS and Android are terrible examples of how to do this. They break decades of convention in how to write POSIX-like applications, and force developers into locked-in practices. Android gives lip service to the NDK, but in practice you can't really run many useful C/C++/Golang/Rust/etc programs on Android, because the system breaks POSIX. You can't keep a simple webserver running without starting a foreground ser…

Android is quite clear why NDK exists:

https://developer.android.com/ndk/guides

> Squeeze extra performance out of a device to achieve low latency or run computationally intensive applications, such as games or physics simulations.

> Reuse your own or other developers' C or C++ libraries.

Writing POSIX CLI applications is not a goal.

ISO C and ISO C++, alongside OpenGL ES, Vulkan and OpenSL are more than enough to have something like Qt running.

Re: Wasmer 1.0

#106

Post by higerordermap »

robbywashere_ wrote: post #91

'For everyone asking, but why use a browser technology server side? Just run a binary' or 'Whats old is new again, java etc' - I am sure you've heard of a browser technology that is used server side, javascript, ever hear of nodejs? The rise of javascript and its server side runtime is due to the immense pressure that language had to evolve to make the web what it is today. Web-assembly is the next step and evolution…

> offer the functionality it has today while balancing with security and sandboxing.

LoL, LoL, LoL

You can say this only because every other operating system sucks at sandboxing.

There is no reason you have to be inefficient as browser to provide security and sandboxing. In return there is also a huge attack surface, with all the code running below, and corner cases in web standards. AFAIK any js click event can allow a website to read your clipboard. Websites can somehow prompt to add extensions to your browser etc.. I know there are legitimate reasons for this but it sandboxing is not exclusive virtue of web platform.

Re: Wasmer 1.0

#107

Post by higerordermap »

apitman wrote: post #2

Browsers are not the right tool for sandboxing applications. I don't think it was a mistake, but it's time to take what we've learned and move to the next level. With a bytecode like wasm, you can create an "app runner" program that's at least an order of magnitude less complicated than current browsers. Just ship apps as wasm binaries with a simple interface (maybe WASI, haven't taken the time to dig into it yet) fo…

A JIT is just more attack surface. Change my mind.

Re: Wasmer 1.0

#109

Post by pjmlp »

vijaybritto wrote: post #89
_TA_12_ wrote: post #88

>> We believe that WebAssembly will be a crucial component for the future of software execution and containerization (not only inside the browser but also outside). Why? I don't get that or maybe miss some crucial parts or maybe it's just a too enthusiastic statement. I understand the security issues of running external code. Those security issues can be reduced with a sandboxed environment like a WA runtime. On the…

I see the main advantage in this as running a polyglot application as if its native. For example if you are making a Rust application, you can have a plugin architecture where the plugins run inside a wasm compiled python interpreter. I dont know if doing this directly and cross platform is as easy without wasmer

Just like CLR, JVM and GraalVM, nothing new besides WebAssembly marketing.

Re: Wasmer 1.0

#110

Post by epse »

CyberRabbi wrote: post #95
robbywashere_ wrote: post #91

'For everyone asking, but why use a browser technology server side? Just run a binary' or 'Whats old is new again, java etc' - I am sure you've heard of a browser technology that is used server side, javascript, ever hear of nodejs? The rise of javascript and its server side runtime is due to the immense pressure that language had to evolve to make the web what it is today. Web-assembly is the next step and evolution…

You don’t need webassembly to run JavaScript on the server side. You don’t need webassembly to run C++ on the server side. You don’t need webassembly to run Rust on the server side. Etc. Node was necessary because you need node (or compatible) to run JavaScript on the server side.

But it helps when running untrusted code, or code that has to be separated (like what you would use containers for)
Post reply on HN