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.
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.
I never used Incus before to know if it has other benefits but Docker solves my use case. Before Docker existed I used to do this with LXCs back when I ran my entire dev environment in a Linux VM.
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
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.
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.
This is a fantastic idea, it sucks to have an upgrade blocked by a slow repo, if you wouldn't mind filing an issue or sending a PR I'd love to have this. Thanks for the feedback!
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
[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.
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.
I can speak to this personally. I used to always tinker with various Linux desktops, themes, etc but nowadays I just use vanilla Ubuntu with zero theming modifications. There are two reasons for this:
1. Like others have said, theming is easy but consistency is hard. I've found that anything besides Gnome just turns into a shitshow where half your apps just don't theme properly.
2. It's a massive time sink. While I could create a very consistent theme, it would involve a massive time sink into dealing with all the edge cases. When I was in college and just used Linux "recreationally", I could justify spending a ton of time tinkering with my system and getting everything perfect. But these days I use Linux professionally so it's less about having a beautiful desktop and more about something that just works and gets out of my way so I can get my actual work done.
I should note that I still play around with other DE's and themes though I now do it all in VM's. I'm slowly building up my own theme stack on a Debian VM and once I get everything buckled up I might actually deploy and it use it on my primary machine.
Seriously, just make GUIs. That is the solution to ALL of Linux problems. MAKE THE GUIs!!! I can't select the background color of panes from a color picker and instead I have to manually edit text config files and create folders inside dotfolders. Ridiculous. It's 2025.
After a while it loses the appeal, we decide to just use whatever defaults get offered, finetune one or two options and that is it.
Surprised it's still going https://www.enlightenment.org/
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 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.
To put things into perspective, GTK themes, unless they bring lots and lots of bitmap images (which doesn't happen nowadays), rarely exceed a megabyte in size.
I guess one could spend less time learning how to package these as RPM packages and set up COPR to do just that, making OCI + bootc entirely optional (and yet you could build an OCI + bootc installing this package if you so wished!).
Side note: Judging by what I see on Reddit, the ability to theme a desktop is one of the top reasons someone develops a personal interest in Linux to begin with, so no need to justify that in my book.
I looked into it, but it looks like that you need to manually build the image and fiddle around with qemu.
Containers are so easy so people just started using them for every use case, even when it doesn't necessarily make the most sense.
One of the rare examples where "Dark Reader" not only failed but actually made it more light; there must be some funky CSS shenanigans going on.
Also discovered that for me it’s less the OS or paradigm or theme/look and more that the windows manager is tiling type.
I also don't think the distinction between distro and container is murky at all.
