Moxnox 1.0: self-hosting POSIX hobby OS with NT-style kernel on btrfs

Moxnox, a hobby operating system that pairs a Windows NT-inspired design with POSIX compatibility and btrfs as its root filesystem, has reached version 1.0, drawing attention on Hacker News. According to the project's GitHub page, the release weighs in at roughly 130,000 lines of C++ and runs on both amd64 and aarch64 hardware.

An NT-shaped kernel serving a Unix userland

The unusual part is the architecture. Moxnox's syscall interface and other low-level design choices are modeled on Windows NT, yet the system ships a full GNU base system and is intended to run software written for Unix-like platforms once recompiled. The README is explicit that this is not an attempt to recreate Windows the way ReactOS does: the contract covers syscalls and low-level interfaces only, not the supporting daemons or the internal structure of the kernel.

That compromise shows up throughout the design. Binaries use the PE format with .exe and .dll extensions rather than ELF; C++ exceptions ride on structured exception handling; POSIX signals are implemented through Asynchronous Procedure Calls; and the kernel-like work that NT delegates to ntdll.dll lands there as well. Code follows the Windows x64 calling convention, and C data types match Windows sizes, such as long being 32 bits wide. Conspicuously absent from the NT side are tokens, the Registry, and I/O completion ports.

Btrfs underneath

Rather than a bespoke filesystem, Moxnox stores everything on btrfs, the copy-on-write filesystem best known from Linux. The README cautions that its btrfs implementation works for basic purposes but has not been hardened by heavy use, and advises mounting only disposable filesystems. Installation involves formatting a fresh partition with mkfs.btrfs, unpacking a release tarball onto it, and copying across an EFI kernel image — a polyglot file that also conforms to the Linux boot protocol, although the author has not tested it with GRUB.

Hardware requirements and device support

On amd64, everything is compiled for the x86-64-v3 baseline, which the project says covers more or less any hardware manufactured since around 2015, with AVX-512 enabled automatically when detected. On aarch64, the use of LSE atomics requires ARMv8.1: a Raspberry Pi 5 qualifies, earlier models do not. The ARM port also relies on ACPI rather than Device Tree, so Pi owners need third-party UEFI firmware to boot it.

Supported hardware includes NVMe, SATA, SD cards, virtio-block and USB mass storage for disks; virtio-net, RTL8168 and RTL8125 network cards; USB HID, PS/2 and virtio input devices; virtio-gpu alongside various firmware framebuffers for graphics; and XHCI for USB. The README includes ready-made QEMU commands for trying either architecture without bare metal.

Self-hosting and the ports tree

Version 1.0 is mature enough to build itself: running CMake and Ninja on Moxnox produces Moxnox, although gcc, rust, hexyl and ripgrep are the current exceptions. The project warns that self-hosting takes a lot of RAM and even more patience, and identifies the userspace heap allocator as the main bottleneck. Cross-compilation from Linux is handled through published Docker images containing the toolchains.

The ports collection is extensive for a hobby system — bash, coreutils, git, Python, Perl, LLVM, OpenSSH, vim, curl, OpenSSL, Mesa, Cairo and dozens of others, with gcc available for amd64. Licensing is split three ways: the GPL covers the kernel and first-party programs, first-party DLLs are LGPL, and the modules directory is MIT.

Known gaps

The project's FAQ is candid about what is missing: a GUI, timezone support, alternative keyboard layouts, locales and non-UTF-8 character sets, multiple users and groups, and any real security model. The networking and memory subsystems also have acknowledged performance issues — TCP sticks to a default 64 KB window without MSS negotiation, there is no early writeback under memory pressure, and neither the page cache nor the dentry cache is ever pruned, so inodes stay open until deleted.

Why it matters

Hobby operating systems rarely reach a 1.0 release, and fewer still become self-hosting, so Moxnox clearing both bars makes it a notable data point in itself. More interesting is the design experiment: most from-scratch kernels imitate Unix, whereas Moxnox tests whether the NT syscall surface can serve as the foundation for a POSIX userland, complete with the familiar GNU tooling. Its in-kernel btrfs implementation is also unusual outside Linux proper. The README's own warnings — unhardened filesystem code, no security, missing NT features — make clear this is an experimental system rather than a daily driver, but as a piece of systems programming it demonstrates that alternative kernel architectures can still support a modern, buildable software stack.