Managing System Extensions on openSUSE MicroOS with sysextmgrcli If you are running openSUSE MicroOS, you already know the drill: the root filesystem is read...
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.
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.