I hope the situation gets better for Firefox.

How does this compare to the c2w container2wasm approach?

container2wasm/container2wasm: https://github.com/container2wasm/container2wasm :

> container2wasm is a container-to-wasm image converter that enables to run the container on WASM.

> Converts a container to WASM with emulation by Bochs (for x86_64 containers), TinyEMU (for riscv64 containers) and QEMU.

> Runs on WASI runtimes (e.g. wasmtime, wamr, wasmer, wasmedge, wazero)

> Runs on browser

> x86_64, riscv64 or AArch64 containers are recommended.

/? container2wasm: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

ktock/vscode-container-wasm https://github.com/ktock/vscode-container-wasm :

> Containers on VSCode for the Web [ https://vscode.dev ]

ktock/vscode-container-wasm-gcc-example: https://github.com/ktock/vscode-container-wasm-gcc-example

JupyterLite works without install on Chromebooks.

JupyterLite still lacks a Terminal e.g. with BusyBox Ash in WASM, with a file system integrated with the Jupyter-xeus kernel file system.

This appears to load much more quickly than other Linux and I think even just bash in WASM demos I've seen.

That requires an ISA emulation layer, this new implementation doesn't - here, every binary is compiled as wasm, and every child process runs as a new Wasm WebWorker, and the Kernel ABI is exposed as Wasm export functions.

Removing the ISA translation layer has the potential to be massively faster for full-system environments. At the expense of maybe some new bugs.

The performance should ultimately be similar to compiling your userspace application directly as Wasm, but you now get to take advantage of the full kernel ABI instead of just the minimal shims that Emscripten give you / whatever DOM glue you create yourself.

One less layer of translation!

Shouldn't browser tabs and/or origins get their own SELinux contexts like all Android apps since Android 4.4, like container-selinux and openshift's k8s? https://news.ycombinator.com/item?id=45418918#45421242

uutils/coreutils, findutils, diffutils, and Toybox are written in Rust which IIRC has a cleaner compile to WASM: https://news.ycombinator.com/item?id=45495100

RustPython may for may not also have a faster loading time than CPython compiled to WASM, though there are already some patches to CPython for WASM.

Where are the tests for the post-patch bugs this finds? Are they're expected behaviors that are not yet in tests which specify?