Skip Navigation
Linux @lemmy.ml
Telorand @reddthat.com

Am I overthinking it?

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.

39 comments

  • Atomic systems or rpm-ostree is an interesting concept and may well be the future of distributing linux, but it has a lot of compromises. It may not be the first place to start when leaving windows.

    The problem is all the apps and things you may wish to do with your OS. Flatpak is the preferred method of installing apps as it doesn't interfere with the OS, but that is a compromise that means more overhead for running apps including memory and disk space, and less integration with the host OS than traditional apps.

    You can overlay native apps but the more you overlay onto the immutable os, the more complex upgrading gets and the risks of breaking stuff.

    I'm not sure I would be starting with an immutable OS when switching away from windows. While it has a lot of theoretical benefits, its a work in progress and with significant compromises at the moment. Your VPN may just be the first of many programmes you find you need to overlay.

    I personally would look at a more traditional install, get it working how you like and if you find Linux works as a permanent home then think about how you might recreate that with an immutable OS base. If your needs a re very simple then maybe it'll be easy, but if you're using lots of software and tools (particularly if its not available Flatpak) or custom OS config you may find atomic desktops are not yet quite ready for you.

    It could be frustrating and off putting if you try linux immutable, find loads of problems and attribute that to linux when its actually the immutable OS that's the cause.

    • I currently run Bazzite full time on an HTPC laptop, but I don't use that for work purposes at all. It's been great, and I would be a little sad if I couldn't fit Bazzite into my use case.

      But I'm fully aware that my frustrations are atomic problems, and I've had no issues installing the software I need on non-atomic distros. The reason I'm so smitten by atomic distros is the fact that there's theoretically no down time. I've had distros break in the past due to some squirrely install or update, and I've never once had that issue on Bazzite.

      I just recently learned that openSUSE users also have a lot of stability due to btrfs snapshots, so maybe that's really the feature I'm looking for. I don't know much about it, honestly.

    • We're appreciative of your considerations and reservations. However, some of your views seem unnuanced at best or plain biased at worst.

      The problem is all the apps and things you may wish to do with your OS.

      I'm aware that the rest of the comment goes over this. But, I hope the mention of "all" here is merely an oversight.

      Flatpak is the preferred method of installing apps as it doesn't interfere with the OS, but that is a compromise that means more overhead for running apps including memory and disk space

      While that's technically true, a (relatively) modern device wouldn't even care. I don't recall OP mention their hardware specifications; but if they're perfectly capable of running VMs, then I don't see why they would be bothered by this (almost) unnoticeable amount of overhead.

      its a work in progress

      Sure..., but we're not talking about alpha, beta or even RC software. Like, I'm not sure if you're aware, but you make it sound as if it's very new and/or immature. Fedora Atomic has been in the works for over 10 years. It first released their Fedora Atomic Host (currently known as Fedora CoreOS) in 2014 and later released Fedora Atomic Workstation (currently known as Fedora Silverblue) in 2018. Heck, Fedora has already put so much trust in their Atomic branch that they intend for 2028 that immutable variants are the majority of Fedora Linux in use.

      By contrast, what is it that you base this statement of? That it receives very active development that most other distros would be jealous of? That it rapidly implements all kinds of new features that you're having difficulty keeping track of?

      and with significant compromises at the moment.

      This is a big claim. But I haven't seen enough in your comment to substantiate this. Your two best claims are:

      • Flatpak is the preferred method of installing apps as it doesn't interfere with the OS, but that is a compromise that means more overhead for running apps including memory and disk space, and less integration with the host OS than traditional apps.

      Which is a problem of Flatpak on all platforms. The very same Flatpak that was recommended by people associated with Steam/Valve for Ubuntu. Furthermore, if OP creates their own image, then this isn't even an issue; they can practically bake whatever they want into their image. There are also multiple tools to get this going. I achieved it in a weekend (as a noob) last year, so it ain't hard. Finally, 'over-reliance' on Flatpak is not even a thing on Guix System and NixOS.

      • You can overlay native apps but the more you overlay onto the immutable os, the more complex upgrading gets and the risks of breaking stuff.

      This is not an issue with your own image. If the image itself is busted, then it doesn't come out of the pipeline. Hence, the busted image would not have been delivered to your device in the first place. And, again, layering isn't a thing on Guix System and NixOS. Hence, this problem doesn't exist for them.

      Your VPN may just be the first of many programmes you find you need to overlay.

      Do you (for some reason) imply that layering is necessarily a bad thing?

      If your needs a re very simple then maybe it'll be easy, but if you're using lots of software and tools (particularly if its not available Flatpak) or custom OS config you may find atomic desktops are not yet quite ready for you.

      I have yet to receive substantive evidence from you to support this view of yours. I hope you'll deliver...

      It could be frustrating and off putting if you try linux immutable, find loads of problems and attribute that to linux when its actually the immutable OS that's the cause.

      I could change the word "immutable" in the above sentence to "traditional" and it would have been an equally nonsensical statement.

  • OP, it seems as if the fear mongering and misinformation may have reached you through your cautious disposition.

    I've gone through every single comment found below your post and at times I've been dumbfounded and/or astonished by the ludicrous claims that are spouted.

    FFS, someone even expressed a problem found on imperative systems... While Fedora Atomic can be made (relatively) declarative (i.e. the exact opposite of imperative) for over a year now.

    I will leave you with two videos in which the recent conference talks by the very same people that work on Fedora Atomic can be found. Consider watching these if you're interested to know what they're actually currently working on. If you pay attention, you will even notice how they mention common misconceptions that have also been brought up here...

    First watch this one. Then, watch this.

    The only fair criticism that I've found is the required investment and effort to adjust due to the associated paradigm shift and learning curve. However, this is peanuts compared to Guix System or NixOS.

    • Okay, I appreciate the links. I've had a chance to go over both, and I think I get the gist:

      • rpm-ostree is a work in progress, and it will be depreciated and replaced with bootc + dnf

      However, I'm still struggling to understand how it all works together. For example, I have a VPN client that is installed via a .run script, so it doesn't work with ostree. If I wanted to apply this software to my system, I'd have to create a bootable container, then rebase to that. But my goal isn't to create a new image, just to apply transient packages to the base Bazzite image, so my remaining questions are these (and it's fine if you don't know):

      If I made a bootable container(file), would that derived image fall out of sync with the parent Bazzite project? Would I have to manually build a new container and rebase each time I wanted to check for updates? I feel like I'm on the cusp of seeing the big picture, but I'm not quite getting it, and maybe that's because I haven't worked at all with services like Podman and Docker.

      • Yo OP, this is me @poki@discuss.online from another account. I had intended to leave the Lemmyverse for a while, but had to come back earlier than intended when I read your comment 😅.

        So, without further a due.

        Okay, I appreciate the links. I've had a chance to go over both, and I think I get the gist:

        Thank you for your time!

        • rpm-ostree is a work in progress, and it will be depreciated and replaced with bootc + dnf

        What do you mean with "work in progress"? You've been using it relatively often in this thread (and IIRC even in others) when talking about Fedora Atomic and/or uBlue and its technologies. Like, do you consider dnf to be work in progress because dnf5 is around the corner?

        I don't recall any mention of deprecating rpm-ostree, though I might be wrong. But, yeah; it will definitely lose focus in favor of bootc + dnf.

        For example, I have a VPN client that is installed via a .run script, so it doesn't work with ostree. If I wanted to apply this software to my system, I'd have to create a bootable container, then rebase to that.

        I'm not actually sure if it works out just like that as of right now. Creating your own image or bootable container is definitely a powerful tool that can help bypass some imposed limits; like e.g. populating files in /usr or baking in (current) rpm-ostree actions -some of which actually wouldn't work otherwise (as of right now)- directly into the image. Finally, it allows one to move from an imperative to a declarative system. However, I'm not aware if it enables one to bake-in the installation of .run files. My only experience with .run files myself was with Davinci Resolve, but that's notoriously difficult to install regardless. Thankfully, it's a popular piece of software and thus avenues have been created by which one could install it on Fedora Atomic and related projects.

        So, in short, I don't see how creating your own bootable container would help you to bypass this.

        But my goal isn't to create a new image, just to apply transient packages to the base Bazzite image

        Exactly.

        If I made a bootable container(file), would that derived image fall out of sync with the parent Bazzite project?

        If you achieve it through legit means (i.e. uBlue's own documentation on this or through a sister project called BlueBuild), then no.

        Would I have to manually build a new container and rebase each time I wanted to check for updates?

        By either of the two earlier mentioned means, the building is done automatically (on a daily basis) by GitHub. Furthermore, when you update, you just receive the latest image from your own GitHub repository in which your own image resides. Updates continue to be done automatically in the background, so you won't even notice. Finally, if it wasn't clear yet, you only have to rebase once.

        I feel like I'm on the cusp of seeing the big picture, but I'm not quite getting it, and maybe that's because I haven't worked at all with services like Podman and Docker.

        That's fine. Please feel free to inquire if you so desire!

        Alright, having said all of that, let's get to the crux!

        So, did you try the following methods when installing the .run file? If so, how did it go?

        • Simply double press or right-click then install (of course, after applying chmod +x).
        • Within a terminal with ./<name of .run file>.run
        • Within a terminal with ./<name of .run file>.run --appimage-extract and then interacting with the AppImage.

        If all of the above have absolutely failed, I only see three ways going forward:

        • Creating your own Flatpak 😅.
        • (OR) Taking this to COPR 😅.
        • (OR) Succumb to Toolbx/Distrobox 😅. Like have you tried running the .run file within Toolbx/Distrobox? If so, how did it go?

        EDIT: 😅. I had hoped you'd return with a reply soon~ish. But alas... Uhmm..., I'll be off for a couple of days and will return only next week. Just wanted to let you know*. FYI, I'll probs return with (yet) another account.

39 comments