Warning: Some posts on this platform may contain adult material intended for mature audiences only. Viewer discretion is advised. By clicking ‘Continue’, you confirm that you are 18 years or older and consent to viewing explicit content.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.