Snap

The System /snap Directory

The /snap directory is, by default, where the files and folders from installed snap packages appear on your system.

A file manager, or the output from some storage-related commands, will show the files and directories within /snap taking up space:

$ du -hs /snap/vlc
766M    /snap/vlc

However, these files and folders are mounted from the heavily compressed data that's stored within the original snap, located in /var/lib/snapd/snaps. These snaps take far less space on your system than their mount points imply:

$ mount | grep vlc
/var/lib/snapd/snaps/vlc_555.snap on /snap/vlc/555 type squashfs (ro,nodev,relatime,x-gdu.hide)
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop12     196M  196M     0 100% /snap/vlc/555
[...]

Can we delete what's inside /snap?

squashfs (which these loop devices contain) does not use any memory unless you actually access the data in it (i.e. by running a program which in turn loads libraries)...

When unused, the files in /snap are just mount points and nothing in there should occupy more ram than needed for holding the directory and file structure, when you do an ls or find command on it...

As long as you do not run the snap app itself, the only resource used is the disk space in /var/lib/snapd/snaps but no CPU or any significant amount of RAM.

Opinions

I don't use any of these things like snap and appimage. One of the things that makes Linux stable and internally simple is that all the programs collectively use the underlying layer of libraries, and all software of both types is either built locally against those libraries or carefully checked by distro devs to make sure it's 100% compatible with the system. Importing separate packages with their own library environment strikes me as the clunky Windows way of doing things.

This is an incredibly idealistic POV. In the real world a$$hole developers produce backwards-incompatible versions of libraries, sloppy distro maintainers take ages to update anything, and of course no distro contains all the software in the world, so unless your needs are very simple indeed sooner or later you will have to leave the ivory distro tower and venture into the real ugly and messy world, and portable packaging systems like snap make it much, much easier. They are somewhat inefficient - and this is the only objective reason to dislike them, and using them for everything is not a clever approach, but completely rejecting them is even less clever.

There are some new Linux distros out that use an immutable root file system, and all user apps are Flatpack or the like. So the OS becomes more like a smartphone which is more intuitive for lots of users who have only used a phone before. It also seems to offer some security advantage since the apps are sand-boxed from the OS.

That said, I prefer the traditional method and removed snap from my system. It's annoying when I click the open or save button and I default to 5 layers inside the app directory and not my home dir. But I may give one of these new distros a try sometime.

Maybe the future is that every program will be a 2GB self-contained image. Just download and run. When storage and bandwidth are cheap it's harder and harder to argue against.

Suppose I want to run program abc. Under the old model I also need to download and install libxyz. Under the new model libxyz is part of the image. What happens when a vulnerability is found in libxyz? Which is going to get me safe sooner? The distro updating libxyz or a new snap image for every program that uses libxyz? Personally I would rather get the updated libxyz and risk breaking some apps than have an unknown number of vulnerable copies of libxyz running on my system.