Fedora Atomic Linux

Not sure what we should call this relatively new technology that is sweeping the internet right now, but it looks like “image based Linux” is a popular term at Red Hat, Red Hat being one of the main contributors to this tech.

I am partial to the name Atomic Linux though, sounds like a powerful new distro. 😉 Endless OS is a Debian variant of image based Linux.

I wrote about CoreOS before, and I started using the immutable distro Fedora Silverblue back in 2022. Since then I have switched my workstation to what is currently known as Fedora Atomic Sway, which is a spin-off of Silverblue with the more minimalistic Sway Window Manager instead of Gnome.

Again I must say that I am very happy with this new modus operandi for Linux. The very first thing that impressed me was how the Fedora Silverblue workstation OS seamlessly allows the end-user to rollback their entire system to a previously working state.

I’ve been using Linux for 25 years at this point but I never recommended it to people outside of tech, because I knew that issues will happen sooner or later, and when they do happen you needed advanced skills to troubleshoot them.

To most people who use their computer for work a show stopping issue due to a package upgrade, or distro upgrade, is a disaster. All people want is to turn back the clock to when they had a working computer.

Until recently this could be achieved using BTRFS snapshots, and custom modifications to the boot manager. Something only advanced Linux users could setup, and maintain.

Now with Fedora Atomic anyone can achieve the same result.

Everything is a layer now.

In image based Linux you cannot install packages the same way you did before using yum or dnf, every change you do to the system must be layered, and each layer is bootable. So every change you make will generate a new Grub boot entry, automatically. If the new change causes problems you can simply reboot and select the previous image layer, and continue working until the issue is resolved by the project maintainers.

You can even switch to a completely new OCI image and try something radically different on your laptop for a while, before switching back to your original image layer. This is called rebasing and is how you upgrade from Fedora 40 to Fedora 41 for example.

Pros

Here are some of the advantages I see.

  • Security - traditional attacks that write files to the system partitions no longer work.
  • Stability - you can revert back to a known good state.
  • Simplicity - It’s integrated with the OS so anyone can use this.

Cons

Some negative aspects.

  • Adding just one package requires a reboot. There is a workaround to this by live-adding packages but I personally rarely use it.
  • For power users it requires a complete change in mindset.
  • Uses more storage. I recently had 3 different layers bootable and this took up 14G of storage by ostree.

What about servers?

Same concept for servers, it just doesn’t include a window manager or wayland display server.

I’ve been using Fedora CoreOS for a while now and wrote a little bit about how in this previous blog post.

Essentially the major shift in mindset is from a traditional Linux server that you install, login on, run commands, logout, upgrade. To the new mindset that focuses on Infrastructure as Code, everything your server is can be defined in a git repository and any changes to your server are pushed from this central source of truth.

The first thing people worry about is: how do I experiment with stuff until they work? No more of that type of work in production, but you can still do it in staging and lab environments, where you test your IaC before you provision your production environment.

The old way of working on Linux servers was very short sighted and caused a lot of problems like configuration drift and difficulty to rollback changes.

Deploying directly on bare-metal

I just learned today about bootc-image-builder that promises it can take a bootc OCI image and convert it into other well known image formats like OVA and ISO, that can then be deployed as virtual machines or on bare-metal servers.