Show HN: Munal OS: a graphical experimental OS with WASM sandboxing

Original Article ↗ Hacker News Discussion ↗

Overall reception and positioning

  • Thread is strongly positive; many call the project impressive and inspirational.
  • Seen as a bold “bucking of conventional wisdom” and an ambitious unikernel-style client OS, not just a toy.
  • Some want more explicit explanation of motivation, target use cases, and what concrete problems this design aims to solve.

WASM as application platform

  • Enthusiasm for using WASM as the primary app sandbox; some hope future OSes will run WASM natively.
  • Comparisons to earlier bytecode-centric systems (Lisp machines, Smalltalk, Inferno, IBM i, Android, ChromeOS); debate over how novel this really is.
  • Skeptics stress that many bytecode OS ideas have come and gone; supporters argue WASM is unique in being low‑level, portable, and designed for safe native compilation.
  • Discussion of WASI vs alternate ABIs (e.g., Plan 9–like) and WASM components as a way to host many small, composable processes rather than one giant app.

Wasmi vs Wasmtime

  • Author chose wasmi because it builds easily in no_std and as a pure Rust dependency; wasmtime’s dependencies and C-oriented examples felt heavy.
  • Wasmtime maintainers note no_std support, optional dependencies, interpreter mode (Pulley), and offer help tuning features.
  • Performance trade‑offs:
    • Wasmtime JIT is usually ~5–10× faster at execution.
    • Wasmi has far faster startup (100–1000× in some cases), which can matter more for short-lived or highly interactive tasks.
  • Portability concerns around wasmtime’s dependency graph on custom targets are discussed but left unresolved; maintainers invite bug reports.

Scheduling, fuel, and cooperative execution

  • OS uses a main loop that steps each app once per frame; concern raised that many apps might slow everything down.
  • Others clarify: as long as each app finishes its per‑frame work, perceived speed is fine; degradation happens only under heavy contention.
  • Wasmi “fuel metering” is highlighted as a good fit for a scheduler:
    • Fuel counts executed instructions in coarse blocks; when fuel hits zero, execution yields deterministically.
    • Overhead in wasmi is reported ~5–10%; design aims at performance and determinism over fine precision.
  • Comparison with wasmtime’s fuel (heavier) vs epoch-based timeouts (lighter but nondeterministic).

Security, isolation, and Spectre/Meltdown

  • Some question whether Spectre/Meltdown undermine WASM-as-isolation; others ask why these would be worse than for native code.
  • One commenter notes that in this OS, apps are compiled into the kernel and the browser doesn’t run JS, so threat models involving untrusted arbitrary code may not apply in the same way.
  • Qubes OS is cited as an example of strong isolation via virtualization; question whether WASM-based isolation provides similar guarantees.

Memory model and lack of virtual memory

  • Concern: without an MMU and virtual memory, implementing WASM’s contiguous linear memory and memory.grow is tricky.
  • Detailed argument:
    • Without virtual memory, app heaps must be physically contiguous.
    • Growing memory can conflict with neighboring allocations, leading to either:
      • Big gaps (wasted RAM),
      • Fixed-size heaps (no grow),
      • Or expensive shuffling/memmove of large regions.
  • Suggested answer (“just give non-contiguous chunks”) is rejected because then you’re no longer really running standard WASM.

GUI, radial menu, and browser

  • Radial menu design receives deep praise; comparisons to RTS games and marking menus in professional tools.
  • Detailed UX advice:
    • Fix the number of slices and positions to build muscle memory.
    • Put common actions on cardinal directions; destructive/surprising ones in harder positions.
    • Keep actions consistent across contexts.
    • Consider edge cases (screen edges, trackpads, keyboard-only use).
  • Minimal integrated browser impresses people and sparks discussion:
    • It illustrates how far modern web complexity has gone.
    • Some argue for a cleaner split between “content web” (simple HTML/HTTP) and “app web” (WASM + a small set of hardware/GUI APIs).

Potential applications and future directions

  • Some see strong near-term relevance on the server side:
    • As a way to run a single key/value store or service with a tiny trusted computing base and WASM sandboxing instead of full multi-process POSIX.
  • Others are curious about using WASM as a safer, more capable alternative to eBPF for kernel-level extensibility.
  • Discussion of using such isolation for game anti-cheat and remote attestation, though this quickly veers into social/philosophical territory.
  • Platform questions:
    • Today it targets virtio; one idea is a Linux+hypervisor “host” on bare metal to keep virtio as the hardware abstraction.
    • Security folks note that to be robust on real hardware, you probably still need the MMU’s protection bits, even if you keep identity mapping.
  • A few ask about quantifying performance gains from skipping syscalls and TLB overhead; no concrete benchmarks are provided in the thread.