Managing System Extensions on openSUSE MicroOS with sysextmgrcli If you are running openSUSE MicroOS, you already know the drill: the root filesystem is read...
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 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.
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 ofmodifying stuff, youmightreintroducesome ofthe statefulness that theparadigmwas 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.
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.
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.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!
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.