this post was submitted on 06 Aug 2024
344 points (92.0% liked)
linuxmemes
21240 readers
16 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack members of the community for any reason.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
- These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudo in Windows.
- No porn. Even if you watch it on a Linux machine.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
Please report posts and comments that break these rules!
founded 1 year ago
MODERATORS
The problem with making the core immutable is that you have to decide where you draw the line between immutable and regular packages.
It sounds nice to be able to always have an immutable blob with some built-in functionality that you can fall back to, but the question is how far do you want to take that blob?
Things that go into the immutable blob don't offer much (if any) choice to the user. I can see it being used for something like the kernel and basic drivers, coreutils, basic networking. It starts getting blurry when you get to things like systemd and over-reaching when it gets to desktop functionality.
Also, you say it's more reliable but you can get bugs in anything. Version x.y.z of the kernel can have bugs whether it's distributed as part of an immutable core or as a package.
I definitely think distributing software as immutable bulk layers can be useful for certain device classes such as embedded, mobile, gaming etc. The Steam Deck for example and other devices where the vendor can predefine the partition table and just image it with a single binary blob.
On the desktop however I struggle to see what problems immutable solves that are not already solved some other way. Desktop machines require some degree of flexibility.
The whole point is you can roll back if something breaks.
Systemd is a core part of the system as init always has been.
Honestly though I don't think you actually understand the difference between declarative and immutable distros. Unlike what some people think they aren't actually the same thing. It would be nice if people stopped limping them together.
Most packages are purely additive to to system. If GNOME is part of the base system, I don't care because I can just not use it. For packages that are mutually exclusive, well, usually that's the distro picking it for you anyway, but if you insist on changing them then OverlayFS lets you mask files in the base.
For something like Arch or Gentoo, the read-only partition approach absolutely won't work, but I know Fedora's been working on an OSTree immutable approach, so it's still technically a mutable partition but it's defined declaratively and is still easy to roll back.