alt

From a comment of yours;

Eh…just trying to learn some new things regarding common “dockerization”-related things, and improving its security.

If the end-goal is not learning but having an as secure container as possible, then consider Wolfi; this is a good read. If you're interested to know its current vulnerabilities, so that you can work on resolving those; then consider Trivy as it is -to my knowledge- the industry-standard for this specific use-case.

I was under the impression that using os-tree should be totally avoided for anything other than necessary system programs

Interaction with ostree directly shouldn't occur that often; with sudo ostree admin pin *number* (and its -u option) probably being the commands your average Joe should interact with. You probably meant rpm-ostree.

and all other software should be installed with flatpaks or containers.

It's indeed true that initially Fedora intended flatpaks should be preferred. If the software isn't available there, then Toolbx(/Distrobox) is used to access it through a container. And if all else fails, then it's layered through the rpm-ostree command.

I now understand that using os-tree for some programs is inevitable, and I should embrace it, though still catiously to maintain as clean of an OS as possible for maximum longevity.

You're getting the drill! Though, I wonder why you weren't able to rebase to uBlue and had to resort to installing the Nvidia drivers through RPM Fusion instead. It's fine as long as it works, but I imagine that some issues might arise eventually. So consider sharing the steps you took so that the community might help out; perhaps even over at uBlue Discord. You could also just share it here if you will.

I want to avoid os-tree if I can, since that seems to defeat the purpose.

How so?

Fedora is and will always be ~~cutting~~ leading edge.

Fixed that for you ;) .

Great piece of information.

Thank you for your kind words 😊!

at least it (without any experience) feels like that I’ll spend more time setting it up and tinkering with it than actually recovering from a rare cases where things just break

That might be the case depending on your proficiency and to what degree the 'immutable' distro allows you to configure your distro declarative. On e.g. NixOS you can define (most of) your system declarative. As such, reinstalling your entire setup is done through some config files. You can even push this further with the (in)famous Impermanence module that has been popularized by the popular Erase your darlings blog-post, in which your system is wiped every time you shut off the machine and rebuild (basically from scratch) every time you boot into it.

Potentially I might had an option to move LVM partition on the disk to grow boot partition, but that would’ve required shrinking filesystem first (which isn’t trivial on a LVM PV)

I haven't worked with LVM yet. Defaulting to Btrfs (as Fedora -amongst others- does) has so far provided me a reliable experience, even though I'm aware that I'm missing out on performance. Hopefully, Bcachefs will prove to be a vast improvement over Btrfs in a relatively short time-span. You've pointed out to have installed Linux Mint with ZFS. Would I be correct to assume that you've been hurt by Btrfs in its infancy and choose to not rely on it since? Or is it related to lacking proper support for RAID 5/6? Or perhaps something else? Please feel free to inform me as I don't feel confident on this topic!

and the experience ubuntu has lately provided I just took the longer route and installed mint with zfs.

Understandable. Though, I can't stop myself from being very interested in their upcoming Ubuntu Core Desktop. But I imagine you couldn't care less 😜.

Are there arguments against immutability?

Initially I was typing out a very long answer, but it quickly got unwieldy 😅. So instead, this one will be oversimplified 😜.

Currently:

• Package management on native system just takes considerably longer on most atomic^[1]^ distros. The exceptions would be Guix and NixOS, but unfortunately their associated learning curves are (very) steep compared to the other atomic distros.
• The learning curve in general is steeper.
• Documentation is lacking.
• Big shifts occur more frequently^[2]^.
• Some things simply don't work (yet).

One might (perhaps correctly) point out that most of these are actually more related to the technology lacking maturity. And that atomic distros would actually (already) net positively otherwise. Therefore, I'd argue, the transition to atomic distros is perhaps more akin to a natural evolution. I believe (at least) Fedora has already mentioned the possibility to sunset the non-atomic variant in favor of the atomic one when the time is there (or at least switch focus). Which is why I believe that atomicity will probably leave a lasting impact to the Linux landscape, similarly to what systemd has done in years prior.

Besides that it’s probably a challenge to maintain…

If your use-case is supported and you've acquired the associated knowledge for setup/configuration and maintenance, then I'd argue it's probably even easier than a non-atomic distro; simply by virtue of atomicity, increased stability and rollback-functionality. But, as has already been established previously, the learning curve is steeper in general, so getting there is probably harder. With the exception being those whose needs are satisfied easily by the accessible software found in the main package-'storefront'. Which makes distros like Endless OS very suitable for people whose primary interaction with 'computers' has been mobile phones and tablets, as the transition is -perhaps surprising to some- near flawless.

1. Yes, that's how I'll be referring to them.
2. Fedora Silverblue switching to OCI container images for delivery of installations and upgrades. openSUSE's offerings switching to image-based. Vanilla OS switching from Ubuntu to Debian and to a model that's a lot more similar to where Silverblue is headed towards. NixOS switching to flakes. etc

It's often used to describe a distro in which (at least some) parts of the system are read-only on runtime. Furthermore, features like atomicity (i.e. an upgrade either happens or doesn't; no in-between state), reproducibility^[1]^ and improved security against certain types of attacks are its associated benefits that can (mostly) only exist due to said 'immutability'. This allows higher degree of stability and (finally) rollback-functionality, which are functionalities that are often associated with 'immutability' but aren't inherently/necessarily tied to it; as other means to gain these do exist.

The reason why I've been careful with the term "immutable" (which literally is a fancy word for "unchanging"), is because the term doesn't quite apply to what the distros offer (most of these aren't actually unchanging in absolute sense) and because people tend to import associations that come from other ecosystems that have their own rules regarding immutability (like Android, SteamOS etc). A more fitting term would be atomic (which has been used to some degree by distros in the past). The name actually applies to all distros that are currently referred to as 'immutable', it's descriptive and is the actual differentiator between these and the so-called 'mutable' distros. Further differentiation can be had with descriptions like declarative, image-based, reproducible etc.

1. That is, two machines that have the exact same software installed should be identical even if one has been installed a few years ago, while the other has been freshly installed (besides content of home folder etc). So stuff like cruft, bitrot and (to a lesser degree) state are absent on so-called 'immutable' distros.

I personally agree with your assessments regarding Debian Sid and Manjaro. However, I didn't want to force my (potential) 'bias' in a comment that tries to be otherwise neutral. Thank you for bringing up the 'asterisks' associated with both of these!

NixOS has been around since 2003, thus making it older than Ubuntu (2004). Even Silverblue has been out since more than 5 years (October 2018). Finally, we can't forget about Guix that had its first release over 10 years ago (January 2013).

In general, consider setting up any kind of rollback functionality; this will enable you to get right back to action without any downtime when you're time-restricted. This can be achieved by configuring your system with (GRUB-)Btrfs+TImeshift/Snapper. Please bear in mind that it's likely that you have to come back to solve it eventually, though*. (Perhaps it's worth thinking about what can be done to ensure that you don't end up with a broken system in the first place. *cough* ~'immutable'~ ~distro~ *cough*)

If this seems too troublesome to setup, then consider using distros that have this properly setup from the get-go by default; like (in alphabetical order) Garuda Linux, Manjaro, Nobara, openSUSE Aeon/Kalpa/Leap/Slowroll/Tumbleweed, siduction and SpiralLinux. Furthermore, so-called 'immutable' distros also have rollback functionality while not relying on aforementioned (GRUB-)Btrfs+TImeshift/Snapper; this applies to e.g. blendOS, Fedora Kinoite/Sericea/Silverblue, Guix, NixOS and Vanilla OS.

If you feel absolutely overwhelmed by the amount of choice, then you should probably consider the bold ones; not because I think they're necessarily better but:

• openSUSE's offerings are generally speaking very polished, therefore being highly suitable to replace Linux Mint or Ubuntu. It's its own thing though, therefore you might not be able to access packages that are exclusively found in Debian's/Ubuntu's repos (though Distrobox solves that trivially). Tumbleweed if you like rolling release, Slowroll if you prefer updates only once every 1-2 months and finally Leap if you lean more towards Stable/LTS releases.
• siduction for being based on Debian; but it's strictly on the Unstable(/Sid) branch.
• SpiralLinux for being based on Debian; this one -however- has proper support for switching branches.
• Vanilla OS for being based on Debian; this one is very ambitious. But, because it's an 'immutable' distro, it might require the biggest changes to your workflow.

nvidia drivers are absent

While any of the aforementioned distros do a decent job at 'supporting' Nvidia, perhaps you might be best off with uBlue's Nvidia images. As these are images relying on the same technology that Fedora's immutable distros do, rollback functionality and all the other good stuff we've come to love -like automatic upgrades in the background- are present as well. In case you're interested to know how these actually provide improved Nvidia support:

"We've slipstreamed the Nvidia drivers right onto the operating system image. Steps that once took place on your local laptop are now done in a continuous integration system in GitHub. Once they are complete, the system stamps out an image which then makes its way to your PC.

No more building drivers on your laptop, dealing with signing, akmods, third party repo conflicts, or any of that. We've fully automated it so that if there's an issue, we fix it in GitHub, for everyone.

But it's not just installation and configuration: We provide Nvidia driver versions 525, 520, and 470 for each of these. You can atomically switch between any of these, so if your driver worked perfectly on a certain day and you find a regression you just rebase to that image.

Or switch to another desktop entirely.

No other desktop Linux does this, and we're just getting started."

Source

I somehow forgot that Fedora also had Firefox in their flatpak repos.

I got a Nitrokey for Heads

You know what's good, fam.

but for some reason it never arrived

That's messed up, though.

Apart from having all the nice KDE integration

I'm a sucker for GNOME :P , but I'll keep it in mind.

things like Keepass integration

The flatpak does allow integration, but isn't built-in unfortunately; so one has to fiddle a bit themselves to set it up.

Fido2 keys

I should rely more on those. Do you have any recommendations? I've been hearing good things about Nitropad and Yubico, but I honestly don't know if they're actually good and how they would fare amongst eachother.

drag and drop

Overrated anyways /s :P .

Also afaik the Fedora Firefox has a good SELinux profile

It's probably better configured with the native package than the flatpak one indeed. I wonder if this will change as Fedora is interested to ship Firefox as a flatpak by default on Silverblue (and variants).

it runs damn fast. I did a speed test and it was best

I haven't had the best internet speeds since I've been relying on free VPN. But that's on me :P .