For years, many Ubuntu users have felt that traditional .deb packages were being gradually sidelined in favor of the Snap ecosystem.

It started quietly. Double-clicking a downloaded .deb file would open it in Archive Manager instead of the installer. Then came controversial changes. Apps like Chromium, Thunderbolt and Firefox began defaulting to Snap packages, even when users tried installing them via the apt command in the terminal.

It continued further as Ubuntu introduced its new Snap Store. In Ubuntu 24.04, it ignored .deb packages completely. Double-clicking a .deb file would open the App Center, but wouldn’t actually install the package and just hang there. That behavior was later reverted after I highlighted it through It’s FOSS.

  • Pennomi@lemmy.world
    link
    fedilink
    English
    arrow-up
    37
    ·
    4 months ago

    Snaps have been utterly stupid. Their sandboxing means my editor apps can’t open the files in my media drive by default. It’s a file editor for fuck’s sake, it needs to be able to access my files.

    • cecilkorik@piefed.ca
      link
      fedilink
      English
      arrow-up
      16
      ·
      4 months ago

      I agree. Flatpaks have similar challenges. I understand the dilemma, I understand what they’re trying to do and what they’re trying to solve, but shifting responsibility for these sorts of things from “here” to “there” is not actually solving the problem it’s just moving it, and often moving it to somewhere that someone who has no business dealing with it will ultimately end up dealing with it in a way that’s even worse than what you started with.

      Personally I try to be pragmatic and not ideological about software packaging. I usually prefer distro-provided deb packages whenever I can get it as a strict first-place-to-check, and I try to convince myself to use that even if it’s a somewhat older version or kind of stupidly packaged, falling back to the project’s own deb repos if they have them for more up to date versions, and if that fails I might consign myself to building from source or banging my head against a docker, unless I really absolutely need to use some other packaging option some specific reason. I’ve even used a flatpak occasionally (often for something I would like somewhat sandboxed) But snap is pretty garbage and has few redeeming features and I’ve never really felt the slightest interest in using it for any reason.

      It’s a mess, but it’s a manageable mess, mostly because I’m forced to manage it whether I like it or not. This is the unfortunate reality of software packaging on Linux. With great choice comes too many choices. It’s a tradeoff I’m willing to make, because I like having choice.

    • [object Object]@lemmy.world
      link
      fedilink
      arrow-up
      5
      ·
      4 months ago

      I like to post issues like that in the bug tracker with concise phrasing like “Why can’t the file editor edit files?” Give them nothing to think that you actually know the answer, make them spell it out.

      • entwine@programming.dev
        link
        fedilink
        arrow-up
        3
        ·
        4 months ago

        Yeah waste open source maintainers’ time by acting like a child. That will surely accomplish whatever you’re hoping to accomplish.

        • [object Object]@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          4 months ago

          Oh yeah, it’s certainly not the maintainers wasting time by peddling the snap bullshit that doesn’t work, without thinking beforehand.

    • Randelung@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      4 months ago

      It’s been dead to me ever since they started adding ads to their premium services. None of their decisions have made me reconsider.

  • Eggymatrix@sh.itjust.works
    link
    fedilink
    arrow-up
    6
    ·
    4 months ago

    App sandboxing is stupid, those that need it need something more refined than snap or flatpack, and all others don’t actually need it, but think they do due to inexperience and end up having problems and asking for support online.

    The amount of times i lost time helping someone that pinkie promised that no, i did not installed it via flatpack, but then it turns out they did and their permissions are messed up is not acceptable.

    I freaking hate snap, flatpack annd sometimes noobs even attempt some docker bullshit for something that is an apt-get away smh.

    These things are used as a crutch for unstable or badly supported programs. Sandboxing often creates more problems that it solves because you actually need to support the instance to do it correctly, the very problem that is attempted to solve.

    • definitemaybe@lemmy.ca
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      4 months ago

      Except for when sandboxing is better, like for server-type things that need to “just work” and won’t directly interface with anything else on the system.

      Like, a WiFi mesh network controller has no need to access anything on the system at all and users will only interact with it by a web portal. Docker (or an alternative) is perfect for that.

      • Eggymatrix@sh.itjust.works
        link
        fedilink
        arrow-up
        2
        ·
        4 months ago

        Agreed, but how many requests do you see for support for people understanding mesh networking enough to set a server up in docker? Those are the people that use it and need it, and surprise they use docker, not flatpack or snap.

        I am talking about non powerusers, non it personnel that are installing steam or gimp via snap or flatpack and then flood support threads with their problems. In those cases sandboxing is fucking stupid.

        • Janx@piefed.social
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          3 months ago

          It’s also really easy to avoid the company that made the slow, proprietary, corporate-owned Snaps default as a slap-in-face to the open-source community they depend on.