As the number of Linux applications grows, so does the concern about security. Even though there are few recorded Linux attack incidents, it is conceivable to be attacked by viruses, hackers, or malware.
Because Linux is open-source, those problems are fixed faster, and the community may contribute to maintaining the Linux World ready for any bug or virus that appears. When installing a vulnerable application (or app), it may require libraries that are no longer accessible on that distro’s version.
In this article, we’ll go through the key distinctions between.deb and.snap packages.
DEB Packages
Debian packages are collections of content files required to implement commands or features required by users to address a problem.
If the file is locally located, we generally use an elevated command, such as the one below, to install from the command line.
The core capability for installing and manipulating Debian packages is provided by dpkg. In most cases, users do not manage packages manually but instead utilize APT package management software.
Signed Packages GPG signature verification of signed Debian packages is supported by Debian-based distributions, however it is not enabled by default. As a workaround, repository metadata is used to validate the file’s authenticity.
Features
- To update, you need to have a PPA.
- If you have a .deb package you can install it by double-clicking it.
- .deb files are not very secure since they can have access to everything on your computer.
- It shares libraries with other installed applications.
“snap” Packages
Snaps are software packages that are containerized and easy to generate and install. They auto-update and are completely safe to use. They also work on all major Linux systems without modification because their dependencies are bundled.
You only need to install snapd on your PC to get it up and running.
If you run it without sudo, it will ask for a password afterward.
Features
- Simple to package leveraging your existing tools.
- Automatic updates for everyone.
- Reach tens of millions of Linux systems.
- Roll back versions effortlessly.
- Integrate easily with build and CI infrastructure.
- Free for open and closed source projects.
- Snaps are quick to install from GNOME Software or the command line.
- Snaps update automatically and transactionally so your app is always fresh.
- Snaps stay secure as they are confined from the OS, other apps, and hardware functions.
- You can revert snap to an earlier state if the snap fails.
Many Distros are already using snap packaging including fedora and Debian.
There are 3 types of confinement for snap packages.
Strict
This is the default confinement for all apps. It gives the application read and writes permissions only in its install folder and if a home plug or interfaces are available for the app, users are also capable of accessing the home folder.
Strict confinement gives you the following readable and/or writable paths:
- /snap/<snap>/<revision> (read-only, snap install path).
- /var/snap/<snap>/<revision> (read/write, per-revision data).
- /var/snap/<snap>/common (read/write, common data).
- /home/$USER/snap/<snap>/<revision> (read/write, per-revision user data).
- /home/$USER/snap/<snap>/common (read/write, common user data).
Devmode
Used for developers to test their applications. Snaps in developer mode cannot be released in stable mode. For them to be able to release, the developer must change strict mode or classic and then change to stable or candidate snap stores channels.
Classic
Classic snaps are snaps that work the same way .deb packages work, without any confinement.
Snap apps with this confinement can go beyond home folder access – it can read and write on root folders.
Although applications can have classic confinement it doesn’t mean that every application can have this confinement. For an application to have this confinement your application needs to be approved by a team at snapcraft.io after the reasons for classic confinement are agreed by all members of the team.
Conclusion
In terms of security and updates, snaps have numerous advantages over deb packages. Snaps allow you to have up-to-date programmes because they come with their own libraries and do not require the system library to execute.
Support for transactional updates allows you to download only the parts of your programme that have changed.
Please provide your thoughts on whether you would prefer deb or snaps for your applications.
I might have a look on Flatpack but I won’t use Snap. I stick to .deb definitively.
I would like to hear your reasons. Why stick to .deb packages?
Example : Remmina (VNC Client) deb package 200KB, snap 200MEGA Bajts.
Another problem is that snaps don’t have access outside their install folder, so you install office and can’t open any document from mounted drives.
Useless…
I think .deb has lower file size compared to snap version of the same app
And snaps take a lot more of system resources, they are low to load on old computers and highly unstable.. (pentium t4500 4gb 320gb hdd).
Native apps take less time to load and are more crash-proof (spotify as an example)
Each snap has a filesystem active even is you don’t use that command at all. I quit using Ubuntu Mate because they forced even Ubuntu Mate Welcome to be a snap package. Conceptually refusing to use shared library even for Welcome app made me mad. I’m running Manjaro xfce now and uninstalled snap* completely.
My first experience with snaps is with Ubuntu 22.04 in which firefox is only available as a snap. I run a second user on my machine for privacy. So a xterm su-ed to that second user needs to be able to execute firefox, just like it does when firefox was a deb (the main user needs to do “xhost + …” to allow this, always has). With the firefox snap the invocation fails with an impenetrable snap/cgroup error. Sorry, snap is not ready for prime time. Happily there are ways to get a .deb from Mozilla and tell apt to prefer it. If Ubuntu tries to force folks to use snaps, then those folks are going to go elsewhere.
I completely agree with you. I encountered various issues in Firefox snap and Chromium snap on Ubuntu 22.04. APT favours snap packages by default, and there has been a lot of discussion about Canonical’s zealous advocacy for snap. Snap is disliked by many individuals for a variety of reasons, one of which is that it uses a lot of disc space. Canonical, on the other side, is encouraging snap, noting a number of benefits, including security by isolation from the rest of the system.
Snap is also broken in many ways. For example to trigger firefox — screenshot as a daemon is impossible, because apache is confined (by systemd) to a private /tmp, whereas snap insists on everything running within /home. It’s also a dreadful waste of resources because we don’t get the benefit of shared libraries (and yes, there are plenty of us with 256GB of SSD and no HDD, so disk is still valuable).