I am playing around with Fedora Silverblue and openSUSE Aeon and I really like the painless updates.

Still, my daily driver for some years now is Debian, and I have a decent setup via Ansible - everything just works for me.

My question is mostly to long term Linux users, which use Linux in a professional context and jumped from a distribution like Fedora, Ubuntu, openSUSE or Debian to NixOS, Silverblue, Aeon etc.

What is your experience? How did your workflows change on your immutable Linux distribution? Did you try immutable and went back to a more traditional distribution - why? How long are you running the immutable distribution and what issues and perks did you run into?

  • TCB13@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    21
    ·
    1 year ago

    These distros are all about making thing that were easy into complex, “locked down”, “inflexible”, bullshit to justify jobs and payed tech stacks / some property solution existence.

    We had Ansible, containers, ZFS and BTRFS that provided all the required immutability needed already but someone decided that is is time to transform regular machines into MIPS-style shitty devices that have a read-only OSes and a separate partition for configs. All in the hopes of eventually selling some orchestration and/or other proprietary repository / platform / BS like Docker / Kubernetes does.

    More here: https://lemmy.world/comment/4574094

    • Nine@lemmy.world
      link
      fedilink
      arrow-up
      7
      ·
      1 year ago

      I have to disagree with you on that. You’re missing the point entirely.

      It’s not about making something easy into something complicated. It’s about making something that is reliable and reproducible.

      Saying it’s just bs to justify jobs, sales, etc is like saying we already have widget X therefore it’s stupid to use widget Y. You’re missing the reasons why someone might need a widget that does something different than widget x.

      No one is (should) be saying one is superior to the other. It’s different technology and methods to get to the same goal. That is a working system that consistently and reliably produces results that are required.

      So yes, there’s different ways of managing those systems but that’s not a bad thing or is it needlessly complicated for no reason or benefit.

      There’s a lot of reasons why someone would choose or need something like nixos or sliverblue. There’s also lots of reasons someone would choose not to use them

      • TCB13@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        arrow-down
        5
        ·
        1 year ago

        It’s about making something that is reliable and reproducible.

        Reliable and reproducible are two problems already solved with the solutions I provided.

        • Nine@lemmy.world
          link
          fedilink
          arrow-up
          4
          ·
          1 year ago

          So yes those are things that can do similar functions and in the case of os-tree based things btrfs is used heavily.

          But you’re still missing the point.

          It sounds like you’re saying people are needlessly trying to be complicated for no reasons. That we have btrfs & zfs so anything else is pointless.

          That’s a lot like saying we have roofs so a roof in Florida should be the same as a roof in Siberia. Anything else is needlessly complicated.

          There’s a lot of nuance missing there. Sure we have different technologies that can do similar things. There’s also reasons why someone would use one over the other.

    • wolf@lemmy.zipOP
      link
      fedilink
      English
      arrow-up
      3
      ·
      1 year ago

      Thank you for your reply, although I have different experience/use cases.

      For example, I have an old laptop as a dedicated multimedia machine. An immutable desktop is the far better option for me, as an end user. Everything works OOTB and updates happen silently on reboots.

      The same is true for a lot of people which only need a browser, IMHO.

      No orchestration or proprietary repository needed.

      • TCB13@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        arrow-down
        2
        ·
        1 year ago

        Any distro with BTRFS works for your use case and will be easier to deal with.

        No orchestration or proprietary repository needed.

        Yes, but guess what happens whenever people popularize immutable distros as the next hype in tech that will make everything better? You get yourself into a totally unreasonable and avoidable ecosystem just because those systems won’t cut it for most use cases… same that happened with Docker/Kubernetes.

    • mintycactus@lemmy.world
      link
      fedilink
      arrow-up
      4
      arrow-down
      1
      ·
      edit-2
      1 year ago

      Maybe it looks more complex under the hood, but actually it is easy. And it is incredibly easy as ‘for user’, I am not going back to common distro now. I see no issue to install layered app/packages I need often (rare ones are in toolbox, which is also easy) and casual user won’t even need it.

      Edit. I also understand btrfs concept, I used it in workstation, but that is complex thing, common user won’t deal with it.

      • TCB13@lemmy.world
        link
        fedilink
        arrow-up
        2
        arrow-down
        2
        ·
        edit-2
        1 year ago

        So complex:

        // take a read-only snapshot:

        btrfs sub snap -r fs snapshot

        … do things on fs

        // rolling back:

        btrfs sub del fs # at which point you’ll lose those things you’ve done

        // if you want to preserve them, just rename fs instead

        btrfs sub snap snapshot fs # reinstate snapshot as a read+write fs btrfs sub del snapshot # delete the non-longer needed read-only snapshot

    • Lurkki@lemmy.world
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      Ansible isn’t a good solution for reproducibility, since when you remove something from the playbook and redeploy, that old state will still be active.