. If you end up with 4.7GB for runtimes, that’s basically nothing these days
Yes but that wasn’t the original comment I replied to was about.
163 flatpaks and the runtimes used 8.7GB
163 flatpaks using 8.7 GiB means that the average flatpak is using 54.6 MiB.
That’s good the other time I got this linked: https://tesk.page/2023/06/04/response-to-developers-are-lazy-thus-flatpak/#but-flatpaks-are-easier-for-end-users
Which is no good as in that example there was 173 flatpaks using 27.66 GiB, average 160 MiB, while in your case the average flatpak is using 91 MiB.
This is what I have with appimages:
In this case the average appimage is using 69 MiB, though there is one outliner which is the Steam appimage that I have there (470 MiB) which is an entire conty container with its own video drivers and everything, without it the average would be 56 MiB.
I know this doesn’t matter these days but once again that wasn’t what the original comment was about.
Well we are talking about two gigs, after all. Unless you’re using an embedded system, it’s not a much of a concern if you ask me. But it is more, true
Thanks for the link showing an average flatpak using 54 MiB though, didn’t think it was possible lol.
WAIT I just took a deeper look at the link, isn’t that guy just showing the runtimes without the applications using 8.7 GiB?
I tested installing some web browers, kdenlive, yuzu and libreoffice and without knowing I ended up with 3 different runtimes and the total storage usage (with deduplication) was 4.79 GIB.
Meanwhile with 33 appimages that I have (which includes same flatpak apps I mentioned) are using 2.2 GiB.
It doesn’t matter if they share if in the end they end up using several times more storage than the appimage equivalent.
Isn’t the gnome runtime alone 2GiB? You know how many appimages that is?
Not to mention you are unlikely to only use one runtime.
I find it funny that thumbnail with a “fail” I’m actually surprised that it got 48% right.
In the old days distros used to separate the location of binaries in several places like /bin
/sbin
/usr/bin
and /usr/sbin
there was this idea that system binaries would go in /sbin
while the rest in /bin
and the similar dirs in /usr
were so that you could mount a separate drive to store more binaries. This is from a time where storage was an issue.
These days distros usually just symlink all those locations to /usr/bin
with the exception of fedora, which still keeps some split.
However it seems they will finally merge the remaining dirs in fedora 41: https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
(once Flatpak get that too, there is no valid reason for snaps to exist).
They said they will not fix it due to “security concerns”
Isnt fedora like the last distro that doesnt symlink /bin and /sbin to /usr/bin?
The appimage is basically just
git clone
->make
->make install DESTDIR=/path/to/AppDir
->wget appimagecreationtool
and finallyappimagecreationtool /path/to/AppDir
and that’s it you have your appimage.appimagecreationtool being several tools that can create the appimage from an AppDir, like linuxdeploy, linuxdeploqt, go-appimage, etc
And that on itself isn’t complex either, it if basically running ldd on the binary, then copy those libraries into the AppDir and finally run patchelf to patch the paths in the binaries and libraries, suyu uses a deploy script instead of using those tools, which I’ve recently forked and began expanding.
I don’t know how easy it is to make a flatpak or snap, but I do know the dev of zen browser hates dealing with the flatpak and iirc right now the flatpak is outdated as result.
EDIT: Also lite-xl has been making a flatpak for like 2 years and it isn’t ready yet.