The correct forum is snapcraft - the observations are applicable to all snap enabled systems & distro’s.
There is little point in continuing the discussion here - this thread should be closed.
2 Likes
I think it’s fair to post here or the snapcraft forum. Given some of these are applications the Ubuntu Desktop team are responsible for. If there’s specific issues identified, then we should hunt down where the bugs are and fix them if we can. The problem with the “snap is slow” argument is that it’s not as clear cut as that. The stack of things happening when you snap run firefox has some differences from the stack run when you /usr/bin/firefox.
We have made some changes in various places, but there’s clearly still a problem, so thanks for bringing it up. We need to do more work to identify the specific parts that have bottlenecks and fix them, for sure.
I’m not dismissing the issue, merely pointing out it’s actually super complicated. There’s a lot of moving parts, with possible issues covering a number of skills and domains.
4 Likes
I understand it is complicated and hope you’d succeed in overcoming them. I checked the Firefox snap out of curiosity. 
The interest is in Ubuntu, not other distros or systems. I don’t believe Archers using snaps, but these snaps may trouble other Ubuntu flavours, but it is still Ubuntu.
They do. Snaps are installed and used by users of basically every mainstream distro. Go here and scroll down to see a sample list of distros.
1 Like
I think it’d be best not to mention snaps in Arch forums. Anyway, this is off topic.
@popey
I never had a real reason to look at other distros with Gnome shell before. Earlier Ubuntu had a DE no one had.
Anyway, checking standalone apps, such as Chromium, that I took out of the Chromium snap in Fedora 31 beta. I just copied the whole folder chromium-browser there and ran,
$ time ~/chromium-browser/chrome
The result,
real 0m4.541s
user 0m3.058s
sys 0m1.146s
In Ubuntu it was,
real 0m5.087s
user 0m6.032s
sys 0m1.318s
Just took the folder and put in Fedora 31 Beta. That folder is ~1/3 of the size of the Chromium snap in terms of MBs (607.3 MB snap, to 237.2 MB) . Just as portable!
Fedora installs Chromium browser normally, and the strange thing is it started slower than the one I took there.
$ time chromium-browser
gave,
real 0m14.429s
user 0m12.534s
sys 0m2.190s
Note: Of course, I can take the whole folder /usr/lib64/chromium-browser and place it anywhere and click on the executive file, and Chromium would start, also placed in Ubuntu. That one is also quite portable.
Yada Yada 
1 Like
Take it anyway you like it.
Firefox is contained in a folder, making it a portable app. Lives in /usr/lib/firefox
Libreoffice is contained in /usr/lib/libreoffice,
And, many more apps are just as portable. They don’t really have to be made portable, another way.
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: 0.8.18.1 2019-09-16 (50) 44MB -
edge: 0.8.18.1 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 
