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