A 64-bit micro-kernel and userspace written in Rust.
Samsara is a micro-kernel for x86-64 that Harsh started in 2024 to learn how kernels actually work, and it kept growing past that. Nutcracker is the userspace side: a small runtime, a console server, an input server, and a port of mlibc that lives in-tree so C programs can build against the thing.
It is not Linux, and it doesn't try to be. The boot path, memory layout, and syscall ABI are all its own design. The only outside spec that applies is POSIX, and only where a libc needs it.
It boots on real x86-64 machines through Limine and runs busybox. Under that: 4-level paging, a first-fit kernel heap, a multi-level feedback scheduler, a PTY line discipline with canonical editing and job control, a vnode VFS with ramfs, devfs and procfs, PS/2 input, and a mappable framebuffer.
Everything is hand-rolled. No external crates, no libc in the kernel, no third-party sync primitives.
Reading about kernels teaches you the shape of the problem. Writing one teaches you why every piece is the way it is, usually by getting it wrong first. Samsara exists because Harsh wanted to actually understand this stuff instead of gesturing at it.
github.com/harshnikarsa/samsara
docs/ARCHITECTURE.md — subsystem tour and memory layout
docs/ABI.md — the syscall contract
Rust nightly with x86_64-unknown-none, plus
nasm, grub-mkrescue, xorriso, and
qemu-system-x86_64.
make # builds samsara.elf and samsara.iso
make run # boots it in QEMU, kernel log on serial
make mlibc # builds the mlibc sysroot under build/sysrootSMP bring-up with APIC timers, drivers moved into userspace, and a real block filesystem with drivers for actual hardware. No timeline.
No AI-generated contributions. Code, commit messages, and docs need to be written and understood by whoever sends them. Looking things up with an AI while writing your own patch is fine — the patch is the line.
Small patches, one change each. Explain the why in the commit message. Test in QEMU before sending. Everything else is in the repo.