I have tested a lot of atomic and traditional distributions lately. Tons of desktop environments strictly for fun and branching out. Having a 1 2 3 backup strategy and not just having it in place, but being able to restore your backup in a timely manner to keep continuity is paramount. You can list infinite reasons why.

Why do atomic distros which are supposed to me more stable, superior to some degree immutable environments lack good backup options? You can hack things together and there are somewhat installable tools. Like timeshift or etc etc. But it seems they place a lot more emphasis on rolling back poor updates in the event than total system backups.

By default it you should have true backups then layer in rollbacks. Not the other way around. Am I missing something?

  • pyssla@quokk.au
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    4
    ·
    15 hours ago

    Fam, I loathe saying this, but -please- if you desire engagement, then at least put some honest effort into proofreading your writings before posting them. I’m just assuming stuff at this point because I can barely grasp your intent/writing. *sigh*

    Why do atomic distros which are supposed to me more stable, superior to some degree immutable environments lack good backup options? You can hack things together and there are somewhat installable tools. Like timeshift or etc etc.

    Which distros even come by default -so installed OOTB- with “good backup options”? Which atomic distros is this statement even based on?

    But it seems they place a lot more emphasis on rolling back poor updates in the event than total system backups.

    Because their atomicity barely goes beyond updates. The ‘atomic’ in “atomic distros” mostly describes how its updates are atomic; i.e. the system either updates successfully or doesn’t update at all. Thus, by design, we have two possible states after an update: a ‘successfully’ updated system or a ‘failed’ update resulting in the same state as the previous. Atomic distros aren’t smart enough to catch all ‘breakage’ occurred by ‘successful’ updates. As such, most of these breakages will only show them after trying to boot into updated system. Deleting/erasing the previous known good state without verifying that the new/upcoming state works well is foolish. Especially on a distro that’s got robust updates otherwise. Hence, the functionality of rollbacks on updates is almost trivially done/applied to atomic distros, as it (almost) follows by design.

    So, what I’m interested in is the following:

    • Are you familiar with the notion of stateless systems? Is this (perhaps) what you’re (actually) seeking?

    By default it you should have true backups then layer in rollbacks. Not the other way around. Am I missing something?

    I think my previous paragraph should be enlightening in this regard. If you disagree (or something/otherwise), then please feel free to elaborate why you think so. Btw, what do you even mean with "true backups?

    • Luke@lemmy.ml
      link
      fedilink
      English
      arrow-up
      7
      ·
      10 hours ago

      Based on their post history, I strongly suspect the OP has English as a non-primary language. They are doing fine, their posts are perfectly understandable. There’s no value in harassing them about that.