WANIX: A WebAssembly Operating and Development Environment by Jeff Lindsay & Julian Del Signore
Vložit
- čas přidán 22. 04. 2024
- Wasm I/O 2024 / 14-15 March 2024
WANIX takes WebAssembly to the next level. Edit, compile, and run WebAssembly from a WebAssembly UNIX-like environment entirely in the browser. Written in and using Go as a runtime, WANIX draws from Genera and Plan9 to provide a local-first operating and development environment of the future.
-
This is the story of a WebAssembly native operating system and integrated development environment called WANIX. From a wild idea at a hacker party to a fully realized open source project, WANIX opens up a world of mind expanding possibilities only possible because of WebAssembly.
It started with the realization that Go’s self-hosting cross-platform compiler could itself be compiled to WebAssembly, creating a pure WebAssembly way to not only make more WebAssembly modules, but executables for any platform. Then, inspired by the beginnings of UNIX and ideas from Genera and Plan9 operating systems, only a few more elements were needed to create a familiar, UNIX-like computing environment that could edit, compile, and run WebAssembly; a foundation to bootstrap much more.
WANIX features a web worker based process model, a programmable filesystem exposed back to the browser via a service worker, a shell that can be modified and recompiled live or switched out with another, a compiler that can build native executables or executables for your host platform, a terminal emulator for command-line and TUI apps, and an iframe based system for web applications.
This 30 minute talk is jam-packed with not only how WANIX was made by veteran software hacker Jeff Lindsay, but, more importantly, where we can go from here. - Věda a technologie
Supporting WASI would be rad
Agreed! It's on the roadmap. The tricky bit is that the current version of WASI is synchronous, so the only way to integrate it with WANIX or anything that isn't running in the same worker is to use SharedArrayBuffer, which adds complexity and extra security constraints. That said I have a prototype of the mechanisms needed, so it's possible even before WASI 0.3 (I think) introduces async. Would love people with motivated use cases to help us prioritize it though.
This is next level
This is really cool stuff. I am having a tiny bit of trouble seeing the use case but I think thats just because its early. The tech here though is epic.
I love wasm
Cool presentation!
Pretty rad!
awesome. Mozart's Ghost! The hottest band on the internet!
Can we get the slides?
Guys, please reduce the volume of the intro! Otherwise cool presentation, thanks!
Fuckin hell.
Not WAOS :( xP
Really cool BUT if you are starting from scratch and want to take inspiration from stuff like smalltalk, why not listen to Alen Kay and not try to repeat the same 50 years old Unix design?
Thanks! Yes, there is plenty we could leave behind. However, I've noticed that without grounding in something familiar, you can make something too "out there" to be practical/compatible/understandable. Also, instead of Unix/Linux, I'm pulling more from Plan 9, which had great refinements of Unix ideas that have not totally made their way outside of that research context. I think the real trick, though, is taking this familiar paradigm and pushing into being something that is actually totally new without you realizing. We'll see how it plays out. Hope you'll be following along!
That's....really boring! It's just another iteration of "the thing we could already do, but in the browser." Jeff even says, "there are no VMs", and then has to clarify, "just WASM"(a VM). Then they share the screens and do the CRDT thing and he goes, "it's like we both SSH'd into a shared server, except there's no server!" But there IS a server - it's the one that's exposed by the service worker! Huh, yeah, it's almost as if we should go back and fix the UX around the actual OS instead of doing whatever this is.