Saphira Linux · Made in England
Saphira Linux is booting on OpenRC and systemd.
A deterministic, from-source musl distribution built in England for direct ownership: no binary-cache dependency, no usrmerge, and no BusyBox substitution layer.
Design position
Correct, not convenient
Saphira Linux is not an attempt to make Linux easy. It is an attempt to make it correct. Where common practice and the published standard disagree, the standard wins, and the reason is written down.
- /usr is split, not merged.
/bin,/sbin,/usr/binand/usr/sbinare separate directories. Early-boot and OpenRC executables stay in/sbin, and init scripts use#!/sbin/openrc-run. - The base utilities are the real tools. There is no BusyBox applet layer standing in for coreutils, util-linux, or the networking commands.
- Every binary is compiled from a pinned source archive. There is no binary cache to trust and no prebuilt package of unknown provenance.
- Build policy is recorded per unit. An image can be explained, not just described.
This is a technical preview. Where a figure below is a target rather than a measurement, it says so.
Dual-init booting · Made in England
One Saphira machine; choose OpenRC or systemd
The original Saphira Linux and Saphira-D are both real boot paths. Saphira-D has booted systemd on Linux 7.2.2, while the original Saphira path continues to boot OpenRC. The systemd path is actively developed, not a future-only claim.
An installed system can be upgraded in place from OpenRC to systemd without rebuilding the entire operating system. The operator can still select init=/sbin/openrc-init and boot OpenRC on the same system. musl libc and systemd are optional parts of that choice, rather than a reason to discard the existing machine.
Is this a first for an English Linux distro? We are not making that historical claim, but it is a serious question raised by a source-built musl system that can preserve its OpenRC boot path while making systemd selectable.
systemd-nspawn is working. User-mode systemd-nspawn is approaching validation and will be documented as tested only when that work is complete.
Boot evidence
Hardware and virtual platforms
Saphira has booted on hardware and virtual platforms. The kernel module set is approximately 53 MB while the boot kernels remain compact: vmlinuz-7.1.5-akadata is 16 MB and vmlinuz-7.2.2-akadata is 17 MB.
Hatchling boot evidence includes loaded ZFS and KVM modules: the active zfs module is 6,365,184 bytes, with kvm_intel and kvm also loaded. ZFS version 5000 has been tested and remains under continuing test.
libvirtd is being added for headless server-side hypervisor operation. There is no graphical-management, desktop, X11, or Wayland plan. pppd and rp-pppoe are now present; their live validation is planned for a maintenance window, so PPPoE is not yet claimed as tested.
Preview targets
How the preview compares
| Characteristic | Typical general-purpose distribution | Saphira Linux |
|---|---|---|
| Runtime base | Broad default package set | Approximately 260 MB without sources |
| Stripped image | Varies by installation media | Approximately 300 MB distributable image target |
| Development environment | Usually installed from external binary repositories | Approximately 4 GB installed; compressed development image target of 1–2 GB |
| C library and init | Often glibc with systemd | musl with OpenRC default or selectable systemd through Saphira-D |
| Base utilities | Distribution-dependent | Purpose-built package set; no BusyBox |
| Filesystem | Frequently usrmerged | Deliberately non-usrmerged; early boot remains in /bin and /sbin |
The 260 MB figure describes the runtime base without sources; the approximately 300 MB figure describes the stripped distributable image target. Final downloads will publish measured bytes and SHA-256 values.
Core patches
What is changed in the C library
mimalloc integration
The toolchain and native system integrate an external mimalloc allocator with musl-facing compatibility changes.
Correct errno behaviour
Allocator error paths carry the expected errno semantics instead of silently losing failure context.
Larger pthread baseline
The default pthread stack increases from 128 KiB to 1 MiB, giving concurrent native services more practical headroom.
These are the verified patches in the current source tree. Saphira does not claim an unverified network-buffer expansion or promise that overload can never drop work.
Core specification
Pinned and reproducible
- Architecture
- x86_64, x86-64-v3 baseline
- Compiler
- GCC 16.1.0, O3
- Kernel
- Linux 7.1.5 and booted Linux 7.2.2
- Target
x86_64-akadata-linux-musl- Reproducibility epoch
1753401600- Boot and services
- OpenRC with
#!/sbin/openrc-run, or selectable systemd on Saphira-D - Current codename
- Saphira · Version 0
- Userland
- Selected native tools; no BusyBox
- Pinned source archives
- 145
- Stage4 APK packages
- 254, including 105
-devand-docsplits - Default build policy
- 2 jobs, load limit 2,
-pipeon - Parallel build profile
settings set profile performanceuses the host CPU count with a load limit of 1.25×
Counts are read from stage4/sources.lock and stage4/dependencies.tsv. A further 90 locked Rust crates are vendored build inputs for bindgen and are not listed as packages.
The story
Saphira, Egg, Hatchling, Hatched, then Spawn
Saphira v0.1 came first. Saphira created Egg; Egg built Hatchling; Hatchling hatched Hatched. These are not product editions or promised release names. They are the working generation and validation loop behind Saphira Linux and Saphira-D.
Saphira v0.1
The running Saphira system from which the next turn begins.
Egg
Builds the next packages without sacrificing the trusted running system.
Hatchling
Tests package installation, upgrades, ownership and boot behaviour.
Hatched
Stresses the assembled system and package set. Faults return to Egg for correction and another test turn.
That feedback loop supplies both the Saphira OpenRC path and the Saphira-D systemd path. systemd-nspawn works; user-mode systemd-nspawn is close but not claimed complete. The remaining investigation is at the ZFS idmapped-mount boundary, not a systemd or musl limitation.
Spawn of Saphira is the next, in-progress turn: Saphira building Saphira with the package base, tooling and installer machinery required to reproduce the distribution from itself. Its current work includes the near-complete user-mode systemd-nspawn route, discovered after first proving systemd-nspawn as root.
More Saphira
The story continues at Saphira Linux
Dragons are part of the project’s language. mailDragon is a live APK in the Hatchling package repository, and PBXDragon is planned. The canonical Saphira site carries the wider build, release, and resource story.