Flatpaks, Snaps, AppImage - Oh My!

Posted by JD 05/05/2019 at 03:18

I haven’t been a fan of snaps since the beginning. Why? Because they include all the dependencies in the install packages, AND those package versions are only used by the single snap/flatpak/appimage, the amount of waste is huge.

Snaps also have restrictions for which storage can be accessed. Snaps usually allow access to HOME and stuff under /media/, but nowhere else.
No, you can’t access NFS storage or CIFS storage that is mounted elsewhere.
No, you can’t access /tmp/.
I’ve found no way to override the compiled-in limitations.

How much disk and RAM waste is involved? An example, is the vidcutter tool. Normally, I’d use mkvmerge —split parts: to accomplish simple cutting, but sometimes a GUI is handy. The cuts will be on GOP boundaries anyway, so it isn’t like this is frame-accurate.

This is the flatpak pulled on 2019-05-03 – here are the contents and sizes:



        ID                                        Arch   Branch Remote  Download

 1. org.kde.Platform                          x86_64 5.12   flathub < 425.0 MB

 2. org.freedesktop.Platform.GL.nvidia-415-27 x86_64 1.4    flathub  < 69.0 MB

 3. org.freedesktop.Platform.html5-codecs     x86_64 18.08  flathub   < 2.9 MB

 4. org.kde.Platform.Locale                   x86_64 5.12   flathub < 333.9 MB (partial)

 5. com.ozmartians.VidCutter                  x86_64 stable flathub  < 32.7 MB

So, in order to install, then run this 33MB application, I have to pull 800+MB of stuff down. Ok, disk space is cheap – well – mostly, unless you are using a chromebook with only 16GB of total storage. What’s the big deal?

I’m writing this as I wait for the 1GB to be downloaded from the flatpak repo. It is slow – 150-ish Kb/s. Looks like I get to wait another 15 minutes. The install command is:
$ sudo flatpak install flathub com.ozmartians.VidCutter

RAM use, that’s my real issue. I’ve been buying computers with 2G and 4G of RAM for a long time. My normal ‘desktop’ has 3GB of RAM usually. Because I don’t use KDE – not that it would matter, snaps/flatpaks use the included version, not the already loaded version anyway – so at least 450MB of RAM will be used for this 33MB application.

Still waiting for the downloads to finish.

I mostly run Ubuntu systems here, but I’ve learned that purging all snap infrastructure is a smart idea to prevent undesirable side-effects to my systems. I’m hoping that flatpaks will be better about their default restrictions, and cgroup limitations. If they block access to USB storage, where lots of people storage lots of their data, that is a huge mistake. Snaps block access to USB storage, at least the few I’ve seen do.

So the downloads finished, but vidcutter wasn’t put into the PATH.
$ which vidcutter
Guess I need to look for the magic incantation to get it running?

$ /usr/bin/flatpak  run com.ozmartians.VidCutter

qt.qpa.xcb: could not connect to display 

qt.qpa.plugin: Could not load the Qt platform plugin “xcb” in "" even though it was found.

This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.


Available platform plugins are: eglfs, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

And it doesn’t work. I thought the point of all this was for code to work no matter what? Chromium, thunderbird, and every other GUI application works fine, just this first flatpak doesn’t. I suppose it could be a KDE issue, but I’m betting wayland is the problem.

My DISPLAY is set and working perfectly.

$ env|grep DISP

DISPLAY=localhost:10.0

I don’t use Wayland. I use X11. Maybe I need to reboot? I missed the weekly approved maintenance period.

Looks like I’ll be using mkvmerge for this for a while longer.

Snaps are not all bad. For high-risk programs like a web browser or full email client, having the added protection of a snap sandbox would be helpful for average users, provided they have sufficient RAM and storage. Until forced, I’ll keep running my browsers inside a firejail sandbox where I can control which storage can be used.
I think there is a way to force snaps into development mode so that storage anywhere can be used. Haven’t tried this fix yet.

My highly limited looks at AppImages and Flatpaks shows that some are larger, some smaller, most are less resource intensive, and I haven’t seen any mention about mandatory sandboxing.

But I could be wrong.

Update: 2020-03-11

$ /usr/local/vidcutter-appimage/VidCutter-6.0.0-x64.AppImage 

Could not initialize GLX

Aborted (core dumped)

It’s broken. Thought that wasn’t possible. The exact file worked for a few weeks. The system is crazy stable. No major changes between the failure and when it worked. Normal weekly patches only.