v0.3

Bundles and Builds

While v0.3-preview brought a full rewrite and introduced a new foundation inspired by Plan 9, this release is a refinement of that preview release. We put a lot of effort into the build process to improve the initial contributor experience and our release process. We now have GitHub Actions creating release-ready artifacts with every push. We are also introducing Wanix bundles, bug fixes, and much more.

Wanix Bundles

Wanix bundles are what the Wanix runtime runs. They let you define a Wanix environment for a particular purpose. A Wanix bundle is a tarball of files made available to Wanix via a #bundle kernel device. They can contain one or more filesystem images, Wasm/WASI executables, an initialization script, and optionally their own build of the Wanix Wasm runtime module. In future releases they'll be able to contain the v86 files and Linux kernel, making the runtime smaller and x86 emulation truly optional.

The Wanix shell seen in the v0.3-preview demo is now a bundle. There is another experimental bundle under hack for an Alpine environment with networking/internet support. Another extremely minimal bundle can be found in the WASI Golang test program (test/wasi/golang). It just contains the Wasm and an init script to run it, wiring its stdout to the new console device. Here is an abbreviated version of this init script, which also shows newly added stream APIs:

const w = window.wanix.instance;        
const tid = (await w.readText("task/new/wasi")).trim();
await w.writeFile(`task/${tid}/cmd`, "#bundle/golangcheck.wasm");
const stdout = await w.openReadable(`task/${tid}/fd/1`);
const cons = await w.openWritable(`#console/data1`);
await w.writeFile(`task/${tid}/ctl`, "start");
stdout.pipeTo(cons);

Bundles and their init scripts are still very loosely defined and are expected to evolve over the next releases.

New Makefile

The CONTRIBUTING doc has been updated on how to use our new Makefile, which now prints its own help. Running make alone will return a list of task targets and descriptions:

all                 Build dependencies and Wanix 
build               Build Wanix (command and runtime) 
build-docker        Build Wanix (command and runtime) using Docker 
clean               Remove Wanix runtime and command artifacts 
clobber             Remove all built artifacts 
cmd                 Build Wanix command 
cmd-docker          Build Wanix command using Docker 
deps                Build Linux kernel, v86 emulator, and shell 
deps-clean          Remove dependency artifacts 
deps-linux          Build Linux kernel (in Docker) 
deps-shell          Build shell for Wanix (in Docker) 
deps-v86            Build v86 emulator (in Docker) 
dist                Build distribution binaries 
link                Link/install the local Wanix command 
runtime             Build WASM and JS modules 
runtime-docker      Build WASM and JS modules using Docker 
runtime-js          Build JavaScript module (in Docker) 
runtime-wasm        Build WASM module 
wasm-go             Build WASM module using Go 
wasm-tinygo         Build WASM module using TinyGo

This should also give a sense of the various components involved in Wanix now. Notably, we've consolidated the Wasm module and all JavaScript into what we call the Wanix runtime. This is what you'd include on a web page to run Wanix. This runtime is embedded in the Wanix command (aka Wanix CLI), which acts as a toolchain for developing and working with Wanix and Wanix bundles.

As usual, we'd love your help with the next release, so if you're interested, take a look at this list of potential good first issues as well as our 0.4 sprint roadmap. Definitely join the Discord either way!

Bug Fixes

• Fixed v86 build by updating patches and pinning #189
• Fixed TinyGo support #190 #211 #171
• Fixed rename for OPFS #181 #179
• Fixed Golang wasip1 support #187

Improved Contributor Experience and CI #191

• Self documenting, configurable Makefile
• Zero config Podman support
• Automatic TinyGo use if detected
• Symlink PATH strategy for command builds
• Entire command and runtime can build in container
• CI: Faster/simpler caching strategy for Linux, v86, and shell deps
• CI: Run all deps and runtime builds in parallel
• CI: Build cross platform, signed command binaries with every push

Introduced Bundles #207

• Loaded bundle is available as #bundle kernel device
• JavaScript runtime will load Wasm from bundle if available
• Shell is now just a default bundle, not hardcoded
• Experimental Alpine bundle with network/internet support

Changes to Wanix command / CLI

• Embeds both Go and TinyGo Wasm builds, picking at runtime #213
• wanix bundle commands added to manage bundles #194
• wanix console and wanix mount experimental commands disabled and moved to hack dir
• wanix serve serves current directory with Wanix files overlayed
• wanix export writes to a dir instead of outputting tar, but is also now deprecated

Changes to API

• runtime: add openReadable and openWritable methods to use JS stream APIs
• runtime: add readText convenience method to decode file bytes into a string
• runtime: add showScreen, hideScreen console helpers
• fskit: add StreamFile and FileFS helpers
• vfs: replace string mode argument with BindMode enum in Bind
• vfs: add BindAllocator interface and use it for Bind
• pipe: add pipe package to replace internal.BufferedPipe and various one-offs
• fs: add IdentityFile interface, Identity and SameFile helpers
• fs: add AppendFile helper

Other Changes

• Added #pipe and #console kernel devices #214
• Service worker made optional, disabled by default #208
• Added Linux kernel support for containers #199
• Deployed all changes to wanix.run

New Contributors

• @ivanov made their first contribution in #189

Thank you to everybody that contributed beyond code as well!

Full Changelog: v0.3-preview...v0.3

v0.3-preview

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 file services

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

v0.2

Deploy WANIX on your domain

This is a big release! You can now deploy WANIX to your own domain using GitHub Pages via our new CLI tool. You can also deploy with authentication using Auth0, which when combined with our new GitHub Filesystem, allows you to use the WANIX environment to modify the site itself by directly manipulating files in the mounted GitHub Pages branch of your repository. Out of the box that means you can use the micro editor or the built-in explorer app to modify your site from the site itself. We also support a build of Hugo, so you could even generate your static site from your static site. Of course, you can build your own editor/admin/tools as well since WANIX is also a full development environment.

🎬 Demo from Wasm I/O 2024

Big thanks to @Parzival-3141 for his contributions in this release.

Quickstart

You can now use this helper to install the latest version of wanix:

bash -c "$(curl -sSL https://raw.githubusercontent.com/tractordev/wanix/main/install.sh)"

Grab a domain and point it at GitHub Pages, then you can run:

wanix deploy yourdomain.com

Running locally currently still requires cloning this repository, but then all it takes is:

wanix dev

More Changes

• Hugo support by @Parzival-3141 in #111
• GitHub Filesystem by @Parzival-3141 in #105
• shell: add get command by @Parzival-3141 in #114
• micro: accept relative file paths by @Parzival-3141 in #132
• hugo: change default options to support githubfs by @Parzival-3141 in #142
• Create faq.md by @taramk in #139
• New CLI and bootdata system by @progrium in #143

New Contributors

• @taramk made their first contribution in #139

Full Changelog: v0.1...v0.2

v0.1

With the first development release, we have a first pass at the core architecture of Wanix with a kernel supporting a pluggable filesystem and Web Worker based process model for Wanix compatible WASM executables. It also includes a version of the Go compiler, an editor, and a shell. It also supports web apps in the environment with built-in support for TypeScript, JSX, live-reloading, and access to the Wanix filesystem through a Service Worker.

New Contributors

• @Parzival-3141 made their first contribution in #8
• @progrium made their first contribution in #11
• @lalyos made their first contribution in #21
• @catilac made their first contribution in #58
• @robby-robby made their first contribution in #91

Full Changelog: https://github.com/tractordev/wanix/commits/v0.1