Lisa's bases: what Lisa runs on, and what it asks of the machine
Most operating systems are one thing all the way down. Lisa is two: a base, which is a Fedora-family system on real hardware, and the Lisa layer on top of it. The line between them is a written contract, and it is the reason Lisa can run on an Intel iMac and an Apple M1 from the same release.
This post explains why we drew the line there, what the contract asks, and how a machine earns its place as a base.
Why a layer, not a distribution
Building an operating system from the kernel up means owning kernels, firmware, drivers, Mesa, systemd and the boot chain for every machine you support, forever. That is years of work before the first pixel of a desktop. Fedora already does all of it, in public, and does it well. On Apple Silicon, Fedora Asahi Remix does it for the M1 and M2 Macs.
So Lisa does not fork Fedora. A base brings the kernel, firmware, Mesa, systemd and the drivers, chosen for its hardware. Lisa brings its own daemons, the compositor, the Embedder, the frameworks and the desktop. Fedora’s own services, such as logind, NetworkManager, BlueZ and PipeWire, are used as they are and are not renamed.
The rule in both directions is the same: nothing distro-flavoured crosses the line. The base owes the contract and nothing more. The layer assumes the contract and nothing more. That is what lets the same layer run on any base that conforms.
The platform contract
The contract is a list of tiers, each one something the base provides:
| tier | the base provides |
|---|---|
| C1 runtime floor | glibc at or above the floor the layer was linked against; clean on 16K memory pages as well as 4K; aarch64 and x86_64 alike |
| C2 service substrate | systemd with journald, logind and sysupdate; the system and session buses; a logind seat; no dev.lisaos.* name claimed by the base |
| C3 graphics and input | DRM/KMS at native resolution; Mesa with EGL, GBM and a conformant Vulkan driver; libinput-compatible input |
| C4 plumbing | PipeWire for audio; NetworkManager, BlueZ, UPower and AccountsService |
| C5 boot and update | a UEFI-shaped boot the image controls, and an update that can never leave the machine unbootable |
| C6 containers | rootless Podman, for the developer tools and application channel tooling |
| C7 remote access | OpenSSH, key authentication only, never a password |
Two profiles compose from it. Core (C1, C2, C5, C6, C7) is what a server needs: the substrate and the services, headless. Desktop adds graphics and plumbing (C3, C4). A base conforms per profile, so a server base owes no graphics.
What a base does not owe matters just as much: no GNOME, no GTK beyond what the Flutter embedder links, no X11, no display manager, no package manager on the device. Lisa brings its own login and session, so a base has nothing to configure there.
The contract is versioned with the layer. Raising a floor, such as glibc, is a deliberate contract bump, because it ends support for every base below it. The layer is always built against the oldest supported base, and that floor is recorded with each release.
The three bases
| base | machines | how it got there |
|---|---|---|
base-mx |
Apple M-series: the M1 iMac today, 16K pages | Fedora Asahi Remix, installed over SSH; GPU, display, audio and webcam all work |
base-x86 |
the Intel iMac, 2017 | the release rehearsal boots from its internal drive |
base-aarch64 |
standard ARM64 over UEFI, 4K pages | stock Fedora aarch64; tested on Ampere servers, with no current host |
The M1 is where Lisa first came up. It is the ground zero the layer was built on, and its 16K pages keep the whole layer honest: every binary must run on 16K and 4K pages alike, and nothing in the layer may be x86-only. One release lock yields three images, for x86_64, generic aarch64 and Apple silicon, because Ampere and Apple silicon share an instruction set but no kernel, no bootloader and no firmware.
On Apple silicon we hold ourselves to Asahi’s own rule. Base work goes upstream first, to the Asahi tree and then mainline. The base carries a patch, pinned by hash, only until it lands. There is no private delta on either side.
A machine earns its place on the hardware
A machine becomes a base in four steps:
- Install the Fedora family on the hardware and reach it over SSH.
- Run conformance for the profile it will carry, and fix until every line passes.
- Keep the dated result beside the base.
- Only then does the Lisa layer go on.
Conformance runs on the booted hardware, never in a virtual machine. One script asserts every checkable item for a profile with read-only probes. The result records the base definition’s hash, the boot, the hardware model, the kernel and the page size. Each probe keeps its command, its exit status and what it saw.
A missing tool or a missing permission can never become a pass. Some tiers cannot be proven by a probe at all: the runtime floor needs the actual linked build, and the update tier needs a real update and rollback. Those stay pending until their proof exists, and a base conforms only when every required tier passes.
That strictness is the point. “It boots” is not conformance. A Mac that almost works is a support burden we would carry for every release after it.
Old Macs count
A base does not have to be new. The graphics rule was written for exactly this: at start, the compositor picks hardware Vulkan, else hardware GL, else software, and everything follows that one answer. An earlier rule said Vulkan only, which would have pushed older Macs onto a software renderer. We changed the rule rather than the list of machines.
Old hardware also teaches you things. A 2011 iMac whose hard drive was replaced with an SSD runs one fan flat out. That is not heat. The firmware reads the drive’s temperature through a sensor wire the new drive doesn’t have, and fails safe. The fix belongs to the base, written down on its page, not hidden in the Lisa layer.
What is not done
The bases page lists its own gaps. The most visible are a production boot chain with full verification on every base, and a current host for the generic ARM64 base. Like everything else, they are tracked at docs.lisaos.dev/gaps. The contract itself lives at docs.lisaos.dev/system/bases.
← All posts