I’m working on my transition plan away from Windows and testing out various things in VMs as I do so, and one big hurdle is making sure the VPN client my work requires can connect. Bazzite is my target distro (primarily gaming, work less frequently), though other more traditionally structured ones like Pop!_OS and Garuda are possibilities.
I’m currently trying and failing to get the VPN client working in a distrobox (throws an error during connection saying PPP isn’t installed or supported by the kernel). However, I can successfully get the VPN connected if I overlay the client and its dependencies via rpm-ostree install,
but I read somewhere that Bazzite’s philosophy is to use rpm-ostree
as sparingly as possible for installing software to preserve as much containerization as possible.
Since I can get it working outside of a container, am I overthinking it? Should I just accept that this might be one of the “sparing” cases? Is Bazzite perhaps a poor fit for my use case? I’ve been trying to make sense of this guide, but I’m having trouble understanding how to apply it to my situation, since I’m not that familiar with Docker or Podman.
If I understand it correctly, layering an application is no more dangerous than a regular install on a non atomic os. In other words, every piece of software you have installed on normal fedora desktop is not containerized, if it’s software you were going to install anyways, layering it is the same as before (albeit significantly slower than install and update).
But that means that you get great benefits because 99% of your software packages are properly containerized
True~ish.
There’s an important caveat though; for whatever reason,
rpm-ostree
can outright fail to upgrade (due to conflicts related to layered packages) while an issue like that is more rare on traditional Fedora anddnf
. Thankfully, I’ve never had a problem that I couldn’t solve withrpm-ostree reset
run on a (previously) pinned deployment (throughsudo ostree admin pin <insert number>
). However, when used irresponsibly, this (i.e. layering) can outright destroy your otherwise very robust ‘immutable’ distro.It’s easier to teach people to be cautious than to teach how they should act accordingly. Hence, uBlue’s documentation tends to be more conservative in order to protect (especially newer) users from shooting themselves in the foot.
This is true, because each layered package is reinstalled every time a new compose is pulled. If you layer 100 packages, 100 packages get re-installed. Which massively slows the update process
Ah, that makes much more sense, now!