> Yes it does, because you end up loading multiple versions of the shared libraries.
Given that not all applications necessarily use the same libraries and versions, that's an issue you cannot avoid even with shared libraries.
So, yes are right; it could be an issue. But it doesn't strictly have to do with the containerization.
To be thorough, let me qualify my statement:
Neither Flatpak nor Snap do necessarily result in an increased memory usage because of containerization.
> Snapd is quite big since it is written in Go.
Yes, that's true. Go probably wasn't the best idea for a system daemon.
Re:Flatpak Is Not the Future
by kirbyfan64sos on Tuesday November 23, 2021 @08:35AM
(#29317583)
IME, all running portal services add up to around 30MB RAM usage, and the two processes that need to run with each Flatpak are around 1MB each. (XDG portals aren't Flatpak-specific and can be used by host applications for some cross-desktop APIs as well.)
Yes it does, because you end up loading multiple versions of the shared libraries.
There is also the memory used by the flatpack/snap daemons. Snapd is quite big since it is written in Go.