You’re right that “immutable” is a bit of a misnomer in that regard, and it’s been argued that “atomic” is a more fitting term.

And I agree that a lot of documentation and how-to-guides don’t account for immutable setups (yet?), which can get novice users especially in a lot of trouble.

Personally, I prefer a declarative system (NixOS) that solves this problem rather cleanly and gives me most benefits of so-called immutable distros as well.

I find it hard to imagine a system that is not borkable by a superuser. Maybe it’s helpful to think of immutable setups as harder to bork by accident during routine maintenance (e.g. through faulty updates) and more resilient to bad code (through containerization).

No, that would clearly defeat the purpose of redundant backups. I remember the passphrases for my backups.

Good catch… and that’s why I keep up-to-date encrypted offline backups in two locations (home and office) always. That should be enough really, but I’ve been thinking about swapping one of those drives with a third backup at one of my relatives’ house from time to time, just to make irrecoverable failure even less likely.

There are many ways to go about this. Files like those keyfiles and encryption headers are extra sensitive because (a) they potentially provide access to everything and (b) losing them can block access to everything. Personally, I keep those types of files unencrypted in a directory that stays 100% offline (encrypted backups to external disks only). But there’s no reason not to back those files up to an encrypted online repository (where you trust the encryption). Just make sure that’s not your only backup of those files for obvious reasons.

A good practice to avoid painting yourself in a corner is to test your backups: Switch off your PC / server, put your mobile devices in a drawer (pretend they’re gone), borrow / wipe a cheap laptop. How do you access your backup files using just that laptop?

℅ (care of)

*laughs in khal*

That seems to be a common usage of the term, but strictly speaking, “userspace” is anything that’s not the kernel. This includes system-level programs, libraries and settings configured as “root” that can affect all users.

Thanks for clarifying! I can totally see where that sort of stuff can really mess things up.

My experience with development environments has been a bit better: Node works out of the box, no problem. For Ruby, the workflow took a little setting up (with bundix), but ended up working very reliably. For R, I actually enjoy that I can set up all my packages with home-manager and they get updated in my regular update cycle and it’s not a separate process altogether.

Out of curiosity, what do you mean by “pain with static linkage”? If my links have broken in NixOS, it was always due to my inability / laziness to set things up correctly.

I have been using NixOS for my daily driver for about a year now, and while it has been a bit of a learning curve to set things up and heavily rewrite my dotfiles, the dependability and availability of packages has been nothing short of amazing. It feels a lot like the final destination for my distro hopping journey.

I use a lot of CLI tools and some system level hackage to get my keybindings just right, so when I tried out Silverblue I had to load in a lot of stuff through rpm-ostree, which was less than ideal. But if OP wants a rock solid system with Flatpak apps, I wholeheartedly second Silverblue.