Arch in a container

Found this comment, pretty cool:

My current setup is Fedora Silverblue, and an Arch container for development. Silverblue as a base system is rock solid, but it being immutable means you need a container, Nix or something else.

Fedora as a development environment is also fine, but I ran into a few issues with packages either not being available or being really out of date. The bigger underlying issue here is Fedora’s dumb packaging requirements (= every dependency must be a package, even if that doesn’t make sense), resulting in (at least I suspect) many people just not bothering packaging their project for Fedora.

An Arch container means you can work around this by, well, using Arch. Since it’s not your base system the usual issues with Arch (e.g. it not always being stable) don’t matter much, because in the worst case you rebuild your container (something I’ve automated down to a simple make arch). And Arch being Arch means pretty much every package is available, either as an official package or an AUR package.

My main gripe with Silverblue is that running development environments inside a container is a bit wonky, and the tooling surrounding it is a hit and miss. For example, Toolbox is generally more stable/of better quality compared to Distrobox, but lacks features that seem pretty important (e.g. generating .desktop files).

And the whole thread is just golden!

This is so great way of formulating this:

Beyond dissing Hansson, which is admittedly why I clicked, this turned out to be a neat laundry list of what not to do when writing orchestration scripts. Worth reading from that perspective alone.

Aaaaaannndd

there’s a huge grey area separating a noob installing Fedora and a noob installing Omarchy.

… called brain 😂

••• Linux Operating Systems

Reply by Email