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

WASI 0.2.0 and Why It Matters

wasmcloud.com

Post reply on HN
Print view View original

41–50 of 110 posts

Re: WASI 0.2.0 and Why It Matters

#41

Post by flohofwoe »

callahad wrote: post #38
mc_woods wrote: post #16

Earlier quoted context omitted.

The WebAssembly standard breaks into two parts, "core WASM" which is the spec the browsers use and everyone else. Then in the non-browser space there is WASI (system interface specification). The WASI-Preview 2 standard uses component model as the underlying mechanism for implementing the APIs it supports. It is not compatible with existing WASI functions... you need to change your binary with an adapter to get exist…

For folks looking to learn more, the Component Model documentation is pretty good! I like this excerpt for explaining the core vs component split: > components interact only through the Canonical ABI. Specifically, unlike core modules, components may not export Wasm memory. This not only reinforces sandboxing, but enables interoperation between languages that make different assumptions about memory - for example, all…

Hopefully it's trivial to push C structs around by value if poking around in other instances memory isn't allowed. Otherwise it sounds like a lot of hassle just to appease "fringe languages" ( ;P ) that don't have a linear memory model. This sort of "directly reading and writing the WASM heap" is quite essential for JS code that sits between a WASM instance and a web API for instance (in the "WASM in browsers" scenario).

...for instance how do you share large amounts of data between components then, there must be some sort of cheap way to safely share portions of memory between components right? Because there are situations where multiple copy steps are simply out of question.

Re: WASI 0.2.0 and Why It Matters

#42

Post by ptx »

ryukafalz wrote: post #34
pjmlp wrote: post #22

Earlier quoted context omitted.

Presenting as if it was the first done anyone has done any of this, UNCOL was the first time such ideas came to be, in 1958. Plenty of historical attempts to dive into, since 1958. Now we have startups redoing Java and .NET application servers, with Kubernetes, WebAssembly, WASI, and YAML spaghetti, because that is so much better. Edge devices running bytecode? That is so last century.

You're right that the fundamental ideas behind WebAssembly and WASI are not particularly new. The most exciting part about WASI for me, though, is that it's sticking to a capability-based interface and it's actually gaining a lot of traction. There are few examples of capability systems getting as much attention as this.

Do you have any pointers to more in-depth comparisons to Java's security model and some analysis of why wasm should work better?

Is the idea mainly that permissions are more fine-grained? It probably makes porting existing applications tricky, though, right?

Re: WASI 0.2.0 and Why It Matters

#44

Post by ramses0 »

PedroBatista wrote: post #6

About Wasm and WASI, I'll try ( and probably fail ) to escape the HN stereotype so please forgive me. I've been more of less following this for a decade ( since asm.js ), I still fail to see a practical use for this. And I mean a generalized use in real products and systems that stand the test of being an actual economically viable product, not cool demos which running Doom is probably the best one from a technical p…

So..... think of it this way:

HTML was built for the "internet", but works just as well for plain local files (eg: file:///one.html => file:///two.html).

JS was added to HTML, and much gnashing of teeth ensued.

JS (minified), HTML (generated), CSS (compiled), Flash, Java Applets, etc... move away from the "original" internet (Hyper-Text DOCUMENTS) into Web2.0 "Apps" and Web3.0 "Walled Gardens".

What if instead of shipping `my_application.html`, we could ship `my_application.exe`, and "break free" of needing the UI's being written in HTML, JS, CSS, etc.

What some of this WASM/WASI/etc... seems to be trending towards is building up enough of a foundation amongst interoperable _CLIENTS_ that have ZERO dependency on HTML, JS, CSS, and instead you get much closer to:

    curl 'https://example.com/one.html'
       => curl 'wasm://example.com/one.app'
...to the extent that "the internet" has hit a complexity wall of what's possible (manageable, maintainable) with HTML+JS+CSS, the people tackling WASM seem to be saying:

Forget trying to coerce a buggy browser into running my `for ...` loops (and rendering my graphics) correctly, and you can't realistically decompile or hand-edit the HTML+JS+CSS for 99.9% of the stuff your browser is rendering... how can we _skip_ the HTML,JS,CSS and get directly at "the VM" and run what we actually want.

Secondarily (but importantly, and interestingly): How can we make 'webapp.wasm.exe' support everything that a "native" app would need (eg: GL, GPU, Bluetooth, Local Files, USB devices, Camera, Sensors, etc...)

There's likely mega-trillions (no exaggeration!) of effort that's been poured into tooling for "the internet", what is the unifying effort/effect that would unlock that for local app development? How can I get `msword.exe` to run "on the internet" for free? How can I get `make clean ; make install ; make wasm` working for any internet connected client?

As a thought experiment, we're almost there! We could technically have `win95.img + bochs86vm.wasm + autorun.inf + msword.exe` wrapped in a "browser evaluator" that could conceivably run `msword.exe` transparently to the user, but still allow you to use `msword.exe` indistinguishably from the "original" native app (bridging the local filesystem, exposing virtual devices, etc).

See also https://www.destroyallsoftware.com/talks/the-birth-and-death... ... circa a decade(!) ago!

Re: WASI 0.2.0 and Why It Matters

#45

Post by dom96 »

andoband wrote: post #43

Another good write-up which gives more context to this release, and it touches on POSIX in relation to the component model. https://blog.sunfishcode.online/wasi-preview2/

Thanks for sharing. I often wondered why we didn’t just create a subset of POSIX for the web and wasm, this seems to answer my questions.

Re: WASI 0.2.0 and Why It Matters

#46

Post by elviejo »

dom96 wrote: post #45
andoband wrote: post #43

Another good write-up which gives more context to this release, and it touches on POSIX in relation to the component model. https://blog.sunfishcode.online/wasi-preview2/

Thanks for sharing. I often wondered why we didn’t just create a subset of POSIX for the web and wasm, this seems to answer my questions.

Other team ask themselves that question and created WASIX. I'm looking into it.

Because to me it seems only logical, to have POSIX that can work on the web.

Re: WASI 0.2.0 and Why It Matters

#47

Post by 6gvONxR4sf7o »

I really want polyglot programming to become easier. What are the barriers remaining for wasm/wasi to provide a foundation for a truly polyglot FFI? It seems like it was the promise from the beginning, but I lost track a long time ago.

Re: WASI 0.2.0 and Why It Matters

#48

Post by elviejo »

PedroBatista wrote: post #6

About Wasm and WASI, I'll try ( and probably fail ) to escape the HN stereotype so please forgive me. I've been more of less following this for a decade ( since asm.js ), I still fail to see a practical use for this. And I mean a generalized use in real products and systems that stand the test of being an actual economically viable product, not cool demos which running Doom is probably the best one from a technical p…

I'm in the same boat. I've been looking at this space since (P)NaCL With a nagging question in my mind:

What does this do that we couldn't do with Java Applets? So far the response is very few things and a lot less. On the few things that it does differently is: + it focus on multi language support. as opposed to the JVM which was focused in getting all of us in writing Java. Here they want to actually use different languages to write webapps. - Although Rust is the favorite (As is C# in the .net) + It has a clear mechanism to communicate with Javascript and therefore the web. + timing bandwidth is now big enough to make this apps seem practical. + it is done by a coallition of vedors (as opposed to java that was only Sun's baby).

Very minor advantages in my opinion... but well I also think that lip's s-expressions are better than json, xml and yaml. and the world has thought differently every single time.

Re: WASI 0.2.0 and Why It Matters

#49

Post by G4Vi »

PedroBatista wrote: post #6

About Wasm and WASI, I'll try ( and probably fail ) to escape the HN stereotype so please forgive me. I've been more of less following this for a decade ( since asm.js ), I still fail to see a practical use for this. And I mean a generalized use in real products and systems that stand the test of being an actual economically viable product, not cool demos which running Doom is probably the best one from a technical p…

On the devx, there's definitely some rough edges around building and using Wasm. My company has been working on a framework to ease integrating Wasm into existing applications. One area it focuses on is providing easy data passing between the host program and the Wasm and vice versa. https://github.com/extism/extism We do not have WASI preview 2 support yet, but are interested in integrating it.

Re: WASI 0.2.0 and Why It Matters

#50

Post by boomskats »

callahad wrote: post #38
mc_woods wrote: post #16

Earlier quoted context omitted.

The WebAssembly standard breaks into two parts, "core WASM" which is the spec the browsers use and everyone else. Then in the non-browser space there is WASI (system interface specification). The WASI-Preview 2 standard uses component model as the underlying mechanism for implementing the APIs it supports. It is not compatible with existing WASI functions... you need to change your binary with an adapter to get exist…

For folks looking to learn more, the Component Model documentation is pretty good! I like this excerpt for explaining the core vs component split: > components interact only through the Canonical ABI. Specifically, unlike core modules, components may not export Wasm memory. This not only reinforces sandboxing, but enables interoperation between languages that make different assumptions about memory - for example, all…

I thought this keynote presentation[0] by Luke Wagner at Wasmcon was great and covered it very well. I also found the WIT Format design doc[1] in the component model repo to be the most complete explanation of how it's all going to hang together.

[0]: https://www.youtube.com/watch?v=tAACYA1Mwv4 [1]: https://github.com/WebAssembly/component-model/blob/main/des...

Post reply on HN