Since there is a lot of people asking questions about Snap store and snapd… Could you please explain to everyone in simple words how the upcoming changes will impact our workflow.
Are snaps slower?
How much will impact boot times?
What if a snap needs to share data with another snap?
How often snaps will update?
What if I have .deb and snap package installed at the same time?
Etc…
3 Likes
- Snaps are slower…
- They don’t impact boot time unless you’re on a slow machine
- You have to grant them permission
- All the time, whenever an update comes out
- Nothing will happen, you can use both
1 Like
Snaps won’t work without snapd, which is not a snap package.
1 Like
Hmm… You’re right 
snaps are minimally slower on first start of an application (they need to set up the environment and load libs to ram). subsequent starts in a running session are as fast as usual, operation is as fast as usual.
the initial seeding of snaps on the very first boot of a newly installled system slows down the first boot by a minimal margin. subsequent boots are not affected.
snaps do have interfaces to talk to hardware or areas of the system. to have snaps share data there is an interface type called content interface that a framework or library snap can provide to other snaps. indeed this means the developer of such a snap needs to provide this interface … beyond this snaps can use desktop portals to share data.
snaps are updated on a manageable schedule, the next scheduled run immediately after a devloper updated his snap package in the store will get you the update. to check the schdule you can use snap refresh --time more details can be found at:
https://snapcraft.io/docs/keeping-snaps-up-to-date
snap binaries live in /snap/bin … at login time this is appended to your PATH variable.
if you have both, a deb and a snap installed that share the same executable; if you run the application from a terminal, the deb (from /usr/bin or /bin) will be found first and be executed by default … to run the snap in this case you need to run snap run <app> or execute it with the full path from /snap/bin.
For desktop snaps you sadly get two (typically identical) launchers in the UI, there it is a bit harder to tell the apps apart …
In general if you have any snap related questions there is a forum for this: https://forum.snapcraft.io
feel free to ask and additional questions over there.
4 Likes
Just for the sake of completeness: I believe there is some runtime overhead due to seccomp filtering: Concerns about performance - #5 by mvo - snapcraft - snapcraft.io
So it also depends on the specific app: syscall heavy => lots of filtering going on.
A good insight into startup overhead can be had via snap run --trace-exec [...]. One can see where time is spent.
And in general: Snaps are evolving, optimizations are being developed, extensions and best practices are getting better all the time. So it’s not a good topic for sweeping generalizations and intuitive guesses…
2 Likes
If you have snaps and snapd installed in your system, it would place all those files needed for each application in the /snap/…, mounted into it. Once, it is there, the executive file in the given app gets activated, when you click the relevant app’s icon. It takes a while to go through the paths to find it. It is inside a /usr/bin, but inside the /snap, so the longer time.
The deb or rpm or snap is a packaging system, but what runs the app is the executive file and the relative helper files (libraries and so on), once that package is un-archived and placed the files in Linux standard folders. It doesn’t really matter, where these files are, as far as the executive file can find them, and faster it finds them, the app appears on your screen. The shortest way gives faster results, the rest are slow.
In a standard Linux system, everything is unpacked and the files are already placed in their relevant places, so the speed.
Look at your installed Ubuntu system from another system , such as a live iso, or from another Linux system, and you’d notice the size of the /snap of that system. Have look inside that /snap and see what is there. Then, run your Ubuntu system and have a look at the /snap folder.
yup, indeed, thanks for pointing this out … there is also a minimal decompression overhead since snaps are never unpacked anywhere on the system, binary bits and pieces are runtime-decompressed by the kernel on access to the squashfs…
PS: while these slowdowns are measurable they are usually not much noticeable from a user perspective…
1 Like
That’s also very true and anyone interested can gain a little insight here too, with this excellent analysis and writeup of various possible optimizations: Squashfs performance effect on snap startup time - snapd - snapcraft.io
1 Like