Flatpak instalation disk space and a AppImage comparison.

[TerryH]

Last week after installing EasyOS 5.4.5, I needed to install Zoom, so it was a good chance to try the flatpak installer. This is the first time I've tried flatpak The install went well and installed Zoom 5.15.2, so very current. All went well and zoom worked without issue. I did notice that lots of extra packages were also being installed. I was somewhat aware that this would occur, due to the nature of flatpak isolation from the installed distribution. The installation was 2,420 MiB(2.36 GiB), which was a surprise.

Yesterday I did a new manual install to another card to see a comparison with the Zoom Appimage using the Appimage Installer. The Zoom Appimage that was initially installed weighed in at a slim 237 MiB, about 10% of the flatpak. The initial version installed was Zoom 5.13.11, so a slightly older version. It worked without issue. I then used the AppImage Installer to check for an update. The installer returned Zoom 5.15.6, so I updated. The newer version was slightly bigger at 241 Mib. This also worked without issue.

Back on the original installation I thought I'd try another flatpak, so I installed the Cherrytree flatpak, this added an additional 877 MiB , making my flatpak directory now 3297 MiB. So if space isn't a concern, flatpak installation in EasyOS works well. Personally if Appimages are available and function correctly, I will choose them first due to the smaller footprint.

[williwaw]

877 MB ?
but the deb is less than 3 MB

https://ubuntu.pkgs.org/18.04/ubuntu-un ... l.deb.html

[TerryH]

Yeah, I know. I knew that cherrytree was small, so wanted to see all the extra packages to run as flatpak. So 2 applications, a total of just over 240 MiB require 3 GiB of extra packages to be able to run. Adding other flatpak applications will require increasingly less extra packages to be able to run.

[wiak]

I think the major difference is FlatPak runs in a container and cannot access normal system libs at all, whereas AppImage can use underlying system libs so tends to be built with that major distro system libs already available in mind (but still adds plenty compared to the likes of deb package management based apps).

Hence with FlatPak you are basically supplying all the main system libs in the app runtime so its huge (kind of like duplicating the distro). If a second app happened to use the same core FlatPak runtime (e.g. one to do with Gnome rather than say Qt) then extra size of second app wouldn't be much. Apparently a user can build their own FlatPak runtime so could also make a smaller first runtime sufficient for say most GTK-based apps and thereafter flatpak 'might' not add much disk space bloat. I haven't tried building a runtime though (first core runtime would still inevitably be pretty huge and selecting what to include would need careful consideration and expertise).

But, yes, I think if FlatPak were adopted for many apps the growth in downloads would slow down rapidly overtime since it can share runtime contents - works a bit like a Git repo, but for binary parts. So you might end up with a 20GB distro maybe for which extra flatpak installs wouldn't further bloat it much, and would have that git-like advantage of being able to be updated easily or rolled-back to earlier app version or versions.

FlatPak has one big advantage over AppImage, it seems to be able to use newer libc/glibc to that in underlying system whereas AppImage cant (libc is on AppImage exclude list).

Whilst Manual building of an AppImage isn't recommended procedure, I can't help thinking some on this forum might find it simple and useful way to build customised AppImages for forum distros: https://docs.appimage.org/packaging-guide/manual.html

[jamesbond]

Imagine if you have to download an entire operating system to run a single application? Well, you don't have to imagine anymore. It's called FlatPak

[williwaw]

Nix is a cross-platform package manager that uses a deployment model where software is installed into unique directories generated through cryptographic hashes. It is also the name of the tool's programming language. A package's hash takes into account the dependencies, which is claimed to eliminate dependency hell, as an alternative to the typical solution of installing multiple versions of dependencies at the same time. This package management model advertises more reliable, reproducible, and portable packages.

The Nix Packages collection (Nixpkgs) is a set of over 80 000 packages for the Nix package manager.

Nix builds packages in isolation from each other. This ensures that they are reproducible and don't have undeclared dependencies, so if a package works on one machine, it will also work on another.

[don570]

Imagine if you have to download an entire operating system to run a single application? Well, you don't have to imagine anymore. It's called FlatPak

Chromebooks allow linux operating system to run simultaneously with Chrome OS.
However it takes up a lot of disk space because a separate file system is created.
_______________________________________________________________