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

61–70 of 168 posts

Re: Wasmer 1.0

#61

Post by [deleted] »

modeless wrote: post #54
amelius wrote: post #11

Earlier quoted context omitted.

All the things you mention could be available as a shared library, to be run inside the sandbox along with the application. Let's keep the sandbox as simple as possible. We can build complexity inside it, and not make complexity part of it. This makes security guarantees much simpler.

I like this vision of shared libraries sandboxed inside a minimal runtime to replace the browser. But there are some serious problems with it (that I hope can be resolved somehow). Replicating a significant fraction of the functionality of a browser ends up being a lot of code and data. For a web-like experience with instant navigation between apps it will be necessary for these shared libraries to be really shared,…

[deleted]

Re: Wasmer 1.0

#62

Post by dmitriid »

coolreader18 wrote: post #46
dmitriid wrote: post #41

How is it "production-ready" anything if WebAssembly itself isn't even out of MVP stage yet?

Because the "MVP" stage is itself production ready, which is why it was stabilized in browsers 3 years ago. Also, some non-MVP features are almost stable, e.g. atomics are now enabled on chrome by default IIRC. WASI, the posix-like system interface ABI, is still technically a "snapshot", which has made me slightly concerned wrt stability given that Rust can compile to WASI even on the stable channel, but hopefully ev…

> Because the "MVP" stage is itself production ready

> some non-MVP features are almost stable

> the posix-like system interface ABI, is still technically a "snapshot"

So... It's not production ready.

Re: Wasmer 1.0

#63

Post by kthxb »

dmitriid wrote: post #62
coolreader18 wrote: post #46

Earlier quoted context omitted.

Because the "MVP" stage is itself production ready, which is why it was stabilized in browsers 3 years ago. Also, some non-MVP features are almost stable, e.g. atomics are now enabled on chrome by default IIRC. WASI, the posix-like system interface ABI, is still technically a "snapshot", which has made me slightly concerned wrt stability given that Rust can compile to WASI even on the stable channel, but hopefully ev…

> Because the "MVP" stage is itself production ready > some non-MVP features are almost stable > the posix-like system interface ABI, is still technically a "snapshot" So... It's not production ready.

WebAssembly's MVP release was primarily targeted at the ... web. It is production ready in all (vital) aspects concerning execution in a browser.

Re: Wasmer 1.0

#64

Post by skybrian »

Ajedi32 wrote: post #21
skybrian wrote: post #8

Earlier quoted context omitted.

It depends on what kind of application you mean. Headless servers doing basic file and network I/O are pretty reasonable to sandbox. This is what Docker does. But GUI applications are a whole different thing. The standards simply don't exist to make that easy. It's not just basic graphics. Things like internationalized text rendering, text input, and accessibility are ridiculously hard and only a few mostly-complete…

Indeed; the web provides far more than just a standardized, sandboxed, cross-platform runtime with multiple independent implementations. There are also lots of higher-level components which benefit from standardization. Text rendering and input are just the tip of the iceberg. For example: navigation (back, forward, refresh, etc), URLs, permission management, text search, image/video rendering, scrolling, credential…

I think Flutter is getting there. That's at least open source, thought not an open standard.

Re: Wasmer 1.0

#65

Post by brundolf »

dmitriid wrote: post #60
brundolf wrote: post #48

Earlier quoted context omitted.

You're talking purely about performance. Sure, you can do whatever you want in a game UI, and it will probably outperform a web UI. But there's a reason game UIs often scale/function badly as soon as you change the screen size or the input type: they aren't built on a platform that has flexibility baked into its bones. In many cases they aren't build on any kind of platform at all. They often have element/text positi…

> You're talking purely about performance. Not just about performance. > Sure, you can do whatever you want in a game UI, and it will probably outperform a web UI. Not probably, but definitely > But there's a reason game UIs often scale/function badly as soon as you change the screen size or the input type: they aren't built on a platform that has flexibility baked into its bones. Yeah, no. Games have had UI scaling…

> Games have had UI scaling since monitors got more resolutions than 640x480

Scaling is different from resizing. Maybe it was my fault for using the wrong word.

Have you ever tried to play an old game on a widescreen monitor? Even a lot of modern, triple-A games have weird HUD layouts on ultrawide monitors because they have to be re-hard-coded for that aspect ratio. So if they haven't, you just get the layout they're hardcoded to for widescreen monitors.

I'm not saying it would make sense to trade performance for robustness in the case of games specifically, because they're always going to be full-screen and usually target one of only a handful of aspect-ratios (at least for consoles and PC; mobile may be a different story). I'm just saying they definitely get to skip a whole lot of hard problem-solving due to the constraints of the end product.

I don't have time to read more than the first part of your reply right now; maybe I will later.

Re: Wasmer 1.0

#66

Post by johncolanduoni »

phkahler wrote: post #59
remexre wrote: post #32

Earlier quoted context omitted.

I think proper sandboxing on a traditional Unix is hard enough that ~nobody does it right; you can't let any apps run as the user if you want to prevent them from snooping on each others' files, but the user needs to be able to control all of them. I don't know of a justification for removing /etc/resolv.conf, but I guess "applications' networking should be under the control of the user" is sorta necessary; I think i…

>> you can't let any apps run as the user if you want to prevent them from snooping on each others' files, but the user needs to be able to control all of them. I was thinking about that recently and my conclusion will be highly controversial. In the same way Wayland implements security that X never could, I think the GUI might be a place to implement file and folder access permissions. If the user does not grant acc…

This is mostly how the Mac sandbox handles file access actually, by going through blessed, OS-controlled file access dialogs. They call it “Powerbox”: https://developer.apple.com/library/archive/documentation/Se...

IIRC flatpak has something similar too, though I believe it’s opt-in for the apps.

Re: Wasmer 1.0

#67

Post by dmitriid »

kthxb wrote: post #63
dmitriid wrote: post #62

Earlier quoted context omitted.

> Because the "MVP" stage is itself production ready > some non-MVP features are almost stable > the posix-like system interface ABI, is still technically a "snapshot" So... It's not production ready.

WebAssembly's MVP release was primarily targeted at the ... web. It is production ready in all (vital) aspects concerning execution in a browser.

> It is production ready in all (vital) aspects concerning execution in a browser

As in (emphasis mine): "This means that there are important features we know we want and need, but are post-MVP" [1]

As in: "a Minimum Viable Product (MVP) for the standard with roughly the same functionality as asm.js, primarily aimed at C/C++;"

It's good that you specified "vital" when talking about "all" aspects. Where vital is basically "let's run MVP in an isolated sandbox with little-to-no interoperability with the rest of the browser". Because the rest of the vital things like "basically everything" [3] [4] are still MIA.

But yeah, I mean, the modern web was built on a language designed in 10 days, so I shouldn't complain, should I.

[1] https://github.com/WebAssembly/design/blob/master/MVP.md

[2] https://github.com/WebAssembly/design/blob/master/HighLevelG...

[3] https://github.com/WebAssembly/design/blob/master/FutureFeat...

[4] https://github.com/WebAssembly/proposals

Re: Wasmer 1.0

#68

Post by no_way »

dmitriid wrote: post #60
brundolf wrote: post #48

Earlier quoted context omitted.

You're talking purely about performance. Sure, you can do whatever you want in a game UI, and it will probably outperform a web UI. But there's a reason game UIs often scale/function badly as soon as you change the screen size or the input type: they aren't built on a platform that has flexibility baked into its bones. In many cases they aren't build on any kind of platform at all. They often have element/text positi…

> You're talking purely about performance. Not just about performance. > Sure, you can do whatever you want in a game UI, and it will probably outperform a web UI. Not probably, but definitely > But there's a reason game UIs often scale/function badly as soon as you change the screen size or the input type: they aren't built on a platform that has flexibility baked into its bones. Yeah, no. Games have had UI scaling…

People are working on solving built in elements problem on the web including customizability and extensibility. https://open-ui.org/

Re: Wasmer 1.0

#69

Post by canada_dry »

genpfault wrote: post #20

> Wasmer is an open-source runtime for executing WebAssembly on the Server.[1] [1]: https://docs.wasmer.io/

Could someone also ELI5 and give some low-hanging use-cases for this... especially in the IoT space??

Re: Wasmer 1.0

#70

Post by cortesoft »

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…

It seems like your argument is the opposite of the point made in the essay you linked. You say a browser is unnecessary, but the essay says that WASM won because it integrates with the rest of the browser.
Post reply on HN