Keep Your Snaps and Flatpaks, I'll Take AppImages! 

Get down below some timestamps: 1:06 Basic of AppImage 2:48 AppImage Hub 3:29 AppImage Launcher (For the sake of your mental health use the .AppImage option huehue) 4:06 LibreWolf 4:30 Explanation about where to put the .AppImage file 7:34 AppImagePool (Kind of Gnome Software) 09:59 Xonsh - Used at 11:54 10:21 Failed try to get Powershell (Oh man dont do that hueuhe) 10:47 eDEX UI - Used at 12:40 11:37 Hyper - Used at 13:03

Flatpaks are decentralized, flathub is just the most popular remote.

The killer feature for me with AppImages is the portability. I can bring my apps on a USB thumbdrive and get them to work on any Linux box without installing anything - it's just awesome and a massive time saver.

AppImages don't come with a manager that easily searches a remote and handles updates automatically. They also don't share any resources at all, take more space and don't have any better system integration than Flatpaks. Flatpaks are currently, on average, much better maintained and if I already must use a universal packaging format, I'd rather use Flatpak for all the mentioned reasons. I wouldn't mind using AppImages at all if they had better support but as of right now, I never see the need to use them over Flatpaks.

Never used a Snap or Flatpak, always loved the simplicity of AppImages

I think AppImages are particularly good for Windows users switching to Linux, as they are more used to the "go on a website and download an executable" method of installing software.

Flatpaks' and Snaps' main flaw is the lack of apps, but with Appimages, I feel like the problem is even worse

have you ever heard of AM and AppMan? They are two command line tools that can install, update, and manage AppImage and other standalone package formats. The first one integrates the programs at the system level, the second one instead installs them only locally.

Honestly, I don't really like AppImages. I've used Snaps and Flatpaks and they work just fine for my needs. There are various issues with AppImages, such as updating them and the duplication of libraries. While the library issue isn't really huge thanks to larger storage volumes, the inability to update AppImages easily is a dealbreaker. AppImages remind me very much of macOS and how it handles applications.

For once I totally agree with DT, now that is a first!

in my book appimages is best

manage to contradict yourself in the space of 10 seconds, appimages are decentralized but then you cant find them so you have to upload them to a centalized website so people can find them whats the difference between windows users downloading exe files from a untrusted random website vs linux users downloading an appimage from a random untrusted web site, none at all the whole point of software repositories is you dont have to visit loads of websites to download your software and you know the software has been vetted telling users to download untrusted software from random websites is the windows way of doing things and is terrible advice maybe some new linux users wont know better, but more seasoned users arent that daft

If all the linux users like decentralised, then why use native package manager where everything is in 1-3 repos. Also if it's your opinion then don't use the word best, because then you need to give facts. In this entire video you gave opinions on why you feel app images are better. App images are like windows exe. I much prefer flatpak, where people smarter than me have tested things.

Flatpak is decentralized, also its the future of Linux.

AppImage is my favourite for sure

I absolutely love and value all the hard work you put into this channel. You are a great teacher and ambassador for all things open source and free! I watch all your videos in brave browser (without adds), but before I go to bed I set up a long playlist and play your vids all night long in firefox (with adds) while I'm sleeping. That way I get an add free experience, and you get paid because I never close the adds early. Thanks again!

AppImage Launcher should actually intercept your first launch of an AppImage file and ask if you want to “Run” or “Integrate & Run”. If you choose to integrate it “installs” the AppImage into a default folder (~/Applications) and creates the necessary desktop entry file to make it work with application launchers. You shouldn’t need to open the downloaded AppImage in any unusual way. When you install AppImage Launcher it becomes the default application for opening the “AppImage” mime type. I think.

It seems weird, as an application user, to care this much about how an app I want is distributed. I just want to easily be able to download and use an app. Whatever distribution method the developer wants to use is likely fine by me so long as I don't have to build from source. The only time Im annoyed by the existence of snaps is when Im running Ubuntu server and snap decides to reinstall itself and use up space and resources. But to each their own.

I don't like appimages. They don't integrate well with your DE and usually are a hastle to keep up to date. Perhaps in the future but for now I prefer Flatpaks.

My problem with any of the options is, that mist of the packages are only available for X86, but not for ARM. I still prefer good old Deb packages from the repo because they are compiled for ARM.

I've always especially loved the Kdenlive Appimage. In my own experience, it's more stable than the packaged install, and a lighter process than installing the flatpaks, even though I do like flatpaks overall.

Doesn't flatpak let you add user repos? You still have to add the flathub repo when you install flatpak iirc

I will never know why App Image Launchers are not part of any major distro (except Manjaro & Arco (?)). It should be installed as part of core utils or at least available in their repos.

Love AppImages. Always have. Always will. I think I’ve said it on a previous video. My preferences are - native package - source - appimage It’s so easy (as you said) to build your own appimage for users to be able to run - irrespective of distro. rofi and dmenu picks them up nice too.

I love how portable appimg are, i just have a portable app directory that simple move from a machine to another and just work.

I don't get what makes AppImage better than Flatpack or Snap. I get how you like them because they aren't "backed by a corporation" and work better with themese. But how do AppImages protect your system from an App doing bad things? Sandboxing is one of the features of Flatpack, and as a security conscious person that's kind of important to me. How do you know that there is a new version of an AppImage, particularly one that addresses security issues? These are problems that can be handled in a decentralized way. I feel like all you did was introduce AppImage, showed some of the shortcomings, and didn't really talk about its advantages enough. AppImages don't work out of the box on my distro of Linux, and if I'm going to go through the pain of making it work I'd like to know it is actually and truly worth it.

To me appimages are what Linux has needed forever. Installing apps should be brainless. Also, I respectfully disagree with those citing duplication of libraries as a downside. Disk space for apps has not been a real issue in what...15+ years?

It pains my heart that you don't do any simple research..flatpak is Is decentralized... I love your Tutorial vids... But sometimes you're a Foss religion Gets in the way

Hang on... No central place to get them, then go to this central for appimages? And snap and flatpacs are the same? You may like what you like, but c'mon mate!

So we should unite on this matter. Nowadays many developers prefer and use flatpaks so everyone should support that. It's better for us and linux

On another note, people often say how appimage is great for portability, yet 99% of the people you know will use either Windows or iOS....

Appimages are really great for archival. I can copy them to anywhere and it's only one file

While decentralization is good, it also makes me worried about the security issues associated with randomly downloaded and installed appimages.

deb - 5mb, appimage - 40mb

Order of priority to get packages: Native Package Manager (APT, RPM, AUR) -> ELF Executable (Or Source Code) -> AppImage -> Flatpak -> Snaps (As a last resort with no other choice)

It doesn't matter, as long as we have all the applications we want and keep them away from system dependencies. A few years back we had to use all kind of wacky methods to get our software, now everything is one click away, it's nice.

AppImages are sooo much cleaner too. Removal leaves behind a settings folder - that's it, and usually wanted that way (like when trying a new version and porting config, or user or folder permissions). AppImages are so much easier to manage device pass-through too, unlike flatpak / snap depending on usr local share etc. It's just so much cleaner to sort, manage and change self contained files, never mind back ups and moving them to other systems via USB or whatever. No need to check or guess where to find it the main file you want to give your friend or put on a laptop. Everything else is good, but app image is ideal in every way. Hubs should just be a community that links to developer websites anyway. I hate "stores" with broken reviews, outdated versions and buggy compatibilities. Hard drives are so cheap we should just enforce programs to contain their dependencies anyway and only use 5he built in if the system dep fails or the user launches with a flag or something. I hate it when Linux tries to be like Apple or MSFT by "helping" me out dropping turds all over my file system when I'm not paying attention. Linux philosophy is entirely app image and everything else is not consistent with Unix ideals imho

AppImage is probably the best idea in Linux for a long time. I never liked the classic standard package methods. The first time I knew them I thought "This is crazy! and my opinion has not changed since then, Now if I can use the appimage version of a program I use with preference to any other.

Honestly for the software project that wants to sell their software to Linux users. AppImage is the best option. Flatpak is only being the declared winner because it's familiar to us Linux users.

The problem with linux is too much choice, it is confusing as fck.. Windows has setup and thats it.. And it fckin works, not buggy and easy to use.. Linux is dissaster

THIS. I fricking hate flatpaks and snaps.

Appimages don't have the security containerization of snaps or even the less secure flatpak containerization.

I LOVE Appimages! That being said, there are some trade-offs with them. They do tend to start up a little slower but that's because it has to open up the appimage file to load all of the requisites files needed to run. After it's up, it runs fine. The thing I like most about it is that everything you need is in one file. No wonky installs. No leftover files after uninstall. Can have multiple versions of the application if you want. To uninstall an appimage, delete the file. Done. Part of me would like to see if it's possible to have the kernel as an appimage (or collection of appimages for certain use cases) and be able to boot from an image instead. Again, have multiple versions just in case one version doesn't work right.

how should updates be handled, any suggestions?

Personally for me, Appimages have been very useful because for some reason currently installing software breaks my computer, so it's very helpful for me to use a software quickly without worrying about repositories and stuff

AppimageLauncher comes pre-installed in latest releases of Garuda Linux

I don't like how complex the syntax is to run a flatpak package and how clunky snaps are. Appimages are simple and better.

appimage is simpler than snaps too it feels similar to how people are use to installing third party software in windows/Mac environments. With snaps and flatpaks it's like you gotta install a second package manager and use these different repositories yuck just give me it in an appimage if you're not in the main repos

They should write a cli package manager which has things like updates and stuff for appimages

AppImages are cool but IMO projects like the fpm package tool don't get enough love. I personally like the package manager of my distribution. I understand that packing for many distributions seems difficult, but tools like fpm make it easy, and it could be totally automated. I also think sandboxing is a different issue in general and should be solved with separate tools, so that the user has the choice when to use a sandbox and when not.

i use the AUR for what i need......i've used some flatpaks and appimages depending what it was.

honestly, i have never used flatpak, snap or appimage. i've never needed to use an universal package actually. i don't get the necessity (excuse my ignorance). aur helpers are more than enough to satisfy my need to search and install. even if they didn't work, you could make a google search of what kind of app you want, then you could find the app code and compile. it seems to me that only upside of using an universal package is that you don't need to sort out the dependency issues manually. but that's rarely needed if you are using package manager and install from repo anyways (which is the way we install things 99% of the time)

What's wrong with apt or pacman? Confused.

The only centralized package distribution is snap. Flatpaks allow users to set any flatpak repositories while with Snaps you can only use Canonical proprietary repository. The problem with appimages is that they are not as simple to install as the rest of apps on Linux. So, in my opinion, Flatpak is the future of application distribution on Linux. Appimages are not that practical.

so..... its like .exe files for windows

if you're gonna have an appimage then why not just use a binary file? what would be the difference between just downloading a binary file

I really like AppImages

Keep in mind despite flatpak, appimage does not ship with all libraries (glibc). This can be good or bad. However, keep this in mind since appimages are dynamically linked to glibc hence distributions with musl like void and alpine will not work with appimages.

AppImages seem easy enough to use, just like the Snap packages and Flatpaks. I have Debian 12 with the gnome desktop installed on my home pc. With the Debian repository being so large, I just haven't found a real need for universal packaging yet. My home computing needs are relatively simple, so I have become content with a system Debian has employed for years. With it's portability and ease of use, I believe universal packaging may be the future in computing - although I wonder which product will become dominate in the coming years. MIT, GPL, and proprietary licensing may determine which flavor of packaging succeeds. Thanks for this video promoting AppImages. With all the forks in the road, Linux is an interesting subject.

I don't use any of those 3, paru [software] always satisfied me. When a fancy app isn't in the repos I don't mind tho.

I always believe in Deb

I never used appsimages, so I can't talk about that, but I use flatpak for Steam, Discord, and kdenlive. What I heard about AppImages is they are a pain in the butt to update because you need to keep track if a new update has come, manually download it, and install it. And if that is true, then that alone is enough for people not to use it i know from my old Gaming days how significant a pain in the butt it was to find, download and install patches to games so that alone would keep me away no matter how good it is. Still, as I said, I never used AppImages, so I wouldn't know. I really like Flatpaks, and that's why I use them.

In my opinion appimages and flatpak are the best. Snap is not really mine.

this is really disappointing...appimage launcher doesn't work...the appimage says 'child process set up failed: execve: no such file or directory and the rpm is just deb converted using alien, and has issues (even upon editing it)

I love the "one file equals one program" concept of AppImage. I just wish more apps/programs were available.

Appimages do not need to be installed since the reason it was created was to run them without any installation... All you have to do is to download and run it the same way as you would run a Windows portable app. This is a very great idea, in fact the best idea in Linux packaging ever. We actually use an operating system to run applications. In Linux world there are a lot of distros. This is good because there is always a choice. But that is not good at all that you cannot use the same app across the distros. You need an mpv instance in Slackware, an other in Debian, and so on. This is not only uncomfortable: it is a big stupidity and waste of energy. For example, if mpv developers should have to develop only one Linux mpv instance, an appimage for all distros, they could develop more efficiently their app. Similarly, if Debian people should not need to create an mpv deb, they could afford this time and energy for other cleverer and more useful things. For example to ensure that appimeges can run without problems; they could make Debian to find and integrate automatically appimages if they are located in some standard directories (or to pass the appimage directory path by a boot option). Synaptic and other package managers should support appimages by default. Of course there need to be an (or more) appimage hub/repo(s) (used by all distros) containing secure appimages. This would be less expensive and more environmentally friendly than a lot of different repos for different distributions. The only problem is that appimages are unfairly treated by the distros and app developers. Most of the existing applications in Linux does not have an appimage variant now. Only some "popular" apps. But this is not enough at all. All app developers who provide on their websites downloadable Linux packages should also provide an appimage besides the usually deb, rpm, etc. package variants. In this way would be resolved the security question, too. If you download the appimage directly from developers you can trust that you download the original app. And there is an other big advantage of appimages: if you use live operating systems (without installation to a storage device) this is the best option of using applications.

appimage fan here!

im new to linux and trying to find videos on how to for linux is hard to find. I was hoping somebody that used linux for many years to have a channel to explain how to use linux. I know most of it is simple but there are things that a new user cant do. Right now when I download something to install and i click on the download and open in folder, it says could not find,,,this is just one example of the videos needed for new users. A whole channel is whats needed. thanks

Flatpaks are sandboxed and (for better or worse) are also verified and the manifests are clean and open. They are simply WAY more trustworthy, period. Appimages are good for small utility programs, prototyping and even portable needs, but they don’t really integrate with your system nor have configurable permissions. They do serve a purpouse but Flatpak is just a good standard that doesn’t really needs to compete with anything else than snap (snap sucks ass tysm). We can have both no problemo.

Snaps do not exist

We have system applications (drivers, base terminal utils, trusted apps) that MUST be up-to-date. And we have beta/untested and proprietary non-secure apps/utils. So, what we need is package system that can: * put firewall rule on non-secure app * have control over rw access of non-secure app * have all options of firejail utility * allow us to run older versions of non-secure app * export and share app projects like you can with docker images

Very old System / Network Admin here..... IMO... Anything like SNAPS, Flatpaks or AppImages is just another layer to the OS I can do without!!! This layer just invites security, integration and performance issues that I just don't want to deal with! Many.... Many... Years ago.... I cut my Linux-Teeth on Slackware. And... Slackware has a motto.... K.I.S.S. (Keep It Simple Stupid). I live by this motto daily! This always reminds me of Star Treks Scotty's famous quote.... "The more they overthink the plumbing, the easier it is to stop up the drain."

Problem with appimage (with appimagelauncher) and Flatpak are really bad CLI support. Especially Flatpaks pretend like apps are just GUI and CLI apps in PATH is not a thing. Snap is better at this. Snap supports CLI programs much better. Flatpak and appimagelauncher should provide better support for CLI programs.

How do you go about updating the AppImages? Would I have to re-download every single one manually or is there a program to batch update them like with flatpaks and snaps?

I am not interested in either a Microsoft Windows or Apple Mac OS X application experience. When I want easy portability between computers running different GNU/Linux distributions (or Microsoft Windows or Apple Mac OS X, for that matter), I create a Docker container. For those preferring AppImage, Flatpak, or Snap distributed applications, enjoy the choices free/libre software makes possible; yeah I know Canonical Snap is a proprietary technology.

Snaps and flatpaks always baffled me. Snaps and flatpaks confuse sandboxing and portability. They also violate Linux philosophy. Dependancies are supposed to be a Linux strength, not a problem. Dependancies have one simple drawback, which is dependancy hell, and old packages will inevitably be impossible to run. So for the packages that will not be kept up to date, or want to keep legacy versions, appimage solves this problem by having one self sufficient version of the program. As far as I'm concerned, games should always be appimage. If I want sandboxing, why can't I use another program to sandbox my appimage, and not suffer the drawbacks of sandboxing.

This is not very convincing. Go to some (sorry, it looks sketchy/gimmicky site) and download executables that will not have updates from your software center. Or download a sketchy/gimmicky software center with low compatibility and presumably no update manager? Totally negates the positives of Flatpak like the fact it updates by diffs and removes duplicated dependencies. Copying the way macOS and Windows handle applications is not the way forward.

What I don't like about snaps, it's not that they're pushed by Canonical and not that they have one one store, running by Canonical. I don't care about that. What I don't like is that it's running hecking snap deamon on my machine, which eats out like 80 Mb of RAM. It makes me feel like I'm back on Windows. Why does anybody need an extra daemon running on your system, just to be able to run some software, where flatpak, essentially the same thing as snap, doesn't need it?

snaps have their issues, and flatpaks don't have a lot of them, but, flathub is pushing online accounts being integral to usage of the linux desktop, all in the goal of attracting proprietary devs and letting them have a nice and pre-built DRM scheme, as opposed to improving the open source alternatives. On windows companies have to make their own DRM, linux doesn't need to make DRM EASIER to attract more proprietary devs, we don't want more proprietary devs, we want open source alternatives to be better.

I feel this video was a bit disingenuous when it comes to flatpak and the usage of appimage. The way I see it appimage use case isn't the same as Flatpak or Snap necessarily. I think going forward this makes a logical use case for each: Package Distribution: This is how the core OS files are distributed, eg the base system and core functions like windows manager. Snaps and Flatpaks: This is for the 'addons' that you may want that distribution maintainers have a long history of sometimes taking ages to package (eg. try getting Libreoffice up to date on a Debian based system, some are but most aren't. Source: My experience). Appimage: Appimages are good for those big distributed apps where the developer wants max compatibility and might have lots of shared or older libs, contain everything in it's own package and it just runs with no issues. Essentially like the apps on Mac. I also think that saying that the flathub is the only repository for flatpaks is just incorrect, as far as i'm aware unlike snaps it's an open format and anyone can have their own repository (Fedora have their own separate one), so it's incorrect to lump flatpak in with snap on that one.

Snaps are a nightmare and canonical is to blame. Flatpak is simpler and much more stable. The snap version of vlc for example frezees a lot while the flatpak version works like a champ. Appimages are the "It just works" example and honestly, when available, they are my To-go option. Example, etcher and openshot appimages.

I understand your point, but by your own words windows installers are insecure, because you have to download from untrusted sources, appimages is the same, not all of them are in the hub. Snaps vs Flatpak: There is an issue in your words, snap IS centralized by canonical, Flathub is a place where you can get mostly all flatpaks, but anyone can create a repository to add as a source, e.g. Tenacity uses its own repository to deliver its application. I agree its a portable alternative, its nice to have, but by far I prefer flatpaks for apps, snaps for system applications. Flatpaks IMO integrates better, your app is not an alien in your desktop, maybe is not an issue to gnome users (Manjaro KDE user here) and re-utilize shared libraries.

This video does a really bad job on convincing me to use AppImages. You show all of the cons with none of the pros. Having to create a folder and manually manage each AppImage seems like a pain. There is no good way to update AppImages without having to manually check each on for an update. Flatpak is decentralized so what you said is FUD. I can also manage flatpaks in the terminal like a package manager similar to pacman or apt. AppImages really seems like a step backwards into the windows way of doing things. Seems like you have no good reason to hate Flatpak other than the fact that it's popular. Being anti bandwagon is just as toxic.

I love the linux ecosystem but there is something wrong when every desktop demo I watch looks janky as sh*t... you sure didn't sell me on app images. I'm not bashing DT here... I see it all the time, fresh distro installs with settings that don't work - linux desktop ecosystem needs to work on quality control

I don't think Flatp* demand you use flathub,, and even if that was the case there is nothing stopping anybody from forking of to make a more distributed version of it anyway. 🙂 I can see why you like AppImages, but I don't get the hate for Flat&Snap. Trying out different things is at the core of FOSS and everything gets better, faster, when everybody can learn from each others strengths and weaknesses . Thank you for your content!

.deb; .rpm; AppImage; Flatpak; Snap and whatnot I am exhausted. I already hop on the distro wagon, every distro so far had some basic bugs and problems right away in the first 20 minutes of use. I try 4 so far. Meanwhile whatever Linux I choose there is fight in the comments which is superior, the rest is for "newbs" they said. I have done nothing productive, just hoping from OS to OS and all fans in the comments cheering, all of them full of bugs.

If you're gonna move away from traditional package managers... appimages are definitely the best format. Vastly superior user experience and convenience. Shithows like flatpak don't even deserve to be compared to appimages

I kinda feel like this video unintentionally highlights many flaws of app image.. most people just want it to work and open quickly.

Why the hype about snaps, flatpaks and appimages anyway? Anyone not just being after a Linux version of MacOS, which has been doing appimages for as long as I can remember, uses apt or the like installing apps from repos or even from source.

Dear DT. Not all appimages will run on all versions of Linux. I know I've tried mini won't launch on my version of Linux I don't like the appimage launcher but this is due to I do programming.

Downloading appimagelauncher did nothing on my fedora. I coudn't launch any app with it even after making it executable. I had to install it as an rpm package and only then it worked exactly as you showed here.

It is like choosing between poop, kool-aid, and a milkshake. Snaps are the kool-aid. They are not healthy for you. They are also bad for your soul.. Flatpak is a full meal. A health shake, with consistent flavor.

comparing to repository installs and appimage, the appimage is much slower on opening... like regular vlc open in 0.1s lets say and appimage vlc opens like in 0.4s but this is small program. appimage is like on macos, they are clean will not leave any files. but it's realy slow...

The only probleme that i have with the appimage, is add some plugings into them. For exemple, i can't add droidcam-obs to obs-studio appimage. But i real need this pluging.

I think you don‘t provide much reasons why AppImage is better except that its not made by a company. You say it‘s decentralized but flatpak is too. And „theming seems to work better“ is not really an argument.

Snap, flatpack, and appimages all suck. Use your distro's app installer (command line). You can still find the latest if not in the distros installer and compile the app from source and install it the RIGHT way.

Is healthly that there is a discussion about this in the community, but the video in this case is not objetive. There is no test, no caveats. For example yesterday I installed a flatpak app which could not access another pc disk. It was because of sandbox(that is cool in some aspects). Then system integration is another thing(icons). This is a huge topic itself. In this days that storage may not be a limitation, lets keep storage "bloat" justifications aside.

Except... the maintainers are not very professional or even up to date with dependency depreciation. App image just does not have a good reputation or even trying to compete that well...

AppImage is ok, unless you want to restrict access. Them they are useless and you need another tool (e.g. firejail) With flatpak you have it built-in...

Flatpak is great, what are you smoking? Instead of using yet another repo-like application - as free as it can get - and focusing of making the ones we have better, we are again fractionning the way to deliver apps to end-user by introducing another way to confuse and break libraries.