About
About Saphira
Saphira did not begin as an exercise in creating another Linux distribution. It grew out of years of running infrastructure, building things from source, keeping old machines useful, repairing systems other people had declared obsolete, and repeatedly discovering that the simplest system is usually the one you can still understand when something goes wrong.
Where it came from
Saphira emerged from practical infrastructure work rather than from a desire to publish another distribution. It comes from years of operating Linux servers, networking, DNS, mail, databases, virtualisation and source builds on real production systems, and from repeatedly wanting the base system to remain understandable at three in the morning when something had fallen over.
- Linux and the servers that run it
- networking, routing and DNS
- mail and message systems
- databases and the applications that depend on them
- virtualisation and the machines underneath it
- building software from source
- old hardware that still has work to do
- production systems where downtime is not theoretical
This is not a CV. The point is that Saphira grew from operating these systems day after day and wanting the base layer to stay comprehensible — something you can still read, reason about and repair when the diagrams stop matching reality.
Why build another Linux?
Saphira was not built because Linux is fun, because other distributions are bad, or because we believe Saphira is better than everything else. It was built because we wanted to know what is in the system, why it is there, how it was built, and what happens from the toolchain through boot and on into service startup.
It is deliberately small. It uses ordinary technologies — Linux, musl, OpenRC and APK. The interesting part is not the ingredient list. It is how little machinery is actually required to produce a useful server system while keeping it inspectable from first boot.
Old hardware, current ideas
Newer hardware should not be held back merely to support older hardware. But older working hardware does not become useless simply because a new CPU generation appeared. That tension is exactly what pushed us toward separate compiler and build profiles instead of a single lowest-common-denominator binary.
- Nehalem, Sandy Bridge and Ivy Bridge class x86 systems
- PC Engines WRAP and Geode platforms that still route traffic
- Raspberry Pi Zero 2 W and Raspberry Pi 4 on the AArch64 side
- i686, and genuine i586, for boards that never moved past them
The aim was never to drain performance from modern machines to keep ancient ones alive. It was to keep each machine on the profile that actually fits it, and to prove that 'old' and 'current' can ship from the same source tree.
Amiga and PiStorm64
AKADATA still builds for Amiga hardware. PiStorm64 is our Amiga-focused PiStorm fork: 64-bit 68k execution on a Raspberry Pi 4, with remote SCSI storage that lets an Amiga boot from a disk that does not have to sit next to it. This is one of the clearest places the 'old hardware, current ideas' instinct became visible.
PiStorm is the bridge: a Raspberry Pi sits where the CPU used to be and emulates the 68k bus, so the Amiga around it keeps living while the compute underneath gets replaced. PiStorm64 is our fork of that idea, taken further into a 64-bit 68k execution and bus-engine runtime with userspace MMIO backends, RTG graphics and PiSCSI storage.
- Raspberry Pi 4 is the validated baseline platform.
- PiSCSI64 remote disk mount and boot is validated.
- ISO-backed CD-ROM mounts are validated.
- RTG graphics are functional, with a known window-decoration issue under active investigation.
- UAE JIT remains work in progress and is not yet a reliable runtime path.
From Amiga to Saphira
Saphira is not an Amiga operating system. The connection is not the hardware; it is the engineering habit. Understand the whole machine. Keep working hardware useful. Replace complexity only where it earns its keep. Combine old and new technology where it helps. Retain operator control.
The line from an Amiga booting storage across a network to Saphira building i586, x86-64-v3 and AArch64 systems is less strange than it first appears. Both start with the same question: what does this machine actually need in order to do useful work?
Built from scratch
Built from scratch means what it says. Saphira is not a Debian respin, not Ubuntu with another theme, and not Alpine with a different repository. The bootstrap, toolchain, root filesystem and package stages are built deliberately from source, so the result can be explained rather than inherited.
The point of building from source is not ceremony. It is that every stage — from the first cross compiler to the running service — can be inspected, reproduced and reasoned about. We keep the build documentation separate from the philosophy so each stays readable.
Why simplicity matters
The goal is not minimalism for scorekeeping. The goal is to minimise the number of places where behaviour can hide. A system can be sophisticated without becoming mysterious.
- configuration should be readable
- startup should be followable
- packages should be accountable
- dependencies should be visible
- networking should be explainable
- logs should tell the truth
What Saphira is becoming
The history points somewhere specific. The modern default is x86-64-v3, with broader x86 builder profiles behind it. i686 and i586 remain because the hardware remains. AArch64 covers the small boards. Saphira-d and the Dragons carry the services. Physical hardware and a VM-first current release keep the project honest about what it actually runs.
None of these directions are accidents. Each target exists because the hardware exists and can be tested, and because inspectability stays central no matter how far the tree spreads. The project grows outward from the same instinct that kept an Amiga booting from a disk across the room.
Built by AKADATA
Saphira is built by AKADATA. That is the same group operating the infrastructure Saphira runs on, which is part of why the project cares about systems you can still understand when something goes wrong at three in the morning.
This is not a company sales pitch. It is a statement of provenance: the people who built the distribution are the people who have to keep it running, and that tends to produce systems that stay comprehensible under pressure.