Managing System Extensions on openSUSE MicroOS with sysextmgrcli If you are running openSUSE MicroOS, you already know the drill: the root filesystem is read...
When something as fundamental as git requires multiple obscure commands to install, you’ve got to think twice about the target audience.
Ideally the tooling gets better and you don’t have to do anything else but “toolname install package” or have a declarative list of what to install.
why Linux power users (i.e. most Linux users on lemmy) aren’t suited to immutable distros.
I think the main problem is that immutable distros haven’t thought things through from the beginning.
It started out as just using flatpak and podman. But each of those has limitations. But rather than improving them, we just keep creating / bringing in new package managers. Homebrew, cold brew, system extensions, nix, etc.
Funnily enough, the only entity who is sane in this regard is Canonical. If snap has a limitation, they just update snap to not have the limitation rather than brining in another package manager.
But honestly I think the biggest offender here is flatpak. If not for its mandatory sandbox and anti CLI tool stance, it could have handled everything. “Flatpak Next” seems to be address the first issue as it is planned to have an unsandboxed mode.
I think the main problem is that immutable distros haven’t thought things through from the beginning.
I think I understand why you might have that feeling, but I think it’s more complex than that.
Say, we look at Fedora Atomic, as that’s the atomic distro I’m most familiar with. At inception, it offered the following (‘staggered’) three-way:
Flatpak, if it’s available (and if it works nicely).
Toolbx, if the above didn’t work (and if it works nicely).
rpm-ostree, if the above didn’t work. Basically your fail-safe.
So AFAIU, as long as you didn’t rpm-ostree your whole system, it was a ‘win’ for the atomic model.
You might argue that their priority should have been the development of an all-encompassing package manager that works (almost) as sleek any other one. And only after that’s been (somewhat) completed, should they have shipped a system built around it. However, the trouble it has been taking Ubuntu to launch its Core Desktop since its announcement, definitely suggests that building an OS around a more complete (and complex) package manager poses its own set of challenges[1]. Contrast that to Fedora and openSUSE, both of which were able to launch their respective atomic distros for Desktop Linux in a more timely fashion.
If snap has a limitation, they just update snap to not have the limitation rather than brining in another package manager.
I think you’re making a category error. If Snap chooses to replace your complete OS, then it makes sense to get rid of any limitations. Because that’s in scope of its intended design. Flatpak, from my understanding, simply tries to become for Desktop Linux what the App Store and Google Play are for iOS and Android respectively. Hence, it doesn’t make much sense to blame it for what is out of its scope. Similarly to how it wouldn’t make any sense to scold VLC because it doesn’t play your Windows games. Here, I explicitly named Flatpak, but note that this principle applies to basically any other alternative package manager we (tend to) find on atomic distros.
Consequently, therefore, perhaps the distros are to be blamed for shipping lackluster package managers instead of introducing one-to-one replacements of the traditional ones. But I think this is just a very complex problem 😅. And I suppose you knew that already…
Certainly I’d love a universal GUI/CLI package manager with optional sandboxing. I don’t use nix, but it seems like the closest solution out there right now
Ideally the tooling gets better and you don’t have to do anything else but “toolname install package” or have a declarative list of what to install.
I think the main problem is that immutable distros haven’t thought things through from the beginning.
It started out as just using flatpak and podman. But each of those has limitations. But rather than improving them, we just keep creating / bringing in new package managers. Homebrew, cold brew, system extensions, nix, etc.
Funnily enough, the only entity who is sane in this regard is Canonical. If snap has a limitation, they just update snap to not have the limitation rather than brining in another package manager.
But honestly I think the biggest offender here is flatpak. If not for its mandatory sandbox and anti CLI tool stance, it could have handled everything. “Flatpak Next” seems to be address the first issue as it is planned to have an unsandboxed mode.
I think I understand why you might have that feeling, but I think it’s more complex than that.
Say, we look at Fedora Atomic, as that’s the atomic distro I’m most familiar with. At inception, it offered the following (‘staggered’) three-way:
rpm-ostree, if the above didn’t work. Basically your fail-safe.So AFAIU, as long as you didn’t
rpm-ostreeyour whole system, it was a ‘win’ for the atomic model.You might argue that their priority should have been the development of an all-encompassing package manager that works (almost) as sleek any other one. And only after that’s been (somewhat) completed, should they have shipped a system built around it. However, the trouble it has been taking Ubuntu to launch its Core Desktop since its announcement, definitely suggests that building an OS around a more complete (and complex) package manager poses its own set of challenges[1]. Contrast that to Fedora and openSUSE, both of which were able to launch their respective atomic distros for Desktop Linux in a more timely fashion.
I think you’re making a category error. If Snap chooses to replace your complete OS, then it makes sense to get rid of any limitations. Because that’s in scope of its intended design. Flatpak, from my understanding, simply tries to become for Desktop Linux what the App Store and Google Play are for iOS and Android respectively. Hence, it doesn’t make much sense to blame it for what is out of its scope. Similarly to how it wouldn’t make any sense to scold VLC because it doesn’t play your Windows games. Here, I explicitly named Flatpak, but note that this principle applies to basically any other alternative package manager we (tend to) find on atomic distros.
Consequently, therefore, perhaps the distros are to be blamed for shipping lackluster package managers instead of introducing one-to-one replacements of the traditional ones. But I think this is just a very complex problem 😅. And I suppose you knew that already…
See NixOS 😜. ↩︎
Hmm, I think I agree with this.
Certainly I’d love a universal GUI/CLI package manager with optional sandboxing. I don’t use nix, but it seems like the closest solution out there right now