Hello friends
I have the intention to install HTTPie to be used in Terminal as client.
Well exists the Desktop GUI client too and to install httpie desktop in Linux the approach is through AppImage
Do you have experience with AppImage?
I’ve used different versions of Python that are AppImage format.
They seemed to work well. I can’t think of any other time I’ve used AppImage. Snaps and flatpaks are what I generally use.
2 Likes
Hi Manuel,
I use a lot of programs distributed in AppImage.
What help do you need?
Jorge
3 Likes
Do clarify what kind of help you are looking for.
You can also refer to: How to Use AppImage in Linux [Complete Guide]
3 Likes
Thanks to all for the replies.
My main concern was if is trustable and fast. I remember in other post I requested some help about snap and 1 or 2 persons indicated me to avoid it, but never gave the reason.
It is the reason I wrote this post as a general question.
Thanks for your understanding
1 Like
Hi Manuel, 
I certainly prefer appimages over snaps.
The reason for that is that - unlike snaps - appimages can be run in a firejail sandbox.
There´s a dedicated option for that: --appimage .
So appimages can certainly be run in a more trusted way.
E.g.: here´s my command for running cool retro term in a closely restricted environment:
cd /media/rosika/f14a27c2-0b49-4607-94ea-2e56bbf76fe1/DATEN-PARTITION/Dokumente/Ergänzungen_zu_Programmen/zu_cool-retro-term/; and firejail --profile=/etc/firejail/default.profile --appimage --private=(pwd) ./Cool-Retro-Term-1.1.1-x86_64.AppImage; and cd
Cheers from Rosika 
3 Likes
Hi Manuel,
I’ll give you my personal opinion and I’d be grateful if forum users could correct me if I’m wrong.
“Trustable”
How can we decide if a program is “trustable”?
What I do: I usually only use releases from GitHub, try to find out if there is information about the program I want to use, always take into account the “stars” of the program and whether it has the checksum of the AppImage version.
After downloading, I always check the program’s checksum. However, I use programs that don’t have checksum information (I also take risks…)
“Fast”
A program in AppImage format is “portable”, i.e. it comes with all the libraries and the like, so it’s a program that doesn’t depend on the distro you have or the versions of certain libraries you have installed.
In my opinion, it might be slower to start up, for example, the same program but in deb package format, and it might use a bit more memory (I’ve never checked), but on the other hand, if the program has libraries that you don’t have installed or that are newer than those in your distro, the program in AppImage format will always run.
In my opinion, some programs are slower. For example, it’s because they’re made in Electron and take longer to load than others, but that’s just my opinion.
A practical example of what I think about AppImage - The Joplin program:
- It has 42.7k stars
- It has 598 contributors
- 333 releases
- Has a SHA-512 checksum to ensure the integrity of the AppImage file
Is it reliable?
I think so
Is it trustable?
Again, I believe so.
Is it fast?
On my PC it takes a while to boot up, but then it’s fast.
On Android, it used to be slow, but now it’s very fast.
Is it reliable?
I think so
Is it reliable?
Again, I believe so.
Is it fast?
On my PC it takes a while to boot up, but then it’s fast.
(On Android, it used to be slow, but now it’s very fast.)
In short, and as I said in the previous post: I use a lot of programs in AppImage format, but I don’t always follow these rules because it’s not always possible, for example, to confirm the checksum, and I decide to take some risks and use the programs I really want to use.
As far as the “garbage” left by AppImages on the system is concerned, as far as I’ve noticed, it’s very little - in ~/.config, I think also in ~/.local/Share (I’m not at my PC…) and not much else.
The AppImages programs are placed in ~/AppImages
I don’t know if this post addresses what you want to know
EDIT:
Please read Rosika’s post regarding security issues (she wrote it when I was writing my post)
Jorge
3 Likes
They for one take too much room up, are not good where security is concerned, lots of malware found over the years, they break or never work properly.
2 Likes
There are a few apps I use that come as appimages. I’m careful to make sure that the appimage comes directly from the apps’ vendor (not some third party), or the Appimage Store.
In my experience, the Appimage apps I’ve used work well, and seem to be stable. I’ve had no complaints or issues with them.
Ernie
3 Likes
Hi all,
I noticed the security aspect seems pretty prominent here. At that´s certainly justified.
Please correct me if I´m wrong, but as far as I know one has to make an appimage executable for it to work:
chmod a+x NAME_OF_FILE.AppImage (see here).
So, wouldn´t it be beneficial to run an appimage without having to do that?
And indeed it can be done.
I don´t want to over-advertise the firejail sandbox, but once again it comes in handy in this case:
Running an appimage within firejail is possible without its need to be executable. 
rosika@rosika-Lenovo-H520e /m/r/f/appimages> ll kgw_Geany-1.24.1-x86_64.AppImage
-rw-rw-r-- 1 rosika rosika 6,5M Apr 19 13:14 kgw_Geany-1.24.1-x86_64.AppImage
and…
cd /media/rosika/f14a27c2-0b49-4607-94ea-2e56bbf76fe1/appimages/; and firejail --net=none --appimage ./kgw_Geany-1.24.1-x86_64.AppImage; and cd
Reading profile /etc/firejail/geany.profile
Reading profile /etc/firejail/allow-common-devel.inc
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc
Warning: networking feature is disabled in Firejail configuration file
Parent pid 9486, child pid 9487
** Warning: dropping all Linux capabilities and setting NO_NEW_PRIVS prctl **
Mounting appimage type 1
Child process initialized in 141.44 ms
/run/firejail/appimage/AppRun: ./lib/libselinux.so.1: no version information available (required by /lib/x86_64-linux-gnu/libgio-2.0.so.0)
/run/firejail/appimage/AppRun: ./lib/libselinux.so.1: no version information available (required by /lib/x86_64-linux-gnu/libmount.so.1)
It works:
… and shutting down doesn´t produce any errors:
Parent is shutting down, bye...
AppImage detached
rosika@rosika-Lenovo-H520e ~> echo $status
0
Many greetings from Rosika
3 Likes
Hello friends
Huge thanks to all for your time and feedback provided, pls give me some days to reply each answer.
Thanks for your understanding
2 Likes
Hello Friends
Again huge thanks for the replies. As I indicated… Here I go
pdecker
I’ve used different versions of Python that are AppImage format.
They seemed to work well. I can’t think of any other time I’ve used > AppImage. Snaps and flatpaks are what I generally use.
Thanks, ok. only one scenario as would be for me for HTTPie
Rosika
I certainly prefer appimages over snaps.
The reason for that is that - unlike snaps - appimages can be run in afirejailsandbox.
Thanks for that info - now I have other topic to research, firejail 
There´s a dedicated option for that:
--appimage.
Can you expand a little more the idea?
So appimages can certainly be run in a more trusted way.
Good to know that
E.g.: here´s my command for running cool retro term in a closely restricted environment:
Thanks for the command share - impressive about the screenshot … since 80s I haven’t saw the wonderful orange text color 
Tech_JA
I’ll give you my personal opinion and I’d be grateful if forum users could correct me if I’m wrong.
Agree, it is a friendly forum
“Trustable”
How can we decide if a program is “trustable”?
In my case, have zero risk about to get any kind of security leak. I know it is a hot topic. But it is the main idea. Furthermore, avoid to get any crash of the software itself (and OS too).
What I do: I usually only use releases from GitHub, try to find out if there is information about the program I want to use, always take into account the “stars” of the program and whether it has the checksum of the AppImage version.
Good approach too. I am agree
After downloading, I always check the program’s checksum.
So do I
However, I use programs that don’t have checksum information (I also take risks…)
I would take that risk in a controlled environment, such as the OS running through VirtualBox
“Fast”
A program in AppImage format is “portable”, i.e. it comes with all the libraries and the like, so it’s a program that doesn’t depend on the distro you have or the versions of certain libraries you have installed.
Sounds great, and I hope see someday there Adobe Reader PDF to run it quickly and in peace in Linux.
In my opinion, it might be slower to start up
A fair trade off I think, it is like “snap” and the same as macOS.
for example, the same program but in deb package format, and it might use a bit more memory (I’ve never checked), but on the other hand, if the program has libraries that you don’t have installed or that are newer than those in your distro, the program in AppImage format will always run.
I understand
In my opinion, some programs are slower. For example, it’s because they’re made in Electron and take longer to load than others, but that’s just my opinion.
Interesting that situation
Thanks for the “Joplin” feedback and experience
As far as the “garbage” left by AppImages on the system is concerned, as far as I’ve noticed, it’s very little - in ~/.config, I think also in ~/.local/Share (I’m not at my PC…) and not much else.
If the impact is minimum I am fine. I am assuming there is something similar as sudo apt autoremove.
Question
How is your experience about update of AppImage itself and any software installed through it? In you case for example Joplin
The AppImages programs are placed in ~/AppImages
Thanks for that point
I don’t know if this post addresses what you want to know
Experience is key to have an idea about what to expect. Thanks for your detailed feedback
Mark
They for one take too much room up, are not good where security is concerned, lots of malware found over the years, they break or never work properly.
If it is about snap interesting. I am only using Firefox and Drawio
ernie
There are a few apps I use that come as appimages. I’m careful to make sure that the appimage comes directly from the apps’ vendor (not some third party), or the Appimage Store .
Thanks for that point
In my experience, the Appimage apps I’ve used work well, and seem to be stable. I’ve had no complaints or issues with them.
Thanks for that feedback
Rosika
About your second post. I see … but if my memory does not fail in the HTTPie docs exists indications to execute the tool itself. It seems it would vary according each tool installed in AppImage. So far I have zero knowledge about AppImage. Soon as I can I would share some feedback.
Thanks to all for your time and replies. Sorry by my delay. A cold beer to all 
2 Likes
Are you saying that an Appimage is a statically compiled binary?
1 Like
More than just that. They also seem to have their own filesystem.
2 Likes
Hi Neville,
I’m going to answer your question by asking you to do the following, please:
download a program in AppImage, for example, Joplin-2.14.20.AppImage (at the moment, it’s the current version) , because that’s what I’ve been using as an example.
Create a folder, put the program there, in the terminal, change the directory to the the forder you created and run the following command:
chmod +x Joplin-2.14.20.AppImage
and after:
./Joplin-2.14.20.AppImage --appimage-extract
A squashfs-root folder has been created. Enter this folder and look at the contents of AppImage
If you’re interested in seeing more AppImage options, go back to the folder where you have the Joplin AppImage and type the following command:
./Joplin-2.14.20.AppImage --appimage-help
in a nutshell:
AppImage is s format that aims to allow the installation of binary software independently of specific Linux distributions. As a result, one AppImage can be installed and run across Ubuntu, Arch Linux, and Red Hat Enterprise Linux without needing to use different files. It aims to be a format that is self-contained, rootless, and independent of the underlying Linux distribution.
source: Wikipedia
I hope I was able to answer your question.
More info about AppImages: https://docs.appimage.org/introduction/index.html
Jorge
2 Likes
Hi Manuel,
Excuse my question, but why Adobe Reader?
There are programs in the AppImage format that already update automatically, such as Bitwarden.
I believe there are programs for managing AppImages, but I like to do everything manually, so I can’t help you with this matter.
The procedure I’m about to mention is personal
The other programs I use that don’t have automatic updates, I usually follow the following procedure, again for Joplin:
- I always follow the programs on GitHub, under Custom → Releases
Step 1:
Step 2:
Step 3:
Whenever an update comes out for the programs that I set to Watch-> Custom → Release, I receive an email from GitHub informing me of the update to the program in question.
Just an example of a GitHub email notification of an AppImage release:
(The following email example is for Lapse, because I’ve already deleted Joplin’s email)
Next, I go to GitHub, download the AppImage and the checksum if it has one and, if it has a checksum, check that it’s correct
Make the AppImage executable and, in the case of Joplin, place it in the ~/AppImages/Joplin folder.
Usually, in each folder where I place the AppImage file, I have created a text file with nothing written in it and, when I copy the AppImage file, I copy the name of the AppImage to the name of the text file and change the name of the AppImage to just the name of the program, deleting the version that appears in the name of the program. I do this so that I know immediately which version I have installed, without running the program, and as I use .desktop files, the names are stantadrized, i.e. I don’t need to edit the .desktop files.
example of ~/AppImages/Joplin folder":
The icons of the programs in AppImage format, I get them from GitHub, or extract from AppImage, as I explained in the post above, in the reply to Neville and put them in the ~/.icons folder.
For each program in AppImage format (almost all of them), I have created .desktop files in the ~/.local/share/applications folder.
I hope I’ve answered your question
Jorge
Hi Manuel,
You´re very welcome. 
Well, when you run an appimage using the --appimage option with firejail, it essentially allows you to run the appimage within a secure sandbox environment.
This means that the appimage is isolated from the rest of your system, reducing the risk of it causing any harm or interfering with other applications or files on your computer.
Think of it as putting the appimage in its own protective “bubble”, keeping your system safe while you use it. 
I´m glad you like the screenshot of Cool-Retro-Term.
In fact you can choose an output colour of your liking. You might like to take a look at it here.
As far as the topic making the appimage executable is concerned:
When you run an appimage within firejail, firejail itself handles the execution of the appimage.
Firejail doesn’t rely on the execute permission of the appimage file because it’s not directly executing the file in the traditional sense.
Instead, firejail creates a secure environment and then launches the appimage within that environment, bypassing the need for the execute permission.
This allows you to run the appimage securely without having to manually set the execute permission on the file.
I did some research on this specific topic some while ago, as I myself was interested to know why that is.
Hope it helps.
Many greetings from Rosika
3 Likes
Hello Jorge
Excuse my question, but why Adobe Reader?
It to have a straight/easy approach to install it in peace in Linux. Such as your other situation about MS Office. I mean avoid use for example wine or other approaches.
There are programs in the AppImage format that already update automatically, such as Bitwarden.
I believe there are programs for managing AppImages, but I like to do everything manually, so I can’t help you with this matter.
Thanks for the info … if is manual such as something like apt I am fine with that approach and to be honest I do this kind of update manually too,
The procedure I’m about to mention is personal
Huge thanks for that detailed feedback. Noted
Hello Rosika
You´re very welcome.
Well, when you run an appimage using the --appimage option with firejail, it essentially allows you to run the appimage within a secure sandbox environment.
This means that the appimage is isolated from the rest of your system, reducing the risk of it causing any harm or interfering with other applications or files on your computer.
Think of it as putting the appimage in its own protective “bubble”, keeping your system safe while you use it.
Huge thanks for the expansion. 
I´m glad you like the screenshot of
Cool-Retro-Term.
In fact you can choose an output colour of your liking. You might like to take a look at it here.
Again, huge thanks it brings me a good memories
Huge thanks for the feedback about Firejail
I did some research on this specific topic some while ago, as I myself was interested to know why that is.
I think like you, I do a research about to tool prior to install and to know at a first glance how it works.
Thanks to Jorge and Rosika for your time and polite support.
To all friends
Just to share: I am not sure if AppImage is similar about to have the same logic as Docker. It because the latter works with images and well the image term appears in AppImage. Perhaps a simple coincidence.
3 Likes
Hi Manuel,
From what I know about Docker, I can’t compare the concept of AppImages to Docker.
As I see it, Docker runs the programs in an isolated system and each one has its own operating system for each container.
I know what you mean, but for me, the closest thing to AppImages are Windows portable apps, which are just a single executable program files and the apps run without being installed.
Jorge
2 Likes
Yes, a docker container has to have an OS, but it can be a minimal one like Alpine.
If you want an app in a container without an OS, you can use
firejail.
3 Likes