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.
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.
I also don't think the distinction between distro and container is murky at all.
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
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.
Never stop tweaking. No computer can be called home until it runs your own set of aliases/commands.
Surprised it's still going https://www.enlightenment.org/
OsrsNeedsf2P•4h ago
[0] https://github.com/grassmunk/Chicago95 [1] https://garudalinux.org/editions (screenshots don't do it justice)
wlesieutre•4h ago
seba_dos1•3h ago
amarant•4h ago
keyringlight•2h ago
WD-42•4h ago
cosmic_cheese•3h ago
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.
WD-42•1h ago
cosmic_cheese•1h ago
ChocolateGod•1h ago
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.
Vilian•3h ago
gnomeluvscorpo•3h ago
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.
Mountain_Skies•2h ago
aecsocket•1h ago
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
cosmic_cheese•1h ago
Aside from that, consistency and themability are not at all mutually exclusive. Back in the early days of OS X, theming by hacking system resource files (or patching them in memory via haxies[0]) was quite popular and for the most part, worked very well — generally, the only apps that didn’t play nice with themes were those sitting in the uncanny valley between native and custom, using bits of both, which tended to not be the highest quality applications anyway. This was way before Apple started pushing devs to parameterize their apps, too, and so similar theming capabilities today would work even better since themes can just tweak the parameterized fonts, colors, etc as needed to maintain coherence and usablity.
The real problem with GNOME/GTK is simply that it wasn’t designed with user customization in mind even as a remote possibility. A UI framework that did keep these things in mind combined with a strong dev culture of parametrization would make for a desktop that’s both customizable and consistent.
[0]: https://en.wikipedia.org/wiki/Unsanity
aecsocket•46m ago
badsectoracula•1h ago
When your app doesn't follow how my desktop looks it doesn't look good on my desktop. And unsurprisingly most modern Gtk3 and especially Gtk4 apps do not look good on my desktop.
What you actually mean here is that you want to guarantee that your app looks good on your desktop, not mine.
aecsocket•35m ago
The counter argument to that is "so let the user theme the app, to suit their own desktop", which would be a decent solution, but:
1. My vision for my app might conflict with your vision for your desktop. Maybe I want this button to be a light blue because it meshes well with some other elements in the app, but you want it to be a darker blue because it fits with your desktop's color scheme. What happens then?
2. This still doesn't guarantee that the app will look good. If you theme my app's home page, but don't theme the rest of the pages, then sure it'll look good at the home page - but as soon as you start using it, the look will fall apart. Or, what if I push an update to my app which adds a new page with a new kind of UI element? Do you really want to be maintaining your desktop theme for every single app you have?
3. This adds a burden on me as the developer to make parts customizable. This is the least convincing argument in this list IMO, since if there was better tooling and infrastructure for theming in GTK this wouldn't be a problem - but there isn't, so it is still a problem.
As a practical example, my app makes use of a WebViewGTK to display some info. I inject some custom CSS into this web view to make it look like Adwaita. This touches on points 2 and 3:
2. The webview has some UI widgets which aren't present in the rest of GTK, like a sticky header bar. You would have to manually maintain a stylesheet for this single element.
3. I now need to write a way to let users theme the custom CSS inside the webview, rather than just the CSS of the GTK widgets themselves. (I have already written this, but it's still a maintenance burden.)
zzo38computer•2h ago