People have poked at the immutable desktop from a lot of directions. Some mixed distributions on one system, some delivered a whole OS as an OCI image, and some ran a desktop out of containers. What made the idea usable were two things. bootc turns the OS into an ordinary OCI image that you switch to atomically and roll back from. Project Bluefin proved that people would use a bootc desktop every day, not only as a demo.

Today the landscape has three corners. Fedora Silverblue showed that an atomic desktop could work with rpm-ostree. Universal Blue and Bluefin showed that bootc desktops can run at scale. TunaOS does the same idea on the Enterprise Linux side.

TunaOS is a small project with an outsized goal: an enterprise-grade, cloud-native desktop that tracks current software without abandoning Enterprise Linux lifecycles. It is built by a small core team — and it should not stay that way. This post lays out every way to get involved, from a five-minute docs fix to building a whole new desktop flavor.

My VMs have escaped the cluster.

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.

I love Proxmox. I have run it for years. But Proxmox is a distribution. It owns the full machine, and Debian holds it tight. If your infrastructure has moved to Kubernetes, Proxmox becomes a second world. You must maintain it next to the first one.

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.

Enterprise Linux has a problem with the desktop. RHEL, AlmaLinux and CentOS Stream are made for servers. They are strong, they have a long life, and they are stable to the point of tedium. For a fleet of production hosts, this is correct. But it is not correct for the machine that a developer or an administrator uses each day.

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.

People have poked at the immutable desktop from a lot of directions. Some mixed distributions on one system, some delivered a whole OS as an OCI image, and some ran a desktop out of containers. What made the idea usable were two things. bootc turns the OS into an ordinary OCI image that you switch to atomically and roll back from. Project Bluefin proved that people would use a bootc desktop every day, not only as a demo.

Today the landscape has three corners. Fedora Silverblue showed that an atomic desktop could work with rpm-ostree. Universal Blue and Bluefin showed that bootc desktops can run at scale. TunaOS does the same idea on the Enterprise Linux side.

We write a GNOME-native office suite in Rust. It has three applications: Letters for text, Tables for spreadsheets, and Decks for presentations. They use GTK4 and libadwaita, and we release them as Flatpaks.

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.

Users of each image-based distribution ask the same question. How do you install one package? This is my answer. Its name is remora. It adds local layers in the container-native way. It operates in the same manner on each variant that we release, and the base can use dnf, zypper, pacman, apt, emerge, or apk.

sudo remora install htop

That is the full interface.

Picking a Linux distro has always felt weirder to me than it should be. Most of them are like 95% the same packages with 5% different defaults, and yet somehow choosing one feels like a permanent decision you're stuck with forever.

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.

Biggest change to the build system since I started this thing: desktops are now just a YAML file. No shell script per desktop, no touching the Containerfile, no CI edits. Wanted to write this one up because I'm pretty happy with how it turned out.