Flatpak Is Not the Future

Tolkem

Well-Known Member
Joined
Jan 6, 2019
Messages
1,567
Reaction score
1,284
Credits
11,462
Hi everyone! Hope you're all having a nice life! :)

I just bumped into this post while checking my feed https://ludocode.com/blog/flatpak-is-not-the-future
An excerpt:
Deploying apps for the Linux desktop is hard. A major problem has historically been library compatibility. Different Linux distributions, and even different versions of the same distribution, have had incompatible libraries. Unfortunately, there hasn’t always been a culture of backwards compatibility on the Linux desktop .... The current solutions involve packaging entire alternate runtimes in containerized environments. Flatpak, Snap, AppImage, Docker, and Steam: these all provide an app packaging mechanism that replaces most or all of the system’s runtime libraries, and they now all use containerization to accomplish this.
The author makes some valid points, and I agree with some of them, specially those regarding flatpak and snaps(haven't used docker or steam). However, I do disagree in others, like his claim that
All of the desktop integration (launcher entries, mimetypes, icons, updates) is provided by either appimaged or AppImageLauncher, one of which must be installed by the user for any of this to work. So in practice, AppImage is no different than any of our other solutions: it requires a service to be usable. If a user doesn’t have the service, well that’s another hoop they have to jump through to install an app.
Not true. Appimages don't require(as in mandatory)any service to be usable. I use 20+ appimages, and I've never had the need for a "special" service, yes, these solutions exist for people that want this to be done "automagically", but you can integrate appimages in your system just as easily, and in fact, most desktop environments provide the means to do so, with one exception(that I know of): Gnome. Maybe that's what the author use, thus his complaint, given he uses fedora which ships with it.
 


Appimages are way better than snaps. I've not used flatpak as it requires installing something. Snaps are a nightmare that I wouldn't go back to. I am sure some are useful but forcing stuff like chromium on people as a snap when it exists as a .deb, or the non-sensical drive to move system components to snap packages is Microsoft-esque. Snap rant over.

I presume you cannot create a .desktop file in gnome?

Indeed appimages don't require a "service" to be usable, although I think they work better once they are integrated into the system, especially with plank. It's a bit much referring to it as a service though, I created a bash script yesterday that downloads and "installs" an appimage yesterday. All I need to do manually is source a 256x256 png file.

Even an automatic updater of appimages could be written as a simple script and set to run at start up. Along with the installer it totals about 20 lines of code.

If those are "services" then I am a developer.
 
I presume you cannot create a .desktop file in gnome?
Yes, you can, the problem is it doesn't work, or at least it didn't in Gnome 40, don't know if it does in 41.
I created a bash script yesterday that downloads and "installs" an appimage yesterday. All I need to do manually is source a 256x256 png file.
I've been working into something similar; a script that checks for newer versions and download them, but I still haven't figured a few things out, for instance, for those I've downloaded from GitHub, I can use the GitHub API, but for others that I got from another source, I'm a bit stuck with. As for icon files, you can just extract the appimage
Code:
./appimage_name.Appimage --appimage-extract
this will extract the contents into a folder named squashfs-root, you'll find the icons within it, that's what I do. Note that this works if the appimage has been created with the latest toolkit, which most have. Maybe we could work together and have that script working. :)
This is part of the script I use:
Code:
curl -v -i https://api.github.com/repos/laurent22/joplin/releases >> appimages.txt && cat appimages.txt | grep  Joplin-2.\*.AppImage
What this line does is check the repo for new releases, and save the results to a .txt file, then another function reads the file, grep the latest release, call aria2 which is what I use to download stuff, and save the file to my ~/Appimages folder. It's not perfect, tho, but it gets the job done. :)
Even an automatic updater of appimages could be written as a simple script and set to run at start up.
Well, there's actually this https://github.com/AppImage/AppImageUpdate but in my experience it doesn't work with every appimage out there, just a few ones, and for those it does, the update process is real fast, since it only downloads new information, not the whole thing.
 
Yes, you can, the problem is it doesn't work, or at least it didn't in Gnome 40, don't know if it does in 41.

I've been working into something similar; a script that checks for newer versions and download them, but I still haven't figured a few things out, for instance, for those I've downloaded from GitHub, I can use the GitHub API, but for others that I got from another source, I'm a bit stuck with. As for icon files, you can just extract the appimage
Code:
./appimage_name.Appimage --appimage-extract
this will extract the contents into a folder named squashfs-root, you'll find the icons within it, that's what I do. Note that this works if the appimage has been created with the latest toolkit, which most have. Maybe we could work together and have that script working. :)
This is part of the script I use:
Code:
curl -v -i https://api.github.com/repos/laurent22/joplin/releases >> appimages.txt && cat appimages.txt | grep  Joplin-2.\*.AppImage
What this line does is check the repo for new releases, and save the results to a .txt file, then another function reads the file, grep the latest release, call aria2 which is what I use to download stuff, and save the file to my ~/Appimages folder. It's not perfect, tho, but it gets the job done. :)

Well, there's actually this https://github.com/AppImage/AppImageUpdate but in my experience it doesn't work with every appimage out there, just a few ones, and for those it does, the update process is real fast, since it only downloads new information, not the whole thing.

Ha ha - I was learning bash scripting for the first time yesterday while I was doing so I am not sure I would be the best person to help!

I had a feeling the icon is in the appimage as it shows up when you run it, but extracting something like Chromium would be more hassle than its worth.

As for updates I only have stuff from apprepo so I will need to check out appimageupdate to see if it works. If so I suppose it will work for all their apps. They actually have their own app too but I don't think it supports automatic upgrades. I was only really coding for the sake of learning.

Do you have any idea how AppimageUpdate only downloads new information?
 
As for updates I only have stuff from apprepo so I will need to check out appimageupdate to see if it works.

Surprisingly easy to try but unfortunately it didn't work. I might contact the guy to see if he'll put up a file with a list of the apps and their respective hash/or last update time. Then I could check against that simply enough and download the new file.

I am very intrigued by the possibility of downloading just the new bits.
 
Do you have any idea how AppimageUpdate only downloads new information?
It uses zsync http://zsync.moria.org.uk/
zsync is a file transfer program. It allows you to download a file from a remote server, where you have a copy of an older version of the file on your computer already. zsync downloads only the new parts of the file.
I looked into it when first started writing my script, to see what I could learn from it. I tried using zsync, but it didn't work as expected, probably need to read more and run a few more tests. It'd be nice to be able to download only the necessary information instead of the whole file, problem is, the appimage itself needs to have that info embedded in order for zsync do its job, that's why appimage update doesn't work with every single one.
I might contact the guy to see if he'll put up a file with a list of the apps and their respective hash/or last update time.
I think you should contact the appimage developer(of the appimage you want to update)and ask him/her to include that info in the app.
Ha ha - I was learning bash scripting for the first time yesterday while I was doing so I am not sure I would be the best person to help!
Oh, I'm not an expert myself, nor I'm a coder. I know a few things and thought I could put this together since I use appimages. Oh, there's also this https://github.com/Nitrux/nx-software-center
Fun fact: You can't use AppimageUpdate to update AppimageUpdate lol
EDIT: I just downloaded the new version for AppimageUpdate and it replaced the old one, it was only a couple of seconds.
EDIT2: Something should've gone wrong because AppimageUpdate doesn't work, I'm downloading again.
 
Last edited:
Hi everyone! Hope you're all having a nice life! :)

I just bumped into this post while checking my feed https://ludocode.com/blog/flatpak-is-not-the-future
An excerpt:

The author makes some valid points, and I agree with some of them, specially those regarding flatpak and snaps(haven't used docker or steam). However, I do disagree in others, like his claim that

Not true. Appimages don't require(as in mandatory)any service to be usable. I use 20+ appimages, and I've never had the need for a "special" service, yes, these solutions exist for people that want this to be done "automagically", but you can integrate appimages in your system just as easily, and in fact, most desktop environments provide the means to do so, with one exception(that I know of): Gnome. Maybe that's what the author use, thus his complaint, given he uses fedora which ships with it.
Yep I agree AppImages do not require additional installs to work - unlike Snap or Flatpack - only have to give it permission to run
 
I use a couple of Appimages here and have not problems on Cinnamon integrating them into the system. Tried snaps early on and found them to be a mess. Only ever tried on Flatpack didn't care for it either.
 
This is what I was talking about
1638129492527.png

I tried updating Joplin, but AppimageUpdate complains with the message you can read in the pic above.

Here's another error. This is why I'd really like to try and put my own solution together, so I can get updates for those I use without having to launch a web browser, visit the website, and download the new version. Instead, I want to just run a command that calls some function that does that for me. I think am getting close, but not close enough, for instance, I can't get that script working with LibreOffice.Appimage. https://libreoffice.soluzioniopen.com/stable-2/
1638129685846.png
 
Last edited:
It uses zsync http://zsync.moria.org.uk/

I looked into it when first started writing my script, to see what I could learn from it. I tried using zsync, but it didn't work as expected, probably need to read more and run a few more tests. It'd be nice to be able to download only the necessary information instead of the whole file, problem is, the appimage itself needs to have that info embedded in order for zsync do its job, that's why appimage update doesn't work with every single one.

I think you should contact the appimage developer(of the appimage you want to update)and ask him/her to include that info in the app.

Oh, I'm not an expert myself, nor I'm a coder. I know a few things and thought I could put this together since I use appimages. Oh, there's also this https://github.com/Nitrux/nx-software-center
Fun fact: You can't use AppimageUpdate to update AppimageUpdate lol
EDIT: I just downloaded the new version for AppimageUpdate and it replaced the old one, it was only a couple of seconds.
EDIT2: Something should've gone wrong because AppimageUpdate doesn't work, I'm downloading again.

Yeah even if you managed to make zsync file for existing appimages, you'd need to download the new file to create a zsync for that which would somewhat defeat the purpose!

I presume the zsyncfilemaker works on the Appimage which I suppose is more like a gzip or iso than a deb package.

----

Why did you say you are you stuck in your script with ones you get from another source? Do you mean just normal websites rather than APIs? You can get HTTP headers to see the last modified date of the download with curl -I
 
This is what I was talking about
View attachment 11004
I tried updating Joplin, but AppimageUpdate complains with the message you can read in the pic above.

Here's another error. This is why I'd really like to try and put my own solution together, so I can get updates for those I use without having to launch a web browser, visit the website, and download the new version. Instead, I want to just run a command that calls some function that does that for me. I think am getting close, but not close enough, for instance, I can't get that script working with LibreOffice.Appimage. https://libreoffice.soluzioniopen.com/stable-2/
View attachment 11005

Updating Joplin​

If you would like to update to a new version, simply download the new Joplin AppImage. From their website - https://appimage.github.io/Joplin/
so I am thinking they did not include the AppImage updater when they built the AppImage
 
You can get HTTP headers to see the last modified date of the download with curl -I
This is what I get with curl -l
curl: (23) Failure writing output to destination
In case that's a capital "i" and not an "l", I tried with that too, and this is what I got
curl -I https://libreoffice.soluzioniopen.c...breOffice-fresh.standard.help-x86_64.AppImage
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 359M 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0
HTTP/1.1 200 OK
Date: Mon, 29 Nov 2021 05:16:18 GMT
Server: Apache/2.4.29 (Ubuntu)
Last-Modified: Fri, 20 Aug 2021 18:04:58 GMT
Which doesn't really tell me much.
If you would like to update to a new version, simply download the new Joplin AppImage. From their website -

Yeah, that's what I do, by using my script. What I want to avoid is the need to launch a browser. I'm aware of links(which I actually use), lynx and the likes, but those have their own caveats.
Neat little update script.

This doesn't work with appimages. Flatpaks and snaps have their own update mechanism.
 
Yep I agree AppImages do not require additional installs to work - unlike Snap or Flatpack - only have to give it permission to run

Sometimes you don't even need that.

Two examples I use are for Waterfox Browser and for Balena Etcher.

Neither needs to be chmodded or changed in your FM, they both just run.

Interesting thread.

Cheers

Wiz
 
Nothing has to be the future, there can be several options to work with. Thank goodness we have choice!
 
In case that's a capital "i" and not an "l", I tried with that too, and this is what I got

Which doesn't really tell me much.

Well it tells you the last modified date which is what you are looking for. You can see it hasn't been modified since August.
 
Well it tells you the last modified date which is what you are looking for. You can see it hasn't been modified since August.
Yeah, I did see that, but still, man curl tells me that
-I, --head

(HTTP FTP FILE) Fetch the headers only! HTTP-servers feature the command HEAD which this uses to get nothing but the header of a document. When used on an FTP or FILE file, curl displays the file size and last modification time only.
Oh, just re-reading that now that I pasted it here, think I understand how to use that info. I don't use curl much, so excuse my ignorance. Thanks! :)
 

Members online


Latest posts

Top