Okay what is the deal with snaps over deb files. I’m just put Ubuntu 20.04 on my laptop and went to install some software from the Ubuntu store and all I see is snaps are these safe to use? For example VS Code in the Ubuntu store is a snap but on Microsoft’s VS Code website I see it’s deb file no snap. So is the snap version not an official version of the software and if so does it have the same functionality as the software installed from the deb file?
Snaps are more like appimages or flatpacks, that sort of thing. I think you can turn that off if you don’t want it? Or at least pick to use the regular deb packages with apt.
Snap packages are another format, basically what Buffy said.
Often, snap packages are preferred because they’re generally not locked to older versions, and are maintained separate from the main package system so there’s less likelihood of conflicts, etc. They are generally safe to use, but the same issue applies to snap packages similar to deb packages - if the package becomes unmaintained, that means it’s not being updated and not receiving security patches. But that same problem can happen to both snaps and debs. So they’re generally safe to use, but like all packages, you do need to audit their versions and check for CVE’s like you would anything else.
1 Like
I actually prefer AppImages to either .deb packages, flatpaks, or snaps when I can find them. Using AppImage Launcher automatically detects an AppImage once you launch it and offers to move the image to the ~/Applications folder and place an icon out on the Whisker Menu or other Menu for you as well.
Let me chime in on snaps a bit…
As Jay mentions, for a lot of apps where the snaps are maintained, they are preferred, since you get the updated version of an app.
However, be aware that there are lots of unmaintained (or poorly maintained) snaps, and in some cases you are better of with updating deb packages yourself.
I have found for some CLI apps (like tmux, htop, nano etc.), it’s easier for me to go to pkgs.org, get the latest Debian package, check if dependencies are ok with my Ubuntu version, and install the updated package manually.
Also for things like Docker, the snap version is very old (19.03), and it’s better to install from the official Docker repos.
This saves me a lot of headache compared to poorly maintained snaps of the same apps.
I have raised the issue several times on the snapcraft forum, that I think the snap store should highlight and issue a warning when a snap has become unmaintained.
So far nothing has really happened though…
You have gotten some great feedback. With all of these “stores” popping up for Docker and Snaps and Flatpaks it feels like we are sliding back into the Wild West of looking for software sources that you can trust and not accidentally download a virus infested program into your Windows 98 like was common back in the day when you got your EXE from random sites on the Internet. Now we have similar issues popping up with crypto miners as Tom Lawrence does good job explaining in this short video:
I guess the best practice would be to check the official snap store site unless they list the publisher/maintainer in the Ubuntu Store, you can find that information here when you search for the program you are looking for:
MS probably doesn’t have a snap listed for download for VS Code because you are supposed to install Snaps either through the CLI or Ubuntu Store. It is probably best to stick with publishers/maintainers that are “verified” or the actual person or company that produces the app because you will more likely have a snap that stays up to date. In the case of VS Code it looks like the Microsoft team in charge of VS Code are the maintainers.
I know with MS Powershell they encourage you to install Snapd on your distribution and then install Powershell by a Snap. I believe it is their preferred method to install Powershell on Linux.
On the VS Code download page I noticed that they do have the link to the Snapcraft website store so they are encouraging you to use that method as well for installing VS Code. Their download site does have the DEB and RPM packages highlighted, and those would probably be the best methods to use for Debian or Red Hat and Fedora.
All that to say, that for your use case the snap is probably a good option because it is being maintained by the VS Code team.
I will admit that I’m partially to blame for Tom’s video, he and I had quite a lengthy discussion about this, more than once.
The truth is, the same logic applies to all software regardless of where you get it from. It doesn’t matter if you get the software from a PPA, traditional repository, Flatpak, AppImage, Snap, or whatever. If the maintainer isn’t doing a good job of keeping it up to date, then you equally have a security issue no matter where you get it from. So in that sense, Flatpaks and Snaps are no different now than repositories have been. I’ve seen traditional repositories get abandoned and lack updates.
Docker itself has an additional layer of insecurity, though. And that extra layer is mindset. People have the false belief that you should “containerize all the things” and people use containers without actually vetting them. This is also made worse by the fact that containers aren’t Linux-specific, macOS and Windows can run them too, and they are more widespread. Linux people generally know it’s a good idea to vet software they install, but people seem to especially have a sense of false confidence with containers, and it’s only a matter of time before we start seeing it in the news more often that companies are hacked due to their blind obedience to containers.
The fact is, each of these application delivery methods are awesome and something to consider, but they aren’t magical things that should be blindly accepted either. Regardless of the technology, test it out, vet it, and make an informed decision on if it’s valid for your environment.
For me personally, I’m more likely to manual build a container than use a Docker image created by someone else, it just seems like a better idea to me (even if it’s more work).
1 Like
I’ll go a step further and say that over the years I’ve seen entire distros get abandoned and lacking in updates. I have to agree with you 100% about PPAs, traditional repos, Flatpaks, AppImages, Snaps, and the like.
That’s a very sad thing to me, especially when I like a distribution a lot (Antergos, Crunchbang, etc).
I use Arch based distro, that is why I don’t use snaps. I rather prefer the native applications on my distro.
1 Like
I can certainly understand that, but a strong case can be made for separating user apps and system packages. I highly recommend using universal apps instead of the underlying package manager as much as possible.
@jay, that is interesting. I guess it also makes sense why you recommended sticking to the LTS of Ubuntu, because snaps would enable you to get more up to date packages while the system packages would remain the same.
On MX they use Flatpaks to enable newer packages than what you find on Debian stable, but they also use their own repos where they have the newest versions of the programs that they ship like they always have the latest Firefox instead of the Firefox ESR that is found in Debian stable. I think they mostly do that because not all programs that they want to keep up to date are available in Flatpaks. As a result, you end up with a Debian stable for the system packages and then their own repos and Flatpaks fill in the gaps.
Having run Debian from years ago, I have struggled to change my thinking to move away from the distros main repos to the universal formats. The encouragement in the Debian community used to be (perhaps it still is) let’s package all of the software as debs in the Debian repos, but today even with the thousands of packages in Debian they have gaps in not having some of the useful FOSS that is in the world. I remember using Debian Sid as my main home desktop Linux computer, and honestly, I can’t remember having a single upgrade that broke my system.
So many choices 
That’s pretty much it. I’m actually a fan of snaps, flatpaks and appimages (each of them). As you said, having stale packages on LTS distros isn’t so much of a problem since we have access to newer things with the universal packages.
Debian stable can still be problematic though, even after you take app versions out of the equation. Debian stable has some of the worst hardware support of any desktop distro available today. And I’m not trying to insult Debian here - I absolutely adore Debian. It’s one of my favorites. But their stale packages have cascading effects that cause some frustrations.
Although I’ll sing praises of universal apps, you don’t have to leave your comfort zone if you don’t want to. All I ask is that people try out new technologies, but if the new stuff doesn’t resonate with you, that’s fine too.
I really don’t understand their mindset. Long-time Linux users often don’t think of this, but think about it from a new users perspective - having all productivity applications locked to specific versions and not providing users with a way of installing new versions is just, well, weird. If a new version of LibreOffice is released, Windows and Mac users just go and download it. They don’t have any understanding at all of locking app versions to the entire OS. The more I think of it, the less sense this makes.
I think it’s important to understand that even though you haven’t had an upgrade that broke your system, it’s still something that can happen. Sure, it may be very unlikely, and Debian’s quality control seems to be very good in my opinion. They handle their repositories well. But package inconsistencies, dependency hell, and other quirks are things that could happen, however unlikely they may be. That’s why I’m a fan of completely abandoning a distribution’s repositories for productivity apps, and pushing those things through a universal package format instead. I fully understand this isn’t a popular idea at all, and the majority of Linux users would be against my opinion on this. And I’m okay with that. That’s why these discussions are fun!
If nothing else, a happy medium if the majority still wants to keep the status quo, is to make it easy and obvious for people to sidestep the repositories to get a newer version of an app, whenever they have a good reason to do so. If nothing else, it’s a heck of a lot better than apt pinning IMHO.
1 Like
You are making a great point here. I love LibreOffice, and have loved it from the day it broke from OpenOffice (which I used before LibreOffice). I also agree that the LibreOffice team continues to make great advancements with each new release, and it is a little frustrating that Debian locks app versions for something like LibreOffice. Although, I agree with you, this Debian lock has helped me a lot recently.
I run a mixed environment of computers. On my Windows 10 I run the latest LibreOffice since I have to install it separate from a package management system anyway. There are two bugs in LibreOffice 7 that have been a source of frustration. First, when I create a presentation in LibreOffice 6.1 on MX Linux and use the “Crop” tool on a picture, LibreOffice 7 on Windows shows that cropped picture in a distorted way. I could try to upgrade to the latest version of LibreOffice using Flatpaks on MX to see if that issue is a version regression or a difference between the Linux version and the Windows version.
The LibreOffice 7 on Windows also has a bug when printing the slides on a handout. When I print on Windows sometimes it makes the first slide a different size on the page than all the others (not the biggest deal) other times it will fail to switch from Landscape to portrait or will only do it for some of the pages which makes the handout useless. On the frozen or locked version on Debian the printout are perfect every time and both computers are talking to the same networked printer at work.
So do I like being locked on version 6.1? No, but I also have to admit that it seems more stable and doesn’t have these code regressions that impact my workflow just because I use Impress as much as I do.
You are not alone in this opinion. I know Ubuntu fans that feel the same, and I have heard the advocates of Fedora Silverblue express similar thoughts too. So you are in the company of wise and experience Linux users and developers, and I am coming around to your thinking.
Since I mostly use Flatpak as my universal package format because I run MX and Fedora and they have support for Flatpak out of the box, I still run into the issue that some of my favorite productivity apps are not always kept up to date as Flatpak either or a Flatpak hasn’t been created for it, but I’m sure this is more because there are so many great FOSS apps and everyone has their personal favorites.