-
-
Notifications
You must be signed in to change notification settings - Fork 133
Description
QDirStat AppImage
TL;DR
- It's big and fat (113 MB packed, 586 MB unpacked)
- It's a very outdated version: QDirStat 1.6.1 February 2020
- It doesn't even tell you what version it contains
- It still needs a fairly recent version of GLibc, so you can't run it on older (but still supported!) Linux distributions like Ubuntu 18.04 LTS
- It's unclear if at least the libraries inside (e.g. the Qt libs) are up to date
Details
I recently came across this:
https://apprepo.de/appimage/qdirstat
Okay... so somebody packaged QDirStat as an AppImage. I am not a fan of those package formats (AppImage, FlatPak, Snap) that basically put half an operating system into a package (at least all involved shared libs), even less so for QDirStat that is all about finding out where disk space got wasted, and then forcing the user to download and install 110+ MB to start the program.
But okay, if somebody got through the trouble of doing that, and if there are users out there who (for whatever reason) like that package format, it's their choice.
AppImage Pros and Cons
AppImage Pros
-
Independent of what Linux distribution you use: They say "Linux applications that run everywhere" (https://appimage.org/).
Okay, let's give them the benefit of doubt.
-
You don't need to install dependent shared libs (the Qt libs in the case of QDirStat) because they are part of the package.
The same could be achieved by good old static linking which however would be a violation of the LGPL under which many libraries are licensed, in particular the Open Source variant of Qt: The LGPL wants the end user to be able to exchange those shared libs with preferred versions that might contain custom modifications or security fixes.
AppImage Cons
-
Very large packages: Large download size, large installed size. This QDirStat AppImage weighs in at 113 MB, and that's already a compressed format: Trying to compress it with
bzip2
results in the exact same size. -
You cannot exchange the shared libs. If one of them gets a security update, you have to trust the AppImage packagers to provide an updated AppImage with the security fix. Worse, you don't even know if the AppImage has that fix. You can only hope that the AppImage packagers stay on top of all those security fixes that keep coming all the time, and that they distribute them without delay.
What Version?
Judging from the screenshot, this may not be the latest released version; the screenshot still has the old menu structure and no "Discover" toplevel menu.
That page https://apprepo.de/appimage/qdirstat doesn't say what version they packaged which is the first thing that greatly pisses me off. It says "build history: latest, 21-06-2021" which would be today.
But what does that mean? Today's QDirStat git version? Or the latest stable release built today with all the dependent libs (Qt, libz, GLibc) in their latest version? It doesn't tell.
That "SHA-1 Hash: 61e73908094d8c0ca47939db828140f74ad81be0" does not exist in the QDirStat GitHub repo:
sh@balrog:~/src/qdirstat$ git show 61e73908094d8c0ca47939db828140f74ad81be0
fatal: bad object 61e73908094d8c0ca47939db828140f74ad81be0
sh@balrog:~/src/qdirstat$ git log
commit 7ed60f20deb53b87e404860b814fd0d932945a63 (HEAD -> master, huha/master, huha/HEAD)
Author: Stefan Hundhammer <Stefan.Hundhammer@gmx.de>
Date: Sun May 30 03:06:40 2021 +0200
Don't kill performance with a crazy default key action
commit e7150bd56ca61a66a8c5a1630c4df39681fb27bb
Author: Stefan Hundhammer <Stefan.Hundhammer@gmx.de>
Date: Wed May 19 17:56:11 2021 +0200
Fixed warning about unchecked return value
commit 138ed33523e9cfa84fd9d30da4dbb95aafce05f9
Author: Stefan Hundhammer <Stefan.Hundhammer@gmx.de>
Date: Wed May 19 17:46:30 2021 +0200
Let the compiler optimize by default (issue #160)
commit 0b75489657312370db377d4b90f27b8c7a858a0d
Author: Stefan Hundhammer <Stefan.Hundhammer@gmx.de>
Date: Fri Apr 30 00:18:29 2021 +0200
Removed reference to outdated PPA
commit 1cf6b2e6526e187c554ec36079032393e5870801
Author: Stefan Hundhammer <Stefan.Hundhammer@gmx.de>
Date: Mon Apr 5 17:20:49 2021 +0200
Post-release version bump for devel versions
commit 735747a7d48324fc287ac5afb5b002e23e0c315c (tag: 1.7.1, huha/stable-1.7.1, stable-1.7.1, release-1.7.1)
Author: Stefan Hundhammer <Stefan.Hundhammer@gmx.de>
Date: Mon Apr 5 15:30:12 2021 +0200
Updated screenshot
commit 70a9f1276fa4b862af6f8dd3f152c0d9c5b003db
Author: Stefan Hundhammer <Stefan.Hundhammer@gmx.de>
Date: Mon Apr 5 15:02:45 2021 +0200
Change log
Okay, so let's download that thing and try to look inside.
Downloading and Starting the AppImage
After downloading:
sh@balrog:~/tmp$ ls -lh
total 113M
-rwxr-xr-x 1 sh sh 113M Jun 21 11:31 QDirStat.AppImage
Yikes. Compared with the freshly compiled binary:
sh@balrog:~/src/qdirstat/src$ ls -lh qdirstat
-rwxr-xr-x 1 sh sh 2.1M Jun 21 11:38 qdirstat
Which admittedly uses quite a number of shared libs (mostly the Qt libs and what they in turn require). But chances are that you have the Qt libs installed anyway for any of those other very common Qt applications, so the footprint of QDirStat is typically in the order of 2 MB, not 113 MB.
So let's start that AppImage:
sh@balrog:~/tmp$ ./QDirStat.AppImage
/tmp/.mount_QDirStTb8US4/bin/qdirstat: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_QDirStTb8US4/bin/qdirstat)
/tmp/.mount_QDirStTb8US4/bin/qdirstat: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_QDirStTb8US4/lib64/libQt5Widgets.so.5)
/tmp/.mount_QDirStTb8US4/bin/qdirstat: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_QDirStTb8US4/lib64/libQt5Gui.so.5)
/tmp/.mount_QDirStTb8US4/bin/qdirstat: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_QDirStTb8US4/lib64/libQt5Core.so.5)
/tmp/.mount_QDirStTb8US4/bin/qdirstat: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /tmp/.mount_QDirStTb8US4/lib64/libQt5Core.so.5)
/tmp/.mount_QDirStTb8US4/bin/qdirstat: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_QDirStTb8US4/lib64/libpng16.so.16)
/tmp/.mount_QDirStTb8US4/bin/qdirstat: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_QDirStTb8US4/lib64/libicui18n.so.66)
/tmp/.mount_QDirStTb8US4/bin/qdirstat: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by /tmp/.mount_QDirStTb8US4/lib64/libicuuc.so.66)
/tmp/.mount_QDirStTb8US4/bin/qdirstat: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /tmp/.mount_QDirStTb8US4/lib64/libglib-2.0.so.0)
You gotta be kidding me.
The very purpose and raison d'être for the AppImage format is to avoid exactly this situation.
"Linux applications that run everywhere" was the promise!
And yet it failed to deliver with the most fundamental of all libraries, the GLibc?!? WTF?
Yes, it said on that download page:
It works in:
- openSUSE Tumbleweed
- Ubuntu 20.04
...- Linux distro with GLIBC >= 2.31
Does not work in:
- Ubuntu < 20.04
- Linux distro with GLIBC < 2.31
I have Ubuntu 18.04 LTS.
So what's the point of this AppImage format if it depends on the GLibc version that much?
If you violated the LGPL already for the Qt libs and all the others that you packaged, what prevents you from at least being consistent and remove this hard dependency on a specific GLibc version by simply packaging the GLibc as well?
Trying to Look Inside Manually
There must be a way to mount that thing. Let's see how this is supposed to work. A web search for "look inside appimage" gets us this as the first answer:
https://askubuntu.com/questions/1231597/how-can-i-examine-the-files-inside-an-appimage
How can I examine the files inside an Appimage?
From what I've read, an Appimage file is a compressed application along with all of its resources,
and when run it is auto-mounted and then executed.I want to inspect the resources and files inside an Appimage file I've downloaded,
without actually running the Appimage.How can I do this?
Answer
As such, an appimage can be mounted or extracted. That is:
my.AppImage --appimage-mount
...
mount -o loop
Okay, let's give that a try:
sh@balrog:~/tmp$ ./QDirStat.AppImage --appimage-mount
/tmp/.mount_QDirStQC67Ps
In a new shell window (because this one is now busy keeping that image mounted):
sh@balrog:/tmp/.mount_QDirStQC67Ps$ du -hs .
586M .
Yikes. Unpacking that AppImage takes 586 MB!
sh@balrog:/tmp/.mount_QDirStQC67Ps$ ls
AppRun bin include lib lib64 libexec QDirStat.desktop qdirstat.svg share
sh@balrog:/tmp/.mount_QDirStQC67Ps$ find . -name qdirstat -type f
./bin/qdirstat
./share/lintian/overrides/qdirstat
sh@balrog:/tmp/.mount_QDirStQC67Ps$ strings bin/qdirstat | grep 'QDirStat 1\.'
<h2>QDirStat 1.6.1</h2>
Adding insult to injury, they packaged QDirStat 1.6.1 which was released on 2020-02-13, i.e. 16 28 months ago. They didn't get around to package V 1.7 from 2020-07-26 (almost two years ago), V 1.7.1 from 2021-04-05, i.e. over one year ago, let alone V 1.8 from 2021-08-28.
Bottom Line
A package that does not tell what version you get and tends to get you outdated versions from well over a year ago is completely worthless.
Admittedly, that's not the fault of the package format, but of the packagers.
But it gets worse because the libraries they packaged in that package are just as outdated; it's still Qt 5.12, not Qt 5.15 which is the latest Qt 5.x version at the time of this writing.
If they can't get even those basics right, why should anybody trust them to ship libraries with the latest fixes, some of which are usually security fixes?
That, my friends, are reasons why I don't like those "shrink-wrap the world" package formats. Not AppImage, not FlatPak, not Snap.