Hamnix logo
1.0 — built to find out whether it was possible

Hamnix

A from-scratch operating system — kernel, drivers, filesystems, network stack, desktop and package manager — written in Adder, a Python-syntax systems language with its own compiler. Plan 9-shape namespaces at the syscall layer, a Linux ABI shim above them, sharing one kernel.

106native Plan 9-shape syscalls
278userland applications
100packages in this repo
577host test gates
0lines of C in the kernel

What it actually is

Not a Linux distribution and not a Linux fork. The kernel, the compiler and the language were all written for this project.

Two worlds, one kernel

Native code sees Plan 9-shape files — /dev/cpuinfo, /net/tcp, per-process namespaces built with bind. Linux binaries run inside enter linux { … }, where the same kernel file servers are bound at the paths Debian expects. No string rewriting in the syscall path.

Its own language

Adder has Python's syntax and a systems language's semantics. A hand-written x86_64 backend compiles the kernel and doubles as the differential oracle; an LLVM backend builds all 278 userland applications and is the only supported AArch64 path.

No sockets

TCP, UDP and TLS 1.3 are exposed as the /net file tree, Plan 9 style. There are zero BSD socket syscalls at the native layer. curl, sshd and an NTP client all dial out through files.

A real desktop

A scene-file compositor in which the kernel owns no pixels — each window is a display list in a file server. Panel, menu, drag and drop, .desktop launchers, and a native toolkit underneath.

Its own browser

HTML, CSS and a JavaScript engine written from scratch and measured against the Web Platform Tests. It renders real pages, and it is not a Firefox replacement — the table below says exactly where it stands.

Its own package manager

hpm — binary packages, Ed25519-signed indexes, a dependency solver, Debian-shape channels. It fetches from this very site, and keeps working from an on-disk mirror after installation with no network at all.

Screenshots

Captured from the framebuffer of a running system, not mock-ups.

The Hamnix desktop showing wallpaper, panel and desktop icons
The desktop — panel, clock, launchers.
The Hamnix application menu open, listing installed applications
Application menu — driven from .desktop files.
The Hamnix browser rendering its built-in demo page
hambrowse — the from-scratch web engine, here on its built-in demo page. The capture machine had no network card, so this is not evidence about real-world sites.
The Hamnix terminal running the hamsh shell
hamsh — Python-syntax shell, job control, service supervisor.
The Hamnix file manager showing a directory listing
Files — browsing the native namespace.
The Hamnix system monitor showing CPU, memory and process list
System Monitor — live CPU, memory and processes.
The Hamnix graphical installer
Installer — partitions, formats and installs to NVMe.

Where it honestly stands

This is a 1.0 in the sense of "it works and it is worth looking at", not "ready to be your daily driver". That distinction matters enough to spell out.

AreaStateDetail
Boot (UEFI, virtual machine)works Boots to a desktop under QEMU/KVM with OVMF. This is the tested path.
Boot (bare metal)stale Booted on an Intel NUC and an Asus laptop — historically, many hundreds of commits ago. Not re-verified at 1.0.
Filesystems & storageworks ext4 read and write (validated clean by e2fsck), FAT32, MBR + GPT, AHCI and NVMe.
Networkingworks ARP, IP, UDP, TCP, ICMP, DHCP, DNS, HTTP, TLS 1.3 over the /net file tree. virtio-net, e1000e, r8169.
Linux binariesworks Real Debian apt and dpkg install packages inside enter linux. CPython and busybox run as static-PIE.
Memory over timeworks A four-hour soak — 2,444 application launches and closes — finished with no measurable leak.
Web enginepartial ~83% of a pinned Web Platform Tests subset; Chromium scores ~91% on the identical harness. Renders real pages; heavy JavaScript sites will not work.
AArch64in progress Boots to EL0 on QEMU virt with per-task address spaces, demand paging and per-task kernel stacks. No hardware port yet.
Wi-Fino No native driver. Wired networking only.
GPU accelerationno Software rasteriser throughout.
Please do not install this on a machine you care about. It partitions and formats real disks, and its bare-metal behaviour is unverified at this revision. A virtual machine is the right place to try it. If you do run it on hardware, a report either way — working or not — is genuinely useful.

Getting it

Images are published on GitHub Releases. The recommended artifact is the in-RAM installer image: firmware loads the kernel and a squashfs root entirely into memory, so nothing is read from the boot medium after handoff.

Or build it yourself. The tree is self-contained; the host needs Python, clang and QEMU.

# build the in-RAM installer image, then boot it under QEMU
git clone https://github.com/HamnixOS/Hamnix
cd Hamnix
bash scripts/build_installer_img.sh

Package repository

This site is also the live hpm repository. Top-level directories are channels, mirroring Debian's split. hpm reads each channel's index.json and fetches packages by URL and SHA-256.

ChannelIndexContents
main main/index.json First-party, free software. Enabled by default. 100 packages — one per CLI tool, plus the hamnix-base metapackage, the bootloader, installer tools and a curated Debian rootfs tree.
non-free non-free/index.json Reserved for software whose licence is not DFSG-free. Empty placeholder; opt in with hpm channels enable non-free.
non-free-firmware non-free-firmware/index.json Reserved for redistributable firmware blobs. Empty placeholder.
# on a running Hamnix system
hpm refresh
hpm search editor
hpm install hamnix-base

Channel indexes are Ed25519-signed and verified against a compiled-in key. An installed system carries an on-disk mirror of the packages outside the base set, so hpm keeps working with no network.

Source & contact

Repositories

HamnixOS/Hamnix — the OS, the language and the compiler.
HamnixOS/packages — this site and the package channels.

Where to start reading

architecture.md for the layering, native-api.md for the syscall surface, and the Adder guide for the language.

Reports welcome

Bare-metal results, boot logs from machines that fail, and pages the browser renders badly are all useful. Open an issue.