Framework x Silverblue -> Indestructible

My Framework laptop finally arrived! Ever since I ordered it back in May I’ve been anxiously awaiting it. My previous laptop, the Xiaomi Mi Air 13 (or something like that) has been a big disappointment ever since I received it back in 2017 or 2018. It’s two main issues were battery life and performance, although it has the same sized battery as the Framework (at around 55Wh) it could only last around 2 hours off of charge. It’s performance was abysmal with the dual core i5-7200U and unfortunately I would struggle with 8GB of RAM at times, especially when running a VM.

I’ve written up a complimentary post about my experience running various Linux distributions on the old laptop. It’s not the most interesting read in the world but I think it provides decent context for my preferences with my new laptop. The TL;DR of it is I switched distributions many times, and over time weird glitches would creep in. That said the last run I had with Ubuntu 20.04 was pretty solid, being fairly reliable for over 9 months.

This blog post isn’t a full review of the Framework laptop. Rather it’s about a realisation I made: the Framework and Silverblue have a similar appeal, breakages are recoverable and upgrades are clean.

The Framework Laptop

For those who don’t know the big appeal of the Framework is that it’s modular. You can easily swap out just about every component of the laptop. This is useful for both repairs and upgrades. Amazingly, this year Framework upgraded the main board from 11th gen intel to 12th gen.

The unit I received has a slight bend in the ‘input cover’ (the keyboard) just below the space bar which makes it just a little bit mushy. I contacted framework about it and they’ve sent me a new input cover! This is basically unthinkable or any other laptop. Best case scenario for most other laptops is you part ways with your device for the repairs to be completed. Worst case scenario is you just have to put up with the issue.

With the framework I can keep it with me the whole time and I can essentially atomically repair the laptop. In computing an atomic operation means that the operation either hasn’t happened or it has happened with no in-between. This is major because I’m never without a computer other than for the low amount of time required to complete the repair.

With most other laptops various things are going to wear out or slow down to the point where you just get an entirely new device. With the Framework you can breathe new life into it with no strings attached. This model is similar to Fedora Silverblue.

Fedora Silverblue

Before receiving my Framework I really wasn’t sure which distribution I was going to put on it. Even on the day of it arriving I wasn’t sure. It was between Silverblue, Fedora Workstation, Pop!_OS and NixOS. There are pros and cons to all of these options and I certainly don’t think there is an outright winner in this competition. I tried Silverblue and NixOS in virtual machines to see if I could handle the learning curve.

Despite me having a negative opinion of Silverblue only a few days before installing it on the Framework, something pushed me towards it. Maybe it was novelty but I think there’s more to it, my experience with other Linux distributions tending to get messier and more glitchy over time. Also, I’d had experiences in the past where upgrading distribution either failed (luckily it failed before anything irreversible happened) or when I did upgrade, things weren’t ‘as good as new’, there was still some cruft. These are things that Silverblue can help with.

So what is different about Silverblue compared to a more ordinary distribution like Fedora Workstation? Well the core operating system that is booted is an immutable image, so during use you can’t mess your base system up. You can ‘layer’ RPM packages on top of the base image, next time you boot you’ll boot a new image with the base image and the layered packages. Every time you create new bootable images you’ll retain the last one. So let’s say I upgrade my OS by running rpm-ostree upgrade and I reboot my system only to find that something broke. I can run rpm-ostree rollback, next time I reboot the old image will be loaded.

I think it’s worth mentioning that you still have regular access to certain directories that are crucial for a relatively normal Linux experience. You can still edit stuff in /etc, /usr/local, obviously your home directory, and a few other locations. Your changes in /etc are partially tracked, you can run sudo ostree admin config-diff to view which files you’ve modified and created.

Most of your graphical applications are Flatpaks which are more or less completely independent of the base OS. For CLI applications, Silverblue comes with Toolbx (formerly Toolbox) which is a tool for creating tightly integrated Fedora Workstation containers which share your home directory. I’ve opted to create one big Toolbx container for all of my CLI needs. I’ve tried to make it at least somewhat reproducible as you can build these container images with Containerfiles (basically a Dockerfile as far as I know). I have a Containerfile which downloads most of the tools I need to be productive. This is cool because if I break my Toolbx, I can simply build a new one and start using it with very little effort. If I was running Fedora Workstation full-time and broke something it would be a much more high stakes situation.

The rpm-ostree upgrades and rollbacks don’t touch the directories I mentioned earlier, and it doesn’t touch your Flatpaks and Toolbxes. So you could upgrade your system, get loads of work done, change your /etc config files, make loads of changes in your Toolbx, download new Flatpaks then realize that something broke with your upgrade. Don’t panic, simply rpm-ostree rollback, your problem was fixed and none of the aforementioned things have changed. They’re just how they were last time you used your computer.

Framework x Silverblue

So, what’s the connection here between Silverblue and the Framework? You can swap the various components in and out independently. You can break things and recover as though nothing bad ever happened. Also, I think there’s a decent analogy between the upgrading process of a Framework and Silverblue. When you upgrade the main board of the Framework you can simply take out the old one, plug in the new one and you’re good to go. With Silverblue, when upgrading from say Fedora Silverblue 35 to 36 you essentially just swap out the 35 image, plug in the 36 image, reapply your layerings and you’re good to go.

So if you’re running Silverblue on a Framework you have one durable setup.