Hey DT The origin is from when Ken Thompson and co originally wrote Unix. /usr Was originally the User Directory, however they ran out of space on their machine, so they made /home /usr now gets used almost like a "Program Files" directory on windows, however it was only ever supposed to be for user files
I never use Snaps or Flatpaks. I highly prefer AppImages as they are fully contained environments for the application (version mis-matches begone), but without the overhead of daemons running etc. For once I completely agree with your regarding the topic of this video. Keep up the good work!
This only works because you already had it compiled on your system, so you have the dependencies. It may run on other distros, however it will never run on a system with older libc. There is a reason "official" AppImages are built against CentOS 6 : libc is backward compatible, but not forward compatible.
@@notuxnobux That's not true at all. Any AppImages built statically won't experience this issue, and building against an older distro doesn't make it useless.
When I first got into Linux, I found appimages pretty quick, and thought it was super cool and simple, and wondered why everything can't be an appimage, I then realized how easy it is to manage stuff with a package manager (I was still new to pretty much everything) and so didn't think about it too much anymore... Now that I see how easy they are to actually make, I'm starting to wonder again...
So the executable is linked to only static libraries? Of course, it will work on the system where it was built! I would like to see it installed on a Linux system that may have different versions of shared libraries installed than yours.
Appimages are very useful for people on static release distros and is probably the one format on Linux that makes it easy to run older versions on software on a machine that is offline.
I think the best reason to use AppImages is to isolate manually compiled Apps from the system. Just think about it. When you build an App manually and then install it with 'cmake install' or something, it gets mixed up with the system files. You can install that app to a temporary directory with 'cmake install destdir=temp.AppDir prefix=/usr' or something, then package that directory as an AppImage, and then use that AppImage without having to ever mess with your system.
Exactly... Another great example would be Wine. If you have a running 64bit system, there are cases in which you DON'T want to introduce slower lib32 libraries to your system. Wine needs lib32 architecture to run most of the Windows prefix executables (vbruns, ttf installs, etc). AppImages would allow you to install Wine along with an Exe without having to have all that bloat(slower lib32 architecture) installed on your system- it would only run in memory while the AppImage ran, and would just vanish when the program stopped.
You should really look into using the standalone Nix package manager (especially, flakes). It’s repos are quite comprehensive (the NUR even more so), it works cross-system (even MacOS and maybe BSD) and packaging things yourself is not bad (Nix expressions are a lot like Haskell, and it gets easy with time). The new Flake system makes it quite easy to host your Nix-related files on Git (packages can be downloaded directly from git repos using the new style commands, and anything defined by a flake including NixOS systems and Nix libraries can be included by other flakes).
Yeah, it's simple for single stand alone binaries. I've spent a couple of days trying to create an appimage of a program I had to build from source, along with several libraries I also had to build from source due to different (newer) versions of them than available in the current repositories. ldd shows me that the program is dependent on 147 other files. The appimage tool with the --generate flag is supposed to figure all of that out for you, but it crashes. So now I'm looking for tutorials that explain including all of the libraries the program also needs. How about a follow up tutorial that goes deeper down the rabbit hole and clarifies such a scenario? BTW, thanks for this one, it helped.
AppImage is the really way to make Linux much easier to everyone. Should be the standard for most distros. AppImage package creation can be fun and even tiring at same time, finding the errors on what are library files needed in order to launch it as stand-alone package.
As a developer, it irritates me that they should go to all the effort of explaining that you don't need the ".png" on your icon definition when it would have probably been less work just to accept the icon definition with or without the extension.
It is much easier than how it is shown in the video. You just need to put binary,desktop,icon file(s) in proper directories inside AppDir/usr and appimagetool will automatically create AppRun and other files needed to be placed directly in AppDir.
@@kendarr It depends on the files included in the AppDir. If they are binary files, they will only work on the systems with the same or newer version of GLibC that they were compiled on. It also depends on if all the dependencies of an application are included the AppDir or not. After trying to create an AppImage for a real application that I developed, I came to the conclusion that packaging a real application as an actually portable AppImage is not easy.
@@RealMazharHussain Thanks, I got curious after seeing a guy on YT packing a full wine version with a Windows game, and it worked just fine on my machine, I'm still very curious as to how to do that for a Photoshop app for example. In theory as long as the AppDir has all of the software dependencies it will work?, so I can to build a appimage and check what it says is missing and so on?, I might be way of track here lol
@@kendarr Yes, as long as the AppDir has ALL of the dependencies (and also, correctly set up environment variables), it should work. But it doesn't always say that a dependency is missing because it is available on the system that AppImage is running on. What it does is throw a random error message which you may or may not understand. Everything is about versions. As long as you are packaging an AppImage on an old system like Ubuntu 18.04 or something, everything should be fine. TLDR; As long as the AppImage has all the dependencies and correctly set up environment, it should work on the system it was packaged on, plus newer systems. E.g. AppImage packaged on Ubuntu 20.04 should work on Ubuntu 20.04 and newer, Debian 11 and newer, Linux Mint 20 and newer, Fedora 32 and newer, Arch Linux, Manjaro, etc. AppImage packaged on Ubuntu 22.04 would only work on Debian 12 (testing) and newer, Fedora 36 (beta) and newer, Arch Linux (no Manjaro). AND AppImage packaged on Ubuntu 18.04 should work on almost every distro.
@@AndersJackson I don't personally know how AppImages and Snap work under the hood (not yet, I'm doing my research), but Flatpak handles file deduplication and works more or less like git. There are some talks on youtube about it talking exactly why Flatpaks are efficient if used correctly. One I'd suggest is an interview made by Cassidy James Blaede from ElementaryOS, which shows why some assumptions about flatpaks are myths and misconceptions and how they can be lightweight and efficient.
@@daveshouldaine2520 The joke is that Gentoo is supposed to be neither fast, nor easy to setup or install anything in. (Usually requiring everything to be compiled from source.) Having something quick and pre-packaged that you can just download and use is the opposite of that. Now that I explained the joke, it's likely not funny to you. 🤣
@@sbrazenor2 anyways, thanks for explaining, I'm currently installing Gentoo alongside with Artix, last time I broke my grub and it didn't work well. So, I'm gonna be careful this time :)
The Nix-bundle project is another cool solution, it’s being integrated into the new Nix3-style command. It can convert Nix expressions into standalone executables, similar to AppImage, while still allowing for the use of Nix’s guarantees in system independence.
*BSD users using AppImage would have Bash because it's done through a Linux compatibility layer (basically WINE but for Linux). It requires kernel support and only the Linux kernel has support for it at the moment (also the executable being run is a Linux ELF, not a *BSD executable so it wouldn't work natively anyway). The Linux compatibility layers installs a small Linux system including tools like bash.
My issue with appimages is that you can't install them from the terminal and they don't integrate as typical packages. They also wouldn't appeal to a new user because they aren't as friendly as the shops you get with synaptic and pamac and other graphical package managers. I feel like there needs to be some sort of integration of appimages as well as some package managers (both graphical and non graphical) to search for and install them. Just my input personally.
@@hostgrady so then couldn't an installer just send it to bin with a config folder somewhere? I'm new to linux I don't mean to be asking obvious questions if that's what I'm doing
but the whole idea is that there is nothing to install. you can do it strictly from the terminal...its just a little harder- use curl or wget to download the AppImage, use chmod u+x to make it executable, and just run it from download directory. You could even add it to your path to make it easier to find.
Appimage is basically an archive with all the dependencies and a script to execute. The only noticeable differences from other packaging formats are that it is executable on its own and is self-contained with no dependencies to cause a dependency hell. The problem I see is that it is as safe as random .exe files from the internet in windows. And we obviously don't want 3 electron apps to take 3 instances of electron worth of space on a disk. Now if we want to wrap a binary with a bunch of docs/images, then it is indeed better to use an appimage.
Does the AppImage also contain the LibC which the binaries were compiled against? Because otherwise, how could this particular AppImage work with anything but the current libraries you used to compile the st binary with? Also: 1. usr does mean user. If I'm not mistaken, the default home directory on FreeBSD is still /usr/home/name. 2. How is a BSD user supposed to use a binary compiled for the Linux kernel?
Question for those who use appimages. Is there a package manager for appimages or a way to manage appimage updates? Or do you guys just manually grab new ones to update?
I believe that you have to download them manually, but there is a gui program that makes grabbing appimages easier. I also believe that many people's attraction to appimages comes from the fact that you don't have to update them while you are trying to an update. So you would get an appimage for all the programs that you don't want to update.
you have to manually go out and grab the new AppImage. However the program developer could write the program to check and tell you when one is available. I use the AppImage of LibreWolf(fork of FireFox), and it will tell you that there is a newer version out, and that you should go get it.
There is a graphical AppStore named App-Outlet that can download and update AppImages along with Snaps and Flatpaks. I think DT made a video on App-Outlet too.
fun trivia: USR stands for: Unix System Resources. It was then used by Linux and stands for: User System Resources. BIN is for storing binary files and the ETC really does stand for etcetera, where trivial stuff like startup, shutdown and admin files would go.
AppImages are nice, but they are going to be much larger than FlatPaks for example, because large libraries like GTK or Qt can't be shared between them.
Well that was great, thank you very much. Could you also show packing appimages including shared libraries? Do you think this could also work with wine-dependent applications?
i believe that appimages are the best solution, they are better than flatpaks and snaps. Ofc they are not perfect but the closest thing to minimal and easy to use, and NO NEED FOR DAEMON OR ROOT ACCESS
@@michaelcarnevale5620 right? i have everything i can put in an appimage as an image and it's very clean and portable, i can just copy paste my apps on any system and run them no need for root or installing anything
There is an appimage called *linuxdeploy*. It is truly the easiest way to compile all the dependencies, icon, desktop icon and it auto generates an apprun file and exports the AppDir to an appimage.
Thanks a lot for some clarity. Didnt know to just copy the binary from previously installed package (from repo). I am a little confused on that but for simple cases makes sense
Packaging is not enough. We need to know how to make an installer. How to install an app on a user's PC jsut like we did with InstallShield on Windows.
Рік тому
Hey DT, AppRun may simply be a symlink to your binary, or even better the binary itself (the .desktop file in AppDir does not seem to need an Exec= definition) ...in case you would want to debloat your appimage.
The 2 problems with AppImage are that every AppImage needs everything it depends on bundled with it or risk system dependence and the inability to integrate with the system (lacking a way to bundle default configs and other data files such as desktop entries).
These are not problems with just appimage, snap and flatpak also have same issue. Because they package apps as a system independent bundle, they need to bundle everything they need to run the app. Desktop entries and other integrated configs are actually available. in appimage, But it is up to distro developer to allow its integration. Mostly, Gnome has created issues when they decided to reduce accessibility to .desktop files. In all major linux distros (except solus) you can install a service called AppimageLauncher, which provide missing integration services. For me, I just mark it as executable manually and use menu-editor to create launcher entries. Somehow Appimage still generate smaller install size compared to Snap or Flatpak. It also has better system theme integration compared to snap and flatpak, while also maintaining similar level of isolation. And if you need even more sandboxed level of isolation, its integration with firejail is one of a kind. Appimage really needs more awareness. Snap and Flatpak has corporate marketing team behind them, but Appimage is truly a community project. Up until recently, The author ( probonopd on github ) personally helped app developers setup CI/CD build chain for AppImage for their app. He still actively responds to community queries.
Have you heard about appimaged? It integrates appimages with system seamlessly. And default config files are mostly created on first run of the AppImage. You can also browse an AppImage after running './app.appimage --appimage-mount' in order to copy the default config from it.
@@JandyCZ I wrote a python script for creating .desktop files. But in reality, I have rarely seen an appimage which doesn't automatically create one for its app.
@@AbhinavKulshreshtha I downloaded appimages from github mostly and none of them created .desktop entry. It's not a big problem for me tho, so I don't really find this inconvinient. sometimes I don't even want desktop entry for an app.
Hey DT! I don't know if you are joking. I thought that you wanted to promote freedom instead of bloated binary blobs ;) There is really no reason to have ordinary applications anywhere else than in the standard repositories of your distro. We don't want redundant and/or outdated libraries stuffed in every application. BUT, out of the three (snap, flatpak, appimages) appimages is the preferred, and it have its uses - for example: Proprietary software that you can't compile and link to your libraries, i.e. games or software that does not get updates anymore. //voluntary bald boomer
Maybe...if it worked. I couldn't get it work a couple weeks ago. Just a bunch of Python errors. So it's not something I would want to put on camera...I don't like trashing free and open source software.
Thanks for the good explanation! Any hint how I would go about packaging an app which requires a big number of dependencies? The app is in the AUR so it would be easy, if I could just install it and all its dependencies in a clean chroot using some AUR helper, but I couldn't find a way to do so, so far.
yeah Windows has a way of doing this called PortableApps, where you can just tote the executable around on a USB stick, stick it on a machine you want to use it on, and just pull out the USB stick when your done. Not really viable with Linux as you already have to be a user on a machine to be able to do anything...and it would try to leave dotfiles behind....
@@debianswami8204 exactly... I wish I could somehow have this on Linux. I read about ways but those don't work. Maybe with AppImage2.0 or something in the future.
@@debianswami8204 You can do that with AppImages too. Just make a directory with the name of your AppImage File + '.home'. For example, for Etcher.AppImage, I would need to create a folder named 'Etcher.AppImage.home' inside the directory where Etcher.AppImage is located. Then, All the config will be saved in this folder instead of user's home. Or you can run '/path/to/Etcher.AppImage --appimage-portable-home' and it will create that portable home folder for you.
Thanks DT for this tutorial, can you make a video on how to use pkgbuild to install stuff via pacman(for dependency convenience) for stuff that is not natively supported for arch(like some companies provide rpm packages for their product drivers) ?
After Creating the AppImage I am getting the following error: execv error: No such file or directory. What could be the problem? Is there a problem in making the directory structure and also the dependency is on Qt
Hey DT! Is there a way to quickly transfer your files and configs and apps from one distribution to another? I fucked up my boot partition on another drive that had Manjaro installed when I tried to install Garuda.
Obly problems are they don't work on musl (most of the time?). Also I packaged an AppImage of something on my system and sent it to a friend, but they couldn't run it because there GlibC was too old.
Asking here first. Not ready to do it yet, but can you talk more about creating .debs and .msis, but .msis should be using non microsoft tools. It should be for linux mint and windows 10, respectively. So far, ive gone with .zips on both platforms, because its for sure, easy and free. But i want to learn, for when im finally ready.
2:33 Haha this is interesting... I keep hearing different things on the meaning of "usr" . People say it means "user," other, people say it means "Unix System Resources" (etc.), and both sides are absolutely sure that the other is wrong.
Good video DT. If you, or anyone else here, is interested in seeing an AppImage in action, I have an open source project which uses them. It's called fractorium (dot com) and the project is hosted on bitbucket. We had to use it in a somewhat non-standard way: it needed to be a self contained executable like you demonstrated, but also needed to perform some install steps to place config files on the system. It also had to be able to run several command line programs contained within, which accept command line arguments. If you look at how we did it, you can see that we were able to accomplish all of this using AppImage.
I always have trouble using AppImage on Ubuntu. Yes you can start that easily, but it doesn't integrate well for me. Also many images fail to start for some reason.
I recommend AppImageLauncher on github, it auto integrates appimages and allows them to be run from the folder in nautilus, or run from your applications menu.
Plz, don't use appimageLauncher. It takes over all the AppImage commands, even if you run an AppImage from Terminal. I use appimaged. It just creates a menu entry for the AppImage and does nothing else since nothing else is needed to be done. You may wanna try it out. Github repo is AppImage/appimaged. It is archived for the sake of probonopd/go-appimage (github repo). But don't use go-appimage. It is still in experimental stage and doesn't work that well. Just use AppImage/appimaged. It works perfectly.
Not all app images work with all versions of Linux. I run MX Linux as a live USB version 18.3. An App Image I downloaded would not work, but the very same App Image did work with version 19, so...
I'm also using MX Linux due to compatibility with latest AMD hardware. From my understanding, MX is a bit of an anomaly in terms of packages, because it is primarily based off Debian Buster (old version of Debian), so this means you have to rely on Buster packages. Bullseye or Sid packages will not work without requiring reinstalling lots of other system packages like libc6. But thankfully the MX team ships the system with custom repositories already included in Apt-Get so you get latest versions of apps you would not find on the stock Debian repositores themselves. From my understanding, that's it. Been running into some problems trying to install OBS-Studio in MX exactly because the Buster versions are outdated. An updated Appimage is lacking as well. Some fine tuning here and there needed to make it even better.
In terms of ease of use and less hassle overall, Manjaro is the number 1 winner by a long shot, in terms of installing apps. But the system would break too often after 2 weeks or so of daily usage, which prevented me from making Manjaro my main system.
no, he was trying to make a "simple" howto. IRL you really only use AppImages if you have different library versions or do not have all dependencies on your machine and don't want to change your local versions or upgrade them.
You can add dependencies to /usr/bin. You can add needed libraries to /usr/lib. You know, put things in their usual places. Of course, you don't have to add dependencies to your personal AppImages if you know the machines that you are going to be using will already have the dependencies installed.
I used the time command to check which one was most efficient, you can't argue against the numbers, test it yourself: #!/bin/zsh # first one on time 1.05s user 0.33s repeat 1000 dirname "$(readlink -f "${0}")" # second one on time 0.00s user 0.01s repeat 1000 pwd
But pwd maybe something different. If you’re running it like ./applications/Utilities/st.AppImage, the pwd is your pwd, not ./applications/Utilities/, right?
Hi! How to export program directories to another directory in the AppRun file? For example src directory: / usr / share / app / src in /user/.local/share/app/src
for my appimages i always use appimagelaunche. so that i can launch it as a app. and i don't have to click on the appimage everytime. i don't need to launch it because it is a system app now
Please PLEAASSEE can you make a video about creating .deb files and how to make a bootable and installable copy of a arch based system or debian based system (ex: when some likes your own "special" distro and he wants to install it on his machine) THANKS❤❤
About the second thing, just dd the original partition to make an iso. Then in the new system, dd again to write the iso to an UNUSED partition (do not overwrite your bootable OS yet). Mount the newly created partition, change the fstab and other configurations (xorg.conf for example), and you should be ready to boot into it. Better search an online guide though, never done it myself. I don't believe it's easy to create your own bootable installer. Not from scratch at least.
@@minepro1206 Thank you so much i really appreciate your help this can help so much and yes i think this solves the problem i can dd my os partition and create a live iso with an installer. Thank you so much.😄❤
Im still new to Linux im trying to make an appimage for a smash bros mod, there's one i got for a different mod to work on steamdeck so i know appimage is what i need
Yes, in fact, updating an AppImage only downloads the differences between versions instead of downloading the whole AppImage. AppImages can be updated using AppImageUpdate (github project) by AppImage (github user).
@@RealMazharHussain Could I do this if I made an appimage from a git hub build? Won't I need to do a git pull first and recompile or can I just use the appimageupdate?
@@Enzed_ If you build an AppImage yourself, then you need to do a git pull first and recompile it. But if the maintainer provides an AppImage in their project's releases, then you can usually use AppImageUpdate to update it. If you don't want to create an AppImage by hand everytime you want to update, you can just create a shell script to automate the processes of git pull, compiling, creating AppImage and putting it in the right place.
Dt if you are seeing this can you do a video on xmonad as tiling window manager for gnome. I like tiling wm but sometimes would just want to use the gui get things done and gnome hybrid seems the best way
Thanks a bunch! I tried once to create an appimage however I only kept failing and it made things rediculously more difficult because I was getting errors I don't even understand anymore. I was following the guide on their wiki. In the end I gave up and just went with flatpak because at least the wiki there worked for me....
Appimage is the best format i've seen, it just works on any distro, and even complex games with wine works like a charm.
Hey DT
The origin is from when Ken Thompson and co originally wrote Unix.
/usr Was originally the User Directory, however they ran out of space on their machine, so they made /home
/usr now gets used almost like a "Program Files" directory on windows, however it was only ever supposed to be for user files
I never use Snaps or Flatpaks. I highly prefer AppImages as they are fully contained environments for the application (version mis-matches begone), but without the overhead of daemons running etc.
For once I completely agree with your regarding the topic of this video. Keep up the good work!
This only works because you already had it compiled on your system, so you have the dependencies. It may run on other distros, however it will never run on a system with older libc. There is a reason "official" AppImages are built against CentOS 6 : libc is backward compatible, but not forward compatible.
Yeah, that’s one of the things Nix fixes. Nix packages can only access what is given to them (outside of user home files).
U can put all dependencies in the appimage
@@sudheerkmuhammed6363 I've tried to add libc into AppImages and no matter what I did, they would just call the one from the system
Right, this makes AppImage completely useless for most use cases.
@@notuxnobux That's not true at all. Any AppImages built statically won't experience this issue, and building against an older distro doesn't make it useless.
When I first got into Linux, I found appimages pretty quick, and thought it was super cool and simple, and wondered why everything can't be an appimage, I then realized how easy it is to manage stuff with a package manager (I was still new to pretty much everything) and so didn't think about it too much anymore... Now that I see how easy they are to actually make, I'm starting to wonder again...
Good saying, we, the Linux community should advocate appimage harder because this is our format!
So the executable is linked to only static libraries? Of course, it will work on the system where it was built! I would like to see it installed on a Linux system that may have different versions of shared libraries installed than yours.
Yeah, totally won't work in that case
I'd like to know if it matters that you use different versions of Glibc.
Appimages are very useful for people on static release distros and is probably the one format on Linux that makes it easy to run older versions on software on a machine that is offline.
This is gonna be so useful. Thanks DT!
I think the best reason to use AppImages is to isolate manually compiled Apps from the system.
Just think about it. When you build an App manually and then install it with 'cmake install' or something, it gets mixed up with the system files. You can install that app to a temporary directory with 'cmake install destdir=temp.AppDir prefix=/usr' or something, then package that directory as an AppImage, and then use that AppImage without having to ever mess with your system.
Exactly... Another great example would be Wine. If you have a running 64bit system, there are cases in which you DON'T want to introduce slower lib32 libraries to your system. Wine needs lib32 architecture to run most of the Windows prefix executables (vbruns, ttf installs, etc). AppImages would allow you to install Wine along with an Exe without having to have all that bloat(slower lib32 architecture) installed on your system- it would only run in memory while the AppImage ran, and would just vanish when the program stopped.
Yeah, that too.
You should really look into using the standalone Nix package manager (especially, flakes). It’s repos are quite comprehensive (the NUR even more so), it works cross-system (even MacOS and maybe BSD) and packaging things yourself is not bad (Nix expressions are a lot like Haskell, and it gets easy with time). The new Flake system makes it quite easy to host your Nix-related files on Git (packages can be downloaded directly from git repos using the new style commands, and anything defined by a flake including NixOS systems and Nix libraries can be included by other flakes).
Yeah, it's simple for single stand alone binaries. I've spent a couple of days trying to create an appimage of a program I had to build from source, along with several libraries I also had to build from source due to different (newer) versions of them than available in the current repositories.
ldd shows me that the program is dependent on 147 other files. The appimage tool with the --generate flag is supposed to figure all of that out for you, but it crashes.
So now I'm looking for tutorials that explain including all of the libraries the program also needs.
How about a follow up tutorial that goes deeper down the rabbit hole and clarifies such a scenario?
BTW, thanks for this one, it helped.
on my github repository, ivan-hc, I've some tools and sample of appimage
AppImage is the really way to make Linux much easier to everyone. Should be the standard for most distros.
AppImage package creation can be fun and even tiring at same time, finding the errors on what are library files needed in order to launch it as stand-alone package.
Thanks DT, that HERE variable hack was super useful.
absolute legend you never over complicate your tutorials thank you again mate was so easy
As a developer, it irritates me that they should go to all the effort of explaining that you don't need the ".png" on your icon definition when it would have probably been less work just to accept the icon definition with or without the extension.
It is much easier than how it is shown in the video. You just need to put binary,desktop,icon file(s) in proper directories inside AppDir/usr and appimagetool will automatically create AppRun and other files needed to be placed directly in AppDir.
Will that work on any system or just the system it was built on?
@@kendarr It depends on the files included in the AppDir. If they are binary files, they will only work on the systems with the same or newer version of GLibC that they were compiled on. It also depends on if all the dependencies of an application are included the AppDir or not.
After trying to create an AppImage for a real application that I developed, I came to the conclusion that packaging a real application as an actually portable AppImage is not easy.
@@RealMazharHussain Thanks, I got curious after seeing a guy on YT packing a full wine version with a Windows game, and it worked just fine on my machine, I'm still very curious as to how to do that for a Photoshop app for example.
In theory as long as the AppDir has all of the software dependencies it will work?, so I can to build a appimage and check what it says is missing and so on?, I might be way of track here lol
@@kendarr Yes, as long as the AppDir has ALL of the dependencies (and also, correctly set up environment variables), it should work.
But it doesn't always say that a dependency is missing because it is available on the system that AppImage is running on. What it does is throw a random error message which you may or may not understand.
Everything is about versions. As long as you are packaging an AppImage on an old system like Ubuntu 18.04 or something, everything should be fine.
TLDR;
As long as the AppImage has all the dependencies and correctly set up environment, it should work on the system it was packaged on, plus newer systems.
E.g.
AppImage packaged on Ubuntu 20.04 should work on Ubuntu 20.04 and newer, Debian 11 and newer, Linux Mint 20 and newer, Fedora 32 and newer, Arch Linux, Manjaro, etc.
AppImage packaged on Ubuntu 22.04 would only work on Debian 12 (testing) and newer, Fedora 36 (beta) and newer, Arch Linux (no Manjaro).
AND
AppImage packaged on Ubuntu 18.04 should work on almost every distro.
I agree
AppImage should more adapted
2:38 /usr was originally used instead of /home on the PDP-11 back then
Thanks. I’m liking Appimages more and more.
Not I, I think it is bloat. Same argument against snap and flatpak. But that is me.
@@AndersJackson one or two sentences to elaborate that (on app images)?
thanks in advance!
@@AndersJackson I don't personally know how AppImages and Snap work under the hood (not yet, I'm doing my research), but Flatpak handles file deduplication and works more or less like git. There are some talks on youtube about it talking exactly why Flatpaks are efficient if used correctly. One I'd suggest is an interview made by Cassidy James Blaede from ElementaryOS, which shows why some assumptions about flatpaks are myths and misconceptions and how they can be lightweight and efficient.
DT: "It's fast and easy."
Gentoo users: "I feel personally attacked." 😥
🤣
explain pls
@@daveshouldaine2520 The joke is that Gentoo is supposed to be neither fast, nor easy to setup or install anything in. (Usually requiring everything to be compiled from source.) Having something quick and pre-packaged that you can just download and use is the opposite of that. Now that I explained the joke, it's likely not funny to you. 🤣
@@sbrazenor2 anyways, thanks for explaining, I'm currently installing Gentoo alongside with Artix, last time I broke my grub and it didn't work well. So, I'm gonna be careful this time :)
The Nix-bundle project is another cool solution, it’s being integrated into the new Nix3-style command. It can convert Nix expressions into standalone executables, similar to AppImage, while still allowing for the use of Nix’s guarantees in system independence.
*BSD users using AppImage would have Bash because it's done through a Linux compatibility layer (basically WINE but for Linux). It requires kernel support and only the Linux kernel has support for it at the moment (also the executable being run is a Linux ELF, not a *BSD executable so it wouldn't work natively anyway).
The Linux compatibility layers installs a small Linux system including tools like bash.
My issue with appimages is that you can't install them from the terminal and they don't integrate as typical packages. They also wouldn't appeal to a new user because they aren't as friendly as the shops you get with synaptic and pamac and other graphical package managers. I feel like there needs to be some sort of integration of appimages as well as some package managers (both graphical and non graphical) to search for and install them. Just my input personally.
is it theoretically possible to install an app-image via terminal? like is it just something that hasn't been done yet or can it never be done?
@@michaelcarnevale5620 well the thing is they arent like "installed". It's like a portable exe in windows if you've ever used that
@@hostgrady so then couldn't an installer just send it to bin with a config folder somewhere? I'm new to linux I don't mean to be asking obvious questions if that's what I'm doing
but the whole idea is that there is nothing to install.
you can do it strictly from the terminal...its just a little harder- use curl or wget to download the AppImage, use chmod u+x to make it executable, and just run it from download directory. You could even add it to your path to make it easier to find.
@@debianswami8204 i still think a repository holding good quality app-images and relevant configs would be useful
thank you DistroTube you helped me with my welcomeapp and some other applications for builds
Appimage is basically an archive with all the dependencies and a script to execute. The only noticeable differences from other packaging formats are that it is executable on its own and is self-contained with no dependencies to cause a dependency hell. The problem I see is that it is as safe as random .exe files from the internet in windows. And we obviously don't want 3 electron apps to take 3 instances of electron worth of space on a disk. Now if we want to wrap a binary with a bunch of docs/images, then it is indeed better to use an appimage.
Thanks DT this was very informative .
that app image is 200Kb in size, are you sure all required dependencies are packaged in it?
Thanks for the amazing tutorial, please make a video on .deb packaging .
Does the AppImage also contain the LibC which the binaries were compiled against? Because otherwise, how could this particular AppImage work with anything but the current libraries you used to compile the st binary with? Also: 1. usr does mean user. If I'm not mistaken, the default home directory on FreeBSD is still /usr/home/name. 2. How is a BSD user supposed to use a binary compiled for the Linux kernel?
It can. DT should’ve probably run ldd on the binary and copied all libraries into it to make it truly portable.
Appimage rocks and love that you think so aswell.Cudos bro
That's pretty awesome. I was wondering how those were made. Very useful
Question for those who use appimages. Is there a package manager for appimages or a way to manage appimage updates? Or do you guys just manually grab new ones to update?
I believe that you have to download them manually, but there is a gui program that makes grabbing appimages easier. I also believe that many people's attraction to appimages comes from the fact that you don't have to update them while you are trying to an update. So you would get an appimage for all the programs that you don't want to update.
I use the AppImageUpdateTool to automatically update the appimage files in my Applications folder.
you have to manually go out and grab the new AppImage. However the program developer could write the program to check and tell you when one is available. I use the AppImage of LibreWolf(fork of FireFox), and it will tell you that there is a newer version out, and that you should go get it.
There is a graphical AppStore named App-Outlet that can download and update AppImages along with Snaps and Flatpaks. I think DT made a video on App-Outlet too.
fun trivia: usr originally stood for user before /home was a thing :p
fun trivia: USR stands for: Unix System Resources. It was then used by Linux and stands for: User System Resources. BIN is for storing binary files and the ETC really does stand for etcetera, where trivial stuff like startup, shutdown and admin files would go.
I'm a bit surprised if the icon parameter doesn't support SVG yet.
Thank you so much. Your video was clear and concise. It really helped me with deploying my app.
AppImages are nice, but they are going to be much larger than FlatPaks for example, because large libraries like GTK or Qt can't be shared between them.
Well that was great, thank you very much.
Could you also show packing appimages including shared libraries?
Do you think this could also work with wine-dependent applications?
i believe that appimages are the best solution, they are better than flatpaks and snaps. Ofc they are not perfect but the closest thing to minimal and easy to use, and NO NEED FOR DAEMON OR ROOT ACCESS
agreed. when i installed neovim as an appimage it rly won me over immediately. gave me way more control and flexibility.
@@michaelcarnevale5620 right? i have everything i can put in an appimage as an image and it's very clean and portable, i can just copy paste my apps on any system and run them no need for root or installing anything
There is an appimage called *linuxdeploy*. It is truly the easiest way to compile all the dependencies, icon, desktop icon and it auto generates an apprun file and exports the AppDir to an appimage.
8hrs ago I searched for how to create app images. 3hrs later DT releases a video on the topic... How. Is. That. Possible.
he's watching you
Thanks a lot for some clarity. Didnt know to just copy the binary from previously installed package (from repo). I am a little confused on that but for simple cases makes sense
Very good tutorial! I find it very useful. I was looking for a way to package aseprite so I don't have to compile it on each of my PCs.
Packaging is not enough. We need to know how to make an installer. How to install an app on a user's PC jsut like we did with InstallShield on Windows.
Hey DT, AppRun may simply be a symlink to your binary, or even better the binary itself (the .desktop file in AppDir does not seem to need an Exec= definition) ...in case you would want to debloat your appimage.
i got the feeling thumbnail text meant it as something it takes long xD, as if "this takes so many minutes!"
AppImages are possibly the best way to take advantage of affordable long term storage space.
The 2 problems with AppImage are that every AppImage needs everything it depends on bundled with it or risk system dependence and the inability to integrate with the system (lacking a way to bundle default configs and other data files such as desktop entries).
These are not problems with just appimage, snap and flatpak also have same issue. Because they package apps as a system independent bundle, they need to bundle everything they need to run the app. Desktop entries and other integrated configs are actually available. in appimage, But it is up to distro developer to allow its integration. Mostly, Gnome has created issues when they decided to reduce accessibility to .desktop files. In all major linux distros (except solus) you can install a service called AppimageLauncher, which provide missing integration services. For me, I just mark it as executable manually and use menu-editor to create launcher entries.
Somehow Appimage still generate smaller install size compared to Snap or Flatpak. It also has better system theme integration compared to snap and flatpak, while also maintaining similar level of isolation. And if you need even more sandboxed level of isolation, its integration with firejail is one of a kind.
Appimage really needs more awareness. Snap and Flatpak has corporate marketing team behind them, but Appimage is truly a community project. Up until recently, The author ( probonopd on github ) personally helped app developers setup CI/CD build chain for AppImage for their app. He still actively responds to community queries.
Have you heard about appimaged?
It integrates appimages with system seamlessly.
And default config files are mostly created on first run of the AppImage.
You can also browse an AppImage after running './app.appimage --appimage-mount' in order to copy the default config from it.
@@AbhinavKulshreshtha I create .desktop files manually, it's very easy. I use a lot of AppImages on my PC.
@@JandyCZ I wrote a python script for creating .desktop files. But in reality, I have rarely seen an appimage which doesn't automatically create one for its app.
@@AbhinavKulshreshtha I downloaded appimages from github mostly and none of them created .desktop entry. It's not a big problem for me tho, so I don't really find this inconvinient. sometimes I don't even want desktop entry for an app.
Hey DT! I don't know if you are joking. I thought that you wanted to promote freedom instead of bloated binary blobs ;) There is really no reason to have ordinary applications anywhere else than in the standard repositories of your distro. We don't want redundant and/or outdated libraries stuffed in every application.
BUT, out of the three (snap, flatpak, appimages) appimages is the preferred, and it have its uses - for example:
Proprietary software that you can't compile and link to your libraries, i.e. games or software that does not get updates anymore.
//voluntary bald boomer
Finally a relief thanks DT for showing us the path✌️
Hi DT! Are you going to make a vlog about archinstall -- a helper library to install Arch Linux?
Maybe...if it worked. I couldn't get it work a couple weeks ago. Just a bunch of Python errors. So it's not something I would want to put on camera...I don't like trashing free and open source software.
@@DistroTube I personally used it and installs a lot of bloat
Now it is easy for me to create an exe like binaries for my Linux...
Thanks Mr.
Love from India.
Very nice short tutorial! 🙂
Thanks for the good explanation! Any hint how I would go about packaging an app which requires a big number of dependencies? The app is in the AUR so it would be easy, if I could just install it and all its dependencies in a clean chroot using some AUR helper, but I couldn't find a way to do so, so far.
Maybe I should try to build my very own absolute portable version of Thunderbird I can just copy over when switching machines.
That would be so nice.
yeah Windows has a way of doing this called PortableApps, where you can just tote the executable around on a USB stick, stick it on a machine you want to use it on, and just pull out the USB stick when your done.
Not really viable with Linux as you already have to be a user on a machine to be able to do anything...and it would try to leave dotfiles behind....
@@debianswami8204 exactly... I wish I could somehow have this on Linux. I read about ways but those don't work. Maybe with AppImage2.0 or something in the future.
@@debianswami8204 You can do that with AppImages too. Just make a directory with the name of your AppImage File + '.home'. For example, for Etcher.AppImage, I would need to create a folder named 'Etcher.AppImage.home' inside the directory where Etcher.AppImage is located. Then, All the config will be saved in this folder instead of user's home.
Or you can run '/path/to/Etcher.AppImage --appimage-portable-home' and it will create that portable home folder for you.
AppImage
Thanks DT for this tutorial, can you make a video on how to use pkgbuild to install stuff via pacman(for dependency convenience) for stuff that is not natively supported for arch(like some companies provide rpm packages for their product drivers) ?
After Creating the AppImage I am getting the following error: execv error: No such file or directory. What could be the problem? Is there a problem in making the directory structure and also the dependency is on Qt
Hey DT! Is there a way to quickly transfer your files and configs and apps from one distribution to another?
I fucked up my boot partition on another drive that had Manjaro installed when I tried to install Garuda.
You can try manjaro architect and mounting root and home partitions without formatting them and just formatting boot partition
@@NOBODYUSEFULL okay gonna try that. Thanks!
@@reaperfs2371 if you need any help feel free to dm me on discord maksez_#4866
@Zion All Linux distros can be installed on a flash drive
how to solve cannot execute binary file: Exec format error this error while build appimage
Obly problems are they don't work on musl (most of the time?). Also I packaged an AppImage of something on my system and sent it to a friend, but they couldn't run it because there GlibC was too old.
Most difficult thing is to create a bundle with all the deps. Is your binary 100% static?
Asking here first. Not ready to do it yet, but can you talk more about creating .debs and .msis, but .msis should be using non microsoft tools. It should be for linux mint and windows 10, respectively. So far, ive gone with .zips on both platforms, because its for sure, easy and free. But i want to learn, for when im finally ready.
I did not remember that "(a) graphical file manager" is THAT complicated to use :o That process would be 10x quicker in terminal.
Love your outros haha ;)
But if you make an appimage, where do you place the executable? How do you put a shortcut on the start menu?
under ...usr/bin folder. You wil need to write command to execute the binary file from the folder.
Can multiple apps be combined into one appimage? And then result multiple apps start on one icon click or one cli command?
Awesome! Not the WM... LOL
Thanks for the video!
LLAP
AppImage for the win :D
Those apps that are directly installed from arch repository.. For then how can we get the binary file?
Ive downloaded the appimage tool kit code but don't know how to build it
2:33 Haha this is interesting... I keep hearing different things on the meaning of "usr" . People say it means "user," other, people say it means "Unix System Resources" (etc.), and both sides are absolutely sure that the other is wrong.
Good video DT. If you, or anyone else here, is interested in seeing an AppImage in action, I have an open source project which uses them. It's called fractorium (dot com) and the project is hosted on bitbucket. We had to use it in a somewhat non-standard way: it needed to be a self contained executable like you demonstrated, but also needed to perform some install steps to place config files on the system. It also had to be able to run several command line programs contained within, which accept command line arguments. If you look at how we did it, you can see that we were able to accomplish all of this using AppImage.
is there a video where he talks about that tower with the sound system?
Is there a way to package an app with it's configs? For example my riced polybar or some window manager
there should be a way
i use all package formats the only package format i don't like to use is snap but i use it if i can't find a non snap version of a app
I always have trouble using AppImage on Ubuntu. Yes you can start that easily, but it doesn't integrate well for me. Also many images fail to start for some reason.
I recommend AppImageLauncher on github, it auto integrates appimages and allows them to be run from the folder in nautilus, or run from your applications menu.
the simplest "packaging" format I've found for Linux programs is a compiled Golang program - hand a person one file and say, "here, run this file"
@@TheSulross Until you try to use cgo
instead of trying to click on an AppImage to try to run it, open a terminal and run it after making it executable "chmod u+x
Plz, don't use appimageLauncher. It takes over all the AppImage commands, even if you run an AppImage from Terminal. I use appimaged. It just creates a menu entry for the AppImage and does nothing else since nothing else is needed to be done. You may wanna try it out. Github repo is AppImage/appimaged. It is archived for the sake of probonopd/go-appimage (github repo). But don't use go-appimage. It is still in experimental stage and doesn't work that well. Just use AppImage/appimaged. It works perfectly.
Not all app images work with all versions of Linux. I run MX Linux as a live USB version 18.3. An App Image I downloaded would not work, but the very same App Image did work with version 19, so...
I'm also using MX Linux due to compatibility with latest AMD hardware. From my understanding, MX is a bit of an anomaly in terms of packages, because it is primarily based off Debian Buster (old version of Debian), so this means you have to rely on Buster packages. Bullseye or Sid packages will not work without requiring reinstalling lots of other system packages like libc6. But thankfully the MX team ships the system with custom repositories already included in Apt-Get so you get latest versions of apps you would not find on the stock Debian repositores themselves. From my understanding, that's it.
Been running into some problems trying to install OBS-Studio in MX exactly because the Buster versions are outdated. An updated Appimage is lacking as well. Some fine tuning here and there needed to make it even better.
In terms of ease of use and less hassle overall, Manjaro is the number 1 winner by a long shot, in terms of installing apps. But the system would break too often after 2 weeks or so of daily usage, which prevented me from making Manjaro my main system.
How good does audacity works as an app image?
Thank you for this video
you didn't talk about the dependencies
no, he was trying to make a "simple" howto. IRL you really only use AppImages if you have different library versions or do not have all dependencies on your machine and don't want to change your local versions or upgrade them.
You can add dependencies to /usr/bin. You can add needed libraries to /usr/lib. You know, put things in their usual places. Of course, you don't have to add dependencies to your personal AppImages if you know the machines that you are going to be using will already have the dependencies installed.
I used the time command to check which one was most efficient, you can't argue against the numbers, test it yourself:
#!/bin/zsh
# first one on time 1.05s user 0.33s
repeat 1000 dirname "$(readlink -f "${0}")"
# second one on time 0.00s user 0.01s
repeat 1000 pwd
But pwd maybe something different. If you’re running it like ./applications/Utilities/st.AppImage, the pwd is your pwd, not ./applications/Utilities/, right?
Hi! How to export program directories to another directory in the AppRun file? For example src directory:
/ usr / share / app / src in /user/.local/share/app/src
I don't know bash scripts very well
Big thanks BRO!!!
now i would like see you package a snap :p
Snap the Snap and Flatpak the Flathub
Hey DT!
Hey hey!
@@DistroTube Hey, U should make a video on your specs of ur workstation
@@angeloprince6190 good idea, i hope he see's you're comment
@@goyslop-consumer Thanks Man
for my appimages i always use appimagelaunche. so that i can launch it as a app. and i don't have to click on the appimage everytime. i don't need to launch it because it is a system app now
you should've shared that st appimage too
Very nice
Please PLEAASSEE can you make a video about creating .deb files and how to make a bootable and installable copy of a arch based system or debian based system (ex: when some likes your own "special" distro and he wants to install it on his machine) THANKS❤❤
About the second thing, just dd the original partition to make an iso. Then in the new system, dd again to write the iso to an UNUSED partition (do not overwrite your bootable OS yet). Mount the newly created partition, change the fstab and other configurations (xorg.conf for example), and you should be ready to boot into it. Better search an online guide though, never done it myself. I don't believe it's easy to create your own bootable installer. Not from scratch at least.
@@minepro1206 Thank you so much i really appreciate your help this can help so much and yes i think this solves the problem i can dd my os partition and create a live iso with an installer. Thank you so much.😄❤
what is this behind you
Im still new to Linux im trying to make an appimage for a smash bros mod, there's one i got for a different mod to work on steamdeck so i know appimage is what i need
Really useful!!!!!!
He talks about how easy it is to use appimages like it isn't easier to type a simple command
Can you update apps from appimages? If you can then that's a very useful way of keeping apps
Yes, in fact, updating an AppImage only downloads the differences between versions instead of downloading the whole AppImage. AppImages can be updated using AppImageUpdate (github project) by AppImage (github user).
@@RealMazharHussain Could I do this if I made an appimage from a git hub build? Won't I need to do a git pull first and recompile or can I just use the appimageupdate?
@@Enzed_ If you build an AppImage yourself, then you need to do a git pull first and recompile it.
But if the maintainer provides an AppImage in their project's releases, then you can usually use AppImageUpdate to update it.
If you don't want to create an AppImage by hand everytime you want to update, you can just create a shell script to automate the processes of git pull, compiling, creating AppImage and putting it in the right place.
@@RealMazharHussain thx for the suggestion. I might try to make a shell script.
@@Enzed_ You're Welcome.
Dt if you are seeing this can you do a video on xmonad as tiling window manager for gnome. I like tiling wm but sometimes would just want to use the gui get things done and gnome hybrid seems the best way
Gnome actually has its own tiling manager. There are gnome extensions for it. Also there is pop_shell, too.
I tried material shell and pop os shell and both are absolutely crap compared to xmonad
it's just a graphical launcher(or way) for executing /usr/bin/st.... I don't really get the point in this...
Universally Shared Resources
Thanks a bunch! I tried once to create an appimage however I only kept failing and it made things rediculously more difficult because I was getting errors I don't even understand anymore. I was following the guide on their wiki.
In the end I gave up and just went with flatpak because at least the wiki there worked for me....
@DistroTube
USR = Unix Shared Resources