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 immutable atomic 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 becomes sysextmgrcli install <package> and systemd-sysext merge. I understand that going from a single command to two commands is effectively doubling the effort. But, as systextmgrcli is a horribly long name to invoke (and why I suspect it will change eventually), you might want to alias that 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, sysextmgrcli is 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 like list, install and update that 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-sysext has been a part of systemd since its v248 release over five years ago, Desktop Linux users haven’t had much use for it yet. Though, thankfully, learning that systemd-sysext merge is done after installing a system extension and systemd-sysext unmerge is done for uninstalling a system extension shouldn’t be too much to ask.

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.