MotorOS: a Rust-first operating system for x64 VMs
A new Rust-first microkernel OS for x64 virtual machines, MotorOS, aims to strip away Linux’s complexity in cloud and container-style deployments by making both the kernel and all userspace programs Rust-only. Commenters weigh this against a long history of hobby and alternative OSes that never reached broad adoption, raising concerns about long-term maintenance, Rust’s ABI stability, and the lack of Linux/C compatibility. The project’s author argues that Linux is ill-suited for minimal VMs despite its dominance, and positions MotorOS as a narrowly focused, fast-booting platform that could eventually evolve into a viable alternative if it gains a community.
Rust‑first design and ABI
- Kernel, drivers, and userspace are all Rust; standard Rust programs should compile and run without FFI.
- Userspace ABI is currently Rust-specific; in principle other languages could target it by reverse‑engineering.
- Some worry about the lack of a stable Rust ABI and draw comparisons to Haiku’s long dependence on GCC 2.95.
- Others argue stable C-style ABIs (
repr(C)), as in Linux, make compiler choice less of an issue; the project’s author questions why compiler instability is seen as a problem.
Async model and concurrency
- Several commenters hoped for an async‑first kernel; they note prior Rust OS experiments showing feasibility.
- Concerns are raised that async Rust is still incomplete (async traits, streaming interfaces), and kernel‑level async adds complexity.
- The author notes they tried async in the kernel but found the needed “cruft” too high at the time; networking is already async‑first, and file I/O may follow.
Scope, niche, and Linux comparison
- Many see it as an interesting hobby OS but doubt it can displace Linux, especially in cloud/server contexts.
- A VM‑only, Rust‑only OS is viewed as potentially useful for microservices, but some question whether it adds much over “FROM scratch” containers.
- Comparisons are drawn with Docker, NixOS, and “serverless” as responses to Linux complexity; some argue those tools are really about package management or billing models, not kernel complexity.
Microkernels, performance, and boot time
- Microkernel design is framed as a more principled alternative to containers for fine‑grained resource slicing.
- The scheduler is simple SMP round‑robin; more sophisticated policies are expected to live in userspace or separate VMs.
- The project claims very fast boot times (~200 ms); others note hardware init and timer calibration can dominate boot time, especially in VMs.
- Some request more performance data, but the README already admits networking and file I/O are currently slow.
Viability, ecosystem, and drivers
- Long‑term maintenance is highlighted as the hardest part; most such projects end up in a “graveyard.”
- Drivers and hardware support are acknowledged as a key barrier, though less so in VM‑focused contexts.
- There is interest in integrating a WASM runtime to sidestep ABI issues and enable safer composition, but this is speculative.