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.

  • thayer@lemmy.ca
    link
    fedilink
    English
    arrow-up
    15
    ·
    edit-2
    2 days ago

    As a fellow Atomic user, my completely biased opinion is that you’ve made a good choice of distro for switching from Windows.

    Don’t sweat the need or desire to layer a few packages. I see a lot of folks stress over this as if it’s a hard rule they are breaking. It’s a general recommendation and little more. I would be surprised if most users don’t layer at least one package (or even a few).

    On my main workstation, running Kinoite at the moment, some of the layered packages include:

    • distrobox
    • gdm (sddm refuses to respect autologin)
    • kate
    • ksystemlog
    • syncthing
    • vim-enhanced
    • virt-manager
    • virt-viewer
    • Lem453@lemmy.ca
      link
      fedilink
      arrow-up
      9
      ·
      2 days ago

      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

      • poki@discuss.online
        link
        fedilink
        arrow-up
        6
        ·
        edit-2
        2 days ago

        If I understand it correctly, layering an application is no more dangerous than a regular install on a non atomic os.

        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 and dnf. Thankfully, I’ve never had a problem that I couldn’t solve with rpm-ostree reset run on a (previously) pinned deployment (through sudo 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.

        • gnuplusmatt@reddthat.com
          link
          fedilink
          arrow-up
          4
          ·
          2 days ago

          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