• 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.