I’ve gathered that a lot of people in the nix space seem to dislike snaps but otherwise like Flatpaks, what seems to be the difference here?

Are Snaps just a lot slower than flatpaks or something? They’re both a bit bloaty as far as I know but makes Canonicals attempt worse?

Personally I think for home users or niche there should be a snap less variant of this distribution with all the bells and whistles.

Sure it might be pointless, but you could argue that for dozens of other distros that take Debian, Fedora or Arch stuff and make it as their own variant, I.e MX Linux or Manjaro.

What are your thoughts?

  • refalo@programming.dev
    link
    fedilink
    arrow-up
    42
    ·
    edit-2
    2 months ago

    The server is proprietary and last I checked you can’t even turn off auto-updating or verify the binaries they push to you.

    https://www.zdnet.com/article/linux-mint-dumps-ubuntu-snap/

    In the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them, or even point Snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.

    • jodanlime@midwest.social
      link
      fedilink
      arrow-up
      11
      arrow-down
      3
      ·
      2 months ago

      This is why I don’t love snaps, proprietary backend. I think snaps actually work great for the most part, and flatpaks don’t support cli apps, only GUI.

      • ZephrC@lemm.ee
        link
        fedilink
        arrow-up
        14
        ·
        2 months ago

        I don’t know why people keep saying that flatpaks don’t support cli apps. They do. I know it’s awkward to type out flatpak run io.github.zyedidia.micro or whatever every time you want to use a text editor, but aliases fix that pretty neatly, and that example wasn’t hypothetical.

        • d_k_bo@feddit.de
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          2 months ago

          You don’t even need to create aliases yourself. Flatpak creates wrapper scripts for every app that you install. Just symlink them into your PATH.

          ln -s /var/lib/flatpak/exports/bin/org.example.CliTool ~/.local/bin/cli-tool
          

          or if you are using a user remote

          ln -s ~/.local/share/flatpak/exports/bin/org.example.CliTool ~/.local/bin/cli-tool
          

          (Note: some lemmy clients render the the tilde in code blocks incorrectly)

  • skilltheamps@feddit.de
    link
    fedilink
    arrow-up
    19
    ·
    2 months ago

    Research what happened to Upstart, Mir or Unity. It won’t take long until snap becomes one of them. Somebody at canonical seems to desperately obsess over having something unique, either as a way to justify canonicals existance or even in the hopes of making the next big thing. Over all these years they never learned that whatever they do exclusively will always fall short of any other joint efforts in the linux world, because they always lack the technical advances, ability/will to push it for a prolonged time and/or the non-proprietary-ness. So instead of collaborating like every serious linux vendor, they’re polluting their distro with half-assed, ever changing and unwanted experiments. They’re even hijacking apt commands to push their stupid snap stuff against the users intent. With the shengians they’re pulling Ubuntu cannot be relied on, and with that they’re sabotaging their own success and drive away any commercial customers that generate revenue.

  • boredsquirrel@slrpnk.net
    link
    fedilink
    arrow-up
    19
    ·
    edit-2
    2 months ago
    • proprietary server (snap store), unlike flatpak
    • snapd only allows one server (but it is foss so you could just patch it), unlike flatpak
    • nonexistent security on snap store, multiple times malware, unlike flatpak
    • no sandboxing without apparmor and specific profiles, so not cross platform, unlike flatpak
    • the system apps are also requiring apparmor, so not cross platform
    • they lack granular permission systems afaik
    • they concur with flatpak, which is horrible as we need a universal packaging format, not 3
    • seemingly no reproducible builds?
    • no separation between all, opensource, verified repo, unlike flatpak

    And people complain abour resource usage etc, but that is just separating apps from the system. Flatpak does the same.

  • lemmyreader@lemmy.ml
    link
    fedilink
    English
    arrow-up
    13
    ·
    edit-2
    2 months ago

    Personally I think for home users or niche there should be a snap less variant of this distribution with all the bells and whistles.

    There is : Linux Mint

  • kylian0087@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    11
    ·
    2 months ago

    For me it is partially the way canonical pushes snaps and forces it on to users. More so they are slow and the proprietary back end is a huge downside. Some snaps are know broken and cause more harm then good like the steam snap for example. Steam actively discourages users from even using it.

  • Revan343@lemmy.ca
    link
    fedilink
    arrow-up
    8
    arrow-down
    1
    ·
    2 months ago

    Snaps are proprietary, flatpacks are not, is the long and short of it

    • boredsquirrel@slrpnk.net
      link
      fedilink
      arrow-up
      2
      arrow-down
      1
      ·
      2 months ago

      They are not. But the store is proprietary and snapd doesnt allow other stores. You could patch snapd to allow other stores though and the format is open

      • d_k_bo@feddit.de
        link
        fedilink
        arrow-up
        8
        ·
        2 months ago

        Snaps are just as “open source” as “Office Open XML” (.docx, .pptx etc.) are open file formats.

        If there isn’t a fully open source software stack, it isn’t really open source.

      • rotopenguin@infosec.pub
        link
        fedilink
        English
        arrow-up
        4
        ·
        2 months ago

        You can’t “just patch it” to make snap work with another store. Instead what you’ve done is invented an entirely different store, which you’re now going to have to maintain. It is never going to be upstreamed to Canonical. You are going to be in a perpetual tug-of-war with Canonical driving snap development towards their own needs and not your own.

  • Snot Flickerman@lemmy.blahaj.zone
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    2 months ago

    So like… I understand the why behind flatpaks and snaps, but I’m an end-user, and more often than not they just make things more difficult, in my opinion.

    They’re really great for server setups for sort of keeping each individual application from being able to deeply influence other applications or the root filesystem.

    But this means if I installed the Spotify snap (at least when I last tried a few years ago) I had to jump through a bunch of hoops to get it to be able to access my media files where all my music was stored.

    So like I said, great for out-of-the-box-server setups where the everything is a little separated from each other (kind of like Docker, from what I understand, but at the app-level? I could be wrong here.) because it helps default security settings and interactions from getting confusing quickly.

    However, for your casual end-user, it can quickly become a confusing nightmare if you actually do need your applications more easily interacting with one another because you’re just trying to write an email.

    Anyway, that’s my personal opinion: The reasons they exist server-side are pretty solid, but the reasons they exist on desktops for the end-user are less compelling and often result in user frustration.

    • BananaTrifleViolin@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 months ago

      I’ve found the opposite as an end user with Flatpaks. It makes it easy to install an app on multiple devices with different Linux flavours and it’ll just work.

      Even if you’re on a single device, if the app isn’t in your repo or the latest version is not available in the repo, then flatpak can be very convenient. Certainly easier than compiling from source.

      It is secure in the sense that it runs in a sandboxed environment with its own libraries. The downside of that though is bloat as you will have duplicates of libraries you already have on your system downloaded for flatpak. That bloat diminishes to an extent the more apps you use as the apps will share and reuse the Flatpak downloaded libraries, but your first app could be 2gb just because of the libraries and dependencies.

      That bloat also extends to memory - you might be running two copies of multiple libraries at a time - one for the native system and another for the Flatpak app.

      So on the one side it’s convenient and allows distributions across all flavours of Linux, and it sandboxes apps which is potentially more secure but the downside is bloat, and resource use.

      Ubuntu have gone too far with Snap, forcing it instead of providing native apps, and it’s proprietary. Flatpak is more open and an option for users rather than forced on them.

      • Snot Flickerman@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 months ago

        Thanks for the really good breakdown. I was familiar with the idea that flatpaks are more open and snaps are more proprietary, but I had less understanding of the details of how they’re sandboxed. Thanks again, I’m sure it will help others understand it better, too.

    • Shareni@programming.dev
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      2 months ago

      They’re really great for server setups

      Please don’t go anywhere near servers with either of those, that’s what docker and alternatives are for.

      the reasons they exist on desktops for the end-user are less compelling and often result in user frustration.

      Try running a stable distro without them. If you want a program not to be years out of date, and don’t want to compile everything manually, the only options are to use an alternative package manager (flatpak/snap/nix/etc.), distrobox, or appimage + some pm for updates.

      However, for your casual end-user, it can quickly become a confusing nightmare

      They’re a lifesaver for casual users, especially when they’re integrated into a gui (software centre and discovery for example). None of the other options are nearly as user friendly.

      Permission issues are really rare and distro specific from my experience. Also there are tools like flatseal to make fixing them easier.

  • Irdial@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    5
    arrow-down
    5
    ·
    2 months ago

    I read a comment on Reddit a while back that pointed out how much of the open source community has no issue hosting projects on GitHub while also lampooning Snap for having a closed-source backend server. However, since Snap (and GitHub) are open source themselves, nothing is stopping curious and concerned users from auditing the codebase or hosting their own servers. I removed Snap from my Ubuntu installation and use Flatpak instead, but I do not hate Snap. And for what it’s worth, I always go for the native DEB when possible…

      • Snot Flickerman@lemmy.blahaj.zone
        link
        fedilink
        English
        arrow-up
        9
        ·
        edit-2
        2 months ago

        I really think people get confused between Git, the open source application, and Github the non-open-source online code repository.

        Part of the reason they probably think they are one and the same is how often Git is used in command line to clone a Github repository locally.

        Gitlab is open source and self-hostable, to my knowledge.