That “Micro” spooked me for a second
Soo, BSD with extra steps?
This is cool, and I’m interested to see where this goes. But to me the whole sysext thing is actually a compelling argument for why Linux power users (i.e. most Linux users on lemmy) aren’t suited to immutable distros.
When something as fundamental as git requires multiple obscure commands to install, you’ve got to think twice about the target audience.
But to me the whole sysext thing is actually a compelling argument for why Linux power users (i.e. most Linux users on lemmy) aren’t suited to immutable distros.
Sorry, but I don’t see why. Btw, I’m pretty well-versed in
immutableatomic distros. So, please don’t feel the need to explain how it works.When something as fundamental as git requires multiple obscure commands to install
I think you’re overstating the bold part.
Instead of
<package-manager> install <package>, it becomessysextmgrcli install <package>andsystemd-sysext merge. I understand that going from a single command to two commands is effectively doubling the effort. But, assystextmgrcliis a horribly long name to invoke (and why I suspect it will change eventually), you might want toaliasthat anyways. At which point, creating a function within your .bashrc to streamline that to a single command shouldn’t be too much to ask for a power user.As for the obscure part,
sysextmgrcliis the tool that’s being introduced. Hence, it would be rather oxymoronic to expect that it’s anything but obscure. Beyond that, its usage seems reasonably sane and relatively standard. Very common arguments likelist,installandupdatethat are found on basically every other package manager work as expected. So, honestly, I don’t see the problem.As for the second command, while
systemd-sysexthas been a part ofsystemdsince its v248 release over five years ago, Desktop Linux users haven’t had much use for it yet. Though, thankfully, learning thatsystemd-sysext mergeis done after installing a system extension andsystemd-sysext unmergeis done for uninstalling a system extension shouldn’t be too much to ask.Its not so much the UX that I take issue with, but the complexity of what’s going on under the hood.
The way I see it, either the base image of an atomic/immutable distro is suitable for you, or it isn’t. Once you start getting into the territory of layering new tools/drivers/whatever on top, you’re reintroducing the statefulness that the atomicity was supposed to eliminate.
Hmm…, I didn’t get that from your first response. But thank you for clarifying!
Once you start getting into the territory of layering new tools/drivers/whatever on top, you’re reintroducing the statefulness that the atomicity was supposed to eliminate.
I agree with your sentiment overall, but with a lot of nuance. I’d rather formulate it purposely ambiguous as follows: Once you start getting into the territory of modifying stuff, you might reintroduce some of the statefulness that the paradigm was supposed to eliminate.
I am aware that this ambiguity invites clarity and elaboration. And therefore I’d like to offer my genuine apologies for not responding to said invitation. However, I hope that this excellently written blogpost suffices in conveying how systems can be both stateless and ever-mutable.
spoiler
The answer is indeed by going declarative.
No apologies necessary! I was partly kicking the hornets nest to see if an interesting discussion fell out…
That blog post is absolutely brilliant! It does a great job of stating what a user should want from a system: easy and deterministic re-deployment. If atomic ends up being the best too for that job, I’ll come back. But for now I’m happy with Debian, a separate home partition, and a strong preference for flatpak over apt.
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-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.
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…
See NixOS 😜. ↩︎
I agree in the case of Fedora Atomic, they’ve stuck to flatpak and podman (so far, they have their system extension manager tool in the work) and have rpm layering as a fallback.
But not all atomic distros have that fallback. Universal Blue, more specifically Bluefin, does not want to allow layering at all; this is already implemented in the LTS version (though it’s just bootc, so you can build your own image to install rpms). This is also true for “distroless” models like Gnome OS (and there you don’t have any prebuilt packages to pull in even if you made your own buildstream image). So for these, you have to make-do with the package managers they provide or you’re out of luck.
In an ideal world, I think we should have a single package manager that sits on top the the OS that can handle everything: GUI apps, CLI tools, sandboxed by default but also able to be disabled completely for the apps that don’t work well with sandboxes. The closest thing we have to that right now is snap.
In an imperfect but more likely world, I would be fine with two package managers. Flatpak for GUI apps and something else for CLI tools. “Flatpak Next” could fix one issue with its unsandboxed mode. But I still haven’t found something that universally works well for CLI apps.
- Podman is the classic answer, but it can be a bit annoying jumping into and out of boxes. Doesn’t work well for more “system tooling” like Tailscale that also want services.
- Homebrew is a more modern suggestion and actually works pretty well. But I’m not a fan out how hijacks PATH in a way that can break OS packages (such as by making homebrew dbus and systemd used over OS versions). And last I tried, the homebrew version of tailscale didn’t work (though I have read that others did get it working).
- Coldbrew is an interesting alternative to coldbrew, which uses alpine packages and doesn’t mess with PATH directly, but it does place some stuff in .local/bin that could end up overriding some binaries anyway (though not to as high a degree as homebrew, and thankfully doesn’t affect libraries). But has integration issues due to sandboxing (personally had an issue where I had an app that wanted to open my browser, but it couldn’t see my browser because of the sandbox).
- I still need to test Nix on an atomic distro
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
Very cool to see that System Extensions are being adopted and that the tooling is improving to reflect that!
This reminds me of the
sysexts-managerproject, which is worked on by a Fedora Atomic maintainer.
