v0.3-preview

[progrium]

The Spirit of Plan 9 in Wasm

• 📺 Demo Video: Shows all the below and more, plus background
• ✨ Interactive Demo: Live deployment of default Wanix environment in the browser

This is a preview release for v0.3 which is a major rewrite and redesign inspired by Plan 9. This release is incompatible with v0.2 and many of its features are not yet available on this new platform. Instead, this release focuses on these new features as a foundation for the future:

Plan 9 inspired design

With the original intention to allow exploring Plan 9 ideas on modern platforms, we've ended up with a radically simple architecture around per-process namespaces composed of file service capabilities using similar design patterns to those found in Plan 9.

Single executable toolchain

The wanix executable includes everything needed to produce Wanix environments.

Filesystem is the only API

The Wanix microkernel is now simply a VFS module with several built-in file services exposed via a standard filesystem API. This ends up making the module itself a file service.

Built-in Linux shell

Using the built-in file service primitives, Wanix can bootstrap a Linux-compatible shell based on Busybox. It comes with several helper commands for working with built-in file services.

Tasks and namespaces

The Wanix unit of compute is a task, which is equivalent and compatible with POSIX processes but allows for different execution strategies. Each task has its own "namespace," which is the customizable filesystem exposed to the task.

Core file services

Wanix includes two singleton file services: one to manage tasks (similar to procfs), and one to manage "capabilities" which are user allocated file services. Built-in capabilities include: tarfs, tmpfs, and loopback.

Web module

With future non-browser deployments in mind, all web related file services are packaged in a web module, which is also built-in but not considered core. This module includes these work-in-progress file services:

• opfs: For working with the OPFS browser storage API
• dom: For inspecting and manipulating the DOM
• worker: For managing web workers
• pickerfs: Capability wrapping the window.showDirectoryPicker() method (not available yet in Safari and Firefox)
• ws: Capability for working with WebSocket connections
• sw: For configuring the service worker, which is used by the system now to cache all resources needed to run Wanix allowing offline usage, as well as exposing virtual URLs to the root namespace.

Filesystem toolkit for Go

The Wanix VFS and file services are built around a general purpose Go package for building and working with filesystems based on the io/fs package and API of the standard library. This package can be used entirely independent of Wanix for building FUSE filesystems and network file servers (9P, etc).

Be sure to watch the demo video linked above for background and example usage. We're working on documenting the roadmap to v0.3 in this milestone. Special thanks to @taramk and @jpf!

Full Changelog: https://github.com/tractordev/wanix/commits/v0.3-preview

---

This discussion was created from the release v0.3-preview.

[joeblew999]

Congrats all.

do the File interfaces for OPFS, DOM, web workers, and service workers also work on OS level like Windows, Darwin, FreeBSD ?

I ask because I need a cross platform system that does mkdir, cp, mv, etc etc . Would make a simple file explorer demo that runs on backend ( as cli ) and in browser ( as WASM ) with file sync and diff between them . Seems like a useful tool for the project , but also a building block as diff , merge, patch on text files is useful for larger projects that I can imagine wanix is designed for .

The exact same charm bracelet TUI on the backend would be running in the frontend, providing interactivity .

[progrium]

Not sure I understand. The web file services can only make sense when run in a browser/webview, right? You could implement a file service with the same "shape" that does something different, but what would the DOM file service do without a DOM? When you say "system that does mkdir, cp, mv, etc" do you mean file system operations or the shell commands? Do you really need file sync or just remote access (maybe dropbox vs NFS)?

[joeblew999]

Hey @progrium

I just need a main.go that has file system operations inside it that is cross platform for desktops and servers. I can extend from there to do differential sync .

Nothing to do with web or dom .

Sorry if I muddied the waters . I was projecting .

[progrium]

Okay. Maybe you're asking about the filesystem toolkit? Otherwise maybe you should reach out in Discord.

https://github.com/tractordev/wanix/tree/main/fs

[joeblew999]

Yes I am asking about it .

https://github.com/tractordev/wanix/tree/main/fs

I will write some sample code and see if it works cross platform .

the plan9 thing is clever

am working on a plan9 plumber .

https://9fans.github.io/plan9port/man/man4/plumber.html