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

[Brian_K_White]

I think all the instances of people saying they like it, are just examples of being trained and accepting the training, to just not be a tinkerer and just use what's given to you by someone else without touching it.

Not only being unable to customize or hack or basically just use a toolbox rather than a product, but being indoctrinated over time, especially new users, not to even think of it in the first place. Pretty much just like commercial software. Why bother running linux in that case? We already have polished untouchable product software.

When I say "unable" I don't count "able by dint of suffering 1000 paper cuts".

[yjftsjthsd-h]

That's fair. Certainly I would expect the thumbnail and ibus stuff to need to be on the host - although I'd also argue it was a bug that you needed to bother; that seems like stuff it should handle properly out of the box? I'm pretty sure the flatpak situation has improved with time, though again bear in mind I'm on a slightly different stack. And the general friction of having all your tools inside/outside the containers and needing to glue it all together... I think it's a question of workflow? Like, if I was on silverblue and decided to ex. write or work on some C program, I'd make a container that installed both the specific tools (gcc, make) and my stuff (git, vim, fzf)... or actually I'd probably stick them in 2 containers with a source code directory mounted into both. The funniest thing I hit was needing to make a container to get git when I wanted to create a repo to hold my Dockerfiles first. So it's definitely a bit of friction, but if you're comfortable defining everything you're doing programmatically then it's a bit of pain up front followed by being able to regenerate your entire environment in a few commands: If a new Fedora release drops, you don't upgrade your containers; you bump the base image, build, and cut over to the new container, and if you hit problems you revert to the old tag. If you don't like that approach then yes it might be annoying. Or, if you prefer pets to cattle, you'd need everything you want to be available in one distro so you have to figure out the host/container demarcation but then it's all one container to manage.

[speed_spread]

I'm on Kinoite. I don't need stability in my dev environment for now. I use a single toolbox based on Fedora rawhide. I get the best of both worlds, immutable distro and streaming distro and it keeps things simple. I agree Silverblue would benefit from an integrated management system / UI.