3 ms·
AppImages are also very big. Example: Blender [0] (210MB), OBS [1] (105MB), Ungoogled Chromium [2] (166MB) The only alternative that does not lead to downloadi
by cherryteastain 3y ago
AppImages are also very big. Example: Blender [0] (210MB), OBS [1] (105MB), Ungoogled Chromium [2] (166MB)
The only alternative that does not lead to downloading 100s of MBs of files is .deb/.rpm files and the associated "the prebuilt binary needs libfoo.so.4.0.1 but Debian ships libfoo.so.4.0.0" problems. Which ultimately means you pull even more dependencies than the Flatpak runtime for building (gcc, make, CMake, libfoo-dev, libfoo-dev's *-dev dependencies,...) and spend a long time compiling the application (also suited only for high memory, high core count machines).
[0] https://www.appimagehub.com/p/1169218/ https://www.appimagehub.com/p/1169218/
[1] https://www.appimagehub.com/p/1409898 https://www.appimagehub.com/p/1409898
[2] https://ungoogled-software.github.io/ungoogled-chromium-binaries/releases/appimage/64bit/119.0.6045.123-1 https://ungoogled-software.github.io/ungoogled-chromium-bina...
- yjftsjthsd-h 3y agoRight; one way or another a program needs all of its dependencies. The traditional model was that a distribution would include one version of each dependency (most of the time) and share that between all the programs on the machine. Of course, that didn't work if you couldn't use that version, so the alternative is to somehow bundle dependencies in with your program (appimage, Firefox-like tarballs, plain static binaries) or ship them separate (flatpak, maybe docker).