4 ms·
I'll offer a less charitable framing of the whole topic of immutable / atomic distros: This is pretty much Linux distributors deciding they want to stop doing
by stakhanov 2y ago
I'll offer a less charitable framing of the whole topic of immutable / atomic distros: This is pretty much Linux distributors deciding they want to stop doing their job (or redefine what their job is to a much smaller scope). -- I'm not saying it's not justifiable that the ecosystem may need to be reshaped in that way. I'm just cautioning people from drinking the “this is the future and the future looks bright” Kool-Aid all too easily.
The job of making a Linux distribution has always been what, in an old-fashioned term, used to be called “system integration” work. They would start with a bewilderingly huge array of open-source packages, each being developed without any centralized standard or centralized control over what the system actually looks like. Then they would curate a collection of build recipes and patches for those packages.
The value a distro delivers for the user is that, for any package “foo” that their heart desires, a user can just say “apt install foo” and it'll “just work”. There will be default configuration and patches to make foo integrate perfectly with the rest of the system.
The value a distro delivers for package maintainers is: “Don't worry about the packaging. Just put your code out as open source, and we'll take care of the rest.”
The job of a distributor is extremely difficult, because of all the moving parts: People select their hardware, their packages, and they mess with the default configurations. It is no wonder at all that Linux distributions don't always succeed in their mission to truly deliver on this. But it's a huge engineering achievement that they work as well as they do, and I think we shouldn't lightly give up on that achievement.
What we have now is basically distros going: Awwwww. Fuck it. This is too hard. I'm done with this. You know what? Instead of “any package your heart desires”, you get a fixed set of packages. The ones that everyone needs regardless of what they actually do with their computer. Instead of being allowed to mess with your configuration, we'll make your rootfs read-only. (In the case of SteamOS): Instead of doing our best to make it work on your hardware, we'll tell you precisely which piece of hardware you'll need to buy if you want our software to run on it. User: Well, that's additional money I need to spend. And, how do I install my favourite app “foo”? The one I need to actually get useful work out of my computer? Distro: Don't worry, we've got you covered. We'll provide a runtime for distrobox and flatpaks. Package maintainer of “foo”: How do I get my package out in a way that perfectly integrates with distros? Distro: Make a container. Congratulations: This is additional work you have to do now, that you didn't have to do before. And about that idea of perfect integration: You can kiss that goodbye. User: I don't know. I'm also in favour of integration. Distro: That's alright. You can share and unshare stuff between containers and the host system. This, of course, is additional work you didn't have to do before. Less work for me, more work for everyone else. The future looks so bright.
- hurutparittya 2y agoWell, I've been using NixOS for a while now, and it's by far the most "integrated" feeling distro I've ever tried.
- stakhanov 2y agoIn what I wrote above, I wasn't referring to NixOS or Guix. I was thinking of the other ones (SteamOS, Fedora Silverblue, OpenSuSE Aeon, Vanilla OS, etc.) -- In fact, I think it's a bit misleading to lump them together in the same category of "atomic" or "immutable". This term has come to mean way too many different things.
- Imustaskforhelp 2y agoTo be honest , most developers would much prefer to write containers or flatpak if it just works on any linux machine. There is no free lunch , the developer might feel that his package just got into apt magically without him doing effort but the maintainer would need to do these efforts and it might not be streamlined for the developer as much as a container created by the dev himself. It also provides more security. Flatpaks are really neat but they aren't that used in cli world in my opinion, I wanted to make a flatpak cli and I just couldn't , so I gave up Appimage are also nice but they also have some issues , I had created appseed which basically created a static binary from dynamic binaries automatically using zapps.app but it has some issues and i am too lazy
- Imustaskforhelp 2y agoThis post also sounds way too passive aggressive to me . I don't know. Just my 2 cents
- rcxdude 2y agoWhat kind of integration do you mean? Basically the only integration that distros do is forcing all packages into one library dependency, which is something with relatively little user-facing benefit (in fact, it's mostly to make it easier for the maintainers to do security updates). This push towards appimages and the like is basically about standardising the interface between the distro and the application, so application developers don't need to rely on the distros packaging their app correctly, or to do N different packages for N different distros and deal with N different arbitrary differences between them (and if they want to delegate this packaging work like before, they can. Not all of these various packages are put out by the author of the software). (Now, whether these various standards work well enough, is a different question. There seems to be a bit of a proliferation of them, all of which have various weaknesses ATM, so it seems there's still some improvements to be made there, but the principle is fairly sensible if you want to a) have a variety of distros and b) not have M*N work to do for M applications and N distros)