64
Experiences using immutable Linux desktops?
(lemmy.zip)
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.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
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
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.
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.
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.