Linux @lemmy.ml Telorand @reddthat.com 5mo ago

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.

36 comments

Containers are great to keep OS separate from apps, but VPN seems pretty integral to OS, so I don't see an issue using rpm-ostree. Containers often prove challenging because of not being able to get permission or share data between apps ( on purpose )
I think that it's definitely a good case for overlaying with install. They say to use it sparingly because it increases the chances of something breaking, but that doesn't mean it will. Something like a VPN usually needs liw level access that container isolation makes difficult.

I've only had 1 issue on silverblue years ago where I couldn't update because I had vim overlayed and they fixed it within a day or two.
- Ah, okay. Yeah, I only need to install OpenJDK and this client, and I don't think either of those are likely to be included in future Bazzite images, since it's gaming-focused and not development- or workstation-focused.
  
  Look at Bluefin or Aurora. They are also made by Universal Blue and have developer versions that come with Tailscale VPN. They're built on Fedora Silverblue just like Bazzite. I personally just moved to Bazzite two weeks ago, and then switched to Aurora.
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.
  
  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.
  
  I'm been daily driving openSUSE Tumbleweed for almost a year and from my end there are no problems with it. In fact, no problem that can be pinned to the particular distro.
  
  I ran into an audio issue with my Bluetooth Headset in Kernel 6.9 3, with sound profiles not appearing. However, this has now been fixed since 2 kernel updates, (eg.it was a bug in the kernel)
  
  The snapshot feature is awesome and always worked without a hitch when I have been tinkering with stuff I dont know how it works.
  
  It has my recommendation. Good for gaming as its a rolling release with all the new stuff to boot.
  
  But I’m fully aware that my frustrations are atomic problems
  
  Are these frustrations solved by layering with rpm-ostree? If so, just go with it. I've always layered over a dozen or so packages and it has worked out fine; it's defaulted to automatic upgrades in the background, so you don't feel much of it anyways.
  
  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.
  
  I love openSUSE and what they do with Btrfs snapshots and Snapper.
  
  However, in terms of 'robustness' and 'stability', I don't think anything currently out there can hold up to Fedora Atomic, Guix System and NixOS. This is just by design; the leap from traditional to atomic, then reproducible and finally declarative ensures that issues related to hidden/unknown state, accumulation of cruft, bitrot, configuration drift are left behind in the past. If Btrfs snapshots + Snapper would have been sufficient, then openSUSE themselves would never have desired the creation of openSUSE MicroOS (i.e. their attempt at an 'immutable' distro) in the first place.
  
  As someone who switched from Windows to Kinoite about 6 months ago (and now using bluebuild to create custom images), wether to use an atomic distro or not comes down to how much time do you want to spend learning everything.
  
  I’m a very technical person with years of experience, and I’m still figuring a lot out. You’r not only learning about the ins and outs of linux, but now your adding more complexity with an atomic distro, and even more if you decided to create your own image.
  
  Atomic distros are very much a work in progress and they do have issues you won’t find in non-atomic distros. Creating your image allows you to get around some issues you may run into that layering alone can’t do.
  
  Also, keep in mind that version upgrades (which happen every 6 months or so on Fedora based atomic distros like Bazzite), can and do sometimes break apps baked into your image until they are updated (which also happens in non-atomic distros). Flatpaks can help avoid this breakage.
  
  There are other distros that are gaming focused if atomic distros are not for you.
- 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.
Yeah, you're overthinking it. Installing a single program is a "use sparingly" situation.
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
- 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
  
  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.
Yes
- Straight to the point!
  
  Also, don’t jump straight into a universal blue derivative. Actually learn how to use Linux before you start in with something that relies on a bunch of convenience features.
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 @[email protected] 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.
Vpns are the things that make more sense to layer. It's fine, have fun with bazzite
My advice is to stick to a popular and well known general purpose distro. Even though I have never tried Pop os myself I would recommend it over that Brazzite thing (which has a very similar name to that one very popular video streaming site if you know) because I have heard good things about Pop os.
- Not Brazzite, "Bazzite." It's a mineral, and its naming proximity to an adult website is entirely coincidental (and I would hazard a guess that the mineral was named first).
  
  Honestly, I'm not that concerned with Bazzite being newer, because it's based on Fedora CoreOS. It utilizes rpm-ostree to manage system upgrades, so for any bad updates, you just rollback to any previous deployments (and you can pin specific ones so you are guaranteed a stable rollback point). Additionally, you can rebase at any time, so you can swap out the system layer for another ostree-based image without touching any of your files in /etc, /var, and /home.
  
  Pop!_OS is a great choice, too, but the biggest problem facing the family of Universal Blue distros isn't notoriety, it's the fact that Fedora Atomics in general are still relatively new. The examples are still being written, and people are getting used to new tooling.
  
  But if you don't need specific customizations like me, and all your software can be found as appimages or flatpaks (or is already installed), Aurora, Bluefin, and Bazzite are all rock-solid choices that will "just work."
Ask your IT for a different client.
- I may try that. They have OpenVPN for connecting to a different domain on the network, so maybe it's possible a config could exist for the one I need to connect to.

36 comments