A modern OS with BeOS in its bones.
NullaOS is an independent 64-bit operating system written from a blank page. UEFI-only, APIC-only, no legacy. It takes the ideas BeOS got right in the nineties, pervasive multithreading and a filesystem that understands its own contents, and rebuilds them for modern hardware.
Why I am building it
It started as MiniOS, out of curiosity about what really happens between the firmware handing over control and a cursor blinking on screen. That gap turned out to be the most interesting part of computing, so it kept going. It is now NullaOS.
I am not trying to replace Linux or Windows. I am trying to build the machine I wished for in the late nineties. BeOS felt faster on modest hardware than many machines feel today, because concurrency was never an afterthought. Every window had its own thread and the interface simply never blocked.
BeOS also treated the filesystem as something closer to a database than a bucket of bytes. Nearly thirty years on, most systems still treat a file as an opaque blob and keep everything interesting about it somewhere else. NullaOS picks both ideas up again, on hardware that can finally afford them, without dragging forty years of compatibility along.
Threads everywhere
SMP from day one, per-core run queues, and an interface that stays responsive while work happens elsewhere
Files that know things
An object-oriented filesystem where a file carries its own identity, history and rules
No legacy baggage
Pure UEFI, APIC-only, 64-bit only. No BIOS, no real mode, no drive letters
One OS, many devices
x86-64 first, then ARM and single-board computers, and one day, perhaps, orbit
The Big Ideas
The design is shaped by a handful of convictions. They guided the first codebase and they are guiding the rewrite, just with far stricter engineering underneath.
Pervasive multithreading
The scheduler is built for many cores from the first boot. Each processor has its own fair run queue, idle cores quietly steal work from their neighbours, and applications are encouraged to spawn a thread for anything that might wait.
One window, one canvas
Every window draws into its own private surface, and a dedicated compositor assembles the screen. If an application freezes, its window stops updating, but the mouse and every other window keep moving.
Message passing, not shared fate
Applications talk to system services by sending messages rather than calling into them. A misbehaving program can crash itself, not the window server, the sound server or the rest of the desktop.
The Object-Oriented Filesystem
In most operating systems a file is a name and a pile of bytes. What kind of thing it is gets guessed from an extension. Which program opens it lives in a separate table. Who may touch it lives in another. Search is a background crawler that is always a little out of date. When any of those pieces drifts apart, things break.
The NullaOS OO-VFS turns a file into a self-describing object. Its identity, its history and the rules about how it can be used travel with it, and are updated in the same step as its contents. The bytes are just one part of the object.
It is the direct descendant of the BeOS attribute model, taken a step further, and it is designed to sit on top of ordinary filesystems rather than demand a new disk format on day one.
Always-current search
Descriptions are indexed as part of the write itself, so there is no crawler and nothing to go stale
Per-file history
Earlier versions of an individual file can be kept and restored without volume-wide snapshots
Identity that travels
Objects keep who and what they are when a disk moves to another port or another machine
Running programs are objects too
A running program is treated as a live state of the file it came from, so activity stays traceable end to end
Two Codebases, One Destination
The first codebase proved the ideas could work, all the way to a desktop. The second is rebuilding them on foundations that can actually be trusted. Yes, the newer one has the smaller version number. That is deliberate.
The v0.4.1.0 Prototype
From a custom UEFI bootloader through SMP, virtual memory, storage, USB, networking and audio, to Ring 3 applications and a Windows 95-inspired desktop with a multithreaded compositor. What it achieved, and why it was retired.
Explore the prototype
The Rewrite: v0.0.5.x
A clean-room GNU C23 kernel built one verified subsystem at a time: explicit boot contracts, a fair SMP scheduler, active IOMMU protection, a managed driver core and ACPI, heading to native storage in v0.0.6.0. Includes a recording of it booting.
Follow the rewrite
Where this is going
The first release stays deliberately narrow: x86-64 machines with pure UEFI firmware. Mini-PCs, NUCs and mainstream desktops from the last several years are the proving ground, and every milestone has to pass on real hardware, not just in an emulator.
After that comes ARM. Raspberry Pi, Rockchip-based boards and other single-board computers are next on the roadmap, which is why the core of the kernel is written to stay independent of any one processor architecture. The long-term aim is one operating system that scales from small embedded boards up to full desktops.
And further out, I would like NullaOS to fly. A kernel with explicit contracts, bounded resources, strict isolation between devices and a boot process that reports exactly how far it got is the kind of software that belongs on something small, autonomous and a very long way from anyone who could reboot it. That is a long way off, and I know it. It is still the direction.
NullaOS follows a strict staged engineering approach: build one subsystem on explicit contracts, validate it with hosted tests, and qualify it on physical hardware.