Nothing necessarily at the tech level. They’re more capable than Appimages or flatpaks to the point that you can use it to build a reproducible system hardened against tampering or defective updates.
The downside is that it’s controlled entirely by canonical, has limited abilities (if any?) for hosting storefronts/packages outside of their ecosystem, and said ecosystem is insecure and has already allowed multiple waves of malicious apps to reach end users because of poor moderation of listings masquerading as legitimate versions.
Canonical has also been increasingly hostile to flatpaks - removing it from Ubuntu and derivatives by default to push users towards snap.
The whole loopfs thing is just an annoyance, but the aggressive posturing by canonical as well as the closed nature of the storefront that has led to malicious attacks on end users is enough to give it more than a few haters.
The primary thing I hate about them is that every snap package appears to your system as a separate mounted filesystem. So if you look in your file explorer, you can potentially see dozens of phantom drives clogging up your sidebar.
Snaps are a standard for apps that Ubuntu’s parent company, Canonical, has been trying to push for years.
The issue that most people have with them, is that Canonical controls the servers, which are closed source. Meaning that only they can distribute Snap software, which many Linux users feel violates the spirit & intention of the wider free and open source community.
Appimages and Flatpaks are fully open source standards, anybody can package their software in those ways and distribute them however they want.
.deb files are software packaged for the Debian distribution, and frequently also work with other distros that are based on Debian, like Linux Mint.
Some further context on this that @[email protected] might want to know:
While Canonical’s snap store is proprietary (which, to be clear, I don’t really like), all the client software is open source and the API is well documented (though a bit janky). Their snap store relay app (which is open source) has a full implementation of it. There was a fully functional open snap store for a while, but the project died out of a lack of interest. You can also distribute snaps through another mechanism and install them locally on the machine (though you then lose the benefit of snapd’s auto updates). You can even do this with snapd still checking the signatures of the snaps.
The standard for snaps is fully open, as is snapd itself.
There’s no need to oversell the negatives to the point of being wrong.
Interesting, didn’t know it was feasible to make the distribution open.
That doesn’t give me much to complain about in theory, but canonical has lost way too much good faith to give people a reason to keep open snap distribution going for free. They should definitely consider hosting an open store just to get people on board again.
It was being done by a group of snapd developers at Canonical, IIRC, but after a couple of years of exactly zero interaction from anyone outside Canonical I think they just gave up and decided it wasn’t worth it because they were getting accused of trying to monopolise whether they had an open store or just an open API.
Of course, you can also distribute snaps without using the snap store API. I’ve used this for airgapped machines in the past. You can either just grab the .snap file (which is just a squashfs file with a meta/snap.yaml in it so snapd knows how to treat it) and install it with --dangerous, or you can include an assertion file for that snap signed by a certificate that your machine’s snapd trusts and not even have to do that. (Those airgapped machines trusted our own certificate so we could ensure that the snaps came from our CI process and weren’t a developer’s random test snap).
Thanks, I recently needed picocrypt and not being comfortable with the terminal, snap were a rather convenient way to get it installed, I’ll avoid them from now on.
I don’t think snaps are bad (and when someone tries to explain why they are, about 85% of the time they say something wrong enough that I suspect they’re probably just parroting someone else rather than actually knowing what’s going on). It’s sad, because if we could get rid of the bullshit we could actually have decent discussions about the benefits and shortcomings of snaps (and how to fix those shortcomings).
On the .deb front: it’s a package format made by Debian. Each archive contains a data tarball, which has the files in the package in their full structure from /, and a control tarball, which contains metadata such as name, version and dependencies as well as pre-install, pre-remove, post-install and post-remove scripts, which are used doing any setup or removal work that can’t be done just by extracting or deleting the files.
The upside of deb files is that they tend to be pretty small. The downside is that this typically comes from having a tight coupling to library versions on the system, which means upgrading a library can break seemingly unrelated things. (This is why you get warnings like this page: https://wiki.debian.org/DontBreakDebian) Many third party distributors (e.g. Google with Chrome) take care of this by packaging most dependencies inside the deb, inflating the size.
Another major difference between packages like debs and rpms and newer formats like snaps and flatpaks is that the latter have confinement systems to prevent apps from having full access to your system.
Honestly if not for the convoluted Linux FS layout, debs would be pretty serviceable and aren’t really different to the Windows solution. The fs layout makes installations way too fickle to clashing with other applications.
That and dependency hell, which distros should have never been allowed to touch beyond the core dependencies required to get your desktop running.
Worth noting that the confinement of Flatpaks and Snaps can have major drawbacks. It has been a major pain in the ass to get Flatpaks working nicely with fractional scaling (think tiny cursor, huge text, tiny text etc etc)
Nothing in theory makes that an issue of flatpaks and snap, just that both rely on different means to interact with the host system that have been woefully slow to implement. If enough protocols are developed a flatpak or snap should be as capable as a native app with the safety benefits for free.
If you look through the desktop portals GitHub, it seems to be a mess of bikeshedding, mostly on the part of a small number of people on the flatpak side. Canonical seem to have been working around this in snaps by writing their own interfaces as stopgaps until the desktop portals catch up, probably because they got such pushback when the similar frustration on the display server side resulted in them releasing mir with its own protocol until the Wayland folks could get their act together.
While you’re right in pointing out that in theory it’s basically as capable as native, it’s a royal pain in the ass as it is right now, which disqualifies it from a great deal of applications.
The first two snaps I compared sizes of on my system are uv and bitwarden. The uv snap is 9.5 megs vs. the wheel’s 12.2 megs, and the bitwarden snap is 97 megs vs. the Deb’s 79 megs and the AppImage’s 114 megs. These seem pretty reasonable - doubly so since snaps also have delta updates.
I don’t use Notepadqq anywhere (I use kate btw), but on my KDE Neon system it’s currently showing:
$snapinfonotepadqqname:notepadqqsummary:ANotepad++-likeeditorforLinux.publisher:DanieleDiSarli(danieleds)store-url:https://snapcraft.io/notepadqqlicense:GPL-3.0description:|
It helps developers by providing all you can expect from a general purpose text editor, such as
syntax highlighting for more than 100 different languages, code folding, color schemes, file
monitoring, multiple selection and much more.
You can search text using the power of regular expressions. You can organize documents side by
side. You can use real-time highlighting to find near identifiers in no time.
snap-id:6iueWFAtx9P2OQz4SIW64Kry9hT8aUCLchannels:latest/stable:1.4.82018-09-14(855)151MB-latest/candidate:↑latest/beta:2.0.0-beta+git2019-10-12(890)201MBclassiclatest/edge:2.0.0-beta+git2019-10-16(897)197MBclassic
It seems to be a dead project (the last release on GitHub is that same 2.0 beta from 2019), but looking at the snapcraft.yaml file, it looks like it’s because they’re vendoring in a pretty big chunk of KDE and gtk libraries. 2019 was before I started doing anything with snaps or flatpaks for desktops so I’m not sure what the state of KDE content snaps was then (I know there was a GNOME one because the core18 gnome content snap is installed on my system for uhh… some app that I have), but these days for desktop apps there are content snaps for gnome (published by Canonical) and KDE Frameworks (published by KDE) to deduplicate those dependencies.
Linux noob here, can someone ELI5 why snaps are bad? And how does .deb works?
Nothing necessarily at the tech level. They’re more capable than Appimages or flatpaks to the point that you can use it to build a reproducible system hardened against tampering or defective updates.
The downside is that it’s controlled entirely by canonical, has limited abilities (if any?) for hosting storefronts/packages outside of their ecosystem, and said ecosystem is insecure and has already allowed multiple waves of malicious apps to reach end users because of poor moderation of listings masquerading as legitimate versions.
Canonical has also been increasingly hostile to flatpaks - removing it from Ubuntu and derivatives by default to push users towards snap.
The whole loopfs thing is just an annoyance, but the aggressive posturing by canonical as well as the closed nature of the storefront that has led to malicious attacks on end users is enough to give it more than a few haters.
The primary thing I hate about them is that every snap package appears to your system as a separate mounted filesystem. So if you look in your file explorer, you can potentially see dozens of phantom drives clogging up your sidebar.
Snaps are a standard for apps that Ubuntu’s parent company, Canonical, has been trying to push for years.
The issue that most people have with them, is that Canonical controls the servers, which are closed source. Meaning that only they can distribute Snap software, which many Linux users feel violates the spirit & intention of the wider free and open source community.
Appimages and Flatpaks are fully open source standards, anybody can package their software in those ways and distribute them however they want.
.deb files are software packaged for the Debian distribution, and frequently also work with other distros that are based on Debian, like Linux Mint.
Some further context on this that @[email protected] might want to know:
While Canonical’s snap store is proprietary (which, to be clear, I don’t really like), all the client software is open source and the API is well documented (though a bit janky). Their snap store relay app (which is open source) has a full implementation of it. There was a fully functional open snap store for a while, but the project died out of a lack of interest. You can also distribute snaps through another mechanism and install them locally on the machine (though you then lose the benefit of snapd’s auto updates). You can even do this with snapd still checking the signatures of the snaps.
The standard for snaps is fully open, as is snapd itself.
There’s no need to oversell the negatives to the point of being wrong.
Interesting, didn’t know it was feasible to make the distribution open.
That doesn’t give me much to complain about in theory, but canonical has lost way too much good faith to give people a reason to keep open snap distribution going for free. They should definitely consider hosting an open store just to get people on board again.
It was being done by a group of snapd developers at Canonical, IIRC, but after a couple of years of exactly zero interaction from anyone outside Canonical I think they just gave up and decided it wasn’t worth it because they were getting accused of trying to monopolise whether they had an open store or just an open API.
Of course, you can also distribute snaps without using the snap store API. I’ve used this for airgapped machines in the past. You can either just grab the
.snapfile (which is just a squashfs file with ameta/snap.yamlin it so snapd knows how to treat it) and install it with--dangerous, or you can include an assertion file for that snap signed by a certificate that your machine’s snapd trusts and not even have to do that. (Those airgapped machines trusted our own certificate so we could ensure that the snaps came from our CI process and weren’t a developer’s random test snap).Thanks, I recently needed picocrypt and not being comfortable with the terminal, snap were a rather convenient way to get it installed, I’ll avoid them from now on.
I don’t think snaps are bad (and when someone tries to explain why they are, about 85% of the time they say something wrong enough that I suspect they’re probably just parroting someone else rather than actually knowing what’s going on). It’s sad, because if we could get rid of the bullshit we could actually have decent discussions about the benefits and shortcomings of snaps (and how to fix those shortcomings).
On the .deb front: it’s a package format made by Debian. Each archive contains a data tarball, which has the files in the package in their full structure from
/, and a control tarball, which contains metadata such as name, version and dependencies as well as pre-install, pre-remove, post-install and post-remove scripts, which are used doing any setup or removal work that can’t be done just by extracting or deleting the files.The upside of deb files is that they tend to be pretty small. The downside is that this typically comes from having a tight coupling to library versions on the system, which means upgrading a library can break seemingly unrelated things. (This is why you get warnings like this page: https://wiki.debian.org/DontBreakDebian) Many third party distributors (e.g. Google with Chrome) take care of this by packaging most dependencies inside the deb, inflating the size.
Another major difference between packages like debs and rpms and newer formats like snaps and flatpaks is that the latter have confinement systems to prevent apps from having full access to your system.
Honestly if not for the convoluted Linux FS layout, debs would be pretty serviceable and aren’t really different to the Windows solution. The fs layout makes installations way too fickle to clashing with other applications.
That and dependency hell, which distros should have never been allowed to touch beyond the core dependencies required to get your desktop running.
Well that’s what
/optis for. Well-behaved application packages that aren’t part of your core distro should install themselves in there.For me, it was
snapdtaking ~2.5GiB of RAM.Worth noting that the confinement of Flatpaks and Snaps can have major drawbacks. It has been a major pain in the ass to get Flatpaks working nicely with fractional scaling (think tiny cursor, huge text, tiny text etc etc)
Nothing in theory makes that an issue of flatpaks and snap, just that both rely on different means to interact with the host system that have been woefully slow to implement. If enough protocols are developed a flatpak or snap should be as capable as a native app with the safety benefits for free.
If you look through the desktop portals GitHub, it seems to be a mess of bikeshedding, mostly on the part of a small number of people on the flatpak side. Canonical seem to have been working around this in snaps by writing their own interfaces as stopgaps until the desktop portals catch up, probably because they got such pushback when the similar frustration on the display server side resulted in them releasing mir with its own protocol until the Wayland folks could get their act together.
While you’re right in pointing out that in theory it’s basically as capable as native, it’s a royal pain in the ass as it is right now, which disqualifies it from a great deal of applications.
The snap store is some proprietary store Canonical runs, and snaps are friggin huge in size. I don’t really know though as I don’t use Ubuntu anymore
Size isn’t an issue imo. Applications are bulky for many more reasons than their packaging formats.
The first two snaps I compared sizes of on my system are uv and bitwarden. The uv snap is 9.5 megs vs. the wheel’s 12.2 megs, and the bitwarden snap is 97 megs vs. the Deb’s 79 megs and the AppImage’s 114 megs. These seem pretty reasonable - doubly so since snaps also have delta updates.
OK that’s better than what I’ve seen. Notepadqq I think was 2.4gb and I said no to that one. But again I don’t run Ubuntu.
I don’t use Notepadqq anywhere (I use kate btw), but on my KDE Neon system it’s currently showing:
$ snap info notepadqq name: notepadqq summary: A Notepad++-like editor for Linux. publisher: Daniele Di Sarli (danieleds) store-url: https://snapcraft.io/notepadqq license: GPL-3.0 description: | It helps developers by providing all you can expect from a general purpose text editor, such as syntax highlighting for more than 100 different languages, code folding, color schemes, file monitoring, multiple selection and much more. You can search text using the power of regular expressions. You can organize documents side by side. You can use real-time highlighting to find near identifiers in no time. snap-id: 6iueWFAtx9P2OQz4SIW64Kry9hT8aUCL channels: latest/stable: 1.4.8 2018-09-14 (855) 151MB - latest/candidate: ↑ latest/beta: 2.0.0-beta+git 2019-10-12 (890) 201MB classic latest/edge: 2.0.0-beta+git 2019-10-16 (897) 197MB classicIt seems to be a dead project (the last release on GitHub is that same 2.0 beta from 2019), but looking at the snapcraft.yaml file, it looks like it’s because they’re vendoring in a pretty big chunk of KDE and gtk libraries. 2019 was before I started doing anything with snaps or flatpaks for desktops so I’m not sure what the state of KDE content snaps was then (I know there was a GNOME one because the core18 gnome content snap is installed on my system for uhh… some app that I have), but these days for desktop apps there are content snaps for gnome (published by Canonical) and KDE Frameworks (published by KDE) to deduplicate those dependencies.