Announcement

Collapse
No announcement yet.

Ubuntu Core 22 Beta Released For IoT & Edge Devices

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Leave a comment:


  • kieffer
    replied
    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.

    Leave a comment:


  • jo-erlend
    replied
    Originally posted by Veto View Post
    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.

    Leave a comment:


  • jo-erlend
    replied
    Originally posted by pkese View Post
    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.

    Leave a comment:


  • Veto
    replied
    Originally posted by krzyzowiec View Post
    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
    Last edited by Veto; 15 May 2022, 04:00 AM. Reason: Remember file system compression...

    Leave a comment:


  • krzyzowiec
    replied
    Originally posted by pkese View Post

    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)

    Leave a comment:


  • Vistaus
    replied
    Originally posted by lyamc View Post
    You know, you could've read the rest of my post…

    Leave a comment:


  • lyamc
    replied
    Originally posted by Vistaus View Post
    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

    Leave a comment:


  • Setif
    replied
    Originally posted by pkese View Post

    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.

    Then once you start apps A and B as .deb, only the single system version of the libc.so library will be loaded into memory and the read-only code segment gets shared between both processes. No matter how many programs are using the same .so file, only one gets loaded into memory.

    With snaps, since apps A and B bring with it different versions of libc.so, each will load its own version into memory so any profit from system resource sharing is gone.

    This continues on with usage of CPU cache: if .so files are shared between processes, they can also share L3 cache so at time of task switch, the next process can use the shared instruction code directly from cache, whereas with non-shared libraries, caches need to be reloaded, etc.
    I asked for proof, not for made-up/speculated analysis. I mean real benchmarks measuring CPU/Memory usage.

    Also, There are few base snaps that all snaps depends on: core (dropped), core18 or core20, so you will end up with 3 system libraries at max. That's when talking about ubuntu desktop.

    For IoT, I think things are different. the developer uses only one core snap and build on top of it.
    snappy - What makes Ubuntu Core's "Snaps" better than normal packages for IoT devices? - Internet of Things Stack Exchange

    Ubuntu Core is more like Android than regular Linux distribution.

    Leave a comment:


  • pkese
    replied
    Originally posted by Setif View Post

    We know that snaps are slow to load, but that doesn't mean they are resource hungry.
    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.

    Then once you start apps A and B as .deb, only the single system version of the libc.so library will be loaded into memory and the read-only code segment gets shared between both processes. No matter how many programs are using the same .so file, only one gets loaded into memory.

    With snaps, since apps A and B bring with it different versions of libc.so, each will load its own version into memory so any profit from system resource sharing is gone.

    This continues on with usage of CPU cache: if .so files are shared between processes, they can also share L3 cache so at time of task switch, the next process can use the shared instruction code directly from cache, whereas with non-shared libraries, caches need to be reloaded, etc.

    Leave a comment:

Working...
X