Ubuntu Core 22 Beta Released For IoT & Edge Devices

[lyamc]

Good argument, saying someone is wrong without providing any source as to why that person is wrong.

Unironically, yes: https://en.wikipedia.org/wiki/Hitchens%27s_razor

[Vistaus]

Unironically, yes: https://en.wikipedia.org/wiki/Hitchens%27s_razor

You know, you could've read the rest of my post…

[krzyzowiec]

Snaps are much bigger than native .deb packages, because each snap brings with it its own set of runtime libraries.

When you have two .deb apps, say A and B, then both will use the same libc.so library that comes with the distro, e.g. libc-2.34.03.1.

Whereas with snaps, snap A can bring with it libc-2.34.03.1.so and snap B libc-2.34.03.2.so (and so forth with all library dependencies - an app usually uses dozens of shared libraries).

So with snaps you end up with multiple versions of system libraries on disk.

No they are much smaller, because snaps are compressed (that's why they are squashFS images in the first place). Each snap doesn't bring its own set of runtime libraries either. They use runtime snaps in the same way that Flatpak does, so you only need to install something like a Gnome or KDE snap and it will provide the shared libs that other snaps use. If they require different versions, well yeah, but that's one of the main selling points of Flatpaks/Snappy in the first place. (avoiding version conflicts and allowing you to update independently of base system libraries)

[Veto]

No they are much smaller, because snaps are compressed (that's why they are squashFS images in the first place).

Hmm. No. As an example the firefox .snap is three times the size of the .deb. Unpacked the snap is 55% bigger.
However, as the snap is stored in its packaged state you are right, that you save 27% on disk trading for bigger memory use and slower startup. That is of course provided that your file-system is not using compression anyway...

156M /var/lib/snapd/snaps/firefox_1232.snap
329M /snap/firefox/1232

56M firefox_100.0-1_amd64.deb
212M deb content

[jo-erlend]

Snaps are much bigger than native .deb packages, because each snap brings with it its own set of runtime libraries.

Snaps have used shared dependencies since 2014. With Debian packages, you are allowed to bundle anything you like.

[jo-erlend]

However, as the snap is stored in its packaged state you are right, that you save 27% on disk trading for bigger memory use and slower startup.

It isn't _actually_ true that programs consume more RAM when they're loaded from compressed filesystems, you know. There are a lot of myths going around. In the case of Snap, the system used an old decompression algorithm in order to be compatible with older Linux kernels used on Android phones, which were supposed to be the basis for Ubuntu Phone. But just because the algorithm was slower, doesn't mean that it leads to slower runtime and it definitely doesn't mean that it makes programs consume more RAM. If that was the case, then no sane person would accept that their kernels were loaded from compressed images.

In reality, once a program has been loaded to RAM, it makes no difference how it got there.

[kieffer]

I have recently attended to a conference on the usage of (lossless) compression to access data (on the network) and the big-picture is fairly complicated since the sweet-point depends both on the compression and decompression speed (depending on the CPU power and the codec chosen) but also on the bandwidth available to access those data.

On very fast network, compression is detrimental to performances, while on slower network it is beneficial. Even more, for a given processor, the fastest access is obtained with different compression algorithm depending if the network is 1Gbit, 10Gbit or 100Gbit/s !

To come back on snaps and other compressed apps, it tends to prove this is a more complicated question then anticipated.

[hamishmb]

It seems like people are getting confused between the way AppImages work (IIRC) and how Flatpak/Snap work wrt bundled libraries.