Testing default snap apps against equivalent deb apps - slow start times

This works by chance because those snaps were built on bionic (core18), and the dynamic libraries they link against are binary-compatible with the ones available on your host systems (Ubuntu 19.10 or Fedora 31). When any of the dependencies on the host system doesn’t satisfy this requirement, your “portable” apps are going to stop working, and will probably do so in “interesting” ways.

Not exactly.
When run from the terminal, the missing dependencies are shown. They can be either be installed in the system, or placed within the app folder itself. For example, the chromium-browser folder I took out of the chromium snap is much smaller than the one from Fedora 31, because there it has some dependencies it might need, or just baggage. The chromium-folder from the snap works faster in Fedora 31.

The dependencies can be put within as the snap does, or just put inside the folder, or installed to the system. More and more apps nowadays are portable as is.

When installing from a deb package, Apt puts unarchived packages in different relevant folders in /usr, /etc and so on in the root. (Snap, btw, lives in the root too.) You can put all those in a (named) folder, if needed add any missing dependencies, then make desktop file or a symlink to the executive on the desktop/menu/panel. You can put that folder in usb stick and run in any distro – simple and fast and portable.

And safe!
When an upgrade is announced, you can simply put the newer one in a folder and try separately. If you like the new one, feels it is safe to use, you keep it, or use both. Your configs don’t go away. You can run both at the same time.

Leafpad is such a small app. The Leafpad snap installed from Snapcraft store was large as 226.9 MB, whereas the Leafpad file that can be standalone is just 521.4 kB. And, it is portable.

The screenies would tell the story.
On Ubuntu,

The same leafpad file taken over to Fedora 31 beta also runs. Portable and quite small?

I’ve tried few more apps from Snapcraft Store with such results.

There’s obvious difference between Snap/Flatpak and file taken from folder and moved around systems with compatible binaries.

I don’t know what argument you are trying to make. That Snaps are slow? Fine, you got your answer from popey. That they are bigger? Well, sorry about that.

This thread, like any others you are part of, is following the same trend of whining and continuous spamming.

I’ve been here for few weeks and I already feel like I am in mental asylum.

You’ve got your answer, just stop, please…

Have you been to one before?

I have no idea about flatpaks. All the files in the folder is the same, and placed in other distros, Arch and Fedora in those that are non-deb ones. The folder is portable, or a solitary file. And they run in other systems, just the same as in Ubuntu., sometimes faster.

Try before commenting and complaining. You are only complaining, but had never seen how it happen.

No, not all snaps are slow, for example Atom is very fast. Meaning it had been packaged well, even though it is quite large 995MB.

(Aha, don’t read my threads/comments, if they send you back to mental asylum.)

This isn’t always true, there are numerous apps that have hard-coded locations to libraries that they need such as from /lib/… or even /opt/… because the libraries are not loaded by the linker but dynamically with dlopen(3). Snaps can solve this when run from inside the snap runtime environment by setting up appropriate mount namespace changes which make the libraries appear to the snap’s processes in those locations, but not to the host filesystem. This means that snaps are self contained within the /snap/<snap-name> folder even if they require hard-coded file path locations.

Additionally, even if the app can be fixed by just installing other dependencies onto the host system, the error messages a user gets from these missing dependencies are not an easy thing for non-technical folks to decode and work through. Snaps solve this by bundling all of the dependencies inside a single snap, so that a user gets everything they need with snap install <the-snap>. Of course debs solve this problem with dependent/required packages, etc.

Another advantage of bundling dependencies with apps into a single atomic thing (i.e. snap) that is separated from other apps is that you can have multiple versions of the same dependency installed concurrently. This is not something that’s easily achieved with debs (I at least don’t know how to do this) without maintaining concurrent versions of dependencies (even then it seems impossible in some cases since the same files would be overwriting each other). With snaps this is easy because snaps don’t “see” each’s files, so if app A needs libabc v1.2.3 and app B needs libabc v2.3.4, if those two things are snaps, they just include libabc inside and neither app sees the other version installed in the other snap. This same concept applies to the entire root filesystem for a snap, since strictly confined snaps use a specific root filesystem called a base snap. Right now, we have a few supported base snaps, currently based on Ubuntu LTS, so there’s a core18 snap for 18.04, and core (aka core16) for 16.04, and this makes it easy to continue to use an app with older or newer dependencies on a given system, as the app doesn’t see which real OS it’s running on it, it only sees the base snap, so a core18 snap run on Fedora will see dependencies in the snap that were installed from the 18.04 archive, etc. These things make snaps more portable than debs or rpms.

All that being said, as @popey and others have already said the snap runtime environment is quite complex and so it’s not as simple as just “don’t do the snap stuff and run the binary directly”. There are also security concerns with doing so, as without the snap runtime environment you don’t have the security confinement options enabled. So, snaps are portable, but the reason they are portable is not simply because the apps inside them are portable. There are non-portable apps packaged as debs which are more portable as snaps because of the machinery inside snaps.

I agree with you that running an app in the terminal doesn’t always show the dependencies. But, one can find the dependencies in the control file. Or, after installing through synaptic. Btw, please have a look at any app inside /snap folder, see what dependencies are needed. Some snap app developers forget some of these dependencies, so while execution of that snap app, it looks for it, slowing down the start of it.

Anyway, I am for self contained apps/packages, but I think they should be smaller, or just about few kbs/mbs larger than the deb equivalent. I’ve been looking into this area, before snaps came into being. I was expecting an app/package that I can keep in a USB stick, take with me and open in any Linux distro. And, without demanding the other person to install a special app, snapd ubuntu core or else. As, you know there are public computers, where you can use a usb stick and some of them allow an outside application to run from it. The question is about portability, more than anything else.

All right, to check this out in another OS platform, I installed few apps in one Windows 10 laptop, copied the relevant app folders to a usb stick, purged those apps from the 1st laptop and plugged usb stick into another Windows 10 laptop. These apps ran well in the 2nd laptop. Then, plugged the usb stick to the 1st laptop. They ran well in the 1st laptop too. They created their own configs in the both laptops. They are quite large applications; GIMP 2.10.10, LibreOffice 6.3.2, Calibre 3.4.2. and some other apps. It took sometime to reply because of this.

You just can’t do this with snaps on another Linux distro, without a special programs and ubuntu core etc installed in it. You can’t download a snap app, only install it. It goes to root, not to one’s home folder.
Found out quite a few things on this. Enough experimenting on snaps for me.

where do you get such numbers ???

$ snap info leafpad|grep MB
  stable: 2019-09-16 (50) 44MB -
  edge: 2019-10-04 (54) 44MB -
$ ls -lh /var/lib/snapd/snaps/leafpad_50.snap 
-rw------- 2 root root 43M Okt 10 22:16 /var/lib/snapd/snaps/leafpad_50.snap

EDIT: same question for you claim about atom:

$ ls -lh /var/lib/snapd/snaps/atom_238.snap 
-rw------- 2 root root 220M Okt 10 22:49 /var/lib/snapd/snaps/atom_238.snap
$ snap info atom|grep MB
  stable:    1.40.1 2019-08-23 (238) 229MB classic
  edge:      1.40.1 2019-09-13 (239) 219MB classic
installed:   1.40.1            (238) 229MB classic

Check all numbered folders in any snap.

this isnt the actual size, you are looking inside a mountpoint of a compressed readonly squashfs file, that has nothing to do with actual size at all … (imagine an 800MB CDROM with a 2GB compressed filesystem, it is actually only 800MB, but if you mount it you will see the full 2GB content)

try copying anything into that dir and you will see :wink:

Copied the Leafpad snap folder to Desktop.

to achieve what exactly ?

like when copying the 2GB compressed data from above from this imaginary CD, the folder content is now not in a compressed squashfs anymore and occupies actual 235MB … like the 2GB data from the CD would if you copied its content around … but that doesnt change the fact that the CD is only 800MB big … same goes for the leafpad snap if you dont copy its content around it is exactly the 43MB the squashfs is big, not smaller, not bigger

Just to show you that it is not a squashfs file. Has actual size, same at the /snap folder or in any other folder in home or somewhere else. Put it in a usb stick and see.

When you squash something, it becomes smaller. The isos are squashed, for example, but not snaps.

but it is a squashfs file, you are just uncompressing it by copying content out of it … please read up about squashfs, it is one of the very core parts of snaps, enables binary deltas (if only 1byte changed between two snap versions only that 1byte will be downloaded) and makes sure that malicious software can not modify the snap application …

copying around content from it is completely pointless and does not prove anything apart from that fact that you can copy it around.

$ sudo file /var/lib/snapd/snaps/leafpad_50.snap 
/var/lib/snapd/snaps/leafpad_50.snap: Squashfs filesystem, little endian, version 4.0, 44702730 bytes, 21750 inodes, blocksize: 131072 bytes, created: Mon Sep 16 09:33:05 2019

Never heard that copying a squashed file can uncompress it.
/var/lib/snapd/snaps/leafpad_50.snap is in the system in /var. /snap folder is somewhere else in root and the executive file is there. Everything that runs in the snap as snap is in /snap.

See, just 521.4kB

All right, enough experimenting.:slight_smile:

$ mount |grep leafpad
/var/lib/snapd/snaps/leafpad_50.snap on /snap/leafpad/50 type squashfs (ro,nodev,relatime)
nsfs on /run/snapd/ns/leafpad.mnt type nsfs (rw)

well, it isnt experimenting, i’m trying to teach you some facts about snap packages (being one of the initial developers of it when the package format was created in 2014) so you understand why the claim you made above is wrong…

Look, when you install a snap, it gets first downloaded to /var/lib/snapd/snaps/, then snappy would install it to /snap folder unsquashed. There lives Ubuntu core. Without that core, no snap would run. In other words, for a snap app to run, you need ubuntu core, and the snap would run only this core is available in the system.

A snap app wouldn’t run on the standard Ubuntu system, but on the Ubuntu core. Take the core off, no snap would run.

The app in the snap should run in the standard Ubuntu system, but can’t because of all kinds roundabout stuff added to it. And, when you take those added stuff off, the app in the snap works very well in the standard Ubuntu system. I am writing from such an app - Chromium Web Browser, very lean and quick! Not installed, but sitting in my home folder!

I am not a developer, but a user and I had been at self-contained apps much before snaps came to be. :slight_smile:

"Look, when you install a snap, it gets first downloaded to /var/lib/snapd/snaps/, then snappy would install it to /snap folder unsquashed. "

No. That is not what happens, and you’re missing a few steps. The snap gets downloaded to /var, for sure, but it does not get “unsquashed” to /snap. It gets mounted. There is a significant difference. It’s the difference between looking at the contents of a zipfile and unpacking the zipfile. Looking at the contents doesn’t mean you take everything that was in the zip file and lay it out on the disk permanently. Unpacking does exactly that.

When a snap is installed it’s mounted under /snap, so stays read-only so as not to be modified, and keeps the files compressed, saving space on disk.

You’re missing a bunch of checks and balances in between to validate the snap. In addition there is work done by snapd to ensure revisioned data is migrated from one revision of the snap to the next.

Further when the application is launched, there are often ‘helpers’ which are used to stand up the environment required by a modern Linux system to ensure the application ‘sees’ what it expects to when it launches. That stuff already exists on your system outside the snap environment which is why when unpacked into your home and run, it just runs. It’s by happy accident that works, not by design. Do the same thing on another distro and it may not work, because the environment isn’t setup correctly. The point of core and other content snaps is to ensure the environment is there for when the applications runs inside the sandbox.

I appreciate you’re just fiddling about, but it’s actually not super useful to us for someone to try and armchair redesign snapd as if we just fell off the banana boat.