I used Ubuntu at work a couple of years ago. When they announced the switch to snaps I didn’t really care, but when they switched Firefox to the snap version it had quite a few issues like really slow startup, inconsistent theming, and problems with some extensions. So I uninstalled the snap, installed the standard DEB and went on with my work.
But then the issues came back, and it took me some time to figure out they had replaced the actual DEB package with an unholy shim which just installed the snap. THAT really pissed me off, so when I got a new laptop I just installed Arch and my only regret was not doing it sooner.
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.
Insert witty comment on how Snap is apparently the worst thing on Earth
(I don’t use Linux. Why’s it so hated?)
I used Ubuntu at work a couple of years ago. When they announced the switch to snaps I didn’t really care, but when they switched Firefox to the snap version it had quite a few issues like really slow startup, inconsistent theming, and problems with some extensions. So I uninstalled the snap, installed the standard DEB and went on with my work.
But then the issues came back, and it took me some time to figure out they had replaced the actual DEB package with an unholy shim which just installed the snap. THAT really pissed me off, so when I got a new laptop I just installed Arch and my only regret was not doing it sooner.
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.