Experiences using immutable Linux desktops?
Experiences using immutable Linux desktops?
I am playing around with Fedora Silverblue and openSUSE Aeon and I really like the painless updates.
Still, my daily driver for some years now is Debian, and I have a decent setup via Ansible - everything just works for me.
My question is mostly to long term Linux users, which use Linux in a professional context and jumped from a distribution like Fedora, Ubuntu, openSUSE or Debian to NixOS, Silverblue, Aeon etc.
What is your experience? How did your workflows change on your immutable Linux distribution? Did you try immutable and went back to a more traditional distribution - why? How long are you running the immutable distribution and what issues and perks did you run into?
You're viewing a single thread.
These distros are all about making thing that were easy into complex, “locked down”, “inflexible”, bullshit to justify jobs and payed tech stacks / some property solution existence.
We had Ansible, containers, ZFS and BTRFS that provided all the required immutability needed already but someone decided that is is time to transform regular machines into MIPS-style shitty devices that have a read-only OSes and a separate partition for configs. All in the hopes of eventually selling some orchestration and/or other proprietary repository / platform / BS like Docker / Kubernetes does.
More here: https://lemmy.world/comment/4574094
I have to disagree with you on that. You’re missing the point entirely.
It’s not about making something easy into something complicated. It’s about making something that is reliable and reproducible.
Saying it’s just bs to justify jobs, sales, etc is like saying we already have widget X therefore it’s stupid to use widget Y. You’re missing the reasons why someone might need a widget that does something different than widget x.
No one is (should) be saying one is superior to the other. It’s different technology and methods to get to the same goal. That is a working system that consistently and reliably produces results that are required.
So yes, there’s different ways of managing those systems but that’s not a bad thing or is it needlessly complicated for no reason or benefit.
There’s a lot of reasons why someone would choose or need something like nixos or sliverblue. There’s also lots of reasons someone would choose not to use them
It’s about making something that is reliable and reproducible.
Reliable and reproducible are two problems already solved with the solutions I provided.
So yes those are things that can do similar functions and in the case of os-tree based things btrfs is used heavily.
But you’re still missing the point.
It sounds like you’re saying people are needlessly trying to be complicated for no reasons. That we have btrfs & zfs so anything else is pointless.
That’s a lot like saying we have roofs so a roof in Florida should be the same as a roof in Siberia. Anything else is needlessly complicated.
There’s a lot of nuance missing there. Sure we have different technologies that can do similar things. There’s also reasons why someone would use one over the other.
Thank you for your reply, although I have different experience/use cases.
For example, I have an old laptop as a dedicated multimedia machine. An immutable desktop is the far better option for me, as an end user. Everything works OOTB and updates happen silently on reboots.
The same is true for a lot of people which only need a browser, IMHO.
No orchestration or proprietary repository needed.
Any distro with BTRFS works for your use case and will be easier to deal with.
No orchestration or proprietary repository needed.
Yes, but guess what happens whenever people popularize immutable distros as the next hype in tech that will make everything better? You get yourself into a totally unreasonable and avoidable ecosystem just because those systems won't cut it for most use cases.... same that happened with Docker/Kubernetes.
Permanently Deleted
So complex:
// take a read-only snapshot:
btrfs sub snap -r fs snapshot
... do things on fs
// rolling back:
btrfs sub del fs # at which point you'll lose those things you've done
// if you want to preserve them, just rename fs instead
btrfs sub snap snapshot fs # reinstate snapshot as a read+write fs btrfs sub del snapshot # delete the non-longer needed read-only snapshot
Ansible isn't a good solution for reproducibility, since when you remove something from the playbook and redeploy, that old state will still be active.