QDirStat AppImage and Why I don't like It #168
Comments
Filesystem Type of the Imagesh@balrog:/tmp/.mount_QDirStQC67Ps$ grep /tmp/.mount_QDirStQC67Ps /proc/mounts
QDirStat.AppImage /tmp/.mount_QDirStQC67Ps fuse.QDirStat.AppImage ro,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
sh@balrog:/tmp/.mount_QDirStQC67Ps$ df -T .
Filesystem Type 1K-blocks Used Available Use% Mounted on
QDirStat.AppImage fuse.QDirStat.AppImage 0 0 0 - /tmp/.mount_QDirStQC67PsFilesystem type Trying to mount the image manually after terminating that sh@balrog:~/tmp$ ls -lh
total 113M
-rwxr-xr-x 1 sh sh 113M Jun 21 11:31 QDirStat.AppImage
sh@balrog:~/tmp$ sudo mount -o loop ./QDirStat.AppImage /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.
sh@balrog:~/tmp$ sudo mount -o loop -t fuse.QDirStat.AppImage ./QDirStat.AppImage /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.:-(( Is there even any different way than putting your trust in that very image that you downloaded and executing it? You can only hope that starting it with That's nowhere near as secure as mounting it yourself with your system's |
|
Feel free to comment and discuss this here. Since this is not a issue of QDirStat, closing for now. |
|
Hello, AppImage author here. Agree that AppImages should always come from the trusted original application author (you) and need to me made so that they run on all still-supported Linux distribution releases. Would you be interested in an official AppImage that is actually working properly? |
|
If there is an AppImage out there, it should be up to date, it should always be clear what program version it is, and it should be as well-maintained as any distribution package; meaning that at least any critical security updates for libs that it uses are always kept up to date, and the versions of those libs should also be clear. Those are the minimum requirements. Having said that, this does not change any of my other points:
And in case this is unclear: I do not intend to build or distribute any such format, be it AppImage, FlatPak, Snap or similar. I do build and distribute RPMs for SUSE Linux distributions only because I work for that company, I have easy access to the infrastructure to do it, and I have the know-how for it. I don't build and distribute any other package format, neither Debian / Ubuntu .deb packages nor any other. For one thing, I don't have enough of the know-how (which could be fixed) nor the infrastructure nor the time. Building binary packages is beyond the scope of an upstream Open Source author; this is the distribution maintainers' role. Not only is it time-consuming, there is also a lot more to maintaining a package than just throwing the source code and some description file (.spec or Debian rules file) into some build system and hope for the best. There are also distribution-specific rules and guide lines to follow, and, more importantly, keeping on top of security problems and their fixes. This is even a lot worse for libraries, even more so for powerful and complex libraries like Qt; Qt is an all-encompassing framework that touches every corner, nook and cranny of programming, not only GUI, but also general programming like file handling, networking and whatnot. Somebody maintaining this needs extensive know-how of all of that, and, more importantly, needs to stay even more on top of security issues than a maintainer of a simple user program. Maintaining something like Qt and keeping it secure can be a tough job; this is certainly not something to do casually. And that is actually my major gripe with all of those package formats that just include all dependencies in one package: I don't see how this can reasonably be done. |
Agree. I recommend building AppImages as part of an application's CI pipeline
Agree. The recommended naming is
Agree. In fact, it should imho be always the latest application version, not just the version any particular distribution happens to carry at that point.
Will always be larger than distribution packages by the necessity of bundling everything privately that cannot reasonably be assumed to be part of all still-supported mainstream Linux distributions. This is an unavoidable tradeoff if you want a portable application that can run on all still-supported mainstream Linux distributions. But it may not as bad as one might think, since e.g., not the whole Qt needs to be shipped but only the parts that the application actually needs. And everything stays compressed on disk all the time, so the net effect depends a lot on the application -- in fact, e.g., LibreOffice is much smaller(!) in an AppImage than when traditionally installed on disk.
Agree. In fact, we reject any AppImage that won't run on the oldest still-supported Ubuntu LTS release from being included in https://appimage.github.io/.
Agree. You can extract every AppImage and exchange any of its contents. Like you can with a zip or other archive file. Being able to look inside the package with standard tools Agree. I wish tools like Ark and other archiving tools would build in native AppImage support. Since an AppImage is basically just an ISO9660 or squashfs file with an ELF prepended to it, that should be no problem to do. In the meantime, you can do it by:
Sorry to hear that, but I respect your opinion, as you are the author.
For the sake of completeness, https://openbuildservice.org/ can build AppImages thanks to @adrianschroeter 👍
Hence, OBS will do that work for you using all the well established distro-grade infrastructure. It will even re-build the AppImage automatically if one of the ingredients are updated on OBS. So, other from the size argument (which is inherent to the objective of this format) I think all of your pain points are addressed? |
...which would dump that whole problem into my lap again. No. The upstream author delivers the source code; that's it. I know from my day job that those CI tools all have their quirks and problems, and they all need regular babysitting. There is not a single one of them out there that does not. I find myself dealing more with that stuff than with real development, and the benefits are questionable at best. |
Disagree. (I mean, you are the author, you decide for your programs; but for the software I use I'd prefer to get it from an author who builds and supports it.) Stallman says: Binaries without source code are worthless. The sad reality is that some people (especially those in large organizations like universities) are forced to locked down (usually outdated) operating system releases and cannot "just install Tumbleweed" or whatever. Hence AppImage. |
LibreOffice is beyond the point here; it will probably benefit much from the compression that an AppImage uses to avoid completely insane package sizes. But look at the numbers that I quoted above: 110 MB for the compressed QDirStat AppImage, 586 MB unpacked size. I still remember the time when that was the total size of a complete Linux installation. This is especially bad when it's about an application for the dedicated purpose of combating disk space waste; this leads the whole idea pretty much ad absurdum. There is also no good reason to waste that much disk space for the alleged benefit of having one package for all distributions; not only did that not work out in this case (see the Glibc incompatibility problems), it's also completely pointless when it's easy to build the real package for the real target distro instead. Also, this can only work for machines with the same architecture; the argument falls apart the moment you need it for, say, an Arm machine like a RasPi. |
No. It's reasonably easy to build; that's not rocket science.
They are always free to build their own. Or simply use the binary package that is available for their (even older) distribution. For SUSE distros, I even provide backported RPMs that go back quite a while (but here we really are in the extra-luxury area).
Wrong conclusion IMHO. You are entitled to your opinion, of course, but I don't share it. |
|
BTW no hard feelings here. I appreciate the discussion, even if we agree that we disagree. ;-) |
Actually OBS can also build DEB packages. In the past we even built the YaST packages for Debian to run in Travis which uses Ubuntu in VMs. After adding Docker support we do not need that anymore, but you can still find the Debian packaging at https://github.com/yast/travis_old/tree/master_old/packages in case you are interested in details... |
|
Reported upstream: |
|
So, that AppImage is not built from sources in that GitHub repo, they simply take the already built binary from Ubuntu 20.04 and repack it into AppImage format. And it appears to be incredibly hard (too hard to accomplish if I read their response correctly) to query QDirStat's version number from that .deb package. I am at a loss for words. |
QDirStat AppImage
TL;DR
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
bzip2results 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:
Okay, so let's download that thing and try to look inside.
Downloading and Starting the AppImage
After downloading:
Yikes. Compared with the freshly compiled binary:
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:
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:
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
Okay, let's give that a try:
In a new shell window (because this one is now busy keeping that image mounted):
Yikes. Unpacking that AppImage takes 586 MB!
Adding insult to injury, they packaged QDirStat 1.6.1 which was released on 2020-02-13, i.e.
1628 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.
The text was updated successfully, but these errors were encountered: