Moxnox 1.0 was published on October 26, 2026, with disk images and kernels for amd64 and aarch64 listed in its GitHub release record. The hobby operating system combines a design modelled on Windows NT with a GNU base system, giving systems programmers an unusual environment for exploring how those choices fit together.
There is a firm limit on where to try it. The version 1.0 README warns that its Btrfs implementation hasn't been hardened and should only mount disposable filesystems. The version number should not be read as permission to entrust it with existing data. We examined the release record and pinned documentation; we haven't booted or built the OS.
Unix software needs a new build
Moxnox's design description identifies its system-call choices as NT-like, while saying Unix-oriented software should run after recompilation. That qualification gives readers a practical way to interpret its POSIX-compatibility claim: expect a porting and build environment, rather than assume an existing executable will work.
The same document says Moxnox can build itself. That makes self-hosting a concrete capability to investigate, though the claim has boundaries. Its build instructions say GCC, Rust, hexyl and ripgrep cannot yet be compiled inside Moxnox. Building the operating system within itself doesn't mean every listed port can also be rebuilt there.
For someone studying operating systems, this is the useful distinction. The project offers a way to examine familiar Unix tools over a different system design, while its documented build exceptions define work that remains. Neither the release label nor self-hosting alone establishes broad application compatibility.
Start with the documented virtual machine
The 1.0 release supplies downloadable artifacts. The pinned README gives QEMU commands for both processor architectures, including an amd64 setup that uses the q35 machine type. It says the example's 1,024 MB of memory needs increasing for heavier work such as self-hosting. These are the project's instructions, not a configuration we tested.
The immediate audience is developers willing to investigate an experimental OS in a disposable environment. Its own filesystem warning makes that a more defensible starting point than following the bare-metal installation instructions on a machine holding useful data. The README provides both routes, but they carry very different consequences if an experiment goes wrong.
Watch the documented filesystem limitations and native-build exceptions in subsequent releases. Those are specific places to assess progress beyond the 1.0 label: which workloads can be rebuilt inside Moxnox, and what evidence supports trusting its storage implementation. For now, the release provides an inspectable experiment, with an explicit warning about its limits.