Regular containers also happen to work great for testing dotfiles.
Many years ago I added an install script to https://github.com/nickjj/dotfiles to get set up in basically 1 command because I wanted a quick way to bootstrap my own system. I used the official Debian and Ubuntu images to test things.
Over the last few days I refactored things further to support Arch Linux which has an official Docker image too.
This enables being able to do full end to end tests in about 5 minutes. The container spins up in 1 second, the rest is the script running its course. Since it's just a container you can also use volume mounts and leave the container running in case you want to incrementally test things without wiping the environment.
Additionally it lets folks test it out without modifying their system in 1 command. Docker has enabled so many good things over the last 10+ years.
I really like the idea of immutable Linux and bootable containers. My next project will probably be switching to bazzite. But I took a look at the Containerfile[1], and I have some big concerns about the fragility of their supply chain. It uses 20 different copr repos (granted, half are their own), and I didn't count how many packages. Best I can tell, none of the versions are pinned. They do dump a diff of all package versions in the release notes[2], but I wonder if anyone actually reviews it before release. All it takes is one vulnerability in one repo / package and you can enjoy your new cryptominer.
There's something nice about running Debian and having confidence in all the packages because they're built and maintained by the Debian team. Of course there are exceptions, but in my experience they're rare. The only non-standard repo I regularly use is fish shell, and the updates are so few and far between (and very public) I think the risk is low.
I suppose this isn't strictly a container-specific problem; you could add the repos and install / update all those packages yourself too. But being able to package everything up into a single file that you can then boot into as your OS means you're also packing all the supply chain risk.
Curious if anyone else shares my concern or if I should just put my tinfoil hat back on...
Right but everytime a new immutable release is created, it automatically pulls the latest version of every package. It's not a manual change of package versions.
Nothing holds you from using bootable containers in the same way you use Debian and only use packages from the official Fedora repositories, starting from Fedora's bootc base images.
Great, original article. I didn't notice at first that this blogger is the very same author behind Blue95: https://github.com/winblues/blue95
I used to love theming my desktop environment, but the joy faded when I realized the UI felt much more magical than anything I was using it for. Wonderful application of the tech, though.
Sometimes I wonder why there isn't more enthusiasm around theming. Chicago95[0] is popular, but I also love how Garuda[0] themes KDE. There's some small websites for downloading themes on various DEs, but most of them are a bit jank and it seems built-in support beyond basic things like accents aren't there.
The Gnome/gtk folks have been systematically removing theming capabilities for the last decade+ in the pursuit of an Apple-like philosophy towards ui. This has really killed a lot of theming because so many apps use GTK.
Even before that, GTK app theming was a bit hit or miss, likely because of the way GTK uses CSS for themes.
Personally I believe CSS to be quite ill-suited for the purpose. It’s ok if you’re writing a theme for a bespoke one-off app but breaks down in the system theme use case. In particular, CSS inheritance makes for a lot of unnecessary trouble for both third-party themes and accessibility affordances.
Last I knew there was something of a disinclination away from paramaterization in the GTK dev sphere too, which is another significant problem for third party themes and accessibility. Hardcoded fonts, colors, etc makes for pointless brittle rigidity.
Before css there were engines, which were like families of themes. One of them was the pixmap engine which was what it sounds like: it used images to make up elements of the theme. Some of the most ambitious themes used this engine. CSS didn’t come until much later.
Perhaps with all these changes to GUI since initial Shell release their goal is to enter some niche mobile market and call job done. Because nothing else explains all this interface gutting out they did over 14 years.
Once they finish sucking donations and other forms of financial support they'll probably announce it's time to "sunset" Gnome/gtk because it sadly didn't met unspecified expectations of unspecified group of people.
Gnome team, what they did and what they still want to do, their attitude towards users - especially those who dare to criticize them is THE result of polluting FOSS with corporate style of software development.
Theming and customization of Linux is half-dead because of what happens at Gnome.
Chasing after The Year of Linux on the Desktop is the community's great white whale. The thinking seems to be that if Linux can be made to look enough like the major mainstream OSes, the masses will flood into Linux and the people who lead them there will get to be the heroes of the day. Problem is the mainstream OSes make UI decisions for many reasons, and the end user often isn't the main concern. Linux could, and in the past did, make itself the OS of user empowerment and choice instead of being a watered down version of whatever is in fashion with the PMs at Microsoft, Apple, and Google.
I think there are many problems with GNOME and GTK. Some programs require GTK, but other than that I avoid them when I can. The theming is not the only problem, but it is one of them.
I used to really enjoy theming and Riceing, but then I realised it was pointless: my monitor always looks the same, with a full screen IDE window covering up all my fancy themes
I think that speaks to another aspect, individual apps taking full control over how they're presented instead of inheriting whatever framework the DE is providing or the cohabitation of various KDE/QT/GTK/X/other, or electron framework defaults. Over on windows even when uxtheme skinning was in full swing it was the start of applications doing it themselves (winamp and quicktime come to mind), but I have the impression developers doing so made sure the extra effort had a payoff.
I think most bootc-based systems keep /etc, /var and others. So, it is more like Nix without impermanence where you can atomically change/update/rollback your system, but keep some system state.
Many years ago I added an install script to https://github.com/nickjj/dotfiles to get set up in basically 1 command because I wanted a quick way to bootstrap my own system. I used the official Debian and Ubuntu images to test things.
Over the last few days I refactored things further to support Arch Linux which has an official Docker image too.
This enables being able to do full end to end tests in about 5 minutes. The container spins up in 1 second, the rest is the script running its course. Since it's just a container you can also use volume mounts and leave the container running in case you want to incrementally test things without wiping the environment.
Additionally it lets folks test it out without modifying their system in 1 command. Docker has enabled so many good things over the last 10+ years.
There's something nice about running Debian and having confidence in all the packages because they're built and maintained by the Debian team. Of course there are exceptions, but in my experience they're rare. The only non-standard repo I regularly use is fish shell, and the updates are so few and far between (and very public) I think the risk is low.
I suppose this isn't strictly a container-specific problem; you could add the repos and install / update all those packages yourself too. But being able to package everything up into a single file that you can then boot into as your OS means you're also packing all the supply chain risk.
Curious if anyone else shares my concern or if I should just put my tinfoil hat back on...
1. https://github.com/ublue-os/bazzite/blob/main/Containerfile 2. https://github.com/ublue-os/bazzite/releases/tag/42.20250417
From your link, everything is pinned? So a theoretical exploit in a future release of package is not going to exist in this immutable release https://github.com/ublue-os/bazzite/releases/tag/42.20250417
I used to love theming my desktop environment, but the joy faded when I realized the UI felt much more magical than anything I was using it for. Wonderful application of the tech, though.
[0] https://github.com/grassmunk/Chicago95 [1] https://garudalinux.org/editions (screenshots don't do it justice)
Personally I believe CSS to be quite ill-suited for the purpose. It’s ok if you’re writing a theme for a bespoke one-off app but breaks down in the system theme use case. In particular, CSS inheritance makes for a lot of unnecessary trouble for both third-party themes and accessibility affordances.
Last I knew there was something of a disinclination away from paramaterization in the GTK dev sphere too, which is another significant problem for third party themes and accessibility. Hardcoded fonts, colors, etc makes for pointless brittle rigidity.
Once they finish sucking donations and other forms of financial support they'll probably announce it's time to "sunset" Gnome/gtk because it sadly didn't met unspecified expectations of unspecified group of people.
Gnome team, what they did and what they still want to do, their attitude towards users - especially those who dare to criticize them is THE result of polluting FOSS with corporate style of software development.
Theming and customization of Linux is half-dead because of what happens at Gnome.
I also don't think the distinction between distro and container is murky at all.
I guess the equivalent in the NixOS world would be its impermanence module, which erases root on every reboot to keep things as stateless as possible.