In the past few months, I’ve come across two interesting and impressive projects. First, Omakub, an omakase developer setup for Ubuntu 24.04+ by DHH, whom I greatly respect. Second, Project Bluefin, an opinionated Linux workstation built on atomic Fedora images (Fedora Silverblue, specifically). I couldn’t help but see this as an opportunity to learn more about immutable operating systems and spin up my own version.
Why Are “Atomic” OS Images So Interesting?
In a nutshell, and completely repeated from the many landing pages of these immutable OS versions, workstations based on atomic Fedora images are interesting for a few core reasons.
- Reliability: Each version is updated for approximately 13 months, and each update takes effect on your next reboot, keeping your system consistent. You can even keep working while the updates are being applied!
- Atomic: The whole system is updated in one go, and an update will not apply if anything goes wrong, meaning you will always have a working computer.
- Safe: A previous version of your system is always kept around, just in case. If you need to go back in time, you can!
These three properties in a Linux desktop provide an opportunity to get some of the best of both worlds: the reliability and ease of use of a Chromebook, with the power of a Linux desktop.
Put another way, if any of you are like me and often play the role of family IT support, you would likely agree that the best OS for the non-technical, aging user and the best OS for me, the developer, are almost certainly very different. However, these universal blue images are, in many ways, making a unique argument that the answer could be the same!
In fact, it seems to me that the update model is uniquely user-friendly. In macOS, major updates take literal hours. Same with Windows. Typical Linux is faster, but things might break, and you might end up cleaning things up yourself.
Here, you just don’t need to think about it—it will happen, like a Chromebook.
I had never used any of these before, so I was eager to give them a try.
In particular, I’m not a fan of Gnome on old laptops—it’s too slow. But, along this exact vein, it turns out there is a community-built version for Sway: https://github.com/wayblueorg/wayblue
Why Is Omakub So Inspirational?
Among developers, we are used to seeing people’s personalized dotfile repositories, often managed with something like chezmoi.
It’s much rarer to see someone produce an incredibly thoughtful, polished one-line-installable script that takes a freshly installed OS and turns it into a complete dev-ready workstation.
Omakub is just that.
It turns a fresh Ubuntu installation into a fully configured, beautiful, and modern web development system by running a single command.
In fact, Omakub is what DHH uses as the default starting point for his companies, now that they have moved from macOS to Linux.
The code is in pure Bash scripts, wonderfully organized, with a lovely manual. It is a prime example of craftsmanship. DHH had a problem, he solved it, and it was done.
Introducing Omakase Blue
With that context in mind, let me introduce Omakase Blue.
omakase-blue turns a fresh Wayblue Sway installation into a fully configured development system by running a single command.
No need to write bespoke configs just to get started or catch up on the latest command-line tools.
It includes a highly curated set of applications and tools that I have discovered, tested, and found to be highly useful from reading blogs, news aggregators, etc.
In addition, it includes default dotfile configurations for most of these tools that feel coherent.
It is a codification of the toolbox I typically use to work.
Nothing here is unique, and in fact, I’m highly confident that (1) there are many other ways to do things and (2) many of those other ways are in fact even better than what I’ve done here (and I would love to know about it, send tips my way!). However, it is tailored and appreciated by me.
For those unfamiliar with Bluefin (like I was), here are some more details I hope provide a useful mental model for this setup. Bluefin’s developer mode encourages the following pattern:
- Development done in devcontainers
- Command-line applications installed using Homebrew
- GUI applications installed via Flatpak
- Other things being done in Distroboxes
I break from this pattern in a few ways. First, I don’t like devcontainers. Not on principle, but because Helix, my editor of choice, doesn’t integrate with them, so I’ve never used them in the past. Second, I like to be on the bleeding edge for many CLI applications. For example, for those written in Rust, I like to build them from source and update via cargo-update. Third, I don’t ever have a need for many pet containers running a mishmash of distributions. I just want a familiar dev terminal, even though I’m using an immutable OS.
Furthermore, I want to fully embrace the idea of an auto-updating foundation of software.
So rather than a “pet container” that you essentially need to set up just like a normal desktop, I use podman quadlets to deploy an ephemeral toolbox container that is built on an image I also control and refine to include everything I want in it.
This is a tradeoff: if I want something else in my containerized dev environment, I need to add it to the base image because if I just install it, it would disappear next update.
But, if I do, I know it will be there and auto-updating forever.
Users of omakase-bluefin should likely fork and create their own personalized toolboxes for this reason.
In the end, here’s how it looks.
How omakase-bluefin works is it first installs terminal-related tooling.
It does so using brew on the host, and then setting up the omakase-toolbox ephemeral image (again, users are encouraged to fork and make their own).
That image is already customized with a variety of tooling simply installed with dnf install, which is consequently only accessible within the container (as indicated by the blue).
Then, for a bunch of useful CLIs, we build from source (e.g., using cargo) from within the toolbox (which has all the necessary dev libraries, unlike the host).
These binaries typically end up in the home directory, consequently, are accessible to both host and container.
Then, we install and configure the desktop apps (e.g., web browsers, image editors, PDF readers, etc.)
We configure GNOME to our liking (e.g., with PaperWM, along with a handful of other tweaks).
Finally, we set up .desktop applications that are useful.
In particular, we set up two WezTerm shortcuts, one that runs on the host, and one that automatically opens a shell in the toolbox.
I prefer WezTerm to the built-in ptyxis since it is more full-featured (e.g., ligatures, better performance, etc.).
Finally, we do allow the container to execute commands on the host automatically if the command is not found in the container, giving access to things like podman or docker.
Summary
omakase-blue is a set of scripts which sets up an omakase developer workflow from a fresh wayblue sway installation.
In addition to specific tooling, along with their configuration defaults, we set up an ephemeral Distrobox container.
My workflow is essentially that only GUIs are used on the host, and the rest of my time is spent inside the container.
With this setup, I avoid the pitfall of feeling like I need to set up multiple computers (i.e., the host + whatever containers I am using).
Instead, I use this atomic OS almost the same as I would any other.
Since the terminal directly launches the container, I almost don’t notice I’m in a container at all.