maharmstone/moxnox

Moxnox is a curiosity-first operating system: worth exploring if you want to see how far a single hobby kernel can go toward running Unix-like software on NT-inspired foundations, not if you need a daily driver or a server.

The problem

A developer or OS hobbyist wants to boot an unfamiliar system, run familiar Unix tools such as bash, git, ssh, Python, or a compiler, and observe where the seams are. Usually that means building or patching a kernel and userspace before anything useful runs. Moxnox changes that step: a release image boots under QEMU, and a prebuilt GNU base system plus a long list of ports comes with it, so the first experiment is exploring an NT-like substrate rather than assembling a toolchain. The result is a system you can log into, build software on, and probe for missing pieces.

What's different

The mechanism is a deliberate split: system calls and low-level interfaces follow Windows NT, while paths are POSIX-style and a large part of POSIX 2024 is implemented, with fork present. Binaries are PE rather than ELF, C++ exceptions use SEH, and POSIX signals are delivered through Asynchronous Procedure Calls. This is not a Windows recreation—the author says tokens, the Registry, I/O completion ports, and NT's hidden object-manager paths are absent—so the practical benefit is seeing NT design ideas exercised by a Unix-shaped userspace. The trade-off is that neither side is complete: about 642 of roughly 1,200 POSIX functions are implemented, AF_UNIX works only partially, and signals arrive only when a thread returns from a system call, so a spinning program cannot currently be killed.

The filesystem choice is the other distinctive piece. btrfs is the root filesystem and mounts on Linux, which makes the disk image inspectable from a host. The README is explicit that the btrfs code works for basic purposes but has not been battle-hardened and only throwaway filesystems should be mounted. That is not a minor footnote: it defines how much you should trust data in this system during experiments.

A commenter on the launch thread (2026-10-28) framed the appeal as NT being designed rather than reimplemented discussion of NT design, while another pointed to persistent complaints about NT's I/O and driver stack critical reply. Those are opinions about NT, not claims about Moxnox's quality; they usefully signal what kind of reader the project attracts.

Who should try it

Good fit: someone interested in operating-system design, cross-platform compatibility layers, or the Windows NT kernel model, who wants a controlled QEMU environment and is content to treat data as disposable. The included GNU base system and self-hosting claim make it more interesting than a demo kernel because you can compile things inside it. Poor fit: anyone wanting a desktop or a stable multi-user system. The README lists no GUI, no multiple users or groups, no security, and no timezone or keyboard-layout support. A single-user, single-locale shell environment is the documented scope.

Arm hardware is a separate audience. The aarch64 build needs ARMv8.1 LSE atomics, so the Raspberry Pi 5 but not earlier models, and Moxnox supports ACPI rather than Device Tree, so the Pi also needs a UEFI firmware project Moxnox README. QEMU's virt and sbsa-ref machines are the documented alternatives if no Pi 5 is available rpi5-uefi.

Requirements and limitations

On amd64, everything is compiled for x86-64-v3, which the README describes as covering roughly anything made since 2015, with optional AVX-512 use. QEMU users must pick the q35 machine type for PCI Express. Booting from the release image is the low-commitment path; installing to a partition uses mkfs.btrfs, efibootmgr, and a recent btrfs-progs, and the author warns not to get the target device wrong.

Ongoing use means living with documented gaps: no automatic daemon startup, so sshd must be launched manually and requires an authorized_keys file because passwords do not exist; full-system builds are slow because the userspace heap allocator is a bottleneck when self-hosting; TCP is slow because MSS negotiation is missing. Ports are extensive but not exhaustive, and POSIX coverage is partial. Expect to check the README before assuming a Unix tool will work, and do not store anything you care about on a mounted Moxnox filesystem.

HotRepo's take

Moxnox was five days old on the only recorded board date: 120 total stars and #23 on the cpp NEW-REPOSITORY board on 2026-10-28—a snapshot, not a growth rate. Trend persistence cannot yet be judged. The Hacker News thread drew 50 points and 8 comments on 2026-10-27, which indicates discussion volume only HN thread. Verify the README's compatibility and missing-feature lists before trying it project README; the self-hosting claim is the author's, and no independent build test is supplied here.