Skip to content(if available)orjump to list(if available)

The Joy of Linux Theming in the Age of Bootable Containers

Havoc

I find LXC a bit more intuitive as testing platform than docker. Much of a sameness I suppose.

Also discovered that for me it’s less the OS or paradigm or theme/look and more that the windows manager is tiling type.

nickjj

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.

gbraad

No place like ${HOME} https://dotfiles.gbraad.nl ;-). I went further and generate images to easily spin up development environments, based on bootc vms or containers.

Never stop tweaking. No computer can be called home until it runs your own set of aliases/commands.

bagatelle

Just glancing through your dotfiles, I was wondering why you use VcXsrv. WSLg has always been fine for me, and I've never heard of anyone trying to use a different X server.

nickjj

Thanks a lot for the reminder.

I just pushed an update to remove VcXsrv at: https://github.com/nickjj/dotfiles/commit/fdc1ddd95c2defb791...

As for why I was using it:

I've been using WSL since nearly the beginning (2017 / 2018) and used VcXsrv back then to get bi-directional clipboard sharing before WSLg was available. For a brief time I even ran Sublime Text in WSL 1 way back in the day.

Then I used WSL 2.

Then I tried WSLg when it first came out and it was really bad. Clipboard sharing didn't work for me which was the only reason I wanted to use it. I set `guiApplications=false` and never looked back.

I just tried it again now by closing VcXsrv and removing any DISPLAY related settings I had in my zsh profile. Then I shutdown WSL and started up my instance.

Bingo, clipboard sharing "just works" and I also installed xcalc which ran flawlessly. This simplifies things so much.

kayson

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...

1. https://github.com/ublue-os/bazzite/blob/main/Containerfile 2. https://github.com/ublue-os/bazzite/releases/tag/42.20250417

samhclark

I agree with your concerns—at least, last time I looked.

I looked over their code, saw some things (I believed) I would do differently, and it was very easy to make my own personal spin to use.

After doing that, maintaining it, and using it daily for the last year I went back on some of my original choices. I feel much less critical of the decisions Jorge Castro made and it's probably time to compare and contribute if I can. Like, Homebrew on Linux ended up being way better than I expected. But some things I liked better my way. Say, including the signing keys for Chrome's 3rd-party repo statically instead of fetching them over the network. (Writing this from my phone I don't exactly remember how they do/did it.)

Overall, I'd recommend trying it yourself! It's been a ton of fun.

jcastro

> 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.

Contributor here, we've been working on this diligently over the past cycle (the rest of the org is mostly done, Bazzite is largest so we're only getting to it now). We're hoping to be done over the summer with published SBOMs and all that good stuff.

danieldk

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.

kayson

Yeah I think that may be what I end up doing.

moondev

> Best I can tell, none of the versions are pinned.

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

kayson

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.

XorNot

I mean that's the big lie isn't it? We all know no one is actually looking at these.

Every system which tells me how immutable it is then shows me it's automatic version bump script or something.

OsrsNeedsf2P

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.

[0] https://github.com/grassmunk/Chicago95 [1] https://garudalinux.org/editions (screenshots don't do it justice)

II2II

> Sometimes I wonder why there isn't more enthusiasm around theming.

My guess: because it is difficult to develop software that can be themed and it is difficult to create themes that look good. Not only is it high effort, but it has relatively low returns. Themes mostly affect how things look and, ideally, have very little impact on functionality. I say ideally since, when there is an impact on functionality it is usually a negative one (e.g. buggy behaviour). Contrast that to a window manager or compositor: while it won't affect the functionality of individual applications (ideally), it does have a fairly significant impact upon how one interacts with the desktop as a whole.

WD-42

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.

cosmic_cheese

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.

ChocolateGod

GTKs CSS engine is great for app developers because it's powerful and easy. You can make something look slick with little work.

But its terrible for themers, it's like running a CSS override on every site that runs Bootstrap and expecting it to work properly. It won't.

I don't run any themes anymore so it doesn't bother me.

WD-42

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.

gnomeluvscorpo

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.

aecsocket

This opinion of "Gnome is killing customization" is something I see quite a lot, but which I think people take the wrong way. It's absolutely true that Gnome is designed to be less themeable than other DEs like KDE, or individual WMs - and by extension, GTK apps and apps designed to be used on Gnome are harder to customize/break more when you do theme them. But I disagree that "customization of Linux [being] half-dead" is a bad thing; on the contrary, I support the lack of theming options, and I like that there's someone on the Linux desktop that pushes this hard for consistency.

To make my biases clear: I'm a software developer that uses Gnome daily, and is developing a GTK/Adwaita app. I used to rice a lot back in the i3 days, but I don't particularly care about that nowadays, and stick to the defaults when I can. For my purposes, GNOME and Adwaita is perfect since it's very opinionated by default, and you can make good looking apps with minimal effort. Since all Adwaita apps are supposed to look similar and follow the same HIG, most of my desktop apps have the same look - but more importantly, the developers of the apps can also be confident that their apps look correct on my desktop. This is something that developers in the GTK space generally want, and for good reason[0].

One argument is that you as a user of the desktop should be able to have the final say on how your apps look, which is a totally valid take! And there are DEs, WMs, and apps which give you this freedom like Hyprland. But this doesn't guarantee that those apps will look good, or look consistent with each other, or even act consistently across apps. On the other hand, I as an app developer want to guarantee that my app looks good on your desktop, and the easiest way to achieve that is to target a single desktop environment, rather than an infinite combination of possibly-similar-but-maybe-completely-different desktops. Every preference has a cost[1][2], and when you take this philosophy beyond just preferences and expand it to color schemes, padding, margin, iconography, typography, it becomes unmanageable.

This isn't to say that GNOME is perfect, and I disagree with the project on some fundamental technical things like not supporting xdg-layer-shell[3], and refusing to accommodate server-side decorations for apps which don't want to render decorations themselves. (On the cultural side I can't comment, since I have no experience with that.) But in my opinion, this is the project that can deliver a usable and consistent Linux desktop to the average person the most effectively.

[0]: https://stopthemingmy.app/

[1]: https://blogs.gnome.org/tbernard/2021/07/13/community-power-...

[2]: https://ometer.com/preferences.html

[3]: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1141

Mountain_Skies

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.

zzo38computer

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.

Vilian

The upsude is a more stable applicationand less headaches for the developers

amarant

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

keyringlight

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.

wlesieutre

Because it always works well for like two applications and everything else looks half assed

seba_dos1

That's how it works in GNOME, yes.

trollied

This made me think, I used to love playing with Enlightenment back in the day. It was really trying to push what X11 could do.

Surprised it's still going https://www.enlightenment.org/

sabslikesobs

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.

pipes

Never seen blue95 before, that is really nice.

dicytea

bootc would be more attractive for this theming use-case, if there's a 1-line method to spin up a graphical VM straight from the docker file.

I looked into it, but it looks like that you need to manually build the image and fiddle around with qemu.

JCattheATM

Yeah, a VM or just filesystem snapshots make much more sense.

Containers are so easy so people just started using them for every use case, even when it doesn't necessarily make the most sense.

qwerty456127

I am actually surprised how bad the actual state of the art is. I would expect modern OSes to be infinitely and easily themable and a thriving scene of OS theming to exist (and offer perfect retro revival themes alongside completely original and loosely inspired ones) but it apparently is not the case at all.

undeniablemess

Interesting. Didn’t know about bootable containers.

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.

danieldk

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.

JCattheATM

I think ZFS snapshots, or whatever the brtfs equivalent is, makes a lot more sense than using containers just to experiment with theming.

I also don't think the distinction between distro and container is murky at all.