> I recommend Chromium-based browsers over Firefox, as the latter does not work very well when debugging Wasm projects of this size.
Using Wasm as an end-all system was never the main intention even if we're heading that way now thanks to all the work people has put in.
I'd say that it's probably used where it's made sense so far.
:(){ :|:& };:- Testing a distro or specific software without downloading it
- Educational use (teaching Linux basics on Chromebooks etc)
- Bypassing restrictions on installing certain software
Soon enough, WASM may just well be the #1 platform upon which to run a Linux on a Desktop ..
In the end, it's kinda cool.
I ran a small performance test with 'bc -lq' and compared with [0]:
scale=1000
4*a(1)
This WASM architecture compilation completely blows away my old emulation setup, which only managed around 200 MIPS. Maybe this approach can be generalized.
Running a full Linux distribution at near-native speed right in the browser would be awesome. ~ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: can't create raw socket: Function not implemented
[Runner sh (18823808)]: Wasm crash: RuntimeError: memory access out of bounds
darnThe segfault is unfortunate though
https://github.com/joelseverin/linux-wasm/blob/master/patche...
and it's gone
echo *
cd /proc
echo *
while read line; do echo $line; done < /proc/cpuinfo
The last line should work and print the entire file, but it seems there's a bug.By the way I have developed a similar project, WebCM, a RISC-V emulator capable of running full Alpine Linux that can be embedded in the Web browser and can reach up to 500 MIPS for some users, which I think is pretty fast despite the emulation, you can try at https://edubart.github.io/webcm/. Booting is also fast, it always boots from scratch when you open the page, so you can boot fast even with emulation.
~ # du -h
(...)
[Runner sh (2390656)]: Wasm crash: RuntimeError: operation does not support unaligned accesses
[Main]: Stopping CPU 0
[Main]: Stopping CPU 1
[Main]: Stopping CPU 2
Kernel panic - not syncing: Aiee, killing interrupt handler!
[Runner sh (2390656)]: Kernel panic: Aiee, killing interrupt handle
> Due to a bug in LLVM's build system, building LLVM a second time fails when building runtimes (complaining that clang fails to build a simple test program). A workaround is to build it yet again (it works each other time, i.e. the 1st, 3rd, 5th etc. time).I'm incredibly curious what this bug might be!
Also tangentially related: I'd love to see a performant build of Node.js compatible with this runtime (or really any flavor of WASM), but I think you'd run into the same issues that I have with WASIX. Namely build headaches, JIT, and wasm(-in-wasm) support. I'd explore it myself but I've already sunk way more time than is reasonable on that endeavor.
It seems like OP put together their own musl-based libc which is awesome, but being able to compile against WASI would open up a lot of possibilities.
This also reminds me of the recent thread on user-mode linux -- how easy it would be to compile to WASM was definitely on my mind.
[Runner sh (18815616)]: Wasm crash: RuntimeError: abort
Illegal instruction
westurner•2d ago
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.
mappu•1d ago
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.
westurner•1d ago
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?