Why Gurnard exists​

Until now, if you wanted the Pantheon desktop — the calm, minimal environment from elementary OS — you mostly had to run elementary OS itself. Gurnard is the first widely-buildable way to get that desktop with a standard Ubuntu 24.04 LTS base underneath, wrapped in a container-native, immutable core.

The result is a familiar Ubuntu with an atomic heart:

• Ubuntu 24.04 LTS base — the LTS with the longest support runway in the catalog, on both x86_64 and arm64
• Pantheon desktop — elementary's elegant, minimal desktop, pre-configured out of the box
• bootc core — atomic updates and rollback, the same container-native foundation as the rest of the TunaOS line
• Flathub and Homebrew pre-enabled — apps and tools ready to install the moment you boot

Gurnard currently ships as Experimental (ghcr.io/tuna-os/gurnard:base and ghcr.io/tuna-os/gurnard:pantheon) — the right time to try it is now, before the surface settles, because Pantheon on a non-elementary base is a new packaging surface and we want your bug reports while they're cheap to fix.

How to try it​

sudo bootc switch ghcr.io/tuna-os/gurnard:pantheon

Or browse the Gurnard variant page for install instructions and image tags.

Part of a growing line​

Gurnard joins the catalog alongside Hummingbird (🐦, a container-native bootc rebase of Fedora Hummingbird) — both new variants in the last week, and both reminders that TunaOS is not one desktop's project. Every major base and desktop pairing we can ship atomically, we will.

Questions, feedback, or a first contribution? We're on Matrix and issues are open in github.com/tuna-os/tunaOS — good first issue and help wanted labels are live on the backlog.

The short version​

• A macOS app walks you through splitting your disk and handing off to recoveryOS — the same flow Asahi Linux users already know
• Underneath, one minimal bootstrap payload runs fisherman on first boot to bootc install the TunaOS image you picked
• The catalog is a verified allowlist: only images that pass the golden-manifest harness appear in the app
• Today: bonito and grouper pass 36/36 checks each and are offered in the shipped catalog

Why it matters​

TunaOS is a bootable-container desktop: atomic updates, one transaction, rollback on failure, verified upgrades. The Apple Silicon path keeps that model — a Mac running TunaOS updates exactly like a server running bootc, not like a hand-rolled dual-boot experiment. The installer project explicitly targets the wider bootc ecosystem too — Dakota, Bluefin, and Bazzite images can be packaged with the same tooling, and we've modeled the payload layout on fedora-asahi and nixos-asahi so the approach stays upstream-compatible.

What's shipped, what's next​

The installer design and validation harness are complete: payload packaging, first-boot agent configuration, asahi-installer --json machine mode, and the recoveryOS walkthrough with LUKS fail-closed and Wi-Fi handoff at first boot. The macOS app (D3) is the remaining milestone.

Two claims are deliberately kept separate in the project's testing philosophy: "a payload boots" (packaging is correct) versus "the bootstrap handoff is green" (the agent recipe passes real fisherman validate and a real bootc install end-to-end). Every promoted *-asahi tag must pass the harness before it is offered — the catalog entry's verified field is the gate, and CI generation consumes harness results rather than tag enumeration.

Get involved​

• Test on real hardware — the project documents two hardware CI tiers (funded Scaleway rental, or a volunteer's M1 Air) with safety-checked automation in scripts/asahi-remote-switch.sh
• Follow the installer — bootc-installer-asahi has a full GUI walkthrough and design docs
• Questions? — Matrix #tunaos

M1/M2 for now — M3+ support follows Asahi upstream's installer roadmap.

Two variants, one goal: a daily-driver ARM laptop​

Both ship the X13s support stack out of the box: the jlinton/x13s COPR kernel enablement, Qualcomm firmware (qcom-firmware), Bluetooth (bluez), power management (pd-mapper), and battery monitor firmware blobs in the initrd — with the required kernel arguments (arm64.nopauth, clk_ignore_unused, pd_ignore_unused, modprobe.blacklist=qcom_q6v5_pas) and device tree preconfigured.

Try it​

1. Write the ISO to a USB stick (dd or your usual tool) and boot to the live desktop
2. Install from the live environment
3. Already running bootc on the X13s? Switch in one command:

sudo bootc switch ghcr.io/tuna-os/bonito-x13s:latest
sudo reboot

Updates are atomic from then on: sudo bootc upgrade, rollback on failure, verified by the same container-native pipeline as every TunaOS image.

Why now​

The X13s is the reference device for Linux on Windows-on-ARM laptops, and the Qualcomm Linux story keeps accelerating. TunaOS's manifest-driven build pipeline makes it cheap to maintain per-device images — the X13s variants are rebuilt automatically on every push to main, so the ISO you download is the latest verified boot image, not a snapshot from release day.

Get involved​

• Own an X13s or another Snapdragon X Elite laptop? — try the ISO and report what works/what doesn't on GitHub
• Docs — variant pages: bonito-x13s, dakota-x13s
• Questions? — Matrix #tunaos

Correction (2026-08-14)​

This post originally thanked a human contributor — "Shimon Schwartz / shimonenator" — as TunaOS's first external contributor. That claim was wrong, and we are correcting it publicly.

On review (#1317, #1451) we confirmed that every commit attributed to the shimonenator account has commit.author.name: antigravity — the work came from a Google Antigravity automated agent, accidentally surfaced as a named coauthor. No person named Shimon Schwartz contributed to this repository.

The commits themselves are real and remain part of the tree; the mistake was attributing them to a human contributor and building a "first external contributor" story on that attribution. We have also removed the claim from the Q3 2026 checkpoint, the roadmap, and our internal decision documents.

TunaOS still has no external human contributor, and we are still a single-maintainer project by the numbers that count. Correcting that publicly matters more to us than the metric would have — closing that gap is exactly why the curated good first issue backlog below exists.

What actually shipped​

Since August 10, commits on the shimonenator account landed changes in the main repository:

• OBS project design for the EL10 package gap (#777) — a concrete design for closing the packaging hole on the RHEL-10 line
• Image Factory completion gate and definition of done (#1283) — establishing what "done" means for the factory
• Image Factory Completion Gate alignment section (#999)
• Hummingbird repo-contract URL fix (#1282)
• Flavor-equality docs (#1315) — removing the GNOME-primary tiering framing

These changes are useful on their merits — the OBS design and the completion gate touch two of the areas our roadmap flags as most at-risk, the enterprise line and the image factory. What they are not is evidence of outside human interest: the same account's commits are consistently attributed to an agent.

Why the correction matters​

TunaOS has a small core team, and we have been open about the single-maintainer bus-factor risk. Mistaking an agent for a human contributor would have let us pretend that risk was easing when it was not. The onboarding loop is still unproven: the docs, the issue labels, and the findability of starter tasks are exactly what a first human contributor will test, and we want that test to be honest.

Be our first?​

If you are a person reading this and the work above looks like work you could do — it is. We curate a good first issue backlog and the ways-to-contribute post covers every path in. The Matrix room (#tunaos:reilly.asia) is where questions get answered.

We would love to meet our actual first external contributor — and we will make sure the acknowledgment is correct when we do.

So where does TunaOS fit? This post maps the landscape honestly — what each family does well, and the specific gap TunaOS was built to fill.

The two lineages​

Almost every immutable desktop descends from one of two ideas:

1. Image-based systems (Silverblue lineage): the OS is a read-only image. Updates swap the whole image atomically. Fedora Silverblue/Kinoite, Bluefin, Aurora, and Vanilla OS all live here.
2. Declarative systems (Nix lineage): the system is a pure function of a configuration. NixOS and Guix System rebuild the entire OS from source on every change.

TunaOS is firmly in the first lineage — but with a twist that changes who it serves.

What the image-based players do well​

Fedora Silverblue / Kinoite pioneered the model. Atomic updates, rpm-ostree layering, Flatpak apps, and a fast-moving desktop. The tradeoff: the base is Fedora's release train, which rolls fast and is supported for about a year per release.

Bluefin (and the Universal Blue ecosystem) took Silverblue's model and productized it — DX tooling, curated defaults, NVIDIA images, and a "this is what we recommend" opinion. It is the reason TunaOS exists: TunaOS is a fork of Bluefin LTS, so we inherit a decade of design decisions that work.

Vanilla OS explored an "immutable-but-not-container" model with its own package managers and Android-style upgrades. Interesting experiment, less interested in the enterprise lifecycle.

Aurora is the KDE sibling in the Universal Blue family — great Plasma experience, same fast-moving Fedora base.

The common thread: everyone builds on the Fedora release train. That is excellent for enthusiasts and fine for home machines. It is a hard sell for an enterprise that standardized on RHEL-compatible operating systems with a 10-year lifecycle.

The enterprise gap​

Enterprise Linux (RHEL, AlmaLinux, CentOS Stream, Rocky, Oracle Linux) is where servers live, but EL has no first-class desktop story. RHEL Workstation exists, but it tracks the same desktop packages for a decade — GNOME 4x-era software on a 2026 machine. Meanwhile the same org's developers get Fedora or Ubuntu on their laptops, creating the two-world problem: one package ecosystem and update cadence in the datacenter, a different one on the desk.

TunaOS closes exactly this gap. It takes the bootc-based image model that Bluefin proved and rebuilds it on Enterprise Linux bases:

• Albacore / Yellowfin — AlmaLinux 10 (RHEL 10 rebuild-for-rebuild)
• Skipjack — CentOS Stream 10
• Bonito — Fedora 44/Rawhide, for teams that want the fast train
• Tromsø / XFCE Linux — KDE Plasma and XFCE flavors built with BuildStream

Same bootc tooling, same image update model — but the base is the OS your servers already run. Your fleet, your compliance team, and your patch processes see one platform.

Where TunaOS deliberately diverges​

• Latest desktops on a stable base. GNOME is backported to the EL10 base rather than frozen at the RHEL snapshot; KDE Plasma 6, COSMIC (System76's Rust desktop), and Niri are all first-class flavors. The desktop moves at desktop speed; the base moves at EL speed.
• Homebrew and Flathub by default. Developers don't fight the OS to get tools — brew install and Flatpak cover the long tail of software EL never packages.
• Cloud-native management. bootc for image updates, plus Corral for Kubernetes-native VM management — the desktop becomes part of the same declarative estate as the cluster.
• XFCE with Wayland. The new xfwl4 compositor brings the lightweight desktop to Wayland, not just GNOME and KDE.

The honest comparison table​

Verdict​

TunaOS is not a Silverblue competitor — it is the EL answer to the desktop question. If you are on Fedora and happy, stay; the uBlue ecosystem is doing great work and we build on it. If your organization standardized on RHEL-compatible operating systems and wants a desktop that updates atomically, rolls back cleanly, and runs current software — that is the gap no one else fills, and it is the gap TunaOS fills.

Try it: grab an ISO at tunaos.org/download, or build your own flavor from the image factory.

The fastest path: tagged starter issues​

We now curate a good first issue backlog: tasks that are deliberately small, well-scoped, and safe to attempt without deep knowledge of the image factory. Right now that includes:

• ARM laptop hardware — the README System Requirements don't document supported ARM hardware (ThinkPad X13s, Apple Silicon) yet (tunaOS#1385).
• Verifying downloads — the README has no checksums/SBOM verification section for the published ISOs (tunaOS#1366).
• Pantheon desktop docs — the new Gurnard (Ubuntu + Pantheon) variant needs a desktop guide and the pantheon suffix documented (tunaOS#1351, tunaOS#1350).

Each issue carries the help wanted label too, which signals "external contribution explicitly welcome." Comment on the issue when you pick it up — that prevents double work, and it gets you a response faster.

Docs and guides​

The docs site runs its own issue tracker and has an independent good first issue backlog. Guides, FAQ answers, variant pages, and screenshots are all welcome. If you use a TunaOS variant daily, you are the best person to write its getting-started guide.

Community​

The project lives in Matrix (#tunaos:reilly.asia). If you are not ready to open a PR yet:

• Answer questions from newcomers in the room
• Triage open issues — confirm reproductions, add logs, mark duplicates
• Join GitHub Discussions and react to release announcements

Testing and reporting​

TunaOS publishes a weekly boot report and runs daily verification across desktop cells. Booting an ISO on real hardware — especially less-common platforms like Apple Silicon (Asahi) or ARM — and reporting what breaks is genuinely valuable work. The verification issues are labeled and tracked; a "works on my machine" report with logs moves the project forward.

Spreading the word​

If you use TunaOS at work or home:

• Add your org to ADOPTERS.md — one-line PR
• Star the repo and share the blog
• Write about your setup; the maintainers read everything

Writing code​

For the full picture, CONTRIBUTING.md has the quick start (just fix && just check), the manifest-driven build model, and the PR process. Desktop environments are declared as YAML manifests — you can add a new flavor without shell scripting at all.

Start today​

Pick a good first issue, drop a comment, and say hi in Matrix. The project is young enough that your first contribution can genuinely shape it.

Some are local QEMU machines on a laptop. Some live in KubeVirt clusters. One Incus server is too useful to replace. One libvirt host answers over SSH. Sometimes a second Corral operates inside Kubernetes, because the local machine has no route to the Kubernetes API.

Corral now treats all of them as one fleet.

A context is a destination, not a global side effect​

The model is deliberately close to kubectx, but it does not mutate kubectl, Incus, or libvirt's global configuration:

corral context add laptop --backend qemu
corral context add homelab --backend kubevirt --context homelab-admin
corral context add lab-incus --backend incus --context lab
corral context add big-iron --backend libvirt \
  --context qemu+ssh://admin@hypervisor/system

corral context use homelab
corral list

The selected context is the default destination for an unqualified create. It does not make the other machines disappear. corral list, the TUI, and the web dashboard continue to show the full fleet. Scripts can stay unambiguous with --backend and --context.

Incus and libvirt authentication also remain boring, which is a feature. Corral uses the trust and credentials of an existing Incus remote. A libvirt qemu+ssh URI uses OpenSSH, including your agent, keys, host verification, and SSH config. There is no second password database to synchronize.

The TUI became a command deck​

corral with no arguments opens the terminal interface. It can fuzzy-search every canonical identity, cycle contexts with Tab, show backend capabilities, and run scoped Doctor checks. Unsupported actions do not tempt you and then fail; they are absent from that instance's action list.

It is the interface I want while living in a terminal: s starts, x stops, Enter opens the full action list, and ? shows the command deck.

The browser is the same fleet​

corral web is not a separate management product. It reads the same contexts, registry, plugins, and peers as the CLI and TUI. The dashboard has bulk actions, tag filters, create flows, health checks, extensions, live consoles, and the backend-specific controls that each VM supports.

A local Corral can also federate an in-cluster one:

corral peer add cluster https://corral.cluster.example --token "$TOKEN"

Guest access is direct-first. If the laptop can reach a VM over Tailscale, an ordinary ingress, or another private route, traffic does not hairpin through two Corral servers. The Corral-to-Corral relay is the fallback for the awkward networks where direct access is impossible. That applies to browser consoles and CLI operations such as corral ssh.

Four backends, tested together​

The built-in backends are now QEMU, KubeVirt, Incus, and libvirt. CI runs a real triple-backend scenario with QEMU, an Incus VM, and a libvirt domain, then checks both CLI aggregation and web inventory. KubeVirt has its own kind cluster browser/API suite.

The interfaces have a no-infrastructure demo too:

corral --demo
corral web --demo

scripts/capture-docs.mjs makes the screenshots in this post from those real demo surfaces. Chromium drives the dashboard and tmux drives the Bubble Tea application. Documentation images are now refreshable test output, not a collection of mystery PNGs from somebody's laptop.

Start with the Corral walkthrough, then read the contexts and authentication guide or the complete command guide.

Corral is my answer to a question I could not put down. The Proxmox experience has a datacenter tree, a create wizard, consoles that open with one click, and VMs beside containers. What if all of it were one static binary? You would point that binary at the infrastructure you have.

The short version:

• Got a Kubernetes cluster? Corral drives KubeVirt through kubectl and virtctl — no operator to install, no agent, no CRDs of its own.
• Only a laptop? The same commands run VMs on local QEMU/KVM under systemd. From this week, the same dashboard shows them under a "local" node.
• Got Tailscale? Every VM lands on your tailnet automatically — SSH from your phone, VNC from the couch.

One binary. create / start / ssh / viewer / clone / delete work identically on both backends, and Corral remembers which VM lives where. There is a TUI for quick jobs, and a Proxmox-style web dashboard for everything else. There is also a compatibility layer for the Proxmox API, if your Terraform provider needs one.

And to be clear about what "one binary" means: the CLI, the TUI, and the web UI are all in it. brew install tuna-os/tap/corral-vm and you have the whole product — there's no separate web package or frontend build to deploy.

Try it in 30 seconds, literally no cluster​

curl -fsSL https://raw.githubusercontent.com/tuna-os/corral/main/scripts/install.sh | sh
corral --demo        # the TUI
corral web --demo    # the dashboard, on Proxmox's port naturally (8006)

--demo boots a fake cluster in memory, inside the binary. It has three nodes and eight VMs. Those VMs show each state you meet in real life. Some run and some do not. One shows a pause, one shows a part-installed system, and one shows a Windows desktop at a pause. One more is an ephemeral scratch VM whose TTL decreases.

The demo cluster also has two containers and live CPU metrics.

This is not a mockup. The real CLI, the real TUI, and the real web UI run their own code against it, and the state is live. Stop a VM in the dashboard, and the TUI agrees.

I built it to improve the interfaces without a cluster, and it became the best introduction to Corral that we have. It's also how CI drives the frontend now — a headless browser clicks through the real dashboard against --demo on every change.

The part I care most about: your OS is a container image​

This is the TunaOS connection. Point Corral at a bootable container image:

corral create dev --bootc ghcr.io/tuna-os/yellowfin:gnome --wait-ssh

It runs bootc install to-disk in a builder VM on the cluster, then boots the result as a first-class VM. Your OS lives in a registry; corral bootc upgrade moves the VM to the next build. Every TunaOS image — and every Universal Blue image, and anything else bootc-bootable — becomes a VM you can summon with one command. Proxmox structurally can't do that.

Containers get the Proxmox treatment too​

corral ct create makes a "pet pod" — a plain Kubernetes pod with a persistent volume and an init process, presented like a Proxmox CT. In privileged mode it seeds a full root filesystem onto the volume, distrobox-style, so apt install survives a restart. There's even corral ct create myproj --devcontainer ./myproj if your project already has a devcontainer.json.

Honest state of things​

v0.1.x, five weeks old. The KubeVirt backend is the most exercised path; local QEMU in the web UI landed this week (lifecycle + info; consoles still route through the CLI). Windows VMs, GPU passthrough, and scheduled snapshots and backups are plugins. They are not all equally mature.

Do you run VMs on Kubernetes, and miss the way Proxmox feels? Or do you run Proxmox, and want one binary in place of an operating system? Give corral --demo thirty seconds. That is the pitch.

Corral is Apache-2.0 at github.com/tuna-os/corral. Stars are welcome: they are the gate to homebrew-core.

Thus most EL sites use Fedora or Ubuntu on the desktop, and something fully different in the datacenter. The result is two package ecosystems and two update rates. It is also two sets of tickets that ask why the same operation is different on the two systems.

TunaOS closes this gap. It gives you true desktop environments as bootc images. They are built directly on the Enterprise Linux base that your servers use now.

The same base, with a true desktop​

Albacore is the primary variant. Its base is AlmaLinux 10, which follows RHEL 10 rebuild for rebuild.

On that base you have a true choice of desktop: GNOME, KDE Plasma, COSMIC or Niri. Each desktop is its own bootc image: ghcr.io/tuna-os/albacore:gnome, :kde, :cosmic and :niri. There are also -hwe and -nvidia images for more recent hardware.

Other variants follow the remainder of the EL family. Yellowfin uses AlmaLinux Kitten 10, the preview of the next major AlmaLinux. Skipjack uses CentOS Stream 10. Redfin uses RHEL 10 itself, and its license lets you build it only locally.

This is not a fork, and it is not a compatibility layer. It is the true AlmaLinux and RHEL package set, with the same lifecycle. A desktop goes on top of it. The pipeline that makes the image is the usual bootc pipeline.

What bootc gives you​

The image is the update. bootc status shows the exact container reference that you booted. bootc upgrade gets the next image, prepares it, and reboots into it. If there is a fault, it returns to the previous deployment.

rpm-ostree on Fedora Silverblue did the same. But here the artifact is an ordinary OCI image. You build it, scan it, and push it with the same registry and the same CI tools as each other product of your team.

For an EL site, this is the important part. Your desktop images can use the same pipeline rules as your server images. Hold a known-good digest for a training laboratory. Push a new tag to send a security fix to all machines. Compare two deployments to see the exact changes.

For none of this do you need a second toolchain. It is the toolchain that you already use in production.

Try it​

Downloads are live at tunaos.org/download, or pull a variant directly:

podman pull ghcr.io/tuna-os/albacore:gnome

The variant table gives the full set of bases, desktops and hardware tags. The bootc usage guide shows the daily bootc commands.

Tell us if something does not operate, or if you have trouble with the download page. Write to us in Discussions. That is what it is for.

This post is about one part that other projects can copy. It shows how a small codebase competes with thirty years of office-suite work, and does not port one line of it.

The problem with "compatible with Word"​

Each alternative office suite makes a claim about compatibility. Almost none of them can say what the claim means. LibreOffice earned its claim across three decades. It has a large set of test documents, and a long history of bug reports.

We had eleven thousand lines of Rust, and a test suite. On day one we found that the test suite had never run. The badge for CI stayed green. pytest || true hid one fact: the runner had no pytest.

Under that badge, the spreadsheet application and the presentation application could not start at all. The save shortcut in the word processor did nothing. Each save discarded the speaker notes.

So this is first a story about honest CI. But red tests tell you only what you already thought to test. The more interesting question is different: how do you test against the files that people have?

Let LibreOffice grade the homework​

Our answer: run LibreOffice headless in CI as an oracle. Do not port its code, its tests, or its data.

There are three mechanisms. Each one has a ratchet: CI holds a count of the tests that pass, and refuses to let the count fall. To raise the count is the definition of progress.

1. Corpora that LibreOffice writes. We write the test scenarios in HTML. At test time, headless Writer makes them into .docx files. Our engine must then extract the same text and the same styles from the file that LibreOffice wrote. We vendor nothing, and the corpus regenerates on each run. Letters has 109 scenarios and passes 109 of them.

   Decks has no cheap input format to author from, so its scenarios go through the oracle instead. We write a .pptx file. Impress imports it, then exports it again in its own grammar. Our reader then reads the version that LibreOffice made. Decks passes 9 of 9, which includes styled runs and speaker notes.

2. Round-trip oracles. Writer, Calc, or Impress must open each file that our engines write. The content must survive the conversion without a change. Both directions gate each commit.

3. Vendored permissive corpora. The 652 examples in the CommonMark specification test the document model for round-trip idempotence, and 594 pass. Another 107 table-driven cases come from ODF OpenFormula, and they measure the spreadsheet engine. All 107 pass. Nine of them started red. Each one was a clean #NAME?, and IronCalc main had the fix already. The ratchet held the gap open until upstream closed it.

The corpus pays for itself continuously. It found table text that our DOCX reader dropped in silence. It found speaker notes that had never survived one save. Best of all, it found a fault that we added ourselves while we added support for images. The ratchet reported it twenty minutes after we wrote it.

A document engine is smaller than you think​

People think the document engine is the difficult part of a word processor. It came to about 2,500 lines of Rust. The large costs are elsewhere, and Rust's ecosystem or the platform pays them for us:

• Pango does the text layout. The platform breaks the lines, shapes the glyphs, and handles bidirectional text, as it does for each GNOME application. LibreOffice wrote its own because it is older than any usable system text stack. We refuse to.
• A library reads and writes the formats. The OOXML package and its XML live in rdocx. We contributed the read getters, and the write support for hyperlinks and images that our fidelity tests needed. IronCalc evaluates the spreadsheets, pulldown-cmark reads the Markdown, and Typst-as-a-library exports the PDFs.
• What remains is the engine. It is a model of paragraphs that hold styled runs, with invariants the code enforces. It addresses offsets in deliberately the same way as GtkTextBuffer, which makes the bridge to the widget a thin adapter. The machinery above measures how honest the format converters are. Decks and Letters share the model: the text boxes in Decks carry the same Run and RunStyle types as Letters.

Some work stays out of scope until it earns an architecture decision: fields, macros, mail merge, tracked changes, and frames that flow text. Our target is the documents that people make. You can read the fidelity off a scoreboard. You do not have to trust us.

The scoreboard, today​

Each number prints into the CI job summary on each push. None of them can go down.

Steal this​

The pattern moves to any project that reads or writes a file format that somebody else defined. Find the reference implementation. Run it headless in CI. Make it write your corpus, and put a ratchet on the count of tests that pass. It costs a few hundred lines of test harness, and it turns "we aim to be compatible" into a number that moves.

Code: tuna-os/gtk-office-suite, GPL-3.0-or-later. The spreadsheet core is on crates.io as tables-core, together with suite-common-core and suite-export. The document model follows as letters-core when upstream accepts its additions to rdocx (tensorbee/rdocx#6).

sudo remora install htop

That is the full interface.

Why the old answers were not sufficient​

On most image-based systems the answer was rpm-ostree install. That command adds package layers to the ostree deployment. It operates, but it is slow, it accepts only RPMs, and it opposes the idea of an image-based system. Your "image" quietly becomes different from every other person's image, and no Containerfile records how it got there.

The bootc community had found a better method. I had not seen a tool that made the method easy. Three sources found the same trick: the Universal Blue forums, akdev1l's zerolayer, and repositories such as renner0e/server. The trick is to operate the image factory yourself, on your own machine.

Keep a Containerfile that derives FROM your base. Build it again on a timer with Pull=newer. Then use bootc switch to move to the result. Your changes become a usual image build. You can examine it, make it again, or reverse it.

The pattern is correct. Only its ergonomics were bad, because it told you to maintain a git repository of build scripts on your server. remora is the same pattern, but it feels like a package manager.

What it does​

A remora is the fish that travels with a larger fish, and that is the name's origin. This tool travels with the image that your system booted:

/etc/remora/remora.yaml ──► generated Containerfile ──► podman quadlet (Pull=newer)
                                                              │  daily / on demand / via uupd
                                                              ▼
                                                localhost/remora:latest
                                                              │
                                                              ▼
                                     bootc switch --transport=containers-storage

sudo remora init prepares all of it. remora install and remora remove change a small YAML file, then build the image again. When upstream releases a new base image, the next build gets it and puts your layers back on top. You cannot become stuck on an old base, and you cannot lose your changes. Each change makes a new image, and bootc rollback reverses a change as usual.

Do you need more than packages? You have three methods. Put scripts in /etc/remora/build_files/. Overlay files with /etc/remora/system_files/. Use extra_run in the manifest for more repositories and keys.

You can do stranger things too. To remora, a BuildStream bst build step is one more build script. remora does not try to contain your tools. It gives them a place in the image build.

One tool, six package managers​

We release 13 variants across each major Linux family. A tool for Fedora alone was never enough. remora finds the base's package manager and builds correctly for it. It uses dnf on Yellowfin, zypper on Sailfin, and pacman on Marlin. It uses apt on Flounder and Grouper, emerge on Guppy, and apk on Alpine bases.

Each manager has its own cache mount, so builds stay fast. A bootc container lint gate stops a bad image before your bootloader gets it.

Your remora.yaml does not know which fish carries it, and does not need to.

dnf install now tells you the truth​

This part pleases me most. On an image-based system, dnf install against the host was always broken. You got an error about a read-only file system, and the error explained nothing. You then had to find the cause yourself. Now:

$ sudo dnf install htop
This is a bootc (image-based) system: /usr is read-only, so 'dnf' cannot change packages here.
Package changes are layered onto your image with remora:
  remora install htop
Run that now? [y/N]

sudo remora shims puts these interceptors in /usr/local/bin. You choose whether to add them, you can remove them fully, and they touch nothing that they did not make. They catch only the commands that would change something: dnf search, pacman -Q, and apt show continue as usual. Twenty years of muscle memory now points you at the correct tool.

Updates go through uupd​

We already use uupd for updates. It knows the battery state, it does not overload a metered connection, and it obeys inhibitors. remora does not do that work again. When uupd is on the system, remora init adds a two-line systemd override. Each uupd run then builds your local image first and gives the result to uupd's usual process. remora adds no daemon, no dependency in either direction, and no second schedule for you to remember.

Try it​

TunaOS images include it. It is also a static binary for other bootc systems:

sudo remora init
sudo remora install htop cmatrix
sudo remora enable        # build again automatically
remora status

The documentation has more, and the source is at tuna-os/remora. This point is worth a second statement. The pattern of a local image factory comes from the Universal Blue community, from zerolayer, and from renner0e. I only tried to make it feel like a package manager, and not like a git repository that you tend.

The fish rides on. 🐟

I didn't come up with this idea, to be clear. Bedrock Linux was mixing packages from different distros on one system back in 2012. Lennart Poettering wrote the whole blueprint out in his mkosi posts — sysext, confext, repart, UKIs, the works. CarbonOS took a run at OCI image delivery with btrfs snapshots on Fedora Atomic back in 2021. And Jessie Frazelle was running her whole desktop out of Docker containers in 2015, which honestly should have gotten more attention than it did. Everyone kept poking at the same idea from a different angle.

What actually made it usable were two things. bootc — you get an OCI image, you switch to it, it's atomic, and you can roll back if you screwed something up. And Project Bluefin proved people would actually use this every day, not just as a tech demo. Once I saw that working at scale I started wondering how far you could actually push it.

So that's what TunaOS is, I guess — pushing it. We ship 12 variants right now across 5 package managers and pretty much every major Linux family, and they all end up as the same desktop experience underneath. If you can swap the base OS out from under a desktop and nothing changes, the distro isn't really a decision anymore. It's just a setting.

It's a factory, not a distro​

I keep saying "TunaOS" like it's one thing, but really it's a factory that spits out images. The inputs are just data:

base OS + desktop + kernel + drivers = bootable image

Out the other end you get an OCI image you bootc switch to, atomically, with rollback if it goes bad. Want a different desktop on the same base? Switch. Want a beefier kernel? Switch. The whole matrix is on the menu:

# Same base, different desktop
sudo bootc switch ghcr.io/tuna-os/marlin:kde
sudo bootc switch ghcr.io/tuna-os/marlin:gnome

# Same desktop, different kernel
sudo bootc switch ghcr.io/tuna-os/marlin:kde-hwe

Cross-family migration (AlmaLinux → Arch in place, say) is on the roadmap but not there yet. Even just same-family switching already makes the base OS swappable in a way regular distros never let you do.

Under the hood it's the same stuff server folks have been using for years — bootc, CI, Podman. We're basically just treating the desktop like a container deployment. Nothing revolutionary, the server side figured this out a while ago, the desktop's just catching up.

The variants​

Everything's named after a fish, because I like fish and also because "AlmaLinux 10 + KDE + hwe kernel" is a mouthful. 12 of them right now:

Variant	Base Distribution	Status
🐠 Yellowfin	AlmaLinux Kitten 10	Stable
🐟 Albacore	AlmaLinux 10	Stable
🍣 Skipjack	CentOS Stream 10	Beta
🔒 Redfin	RHEL 10	Local-build
🎣 Bonito	Fedora 44	Beta
🐉 Bonito Rawhide	Fedora Rawhide	Beta
🐟 Grouper	Ubuntu 26.04	Beta
🐡 Flounder	Debian Trixie (13)	Beta
☢️ Flounder Sid	Debian Sid	Beta
🚀 Marlin	Arch Linux	Beta
🦈 Sailfin	openSUSE Tumbleweed	Beta
🌈 Guppy	Gentoo Linux	Beta

Most variants get the same 5 desktops: GNOME, KDE Plasma, COSMIC, Niri + DMS, and XFCE on Wayland. Guppy ships 2 (GNOME, KDE). Sailfin ships 4 (no COSMIC). Stack a custom kernel or NVIDIA drivers on top of any of them if you want.

How this got easier​

Not that long ago, adding a new base OS meant writing a few hundred lines of shell. Now it's three things:

1. A Containerfile that bootc-ifies the stock image (started from bootcrew's base images, saved me a ton of work)
2. A package manager manifest (pacman:, apt:, whatever) listing what that OS needs for each desktop
3. An entry in build-config.yml — name, base image, platforms

That's the whole job now. CI does the rest and spits out container images and ISOs on its own. No per-distro bash, no combinatorial mess of per-desktop-per-distro scripts to keep in sync.

The desktops themselves​

Mostly the same desktops on every variant, and none of them are built from scratch — we're layering existing customization work on top of stock packages and just running that layer across every base OS we support. Each one has an upstream project doing the actual hard work, and honestly they deserve more credit than they get.

GNOME​

GNOME already looks good out of the box, but we still pull from Project Bluefin's common layer on top of it — dev tooling, curated Flatpaks, and just years of them running bootc desktops in the real world that we'd be dumb not to use. Every GNOME image we build, Arch or Fedora or Gentoo, gets the same Bluefin layer. They also have a distroless BuildStream build on freedesktop-sdk if you want to go further down that hole.

KDE Plasma​

Plasma's look comes from Aurora's common layer — theming and branding that makes stock Plasma actually feel like one coherent thing instead of a pile of defaults. That's what gives our KDE its look across all 12 bases. They've also got a source-based BuildStream build on freedesktop-sdk if you're into that.

Niri + DMS​

Niri is a scrollable-tiling compositor — windows line up horizontally on a ribbon you scroll through instead of stacking into workspaces. It's the odd one out in the lineup and probably the most "pure Wayland" thing we ship.

We pair it with DMS (DankMaterialShell) for the greeter, a control panel, and app launching. So the stack is greetd → Niri → DMS. DMS is still pretty early but it's enough to make Niri feel like an actual desktop and not just bare windows on a ribbon.

Config and theming come from Zirconium, same deal as Bluefin and Aurora — one layer, applied everywhere.

XFCE (Wayland)​

XFCE 4.20 shipped experimental Wayland support with a new compositor, xfwl4, replacing the old X11 xfwm4. It's still maturing but it's already good enough to daily-drive on Fedora and EL10 — we ship the optional xfce4-wayland package and default to GDM so the Wayland session actually shows up in the login list. Basically: XFCE, but with tear-free rendering and per-monitor refresh rates now.

XFCE's the only desktop here without a dedicated customization layer — no Bluefin, no Aurora, no Zirconium equivalent. If you use XFCE and have opinions on what it should look like, I'd take the help.

COSMIC​

COSMIC is System76's Rust desktop, Wayland from the ground up. We ship it mostly stock — it's already opinionated enough on its own that it doesn't really need our fingerprints on it.

Same story as XFCE — no dedicated layer yet. If you want to be the person who defines what a curated COSMIC setup looks like across every variant, go for it.

What's next​

• Getting CI actually green across all 12 variants on all platforms (we're not there yet, not going to pretend otherwise)
• More desktops — Hyprland, Sway, Budgie are basically just a manifest file away at this point
• Cross-backend migration — bootc-migrate-composefs (alpha) does OSTree → ComposeFS in place, cross-family (AlmaLinux → Arch) is the next hard problem
• Letting people contribute a desktop definition without having to touch the actual build scripts

Credit where it's due​

None of this happens without a bunch of other projects doing the hard work first. If any of this is useful to you, go support the people who actually built it.

Infra​

• bootcrew — reference bootc setups for Arch, Gentoo, openSUSE, Debian
• atomic-shindig / shindig-deb — bootc-deb packaging for Ubuntu and Debian
• Universal Blue and Project Bluefin — did the bootc desktop thing at scale before anyone else
• bootc — none of this exists without this project

Desktop upstreams​

These are the folks whose customization layers we're shipping. They did the actual work of making each desktop feel cohesive — go support them if you can.

Project Bluefin (GNOME): sponsor @castrojo · sponsor @tulilirockz

Aurora (KDE Plasma): sponsor @NiHaiden

Zirconium (Niri): sponsor @tulilirockz

The desktops themselves​

And obviously the desktop environments are their own massive community efforts, worth supporting directly too.

• Donate to GNOME
• Donate to KDE
• Donate to XFCE
• Sponsor Niri

Full list on the Support page if you want more ways to help out.

Pick your fish. It's less of a decision than it used to be.

What it was before​

Every desktop had its own 150-line bash script — gnome.sh, kde.sh, cosmic.sh, niri.sh, xfce.sh. Each one was a pile of if fedora; dnf install X; elif el10; dnf group install Y; fi. Wanted GNOME 50? Copy-paste gnome.sh and hope you didn't miss a spot. Wanted Ubuntu support? Go add elif apt; pkg_install Z to five different files and pray you got them all consistent.

The Justfile wasn't much better. The _build recipe was 150 lines of positional arguments, and if you wanted to know what arg 7 did you had to go read the whole signature. Not fun to touch.

What it is now​

Desktop manifests​

Each desktop is now a YAML file in manifests/desktops/:

# manifests/desktops/kde.yaml
display_manager: sddm
packages:
  fedora:
    groups: [kde-desktop]
    packages: [sddm, dolphin, konsole, kate, ...]
  el10:
    groups: ["KDE Plasma Workspaces", ...]
    optional: [kdeconnect, nvtop, ...]
  pacman:
    - plasma-desktop
    - sddm
    - dolphin
    - konsole
  apt:
    - kde-plasma-desktop
    - sddm
versionlock: [plasma-desktop, "qt6-*"]

One generic installer (install-desktop.sh) reads the manifest and does the rest — groups, packages, COPRs, version locks, enabling the display manager, all of it.

Pulling the build engine out​

The _build monolith in the Justfile is now scripts/build-image-inner.sh — 198 lines, driven by env vars instead of 11 positional args you had to memorize. The Justfile itself is down to a 25-line wrapper.

Flavor resolution​

scripts/resolve-flavor.sh maps a flavor to its build params now, and I actually wrote 18 BATS tests to cover the paths instead of just hoping. The old 50-line if/elif/case block in the Justfile is just gone.

Numbers, if you like that sort of thing​

What's next​

Manifests now cover 4 package managers — dnf, apt, pacman, zypper — and I've since added Arch (marlin) and Debian (flounder, flounder-sid) on top of it. The matrix just keeps growing:

9 base variants × 5-6 desktops × 3 hardware layers

Adding a new distro at this point is: write a Containerfile that bootc-ifies it, add the pacman/apt/dnf sections to the manifests, done. The build system doesn't care what you throw at it.

Quick version of what TunaOS is: bootc-based, immutable desktop images built on top of Enterprise Linux — AlmaLinux, CentOS Stream, Fedora, that kind of thing. If you have used Bluefin or Bazzite, you know the idea. We do the same for the EL side of the world too.

What's actually in it​

You select your desktop — GNOME, KDE Plasma, COSMIC, XFCE, or Niri — and each one runs on that same Enterprise Linux base. bootc makes each update atomic. If an update fails, you go back to the last one. There is no cause for alarm.

Where things are at​

We're still early but it's moving fast:

• 47 stars on GitHub. That is not many, but the number goes up
• 4 desktop variants across a handful of base OS options
• -nvidia variants with NVIDIA/CUDA baked in if you're doing AI/ML stuff (formerly the -gdx suffix)
• A Rust-based office suite — Tables, Decks, Letters — because why not
• Some ecosystem tools too: Corral for VMs, Tacklebox for multi-boot USBs, Tavern as a Homebrew GUI

What's next​

More desktops, better GPU support, actual documentation instead of tribal knowledge, and hopefully some community stuff down the line. We'll see how it goes.