I don’t use Linux either, but a quick bit of research tells me it’s like an App Store and software that is specific to Linux. It allows for ease of installing/uninstalling programs but it can can run slow, seems redundant to what flatpaks already does, and isn’t fully fleshed out which leads to weird errors.
I’m guessing it’s because Linux is more hands on and this takes some agency away from users who feel like it might hurt privacy?
That’s what I’m reading anyway. Someone who is more familiar can correct me if I am off base.
One of the things missing from other comments is the architecture of it, why it use to be slow, and how the binaries were handled. Canonical started Snap as a server oriented application deployment system, that has been adapted to desktop use with some technological debt. The differences between it and Flatpak as far as configurability, dependencies, bundled binaries, etc are somewhat nuanced. They dealt with the application speed opening issue by allowing decompressed executables and different hooks to be used.
The other main point of contention aside from technological debt inherited by a server-first development principle is how they closed sourced their Snap server backend. It’s proprietary, while the Snap client is open source, how the actual Snap server runs is a mystery.
Flatpak (and by extension Flathub) are all open sourced, which aligns more with the philosophy that users tend to prefer. It was covered in other comments that everyone else uses Flatpak, and this really isn’t so much as a debate between package managers vs Flatpak, but moreso of application deployment overall. The community prefers Flatpak, and Snap is pushed as a means of lock-in and sunk cost fallacy on the side of Canonical.
The issues are twofold: Linux distros historically update software through a package manager. Something that was working fine for everyone, however it was causing a lot of work for maintainers. They got together and designed a packaging format for software that works across all Linux distributions called ‘flatpak’. However, Ubuntu decided to create an alternative called Snap, which solves the same problem, except it’s not used by anyone else.
Also, there’s some implementation details that make it look messy in your system (every application is mounted as it’s own filesystem, so if you use tools to list your disk’s there’s a bunch of weird spammy looking drives and things like that).
Didn’t it also used to be noticeably slower than apt installed apps? This was one of the reasons I got rid of it at the time, Ive heard it has better performance now but not tried it.
Native package managers were not “working fine for everyone”, the software and libraries in them are often very outdated and contain custom patches that don’t come from the original software authors.
So you often end up dealing with bugs that were already fixed and the fixes released months ago.
That sounds like the maintainer’s problem, not a problem with apt/dnf/whatever. We’ve had automated build processes for decades. If you want stable, use a stable distro; if you want the latest, use a rolling release like Arch or something.
That’s one of the main reasons I use a rolling release distro. I used Arch for years, and now I use Tumbleweed.
With packaged apps (like flatpak, snap, etc), you can end up with outdated dependencies in those apps because they bundle everything together. So instead of fixing bugs once for everyone, you have to pester each individual package maintainer to update the dependencies. However, this is mitigated by having these apps be somewhat containerized and limiting impact of a breach on other apps, so YMMV depending on what kind of sandboxing you use.
I’m not really decided here, and I use both flatpaks and distro packages. I don’t touch snaps though.
Specific to Ubuntu, not very open for collaboration, and operated by the company who owns the Ubuntu trademarks. Additionally they’ve made it unnecessarily difficult to install non-snap versions of many popular packages. (they removed non-snap versions from upstream Debian repositories).
I don’t use Linux either, but a quick bit of research tells me it’s like an App Store and software that is specific to Linux. It allows for ease of installing/uninstalling programs but it can can run slow, seems redundant to what flatpaks already does, and isn’t fully fleshed out which leads to weird errors.
I’m guessing it’s because Linux is more hands on and this takes some agency away from users who feel like it might hurt privacy?
That’s what I’m reading anyway. Someone who is more familiar can correct me if I am off base.
One of the things missing from other comments is the architecture of it, why it use to be slow, and how the binaries were handled. Canonical started Snap as a server oriented application deployment system, that has been adapted to desktop use with some technological debt. The differences between it and Flatpak as far as configurability, dependencies, bundled binaries, etc are somewhat nuanced. They dealt with the application speed opening issue by allowing decompressed executables and different hooks to be used.
The other main point of contention aside from technological debt inherited by a server-first development principle is how they closed sourced their Snap server backend. It’s proprietary, while the Snap client is open source, how the actual Snap server runs is a mystery.
Flatpak (and by extension Flathub) are all open sourced, which aligns more with the philosophy that users tend to prefer. It was covered in other comments that everyone else uses Flatpak, and this really isn’t so much as a debate between package managers vs Flatpak, but moreso of application deployment overall. The community prefers Flatpak, and Snap is pushed as a means of lock-in and sunk cost fallacy on the side of Canonical.
The issues are twofold: Linux distros historically update software through a package manager. Something that was working fine for everyone, however it was causing a lot of work for maintainers. They got together and designed a packaging format for software that works across all Linux distributions called ‘flatpak’. However, Ubuntu decided to create an alternative called Snap, which solves the same problem, except it’s not used by anyone else.
Also, there’s some implementation details that make it look messy in your system (every application is mounted as it’s own filesystem, so if you use tools to list your disk’s there’s a bunch of weird spammy looking drives and things like that).
Didn’t it also used to be noticeably slower than apt installed apps? This was one of the reasons I got rid of it at the time, Ive heard it has better performance now but not tried it.
Native package managers were not “working fine for everyone”, the software and libraries in them are often very outdated and contain custom patches that don’t come from the original software authors.
So you often end up dealing with bugs that were already fixed and the fixes released months ago.
That sounds like the maintainer’s problem, not a problem with apt/dnf/whatever. We’ve had automated build processes for decades. If you want stable, use a stable distro; if you want the latest, use a rolling release like Arch or something.
That’s one of the main reasons I use a rolling release distro. I used Arch for years, and now I use Tumbleweed.
With packaged apps (like flatpak, snap, etc), you can end up with outdated dependencies in those apps because they bundle everything together. So instead of fixing bugs once for everyone, you have to pester each individual package maintainer to update the dependencies. However, this is mitigated by having these apps be somewhat containerized and limiting impact of a breach on other apps, so YMMV depending on what kind of sandboxing you use.
I’m not really decided here, and I use both flatpaks and distro packages. I don’t touch snaps though.
Awesome! Thank you for this explanation. So it’s mostly just because it’s a redundancy and specific to a certain distro (Ubuntu in this case)?
No, redundancy is fine. It’s the proprietary backend and Ubuntu forcing it on users that people don’t like.
Specific to Ubuntu, not very open for collaboration, and operated by the company who owns the Ubuntu trademarks. Additionally they’ve made it unnecessarily difficult to install non-snap versions of many popular packages. (they removed non-snap versions from upstream Debian repositories).