Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • The Gary Bernhardt prophecy is still alive.

    (https://www.destroyallsoftware.com/talks/the-birth-and-death...)

    by littlestymaar
  • Very cool! I'm curious as to how it compares with WASIX in terms of both compatibility and performance.

    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.

    by seanw265
  • This is crazy cool. 8,000 CPUs. I wonder if any types of programs would ever make 10k tasks in their normal runtime behavior.

    "One important difference is that there is no way to suspend execution of a task. There is a way around this though: Linux supports up to 8k CPUs (or possibly more...). We can just spin up a new CPU dedicated to each user task (process/thread) and never preempt it. Each task is backed by a Web Worker, which is in practice backed by a thread in the host OS (through the WebAssembly implementation). "

    by koolala
  • Really impressive work. Would love to see it progress.

    Some ways I can see it could improve:

      1. setjmp/longjmp could implemented via Wasm Exceptions (this is how we do it on WASIX) - no need to wait on stack switching proposal
  2. fork could work easily with asyncify (start/resume), per binary compiled
  3. JIT could work via dlopen/dlsym (compiling the Wasm and linking it), even with runtime patching (using memory spaces on tables and updating them as you go to newly compiled code).
    In general, I recommend taking an inspiration from WASIX [1] for those things, as we have spend quite a bit of time to make things work as much as possible!

    [1] https://wasix.org/

    by syrusakbary
  • 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.

    by westurner
  • This is cool because it avoids emulation. However I think it has many shortcomings today which could all be solved by emulating a real CPU architecture (e.g memory protection support, ecosystem with tooling and Linux distributions).

    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.

    by edubart
  • Tried running:

      ~ # 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!

    by lalitmaganti
  • That’s fast. Buggy, but fast. I’m totally impressed! Especially because I researched the necessary steps to do the same thing 10 years ago based on [0]. The patches required for this hack touch LLVM, libc, Linux kernel, BusyBox, ... and total approximately 15,000 lines of code.

    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.

    [0] https://github.com/s-macke/jor1k

    by s-macke

Explore Birbla archives