[gawa]

I like that they went from Ubuntu to Debian as the base OS. I assume they target Debian Sid (the unstable flavor of Debian) because they can compensate for the instability with the immutability provided by ABroot. Or is it simply because the distro is pretty much in a rapid development stage?

The distribution looks very fun. Something quite new to play with for distro-hoppers and to learn more about some techs.

Last time I tried fedora-silverblue I didn't like it. My packages were scattered in 2 or 3 distrobox containers. It's not that much, but they can be different distributions, and then we add flatpak to the mix, and apps installed in the base OS with rpm-ostree... It felt like a frankenstein distro. Upgrades were time consuming, and not smooth at all. Not only did I have to learn how to manage a fedora-silverblue, but I also had to maintain a debian container, upgrade another fedora (a regular one, not silverblue), learn the quirks of flatpak, and... that was too much work. It doesn't really matter that I can confidently upgrade the empty base OS, if I still need to manually upgrade my fedora container and it can break the package I need from that container.

The approach here with Apx is worth a closer look. It abstracts away the different package managers of the main distro (`apx search` PACKAGE will translate to `apt-cache search` in debian container, `pacman -Ss` in arch container, `zypper search` in opensuse...). The concept of "exporting" the packages, and the UI around it, makes me think they aim at making the management of these distrobox containers easier.

[yjftsjthsd-h]

> Last time I tried fedora-silverblue I didn't like it. My packages were scattered in 2 or 3 distrobox containers. It's not that much, but they can be different distributions, and then we add flatpak to the mix, and apps installed in the base OS with rpm-ostree... It felt like a frankenstein distro. Upgrades were time consuming, and not smooth at all. Not only did I have to learn how to manage a fedora-silverblue, but I also had to maintain a debian container, upgrade another fedora (a regular one, not silverblue), learn the quirks of flatpak, and... that was too much work. It doesn't really matter that I can confidently upgrade the empty base OS, if I still need to manually upgrade my fedora container and it can break the package I need from that container.

I... don't think you're supposed to do that? Like, I haven't used silverblue specifically, but on suse microos there's a big warning with metaphorical flashing lights that says in so many words "don't touch the host OS unless there is literally no other way to possibly do what you need". You should never use it for normal applications, at the very minimum. And as to multiple distros in multiple containers - why not just run everything on Fedora container(s)?

[0rzech]

Using package layering (rpm-ostree install [...]) used to be discouraged unless strictly necessary, but it's no longer the case: https://docs.fedoraproject.org/en-US/fedora-silverblue/getti... . Nowadays you can as well use only that if it suits you.

[gawa]

I'm aware. I think I tried. At the time (silverblue 26) they recommended to use a firefox installed as rpm (actually, the GUI was offering both flatpak and RPM for some packages, and "RPM" meant it used rpm-ostree under the hood to overlay the package). At least they warned about some issues when using firefox as flatpak (mostly related to integration with the rest of the desktop environment). And so, in order to get some things to work I had to install a few packages with rpm-ostree. Digging in my docs, it was:

> # nvidia and codecs necessary for firefox and youtube: > # You'll need rpmfusion repo (see dedicated section for how to install them. Ugly.)) > rpm-ostree install akmod-nvidia ffmpeg xorg-x11-drv-nvidia xorg-x11-drv-nvidia-cuda

Maybe I used it wrong, idk, but here is how my .zshrc looked like:

> alias "hx"="toolbox run -c devops hx" # I installed there all the mess for LSP server > alias "aws"="toolbox run -c devops aws" > alias "mpv"="flatpak run io.mpv.Mpv" > alias "yt-dlp"="toolbox run yt-dlp" # default distrobox is fedora

I could go inside containers ("activate" containers), but then, if I want all my tools... they need to reside in the same container, right?

I didn't feel like installing all the utils in all containers, or running exa and ripgrep in some fedora "basic-utils" containers and adding more aliases for very basic tools. So I ended up overlaying the utils I cannot live without, thinking they are not really unstable software, it can't possibly break the upgrade (and indeed it never did for the time I used silverblue) :

> rpm-ostree install bat exa git-delta ripgrep vim zsh zsh-syntax-highlighting zsh-autosuggestions fzf jq

I also needed some stuff to fix the thumbnails of the default gnome (I don't remember, but I'm pretty sure that if I did it with rpm-ostree it's because I didn't find another way):

> rpm-ostree install ffmpegthumbnailer gstreamer1-libav gstreamer1-plugin-openh264

I also couldn't install some ibus packages (with too much integration with the desktop/keyboard) in a container so I resorted to rpm-ostree there as well.

So while I really tried to keep everything out of rpm-ostree as much as I could, I felt like it was a constant trade-off: going against the spirit of the distribution VS managing every single util and running little cli tool in containers (that need to be maintained).

I'd be happy to read about some workflows, the "correct way to do it", or if silverblue changed since the last time I used it. But for me it's in the design itself: "use containers" mean "do the plumbing between or your tools yourself" (even if distrobox makes it easier by exposing/sharing pretty much the whole home, network, env vars etc...)