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

        What’s your alternative? I’ve used OpenRC before and it was nice, but it didn’t take long to find a use-case that systemd handled easily but OpenRC made difficult. Also a few packages expect systemd to be present and either fail to install or partially install so I had to figure out how to implement the missing functions in OpenRC.

    • Jumuta@sh.itjust.works
      link
      fedilink
      arrow-up
      10
      ·
      edit-2
      1 year ago

      why? Do you mean “like” as in you’d rather have them than not, or that you think they’re a good way to package apps?

      • Avid Amoeba@lemmy.ca
        link
        fedilink
        arrow-up
        4
        arrow-down
        1
        ·
        edit-2
        1 year ago

        I think they’re a good way to package apps. Superior to Flatpak for sure. I like Flatpak too and if Canonical abandoned Snap tomorrow, I’d switch my snap-packaged apps to Flatpak. The only non-bullshit downside of Snap is the proprietary server-side and the lack of multi-repo support. I don’t care much about either because I know implementing either is fairly uncomplicated and it will happen should the reason arise. If Debian wanted to start using Snap, it’d take them a month to get the basics working with their own server side. If the client side was proprietary too, I’d have had a completely opposite opinion on Snap. Finally Canonical supplies all the software on my OS. I use third party repos only when absolutely necessary. If Canonical ran a proprietary apt server side, I wouldn’t even know, apt doesn’t care. Some of the myriad HTTP mirrors could easily be running on IIS, or S3, or Nexus. The trust equation for snap is equivalent.

        • corsicanguppy@lemmy.ca
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          I think they’re a good way to package apps.

          Tell us you don’t know why you need Single Source of Truth on package installation and content without using the phrase “dependency hell is self-inflicted”.

          • Avid Amoeba@lemmy.ca
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            1 year ago

            A single source of truth for software is one way to solve that. There are others with different pros and cons in active use that have shown pretty good results.