Ubuntu Core 22 Beta Released For IoT & Edge Devices

[phoronix]

Phoronix: Ubuntu Core 22 Beta Released For IoT & Edge Devices

Building off last month's Ubuntu 22.04 Long-Term Support release, Canonical today has published the beta builds of the upcoming Ubuntu Core 22...

https://www.phoronix.com/scan.php?pa...u-Core-22-Beta

[pkese]

Embedded, IOT and Edge devices are usually resource limited: less RAM, less storage, weaker CPUs.

I wonder where did Ubuntu get the idea of pushing Snaps onto these devices,
because Snaps are exceptionally resource hungry.

This is another really dumb idea on Ubuntu's side.

[pkese]

... and I should add: OK, maybe the problem that Ubuntu is trying to solve is how to security and safely keep software up to date.

But I still think that they are bringing excessively oversized artillery to this battlefield.

[jo-erlend]

Embedded, IOT and Edge devices are usually resource limited: less RAM, less storage, weaker CPUs.

I wonder where did Ubuntu get the idea of pushing Snaps onto these devices,
because Snaps are exceptionally resource hungry.

This is another really dumb idea on Ubuntu's side.

No they're not. If they had been, you would've been correct, but since you're wrong, you're not.

[jo-erlend]

... and I should add: OK, maybe the problem that Ubuntu is trying to solve is how to security and safely keep software up to date.

But I still think that they are bringing excessively oversized artillery to this battlefield.

The snap system is actually quite minimalistic, which is a good thing.

[Setif]

because Snaps are exceptionally resource hungry.

Proof!

We know that snaps are slow to load, but that doesn't mean they are resource hungry.

[Tuxee]

Snaps are exceptionally resource hungry.

Can you back that up with facts and hard data? Or are you just rehashing things you heard "elsewhere"?

[Vistaus]

No they're not. If they had been, you would've been correct, but since you're wrong, you're not.

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

And yes, the same goes for the person you quoted: he/she should've provided a source as well.

[pkese]

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.

[Setif]

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.