Is the future of Linux really read-only? This video breaks down the rise of immutable Linux distributions like Fedora Silverblue, Universal Blue, NixOS and t...
I could see it becoming the future. But only under a couple of scenarios.
Scenario A: It becomes (strictly) better and/or easier than the alternative. Kinda like how systemd effectively replaced SysVinit within a couple of years, simply because it was a more sane alternative. But this is reliant on the read-only aspect being put in place without affecting existing workflows on traditional distros.
So, as Fedora Atomic is the atomic distro I’m most familiar with, I’ll provide explicit examples from it:
Installing packages shouldn’t take a reboot to take effect. I can see sysexts being leveraged for this eventually.
Any commands that involve dnf should (somehow) continue to function. It could even be an alias (or something) that invokes something else entirely. I don’t even think most users will care for what exactly happens in the background, as long as the functional expectation is being met.
The previous two points shouldn’t come at a (significant) speed loss.
Scenario B: It’s enforced on us by (some of) our Linux overlords and/or expected by (parts of) the Desktop Linux stack. Kinda like how the GNOME desktop environment currently has dependencies that are systemd-components. Thus, requiring some hacking to make it work in its absence. Currently, I can only see some RHEL(-adjacent) projects committing to this.
But I think both of the above scenarios are at least 5 years away. While atomic/immutable distros enjoy a healthy (perhaps even generous) amount of development, AFAIK none of them are actually 100% feature-complete[1] compared to their traditional counterparts. So, fixing (most of) the remaining edge cases to make migration possible for every enthusiast that even considers switching, should probably be their priority.
I found the regular Fedora SilverBlue install did not give enough flexibility to be very usable. The suggestion to just use toolkits is not for mortals. I copied Bazzite and installed homebrew (coming from Mac, that’s comfortable). Brew solved 95% of the pain.
The next annoying 4% was stuff that doesn’t work well with flatpack: Steam, gamescope, password managers, etc.
Then there’s a final 1% of the masses of content written about Fedora using rpm and dnf that just kinda doesn’t work. Makes stuff like following a build guide or install steps a little bit more annoying.
The really nice thing about it though is I was able to switch between different fedora environments and bazzite with relatively little pain. Nothing really broke, which was great.
If the future of the desktop is linux, it needs immutable distros to get really good. Personally, I wouldn’t want to go back to fully-root-editable linux, but I also do not blame the folks (who want to) to be able to nuke systemd and Wayland (which both do too much for my taste) and do their own thing.
I 100% agree with you. I think atomic distros are great for people like my parents, where they just need a browser and maybe libreoffice, and it’s valuable to have something that “just works” (now I need to just convince them to give linux it a try…)
If you start getting into coding or customization then it quickly becomes clunky to use and requires knowledge beyond what a beginner would have, especially because most guides will tell you to use the traditional package manager, but that won’t work with immutable root.
Containers, installing software to /home, changing advanced settings is in my experience way too much for most people.
I hope though that this might be solvable in the future with flatpak. Maybe by creating some special category for “CLI tools” with less/no sandboxing but still installable and runnable from a normal user account, and shipping the whole dependency tree.
Overall, I wholeheartedly agree with your assessment.
The suggestion to just use toolkitstoolbox is not for mortals.
I am also not convinced that it was ever meant as the endgame. Like, toolbox still doesn’t offer a mechanic to upgrade a(ll) container(s) without entering one. The last time I used it, it also shat itself whenever the old pet container became EOL and desired a ‘system update’ to become functional. IIRC, distrobox doesn’t fare any better at this. Thus, coming with what looks like planned obsolescence; with the recreation of the pet containers every couple of months as a result. I suppose the solution is picking an image that’s supposed to be rolling-release. Which is why I think this workflow suits Aeon better.
Yeah, NixOS is excellent. But, for nix (or close enough) to be the future, an upgrade path should exist for other distros. But, for some reason, I don’t really see any such efforts. Like, where are the nix-variants of other distros?
Which is still very rough around the edges. There’s still software that doesn’t work properly at all in some setups, and flatseal is still essential to make some other apps work as expected.
Perhaps I should have been more clear. My apologies. I wanted to draw attention to the fact that -in the case of Fedora Atomic- layering remains a necessity (for most users). This thread goes over it in more detail.
flatpak
Technically speaking, the flatpak format isn’t even as limited as some make it out to be. For example, software like Bottles have offered CLI/TUI functionality through it. But Flathub, its most popular storefront, does put a limitation on submissions. Which means that it’s effectively not even competing with other package managers that (conventionally) try to offer a broader set of software.
Furthermore, even if the flatpak package exists, not all functionality is retained. For example, the situation around native messaging is still a mess. This prevents e.g. your flatpak browser from communicating with your locally installed password manager. While a(n ugly) workaround exists, it’s quite maddening that it hasn’t been resolved in all these years 😅.
I could see it becoming the future. But only under a couple of scenarios.
Scenario A: It becomes (strictly) better and/or easier than the alternative. Kinda like how systemd effectively replaced SysVinit within a couple of years, simply because it was a more sane alternative. But this is reliant on the read-only aspect being put in place without affecting existing workflows on traditional distros. So, as Fedora Atomic is the atomic distro I’m most familiar with, I’ll provide explicit examples from it:
dnfshould (somehow) continue to function. It could even be an alias (or something) that invokes something else entirely. I don’t even think most users will care for what exactly happens in the background, as long as the functional expectation is being met.Scenario B: It’s enforced on us by (some of) our Linux overlords and/or expected by (parts of) the Desktop Linux stack. Kinda like how the GNOME desktop environment currently has dependencies that are systemd-components. Thus, requiring some hacking to make it work in its absence. Currently, I can only see some RHEL(-adjacent) projects committing to this.
But I think both of the above scenarios are at least 5 years away. While atomic/immutable distros enjoy a healthy (perhaps even generous) amount of development, AFAIK none of them are actually 100% feature-complete[1] compared to their traditional counterparts. So, fixing (most of) the remaining edge cases to make migration possible for every enthusiast that even considers switching, should probably be their priority.
To be clear, it’s probably at like 95% or so. ↩︎
It’s definitely getting there.
I found the regular Fedora SilverBlue install did not give enough flexibility to be very usable. The suggestion to just use toolkits is not for mortals. I copied Bazzite and installed homebrew (coming from Mac, that’s comfortable). Brew solved 95% of the pain.
The next annoying 4% was stuff that doesn’t work well with flatpack: Steam, gamescope, password managers, etc.
Then there’s a final 1% of the masses of content written about Fedora using rpm and dnf that just kinda doesn’t work. Makes stuff like following a build guide or install steps a little bit more annoying.
The really nice thing about it though is I was able to switch between different fedora environments and bazzite with relatively little pain. Nothing really broke, which was great.
If the future of the desktop is linux, it needs immutable distros to get really good. Personally, I wouldn’t want to go back to fully-root-editable linux, but I also do not blame the folks (who want to) to be able to nuke systemd and Wayland (which both do too much for my taste) and do their own thing.
I 100% agree with you. I think atomic distros are great for people like my parents, where they just need a browser and maybe libreoffice, and it’s valuable to have something that “just works” (now I need to just convince them to give linux it a try…)
If you start getting into coding or customization then it quickly becomes clunky to use and requires knowledge beyond what a beginner would have, especially because most guides will tell you to use the traditional package manager, but that won’t work with immutable root.
Containers, installing software to /home, changing advanced settings is in my experience way too much for most people.
I hope though that this might be solvable in the future with flatpak. Maybe by creating some special category for “CLI tools” with less/no sandboxing but still installable and runnable from a normal user account, and shipping the whole dependency tree.
Overall, I wholeheartedly agree with your assessment.
I am also not convinced that it was ever meant as the endgame. Like,
toolboxstill doesn’t offer a mechanic to upgrade a(ll) container(s) without entering one. The last time I used it, it also shat itself whenever the old pet container became EOL and desired a ‘system update’ to become functional. IIRC,distroboxdoesn’t fare any better at this. Thus, coming with what looks like planned obsolescence; with the recreation of the pet containers every couple of months as a result. I suppose the solution is picking an image that’s supposed to be rolling-release. Which is why I think this workflow suits Aeon better.NixOS doesn’t require a reboot for installing packages to take effect
Yeah, NixOS is excellent. But, for
nix(or close enough) to be the future, an upgrade path should exist for other distros. But, for some reason, I don’t really see any such efforts. Like, where are thenix-variants of other distros?FWIW, Bootcrew has created
bootc-variants of many other distros. And, even before, both Endless OS and GNOME OS offered examples of non-Fedora distros withostree.EDIT: TIL
You’re just supposed to use flatpak or stuff like distrobox/toolbx. No reboots necessary.
Which is still very rough around the edges. There’s still software that doesn’t work properly at all in some setups, and flatseal is still essential to make some other apps work as expected.
Perhaps I should have been more clear. My apologies. I wanted to draw attention to the fact that -in the case of Fedora Atomic- layering remains a necessity (for most users). This thread goes over it in more detail.
Technically speaking, the flatpak format isn’t even as limited as some make it out to be. For example, software like Bottles have offered CLI/TUI functionality through it. But Flathub, its most popular storefront, does put a limitation on submissions. Which means that it’s effectively not even competing with other package managers that (conventionally) try to offer a broader set of software.
Furthermore, even if the flatpak package exists, not all functionality is retained. For example, the situation around native messaging is still a mess. This prevents e.g. your flatpak browser from communicating with your locally installed password manager. While a(n ugly) workaround exists, it’s quite maddening that it hasn’t been resolved in all these years 😅.
This is actually a mess. See this comment elsewhere under this post for a bit more elaboration.