UbixOS 3.1.0 — It Builds Itself Now

UbixOS 3.1.0 is out, and the headline is the one I’ve been working toward for a long time: UbixOS builds itself.

On both supported architectures, aarch64 and x86_64, UbixOS compiles its own kernel and userland inside UbixOS, the redesigned desktop included. The same desktop described below now runs on a system that builds itself. An image made from that output boots on the self-built kernel and passes sigtest and vfstest, the signal and filesystem test programs I use as the gate.

Self-hosting

	aarch64	x86_64
In-OS bmake -j4 world (clean, 4 vCPUs)	passes, 3h44m	passes, 9h48m (QEMU TCG)
In-OS bmake -j4 kernel	passes	passes
Self-built kernel boots; sigtest + vfstest	pass	pass
Image made only from the in-OS build output boots; sigtest + vfstest	pass	pass

The x86_64 number is long because it ran under QEMU’s software emulation (TCG), not hardware acceleration. It’s a correctness result, not a speed result.

What it took

None of this was one big change. It was a chain of small things that each had to be true:

• musl builds with bmake. The musl libc now has a BSD makefile that builds the same 1,355 objects with the same flags as the GNU build, so /usr/src/lib builds in-OS with the BSD toolchain.
• Bare in-OS clang links programs. crtbeginS.o and crtendS.o now come from compiler-rt and are staged into /lib, so clang -o h h.c just works inside the OS.
• A page leak, fixed. mmap(MAP_FIXED) over a live page dropped the old frame without freeing it, and musl’s allocator did that once per process. Roughly 4 KB lost per process on aarch64 and 1.36 MB per 300 on x86_64. A long build is exactly the workload that finds this. 500 ls on aarch64 now leaves memory use flat.
• Programs linked in-OS are executable. open(O_CREAT) applies the mode, chmod and fchmod work, rename is an atomic native entry move, and O_EXCL gives EEXIST. There’s also a real per-task umask(2).
• /bin/sh and bmake are built by world. oksh and bmake are vendored in contrib/, so a world built inside UbixOS rebuilds its own build tools.

The new desktop

3.1.0 also carries the “ubixos-v2” desktop redesign, drawn first as interactive mockups and then built for real. It’s the same on both architectures.

• Light and dark modes. A shared theme with both palettes, switched OS-wide at once. Apps can opt out; the terminal stays dark.
• A per-user accent colour, chosen in Settings and used across the desktop, Alt-Tab included.
• A new window frame. A pin button, and minimize, maximize and close grouped in one capsule. Windows resize from any edge or corner and stack in proper layers.
• A floating, translucent taskbar replaces the old Windows-11-style one.
• A launcher replaces the cascading start menu: app categories, search, recent items and a power menu. The Super key opens it on both architectures.
• Flyouts for calendar, volume and network status. The kernel gained a small call that reports link state and IPv4 address for this.
• A new lock screen, drawn from the design.
• Real power-off and restart from the desktop. The power menu asks init, which syncs the disks and then powers off or reboots: PSCI on ARM, ACPI power-off on x86_64 with keyboard-controller and fallback resets.
• Smoother drawing. Shared helpers draw anti-aliased shapes and icons, windows can be per-pixel translucent, and there’s a new icon set at 16, 24 and 48 px and a new wallpaper, “Nocturne”.

Settings (with a new Appearance page), Files, the activity monitor, Disk Utility and the Terminal’s palette were restyled to match.

Honest limits

I’d rather you hear these from me:

• The in-OS toolchain is LLVM built on the host. UbixOS runs Clang and lld inside itself, but it didn’t build them. The whole-image test also used host-built sh and bmake; world builds those itself now, but that test predates the change.
• NetSurf is skipped in-OS. It’s a port that needs GNU make.
• mkdir ignores its mode. Directories are always 0755.
• Stage /usr/src first. Re-stage it before an in-OS build, or the in-OS libc is built from stale sources.
• Desktop things dropped for now: taskbar hover previews and the Files details view with its editable address bar. They may come back.
• Multi-CPU came later. The redesign was verified on one CPU per architecture at first, because a multi-CPU messaging bug blocked login. Kernel fixes since resolved that, and the desktop now boots to the login screen with 4 CPUs on both architectures in the test VMs.

What’s next

A widget toolkit. Apps still hand-draw their controls, and I want that to stop.

An installer. The plan is a UEFI loader for both architectures, GPT disks, a live image you can boot and install from, text installer first and a graphical one on the same library after. VMs first, real PCs later. It’s written up as a design and a build plan, and none of it is built yet.

The full release is in the changelog.