SAPHIRA LINUX

Saphira defaults to x86-64-v3 today, and that choice is deliberate: modern hardware should be allowed to compile against a modern instruction set instead of being held back to the oldest common denominator. But 'modern default' is not the same as 'only thing we will ever build'. Older x86-64 machines have not stopped being useful, and some of them — Sandy Bridge, Ivy Bridge, even Nehalem-era boxes — are still perfectly good at focused server jobs. We still have those machines here, so this is a plan we can actually test rather than a processor-history footnote.

So the builder is being designed around selectable compiler baselines, not a single monolithic target. x86-64-v1, v2, v3 and v4 are build/compiler profiles, not separate distributions and not identical binaries with different labels. A Sandy Bridge machine gets a build suited to Sandy Bridge; an x86-64-v3 server stays an x86-64-v3 build; future v4 hardware can use v4 without dragging everyone else along. Supporting older hardware does not mean holding newer hardware back, and vice versa.

The same idea reaches backwards into 32-bit and forwards off x86 entirely. i686 is coming back, and a genuine i586 userspace baseline is now being developed — not i686 quietly requiring SSE and calling itself i586. It reaches into ARM: AArch64 is the first step that proves the source-built model is not secretly welded to x86, starting with real Raspberry Pi hardware.

Modern x86 by default. Older hardware remembered. ARM starts with Raspberry Pi 4.

One honest caveat: the builder is intended to know about x86-64-v4, but we do not yet have v4 hardware here to validate native builds and runtime behaviour. Builder capability and tested images are different states — we would rather say 'not tested here yet' than turn a compiler flag into a support claim. Suitable hardware donations are, of course, politely welcome.

View architecture profiles and machine targets →

APK packages

481

Earlybird downloads

—

Total downloads

—

Current release

Earlybird

Build toolchain

GCC 16.1.0

Repository status

Live

Simplicity here is an engineering constraint, not a shortage of features. Fewer layers means fewer places for a failure to hide, a boot sequence you can follow end to end, and a package set you can actually account for. Simple does not mean incapable.

Read the longer argument →

1. Stage0

   Bootstrap toolchain

2. Stage1

   Native toolchain

3. Stage2

   Root filesystem

4. Stage3

   Base build image

5. Stage4 packages

   Profiled APK builds

6. Stage4 image

   Image generation

7. Image

   Validated & bootable

# /etc/apk/repositories
https://packages.akadata.ltd/saphira/main

apk update
apk search nginx
apk add nginx

Browse the package index →View Stage4 build profiles →Open the raw repository →

Bare metal is not the initial target. The Earlybird image is designed and tested for virtual machines. That remains true for Earlybird; physical x86-64, WRAP and Raspberry Pi hardware is an active roadmap direction — see the architecture roadmap.

• First-boot setup

  Working

  The Earlybird image includes guided setup for the root password, normal user, full name, user password, IPv4 and IPv6 addresses with gateways, DNS selection, an optional search domain, and APK repository configuration.

  • DNS providers: Quad9, Cloudflare, OpenDNS / Cisco Umbrella, or custom DNS.
  • The setup applies the configuration, updates the repository file, copies /etc/skel profile files into root and the new user's home, and drops to a shell ready for apk use.

• Package quality fixes

  In progress

  Earlybird is a real beta release and package-level issues are still being corrected through actual use.

  • Examples include runtime dependency fixes, package split corrections, service script fixes, library SONAME corrections, and configuration packaging fixes.
  • A current example is PHP SQLite support: when a dependency is missing, runtime symbols usually identify what needs to be added with apk add.
  • The packaging is fixed where possible rather than documenting permanent workarounds.

• GCC 16.2.0 toolchain migration

  In progress

  The development tree is migrating to GCC 16.2.0 with broader native language support and musl-specific compatibility work. The released Earlybird Beta and Bootstrap images shipped on GCC 16.1.0.

  • Once the native compiler and toolchain are proven, the full distribution will be rebuilt cleanly from the beginning.

• Installation tooling

  In progress

  The current image can already be imported into a hypervisor and configured through the guided first-boot setup.

  • A more complete TUI installation path for installing Saphira onto target disks is planned.

• Desktop support

  Not planned

  Saphira is a server operating system. There are no project plans for X11, Wayland, Plasma, or graphical installation.

  • Nothing prevents users from packaging or building those themselves.

• NVIDIA Open kernel modules

  Staged for testing

  nvidia-open 610.57.04 and matching GSP firmware are staged in hatchling for the pure-musl host. The no-GPU Hatchling load, initialisation, no-device PCI probe, and clean unwind are proven; real RTX 3060 / GA106 testing on Homer remains pending.

  • Saphira does not install CUDA, glibc, or NVIDIA proprietary userspace on the host.
  • The planned CUDA route is a glibc systemd-nspawn container with NVIDIA userspace exactly matching the host module release and required /dev/nvidia* nodes passed through. It is not yet tested.

Full roadmap →

Beta software benefits from people who write things down. Report bugs, ask compatibility questions, or tell us what broke on your hypervisor.