Apps in Toolboxes Or As Flatpaks on Host?

Hi, I’m rather new to Silverblue, yet planning on migrating to Silverblue 36 when released. I’ve read that some prefer keeping their host system as close to when first installed as possible, and choosing to install their apps within Toolboxes or Podman containers. Others choose to simply install their Flatpak apps alongside the host (which seems to be the “default” method).

Is this simply a matter of preference or is there any advantage of installing all your apps from within a Toolbox or Podman container? I’m still reading and learning about Silverblue, but your input is appreciated.

Thanks!

It comes down to preference.

I can share what I did and the rationale behind it in order to help you determine what you may want to prioritize.

What I did

I layered several packages using rpm-ostree install <pkg names here> because they were my preferred desktop (Sway and related tools), provided much needed media codecs (ffmpeg), or enabled the use of work-related VPNs (ICAClient, OpenVPN profiles, etc). Those are packages that don’t necessarily make sense for a flatpak or would be otherwise too isolated in a container/toolbox, so having them on my system made sense.

Other than those specific packages, as someone who works with container technologies and development as my day job, I already did most things in a container (I’ve been using container based development environments for years), so using podman directly is already a common pattern for me, though I do appreciate some of the convenience automation that toolbox provides out of the box, such as mounting common directories I use without needing an extra argument to podman.

Why I did it
The rationale for minimizing how much I layered into the ostree is that with fewer dependencies comes fewer problems. Also, that means that, while I generally need to reboot for OS updates to take effect, I’m never surprised by changes in how my system behaves, because the behavior doesn’t change often between updates enough to care about. If I treated my Silverblue system the way that I treated my former workstation OS, I might have a hundred config file changes to review from package maintainers, or several dependencies which included API changes which impact other apps which will require me to read through hours of documentation to unwind and understand well enough to make necessary changes/trade-offs.

Keeping the system small (not layering more than is absolutely necessary for my convenience) means that I focus less on managing my system and more on using my system for productive work.

In general, unless there’s a known issue in the Flatpak version, I’ve migrated to using Flatpak as the default for GUI applications, and I continue to use my existing containers for dev environments and toolboxes for task-specific work.

For example:
I use the Slack and Discord flatpaks, my own “go”, “python”, and “ansible” containers from before for development, and I keep an openshift toolbox for OpenShift cluster administration as well as a “net-tools” toolbox for network debugging.

Your workflow and typical system usage will determine how you manage your Silverblue system, but you do have the flexibility to customize as you see fit. Hopefully sharing how I work with mine provides some inspiration :slight_smile:

1 Like

Thanks for sharing your experience and rationale, @darthlukan. This quote of yours sums it up nicely:

Well said… and this is essentially what I’m aiming for. I am currently running Silverblue in a VM and playing around with it while I wait for Silverblue 36 to release. Again, thanks for your insight!