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 )
this post was submitted on 01 Jul 2024
69 points (98.6% liked)
Linux
48331 readers
636 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
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.
Aurora is really nice, and I should see if I can get it working better in a VM to try it out. The main differences between Aurora and Bazzite that I can tell are the suites of preinstalled packages and the particular ujust recipes included.
Tailscale is probably not something I can use, unfortunately, since my employer has set up connectivity via SonicWall. I doubt they're going to allow a change just for me. 😅
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.
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.
Atomic distros are very much a work in progress and they do have issues you won’t find in non-atomic distros.
And this is kind of how I'm starting to look at it, after reading all of these comments. There definitely feels like there's a disconnect between services like Podman and atomic ideology born out of the fact that they were created with different goals in mind. If the two can be married a bit better, the learning curve can be flattened (and I think that's a distinct future possibility, since Podman and Fedora Atomics have Red Hat backing).
Regarding breaks, being able to rollback is very handy, and I've used it many times when I was running Bazzite on my Steam Deck. Regressions happen, and I've experienced problematic regressions on non-atomic distros where my only option was to reinstall. This will be my daily driver that needs near full uptime, so whatever I pick, it's gotta be solid without entirely sacrificing relative newness (i.e. not Debian).
Either way, there's more to consider than I initially thought, and I appreciate your input.
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.
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.
An excellent point.
But to your earlier one, I can get the VPN client working outside of a container. There's even an RPM file from the vendor, so installing it is just as easy as installing any other package.
I appreciate the input!
But to your earlier one, I can get the VPN client working outside of a container. There’s even an RPM file from the vendor, so installing it is just as easy as installing any other package.
Aight. You know what you ought to do then 😉.
I appreciate the input!
It has been my pleasure!
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.
That's good to know, especially the gaming part. I have tried it in the past, only briefly, and I remember enjoying the experience (older laptop, so gaming was out of the question). I'll have to throw an ISO on my thumb drive to give it another try!
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.
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.
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!
Yeah, you're overthinking it. Installing a single program is a "use sparingly" situation.
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.
Very good advice, though I've personally been dabbling for many years and generally know a handful of things. Still, I would recommend the same thing for anyone new to Linux. There's some fantastic options, these days!
I might just be a glutton for punishment, however. 😆
Even if you know how to do stuff, I’d avoid doing ostree on a universal blue derivative.
I been using Linux for 25 years and just recently embraced the “don’t break Debian” part of the backport manual.
Stuff you do and don’t document or don’t force yourself to recognize comes back to bite you years later when you can’t use the normal tooling in order to deal with it.
Anyway, good luck, it sounds like you’ll be fine.
Stuff you do and don’t document or don’t force yourself to recognize comes back to bite you years later when you can’t use the normal tooling in order to deal with it.
And it's this right here that forces me to really consider if Bazzite is right for me in this case (and why I didn't just immediately go with the easier rpm-ostree option). Podman is kind of a necessary tool, at least currently, and if your use case falls outside flatpaks, rpm-ostree, and appimages, it's Podman or bust (and I currently have an app like that, which I haven't yet figured out).
I appreciate your experienced advice. I have probably a total five years of experience, so I would be foolish not to consider to the long-timers offering similar advice in these comments.
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-ostreeis a work in progress, and it will be depreciated and replaced withbootc+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-ostreeis a work in progress, and it will be depreciated and replaced withbootc+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
.runscript, so it doesn't work withostree. 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-extractand 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
.runfile 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.
Sorry I didn't get back sooner, but I made some progress.
What do you mean with "work in progress"?
Their words (second video, I think), and more in reference to how they are still working out how they haven't yet covered all of the use cases (like maybe my needs can't currently be met by rpm-ostree or bootc). rpm-ostree has functional limitations, and bootc is still being developed. Obviously, both are still useable and useful, and Universal Blue has been using them for quite a while. I may have been reading too much into it with the "depreciation" comment.
So, did you try the following methods when installing the
.runfile? If so, how did it go?
It can't work on its own. Running with sh or making it executable runs the script, but it fails when it tries to write its icon and .desktop entry to /usr (it also doesn't take an --appimage-extract argument). You can use sudo rpm-ostree usroverlay to create a temporary FS overlay for /usr, but it's wiped on the next boot. Still, that allowed the installation to complete.
I discovered that it's installing all of the necessary components to /opt, and they remain functional. I was able to manually run the daemon script required and get a WireGuard tunnel established in the client.
Now, I'm trying to get a .service module to work so it can run automatically as root on a reboot with systemd. So far, it's giving me a 126 exit code, so I still haven't figured out how to escalate its privileges automatically, but this is the most progress I've made to date.
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."