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?
I’m personally not a fan of any universal packaging solution. I’ve tried flatpaks, appimages, and snaps, and ran into weird, annoying issued that I just never have when I install via package manager, build from source or even just run a portable build of an app.
I see the appeal of a universal package, but imo a bigger emphasis on portable native builds would solve a lot of the issues these packaging solutions are aiming for, while not introducing many of the downsides
As you can probably tell by all the lovely comments about Snaps, that’s the reason. Snaps is crap, by design.
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.
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.
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.
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.
Try running a stable distro without them
Arch mentioned btw
I hate snaps and how they pushed them on desktop users, but they’ve always been intended for servers, it’s one of the reasons they can ship things like unified kernel images. Ultimately they allow for a modular immutable system, potentially much more flexible than some others like Silverblue or Fedora Atomic stuff.
What they can do is pretty neat, but their “transitional” deb packages for normal users were ridiculous and should never have happened.
TBH I haven’t used snaps but based on info from this thread:
- can’t pin specific package version or force reproducibility in any way
- can’t stop updates
- can’t add private repos without modifying snapd, only manually install downloaded snaps
- can’t inspect the package definition or modify it
Because of those reasons I wouldn’t use it even on a private server, let alone in production.
Ultimately they allow for a modular immutable system, potentially much more flexible than some others like Silverblue or Fedora Atomic stuff.
So does nix, but it also enables declarative package management, adding your own package sources, modifying existing package definitions, creating your own repos, and generating docker images. It also works perfectly fine for userland packages.
We could just kill snaps on the desktop in favor of flatpak. Oh wait
Snaps are proprietary, flatpacks are not, is the long and short of it
The store is SaaS (service as a software substitute) and not necessary proprietary
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
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.
Not proprietary though
It is SaaS (service as a software substitute) and vendor lock in
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.
- 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
- they pollute the mount list with all the loop devices
And people complain abour resource usage etc, but that is just separating apps from the system. Flatpak does the same.
I think the second point is the biggest for me: it’s almost like Canonical wanted to have a single dominant store for apps, as the ecosystem they are building supports only one. And, apparently, that one server is also closed?
So if you try to make an alternative source and give instructions to people how to configure their snap installation to use it (I found this information very hard to find for some reason…), your “store” probably won’t have the same packages Canonical’s has, so users won’t be able to find the packages and I imagine updates are also now broken?
Contrasting this with flatpak: you just install apps from wherever. Or from flathub. Or your own site. Doesn’t matter. No business incentive behind—built into the tools—to make everyone use flathub.org.
Yes, Flathub is important but there are many other repos. Nothing for non development though.
I maintain a hopefully complete list here
So they have GPL Violation’s?
They’re pulling packages from Debian and i don’t know if they’re doing Nvidia like stuff or not.
Not to mention the extremely complicated back end. Flatpak doesn’t need extra permissions because it is based on bubblewrap. Snap is doing its own thing which is incredibly complicated.
You forgot also snaps pollute both the mount list and the path. Whether you like or dislike the second is up to opinion, but nobody likes the first.
Yeah but this is just because they are sandboxed and use their own libs.
There is a ton of overhead
snapdeez nutsLost a couple hours of work on the snap version of krita since it couldn’t save the file for some reason. Switched away from Ubuntu as a whole after that experience.
I would hate snaps a lot less if Ubuntu just stopped trying to force me to use them.
If it was a cool optional thing they were experimenting with it might be different. The problem is that it was forced onto the desktop
The problem with snap isn’t that it’s useless, it’s that it’s garbage. Snaps are just plain worse in every way, compared to other packaging formats. They impact boot time A LOT… like A LOT A LOT on a hard drive, use a ton of space, are slow to launch unless you use like tricks or what not to speed up consequent launches after the 1st one, the store backend is proprietary and poorly moderated, the store is slow and unresponsive, and cannonnical is pulling some real micro$oft-esk shit to try and force them on users… Stuff like aliasing apt commands to snap, disallowing ubuntu spins to ship flatpak by default, etc…
The only redeeming quality that snaps have is that you can run CLI/server programs as a snap, and even then, just use docker lmao.
they both suck.
Imma be honest. I never used Snap. I had left ubuntu long before they started rolling it out.
That said, hearing they redirect apt calls to snap instead feels – A bit too microsofty for my tastes
Like, when you use a flatpak (or even a snap!) in a non-ubuntu distro, you’re not forced to use it. And if the same package exists on both the repo and on flatpak/snap, you CAN choose to get it from any of the three sources. Forcing people into snap is weird and scummy.
I have heard that snap is slower than flatpak, but also that it can do some stuff flatpak cannot, but again, didn’t test enough to know it.
That said, hearing they redirect apt calls to snap instead feels – A bit too microsofty for my tastes
I also haven’t been with an Ubuntu based distro for awhile, but I’ve got a lot of affection for Canonical generally. I even accepted the idea of the amazon-in the-dash-thing (which had a lot of folks sharpening pitchforks some years back) as being kind of an honest mistake - so excited that they could that they didn’t consider if they should, sort of.
But yeah, that’s exactly what it feels like with snaps, and for that specific reason.
I think most people hate Snaps because Ubuntu is replacing .deb packages with snaps with no user prompt and that is a cardinal sin in Linux against the freedom and power of the user. Being “bloated” can’t help either when package maintainers do all what they can to ship programs light and simple. So it goes against at least two Linux principles.
I use apt because I care about security
Sudo apt install Firefox
Ubuntu then installs the snap version.
Well that’s not apt then
Its aptly Ubuntu apt
Fucking scumbags.
Sadly. Now, though, Mozilla has instructions you can follow to return to their PPA.
Or you could use flatpak
Or use a different distro.
When I install this snap am I getting a kernel driver, a native raw binary, or a containerized user application that conforms to a communication interface? Who knows! They’re all mostly undifferentiated in the store.
What about a third party store? Only if you fork the snap daemon and change the hard coded URL. And good luck with that mandatory Canonical contributer agreement you have to sign.
Want to pick when your apps update? Nope. That’s the official stance. They will never support that. But here’s a way to manually block network access to the daemon if you really really need to. But then everything will update at once when you give it access again.
Want a specific version of a snap? See above. Explicitly will never be an option.
“I guess there’s a fee to pay to get access to quality apps.” Incorrect. There is no real vetting process for what’s added to the store, there’s barely even minimal checking that you’re not overwriting someone else’s snap. You do have to sign the Canonical contributor agreement, and setup an identity to submit as, but even if your snap is proven to be malware there a good chance it will stay in the store, or can be immediately re-uploaded.
Not to mention snap is overly complicated for what it is. If it breaks good luck as you probably can’t fix it without starting over.
