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
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.
Even with different versions. Imagine there is a feature that was removed and is available only on an older version. Or the new version is unstable for some reason. Just double click another executable and you're done, without recompiling or worrying about dependencies.
It is little-known but it is possible to have portable flatpaks. EndlessOS does this. This functionality will not be introduced into flatpak in general until it is perfected in EndlessOS. In EndlessOS you click a single button and the flatpak is copied in entirety to a thumb drive. No internet required to reinstall on the next system.
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.
Is there any way to run it outside of running a command line? I shouldn't have to run a command line every time I launch the flatpak version of Firefox. I can't find any way of automatically adding it to my KDE K launcher.
that is like asking for a Supply Chain Attack or a Bad code day, and then your app wont run..... however the AppImage will still keep on working. what you got a new app image that doesn't work on your machine but the old one does then use the old one.... very simple and does not require dependency downgrade / conflicts nightmares...
You can create a desktop and menu entry for AppImages and Set a custom icon. You just need to create a file in /share/applications you need to create a .desktop File. Pro Tip: To make AppImages fully portable, create 2 folders in the same Place where your AppImage is. Both folders need the same name as your AppImage and just add .home and .config. Example: ABC.AppImage ABC.AppImage.home (folder) ABC.AppImage.config (folder)
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.
They’re even better for users migrating from Mac to Linux than for users migrating from Windows to Linux because, like macOS apps and unlike Windows apps, they don’t even need to be installed.
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.
I think the best solution would be having a script watch your ~/Applications folder and "Integrate" on changes. It should work both ways, too, so you don't have lingering menu items when you remove an application.
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.
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.
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.
@@louistournas120 this, in this community software is provided by other users and will be decided by what those users need themselves and what they have access to, people often easily forget that almost everything we do is a community effort and no one pays those people for contributing
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.
It matters a lot more for devs. You can just make one app image/flatpak/snap and forget about it, instead of making a package for each and every Linux distro
@@walking_on_earth Realistically it's not every distro, it's just each distro family of which only 3 really matter (Debian, RHEL, Arch), moreover for pretty much all FOSS projects this isn't really an issue at all, since communities of those distros always create and maintain a package even if the developers don't provide one. It does matter for proprietary projects though that only release binaries and don't let us handle it for them. It's also helpful for very big and complex projects with tons of dependencies that can be managed differently depending on the distro, like in the case of OBS, where flatpak provides an "official" release which provides the same functionalities and experience no matter what. Still, there will always be benefits of using standard repos especially for advanced users.
@@walking_on_earth Just go take a look at a kinda recent testimony from one of snaps' main developers at Canonical who went into depression and left the company because of that before telling that's better for devs, forgot his name but certainly easily findable. It might seem "easier" but it brings lots of new parameters on the table.
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 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?
With Appimage there are no updates. If the application you downloaded was not developed with its own update manager then you have to manually download each update from the internet. (It causes huge security issue in the long term.)
Fix: There may be instructions to do updates in some AppImage (not the majority). And if you have a distribution that supports these instructions (because it doesn't manage itself) then it can handle updates. But I heard (I don't know how widespread it is) it was buggy and often failed for the few apps where it tried.
Youve just encountered the biggest problem with appimages and what makes me avoid them at all cost. Theyre just like windows programs, theyre either made to auto update independently or you have to download new versions manually
Yes you can add as many repos as you want. So it's fully decentralized. But almost all beginner distro (not restricted to snap like the main ubuntu distro) have flathub by default (to work out of the box).
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.
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.
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.
question i have installed cemu appimage for debian version of linux and it works fine clicking on the appiamge file but when i install appimagelaucher and run that to run the appiamge etc.. it wornt work.
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
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)
If you really want you can set. Some appimages support this ( read their documentation). Actually appimages behave like normal apps: use the same configuration files as the "native" apps. For example a Leafpad appimage can be configured with ~/.config/leafpad/leafpadrc as the same way as the installed Leafpad. Maybe you meant other kind of thing, but I think also the theme question could be resolved.
Can someone help I downloaded the x86_64 appimage of "appimage launcher" and I don't know what to do next I right clicked on appimage of librewolf but launch with appimage launcher didn't show up Plzz help
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
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.
Because Appimges used outdated dependencies believe it was liber2, the maintainers are kind of poor at maintaining. Really would recommend flatpaks for better maintenance, and also better developer support, there was a whole controversy with the appimage developers and OBS developers.
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.
You can't take your Debian packages to Arch...or vice versa. The point of Snap, Flatpaks and AppImages is that you have all the libraries and dependencies contained in them, so you can install them on any distro.
@@DistroTube I think fpm could be interesting here, at least the idea. It can convert a debian package to a pacman package. Am I the only one who thinks we just need a better platform to publish packages like AUR, but cross-distribution, without the need for packages to be reviewed? :-(
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.
I think AppImage lost the battle. The integration is bad, it's not secure (no separation from the rest of the computer, and no management of rights), and there is almost never any update management (which is absolutely catastrophic).
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
@@yash1152 well I assume people using computers could afford their computers. Hard drives are cheaper than power supplies, motherboards, ram, CPUs, and all the other parts that make the system run. It's an economic statement of material reality, not a subjective opinion lol If you had a 500gb ssd for $50 you could hold thousands of applications with their dependencies. Nobody used 500gb of applications, it's files that take up hard drive space not applications and libraries. Most Linux users root filesystems don't even use 100gb of applications in their lifetimes.
I hate all the ancilliary files that get created all over the place more than anyone else but, at the same time, appimages bring to linux the worst of the windows world since theyre meant to auto update independently
but what about dependences? Appimage is supposed to have them statically linked, or does it search for the packages on the system? And if it is statically assembled, then what about the bloat?
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.
2 года назад
I used to have an ~/Apps or ~/Applications folder, but it's not really good to have it in your home folder. It's messy, it's one of the reasons I hate Snap packages because of the ~/snaps folder. There's already a Linux folder for your manually (not package manager, distro) installed programs, it's the */opt* folder. I now place them there, and to great desktop environment integration create (or move provided) .desktop files in */usr/share/applications*
@@Codename1Alice8 Thank for the reply. I will admit I don't know a whole lot about app images. What method of containerization do they use? I know there are issues with flatpaks which is why they are developing "portals", but I haven't heard anything about appimage containers.
@@linuxdeveloper2325 Technically, an AppImage is a ELF file that also contains an embedded filesystem - usually a squashfs filesystem. All the files needed to run the application are stored here. When you run the file, the program embedded in this file mounts the filesystem in a directory under /tmp
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
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)
Arch repos + AUR = epic win, those are nice for peasants /s still running fedora or debian based distros tho. Compiling from source is rarely an option for the average user.
Was very frustrated by flatpak after installing wireshark and realizing you cannot capture packets locally and you cannot sudo flatpak run wireshark So some limitations exist that you just won't be able to overcome and will need to install apps through more traditional methods.
Appimage's are the best ! Small, fast and fully mobile. The best who someone developed about 20 yo i think. I'm using shortcut near year and it just work. No issues at all. Thanks DT
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.
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
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."
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.
Derek, 4:16 - I find it's better to click on the Files tab under the screenshot, that way you can see the full name of the packages available for download.
The AUR are just bash scripts, appimages are an isolated application, that does not interact with the user environment. AuR, would be better, because they are now better maintained than appimages, although it does make it easier to break your system, personally. Would recommend flatpaks nowadays if you don't fully understand the AUR yet.
What are the security implications using AppImages (or FlatPak or Snap)? How can we trust these packages to not do nefarious things on our systems? I think I'll try to stick with native packages, thank you!
@UCi4ISTXO1j3Kz7WGD2uECRg On Flatpack and Snap it's made by default and it has been think for it. On AppImages it is an other layer you can add on top of it and need to manage yourself. Be able to turn AppImage into something secure doesn't mean "AppImage is secure". Otherwise I can say "Windows is more secure than Linux" because you can add more and better quality Anti-virus on top of his poorly secured OS than on Linux.
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.
Hi guys. Recently had to change working station to MacOS(due to work reasons), what is the adequate WM for macOS ? On Linux I’ve been using i3wm. Have tried amethyst - not satisfied . Heard about yabai, but since this is working laptop I do not have permissions to turn off some security things yabay requests to. Any suggestions ?
Do you think appimages would work decently over an nfs? Like mount your nfs share to ~/Applications store your apps there, then do that on all your linux computers, so they all share the same apps and all share the same configs. Or do you think that'd be slow?
I think it depends on bandwidth to just "download" and mount them. I've tried it on a atleast 48 MB .AppImage file. it works very fine and quite slow to initialize. But it's good to share with other people.
@@hantimagyar Yeah. We should only be using appimages from the developer sites and from well known hub(s) only. But I still feel that going all for appimages/snaps/flatpaks is going towards the windows way of application installations. I thought (and still think) the Linux distro way of packaging was technically superior way of managing packages. The problem flatpak et al are trying to solve should be solved through standardization of distro based package management. Would there be too much of an issue if all distros standardized on a single package management tool (much like more or less every distro has switched to systemd nowadays)?
@@gamerboy4566 This also depends on how you use the OS. For example I use only live systems, never install any OS (and any application). So the "appimage way" is the best option for me. Actually the only usable way... The solution would be just the "standardization" of appimages. I mean by this: universal and security checked appimage repo(s) (common for all distributions), and all package managers should support them. This could make app development mor efficient, less time and energy waste both for app and distribution developers, and would strengthens the Linux world in general. Distribution developers should ensure that these standard appimages could run on their systems.
I'll consider using appimages when they can be installed from the terminal and appear in the app menu on gnome, kde, cinnamon, etc just like snaps and flatpaks.
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?
If what you want is default applications to be in AppImage format ... you can uninstall the applications and reinstall them with AppImage. But that's stupid because your apps will take up a lot more space, will be poorly integrated, and you'll never have any update on an application if it has not been specifically developed with his own update manager (huge security issue).
Snaps be causing the system to take a billion years to start up, and Flatpaks still have some issues regarding permissions (Steam for example requires steam-devices which isn't even installed by default through flatpak to get controllers working). I believe RetroArch's Linux build that's on Steam uses AppImage, and that seems like an okay solution. I think that Valve solely relying on Flatpaks in SteamOS 3.0 is going to present issues that other immutable distros like Fedora Silverblue doesn't have (due to having an equivalent to dnf called rpm-ostree where you can install standard rpm packages from). I also think the setup process for getting a system up and running in Windows is a pain in the ass with how many things you have to go onto a search engine to find, and download installers for (that you can't keep on your hard drive due to easily becoming outdated). Stuff like Chocolatey's user repository (considering how scarcely used MS's WinGet is) and how Linux distribution repos and Flathub are set up are definitely a life saver considering how many unstable Windows builds that I've had, and how long it takes to get everything back up and running the way I want it. I definitely like having a central resource to install my stuff from, assuming it's community managed. Honestly, Microsoft making Windows 11 immutable and having everything available on the MS Store or through winget would be an improvement towards what there is now. Assuming some checks are in place to keep bad faith actors in line, I don't mind better (huge emphasis on this, as there's bad examples of centralization like the Apple App Store) centralization, and I've grown absolutely tired of hunting down installers for everything on Google (or in my case DuckDuckGo) and then also having the problem of keeping that stuff up to date. I've recently moved to Fedora after constant distro hopping to see how things are going, and I honestly think that Arch (With pacman and aur), and Fedora/RHEL(With rpm/dnf and copr) do the whole centralization thing that people feared that Microsoft was going to do (ever since the Windows 8 years) far better and in a way that makes sense. A process which I can easily figure out with terminal commands (that you sadly can't do with a lot of installers losely put on GitHub or other sites) and have updated with everything else (rather than the clusterf#$k that is Windows applications which just direct you to a site) is what I personally would choose outside of maybe having the option of automating cloning a Git repo and building/installing manually.
Flatpaks and AppImages are two different things altogether. They are as similar as containers and virtual machines. Both can be used as a single output from source code that'll run on any distro, but inner workings are night and day. Appimages are self contained portable, as the name implies, application images. Flatpaks are the solution between that and a regular package manager. Package managers work great on a few conditions: a) Someone mantains a central repository to match dependencies b) Software is currently mantained c) Software is free and open source, so dependencies can be updated in case the developer doesn't d) The user wants to only keep the latest version available of the software That's the case for most programs, but there are cases where these conditions don't match. Old games can have dependencies on very different versions of, say, dot NET or DirectX. You might think, well, why can't we have a "dot NET" directory with all versions, and redirect accordingly? And in that case you'd have more than a single file to move around. What's the point of it being "packaged" anymore? You'd need a "package manager" for that. Modularity takes away simplicity. All in hopes of saving a few megabytes on disk.
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.
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.
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.
Struggled with snap and flatpak yesterday. Lot of problems with permissions and still user unfriendly. I will try App image some time later. I think I these technologies are still blossoming, some more time to go before they remove bugs and work as smoothly as deb/rpm package.
Or you can just install flatseal if you dont want to configure permissions on cli. On flatseal you have a gui and all permissions are listed there, just need to click on the sliders to give or revoke permissions....
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.
The reason why Flatpak is the best is that it's professionally written, made with desktop apps in mind and integrate well with DEs with sorts of cool feature like sandboxing. AppImage feels to DIY, and yes I'm RedHat fan.
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.
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)
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.
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
A few apps like kdenlive i use them on appimage cuz debían has old repo and flatpak integration/permissions not alwais go brrrrr 😅
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.
Docker containers are equally portable and lightweight. I will agree portability, by whatever means, it beneficial.
Even with different versions. Imagine there is a feature that was removed and is available only on an older version. Or the new version is unstable for some reason. Just double click another executable and you're done, without recompiling or worrying about dependencies.
@@0x007A And where can you find downloadable docker containers for different applications...? Please provide some sites.
It is little-known but it is possible to have portable flatpaks. EndlessOS does this. This functionality will not be introduced into flatpak in general until it is perfected in EndlessOS. In EndlessOS you click a single button and the flatpak is copied in entirety to a thumb drive. No internet required to reinstall on the next system.
@@antoniostorcke interesting, I did not know about this. Going to check it out, thanks.
Flatpaks are decentralized, flathub is just the most popular remote.
Why?!*?#),!
Fn main() -> Why {
Why(println!("why?"));
{
@@xrafter lmao. Rust..
@@sudaphedz433 why?
Yes, I was really disappointed he got something so simple wrong
@@xrafter wtf
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.
yeah I fully agree with you. Flatpaks are the best option for the time being.
Is there any way to run it outside of running a command line? I shouldn't have to run a command line every time I launch the flatpak version of Firefox.
I can't find any way of automatically adding it to my KDE K launcher.
@@somethingelse401 What distro do you use?
that is like asking for a Supply Chain Attack or a Bad code day, and then your app wont run..... however the AppImage will still keep on working. what you got a new app image that doesn't work on your machine but the old one does then use the old one.... very simple and does not require dependency downgrade / conflicts nightmares...
@@adamraad8445 Garuda (Based on Arch)
Never used a Snap or Flatpak, always loved the simplicity of AppImages
You haven't lived yet
I prefer AppImage as well
Only inconvenience is having to launch them from my file manager since they don't show up in the system menu.
You can create a desktop and menu entry for AppImages and Set a custom icon. You just need to create a file in /share/applications you need to create a .desktop File.
Pro Tip:
To make AppImages fully portable, create 2 folders in the same Place where your AppImage is. Both folders need the same name as your AppImage and just add .home and .config.
Example:
ABC.AppImage
ABC.AppImage.home (folder)
ABC.AppImage.config (folder)
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.
Appimage doesn't require root
And the desktop will get crowded with app images if you dont use a terminal
@@gamerking64 You have appimage managers that move the appimage to a set folder and add it to the system/action menu when 1st ran
They’re even better for users migrating from Mac to Linux than for users migrating from Windows to Linux because, like macOS apps and unlike Windows apps, they don’t even need to be installed.
I don't think that's a good thing, and it's not an experience I want to see brought to Linux.
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.
Something like MacOS does, I think is kinda ugly but it works and AppImageLauncher could do the same thing.
I think the best solution would be having a script watch your ~/Applications folder and "Integrate" on changes. It should work both ways, too, so you don't have lingering menu items when you remove an application.
The launcher does just that.
Flatpaks' and Snaps' main flaw is the lack of apps, but with Appimages, I feel like the problem is even worse
Actually the opposite is true, snaps and Flatpaks add the ability to install applications not normally included in most distribution's repositories.
*worse
@@PenguinRevolutionyep I can install snaps on any Linux distro that I can install snapd on
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.
that's very informative. Thank you
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.
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.
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.
That is probably bc the programmer doesn't have such a PC. I don't. I only have x86_64 CPUs.
@@louistournas120 this, in this community software is provided by other users and will be decided by what those users need themselves and what they have access to, people often easily forget that almost everything we do is a community effort and no one pays those people for contributing
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.
VLC installed itself as snap which meant i couldn't play anything outside the sandbox🥺
It matters a lot more for devs. You can just make one app image/flatpak/snap and forget about it, instead of making a package for each and every Linux distro
@@walking_on_earth Realistically it's not every distro, it's just each distro family of which only 3 really matter (Debian, RHEL, Arch), moreover for pretty much all FOSS projects this isn't really an issue at all, since communities of those distros always create and maintain a package even if the developers don't provide one. It does matter for proprietary projects though that only release binaries and don't let us handle it for them. It's also helpful for very big and complex projects with tons of dependencies that can be managed differently depending on the distro, like in the case of OBS, where flatpak provides an "official" release which provides the same functionalities and experience no matter what. Still, there will always be benefits of using standard repos especially for advanced users.
@@walking_on_earth Just go take a look at a kinda recent testimony from one of snaps' main developers at Canonical who went into depression and left the company because of that before telling that's better for devs, forgot his name but certainly easily findable. It might seem "easier" but it brings lots of new parameters on the table.
agreed, tho I don't see what's so bad about building from source
Thanks for another great video and insight as always Derek. Good to see you my friend!
For once I totally agree with DT, now that is a first!
how should updates be handled, any suggestions?
AppImage is my favourite for sure
4:45
my system is not in english, so... where should i put the app images?
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
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 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?
With Appimage there are no updates. If the application you downloaded was not developed with its own update manager then you have to manually download each update from the internet. (It causes huge security issue in the long term.)
Fix: There may be instructions to do updates in some AppImage (not the majority). And if you have a distribution that supports these instructions (because it doesn't manage itself) then it can handle updates. But I heard (I don't know how widespread it is) it was buggy and often failed for the few apps where it tried.
Youve just encountered the biggest problem with appimages and what makes me avoid them at all cost. Theyre just like windows programs, theyre either made to auto update independently or you have to download new versions manually
Doesn't flatpak let you add user repos? You still have to add the flathub repo when you install flatpak iirc
Yes you can add as many repos as you want. So it's fully decentralized.
But almost all beginner distro (not restricted to snap like the main ubuntu distro) have flathub by default (to work out of the box).
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.
Thank you. Finally I understood how to integrate the appimages in my menu.
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.
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.
question i have installed cemu appimage for debian version of linux and it works fine clicking on the appiamge file but when i install appimagelaucher and run that to run the appiamge etc.. it wornt work.
I love the "one file equals one program" concept of AppImage. I just wish more apps/programs were available.
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
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)
Nope Snaps should be #2 in that list
@@PenguinRevolution snaps shouldn't exist in that list
This is correct
This is the correct answer.
@@szymex8341also say it's for arch based
I have tried to install the appimagelauncher-git from the AUR, but it keeps failing to build. Any ideas?
Try the AppImage maybe? :D
I like appimages A LOT. The only thing that bugs me is that I can't change the theme in them to follow the system theme
If you really want you can set. Some appimages support this ( read their documentation). Actually appimages behave like normal apps: use the same configuration files as the "native" apps. For example a Leafpad appimage can be configured with ~/.config/leafpad/leafpadrc as the same way as the installed Leafpad. Maybe you meant other kind of thing, but I think also the theme question could be resolved.
Can someone help
I downloaded the x86_64 appimage of "appimage launcher" and I don't know what to do next
I right clicked on appimage of librewolf but launch with appimage launcher didn't show up
Plzz help
have you got it working
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
5:43 so, it's like portable package thing, right?
AppimageLauncher comes pre-installed in latest releases of Garuda Linux
Appimages are really great for archival. I can copy them to anywhere and it's only one file
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.
Good to hear a different perspective on this for a change!
Why does Appimage Launcher not intercept files for me on Ubuntu 22.04?
Because Appimges used outdated dependencies believe it was liber2, the maintainers are kind of poor at maintaining. Really would recommend flatpaks for better maintenance, and also better developer support, there was a whole controversy with the appimage developers and OBS developers.
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.
What's wrong with apt or pacman? Confused.
You can't take your Debian packages to Arch...or vice versa. The point of Snap, Flatpaks and AppImages is that you have all the libraries and dependencies contained in them, so you can install them on any distro.
@@DistroTube Thank you DT.
@@DistroTube I think fpm could be interesting here, at least the idea. It can convert a debian package to a pacman package. Am I the only one who thinks we just need a better platform to publish packages like AUR, but cross-distribution, without the need for packages to be reviewed? :-(
@@DistroTube What about containers? I can use, for example, Arch on anUbuntu machine!
I love how portable appimg are, i just have a portable app directory that simple move from a machine to another and just work.
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.
Flatpaks haven't won yet, snaps still have a lot of users, including me.
I think AppImage lost the battle.
The integration is bad, it's not secure (no separation from the rest of the computer, and no management of rights), and there is almost never any update management (which is absolutely catastrophic).
Appimages bring to linux one of the worst characteristic of windows, apps that independently auto update
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
> _Hard drives are so cheap we should just enforce programs to contain their dependencies anyway_
i disagree
@@yash1152 a terabyte nvme is $100. I once paid $250 for 30gigs 5400 rpm HDD lol. All measures of economics will disagree with you.
@@paxdriver check your assumption that all people have that money to spare.
@@yash1152 well I assume people using computers could afford their computers. Hard drives are cheaper than power supplies, motherboards, ram, CPUs, and all the other parts that make the system run. It's an economic statement of material reality, not a subjective opinion lol
If you had a 500gb ssd for $50 you could hold thousands of applications with their dependencies. Nobody used 500gb of applications, it's files that take up hard drive space not applications and libraries. Most Linux users root filesystems don't even use 100gb of applications in their lifetimes.
I hate all the ancilliary files that get created all over the place more than anyone else but, at the same time, appimages bring to linux the worst of the windows world since theyre meant to auto update independently
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....
Why couldn't the required functionality have been given to debs and rpms?
but what about dependences? Appimage is supposed to have them statically linked, or does it search for the packages on the system? And if it is statically assembled, then what about the bloat?
Appimage is not supposed to have statically linked. It is a compressed sqashfs image that contains required dependencies.
I've gotta confess: I've never used an AppImage. But you've convinced me to give them a try.
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 used to have an ~/Apps or ~/Applications folder, but it's not really good to have it in your home folder. It's messy, it's one of the reasons I hate Snap packages because of the ~/snaps folder. There's already a Linux folder for your manually (not package manager, distro) installed programs, it's the */opt* folder. I now place them there, and to great desktop environment integration create (or move provided) .desktop files in */usr/share/applications*
Appimages don't have the security containerization of snaps or even the less secure flatpak containerization.
That isnt true.
@@Codename1Alice8 Thank for the reply. I will admit I don't know a whole lot about app images. What method of containerization do they use? I know there are issues with flatpaks which is why they are developing "portals", but I haven't heard anything about appimage containers.
@@linuxdeveloper2325 Technically, an AppImage is a ELF file that also contains an embedded filesystem - usually a squashfs filesystem. All the files needed to run the application are stored here. When you run the file, the program embedded in this file mounts the filesystem in a directory under /tmp
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
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)
Arch repos + AUR = epic win, those are nice for peasants /s still running fedora or debian based distros tho. Compiling from source is rarely an option for the average user.
100% agree. I prefer AppImage way more than the other formats.
in my book appimages is best
How to update app images
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
Libs
Was very frustrated by flatpak after installing wireshark and realizing you cannot capture packets locally and you cannot sudo flatpak run wireshark
So some limitations exist that you just won't be able to overcome and will need to install apps through more traditional methods.
saw The Batman, and I noticed a resemblance between the Batcave and your office
I just realized there is a more up to date appimagelauncher in the AUR called just appimagelauncher.
Appimage's are the best ! Small, fast and fully mobile. The best who someone developed about 20 yo i think. I'm using shortcut near year and it just work. No issues at all. Thanks DT
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.
Exactly! but I have informed certain 3rd parties and they reverted to an older glibc! otherwise newer ones need to be embedded in the appimage.
DT people don't know what app images are or how to use them. By the way what did you put in your path? How & why?
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
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."
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.
"DT, he is an AppImage!"
Didnt see that one coming 🤣🤣
Derek, 4:16 - I find it's better to click on the Files tab under the screenshot, that way you can see the full name of the packages available for download.
Flatpak is decentralized, also its the future of Linux.
Whats the difference between installing the app from the Arch or AUR repository to the Appimage? Does one way work better?
The AUR are just bash scripts, appimages are an isolated application, that does not interact with the user environment. AuR, would be better, because they are now better maintained than appimages, although it does make it easier to break your system, personally. Would recommend flatpaks nowadays if you don't fully understand the AUR yet.
@@Rerum02 thank you for the info.
What are the security implications using AppImages (or FlatPak or Snap)? How can we trust these packages to not do nefarious things on our systems? I think I'll try to stick with native packages, thank you!
The developers on their site should provide their appimages besides the deb, rpm packages... Also a hub is secure, if they check the uploaded files.
Flatpack and Snap are far more secure. Unlike AppImages, they are isolated from the rest of the computer, and their rights can be managed.
@UCi4ISTXO1j3Kz7WGD2uECRg On Flatpack and Snap it's made by default and it has been think for it.
On AppImages it is an other layer you can add on top of it and need to manage yourself.
Be able to turn AppImage into something secure doesn't mean "AppImage is secure".
Otherwise I can say "Windows is more secure than Linux" because you can add more and better quality Anti-virus on top of his poorly secured OS than on Linux.
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.
That's a nice qt theme you got there, which one is it?
Hi guys. Recently had to change working station to MacOS(due to work reasons), what is the adequate WM for macOS ? On Linux I’ve been using i3wm.
Have tried amethyst - not satisfied .
Heard about yabai, but since this is working laptop I do not have permissions to turn off some security things yabay requests to.
Any suggestions ?
Can docker image become a viable alternative?
I'd love to see the Linux kernel as an appimage.
Do you think appimages would work decently over an nfs? Like mount your nfs share to ~/Applications store your apps there, then do that on all your linux computers, so they all share the same apps and all share the same configs. Or do you think that'd be slow?
I think it depends on bandwidth to just "download" and mount them. I've tried it on a atleast 48 MB .AppImage file. it works very fine and quite slow to initialize. But it's good to share with other people.
While decentralization is good, it also makes me worried about the security issues associated with randomly downloaded and installed appimages.
The developers on their site should provide their appimages besides the deb, rpm packages... Also a hub is secure, if they check the uploaded files.
@@hantimagyar Yeah. We should only be using appimages from the developer sites and from well known hub(s) only. But I still feel that going all for appimages/snaps/flatpaks is going towards the windows way of application installations. I thought (and still think) the Linux distro way of packaging was technically superior way of managing packages. The problem flatpak et al are trying to solve should be solved through standardization of distro based package management. Would there be too much of an issue if all distros standardized on a single package management tool (much like more or less every distro has switched to systemd nowadays)?
@@gamerboy4566 This also depends on how you use the OS. For example I use only live systems, never install any OS (and any application). So the "appimage way" is the best option for me. Actually the only usable way... The solution would be just the "standardization" of appimages. I mean by this: universal and security checked appimage repo(s) (common for all distributions), and all package managers should support them. This could make app development mor efficient, less time and energy waste both for app and distribution developers, and would strengthens the Linux world in general. Distribution developers should ensure that these standard appimages could run on their systems.
@@hantimagyar For your use case, appimages do seem to be the best option.
I'll consider using appimages when they can be installed from the terminal and appear in the app menu on gnome, kde, cinnamon, etc just like snaps and flatpaks.
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?
I installed Mint cinnamon and I like it but flatpacks..maybe anyone knows distro like Mint but without flatpacks?
Mmm ... A principle of flatpacks is to be totally universal. So you're asking for a distro that doesn't support something made to work everywhere ?
@@labonnelambda58 no, which aur or other packages
If what you want is default applications to be in AppImage format ... you can uninstall the applications and reinstall them with AppImage.
But that's stupid because your apps will take up a lot more space, will be poorly integrated, and you'll never have any update on an application if it has not been specifically developed with his own update manager (huge security issue).
@@labonnelambda58 OK, thanks for advice
Snaps be causing the system to take a billion years to start up, and Flatpaks still have some issues regarding permissions (Steam for example requires steam-devices which isn't even installed by default through flatpak to get controllers working). I believe RetroArch's Linux build that's on Steam uses AppImage, and that seems like an okay solution. I think that Valve solely relying on Flatpaks in SteamOS 3.0 is going to present issues that other immutable distros like Fedora Silverblue doesn't have (due to having an equivalent to dnf called rpm-ostree where you can install standard rpm packages from).
I also think the setup process for getting a system up and running in Windows is a pain in the ass with how many things you have to go onto a search engine to find, and download installers for (that you can't keep on your hard drive due to easily becoming outdated). Stuff like Chocolatey's user repository (considering how scarcely used MS's WinGet is) and how Linux distribution repos and Flathub are set up are definitely a life saver considering how many unstable Windows builds that I've had, and how long it takes to get everything back up and running the way I want it. I definitely like having a central resource to install my stuff from, assuming it's community managed. Honestly, Microsoft making Windows 11 immutable and having everything available on the MS Store or through winget would be an improvement towards what there is now.
Assuming some checks are in place to keep bad faith actors in line, I don't mind better (huge emphasis on this, as there's bad examples of centralization like the Apple App Store) centralization, and I've grown absolutely tired of hunting down installers for everything on Google (or in my case DuckDuckGo) and then also having the problem of keeping that stuff up to date. I've recently moved to Fedora after constant distro hopping to see how things are going, and I honestly think that Arch (With pacman and aur), and Fedora/RHEL(With rpm/dnf and copr) do the whole centralization thing that people feared that Microsoft was going to do (ever since the Windows 8 years) far better and in a way that makes sense. A process which I can easily figure out with terminal commands (that you sadly can't do with a lot of installers losely put on GitHub or other sites) and have updated with everything else (rather than the clusterf#$k that is Windows applications which just direct you to a site) is what I personally would choose outside of maybe having the option of automating cloning a Git repo and building/installing manually.
thanks for the video. I'm learning something.
Flatpaks and AppImages are two different things altogether. They are as similar as containers and virtual machines. Both can be used as a single output from source code that'll run on any distro, but inner workings are night and day. Appimages are self contained portable, as the name implies, application images. Flatpaks are the solution between that and a regular package manager.
Package managers work great on a few conditions:
a) Someone mantains a central repository to match dependencies
b) Software is currently mantained
c) Software is free and open source, so dependencies can be updated in case the developer doesn't
d) The user wants to only keep the latest version available of the software
That's the case for most programs, but there are cases where these conditions don't match. Old games can have dependencies on very different versions of, say, dot NET or DirectX. You might think, well, why can't we have a "dot NET" directory with all versions, and redirect accordingly? And in that case you'd have more than a single file to move around. What's the point of it being "packaged" anymore? You'd need a "package manager" for that.
Modularity takes away simplicity. All in hopes of saving a few megabytes on disk.
Do Appimages get updated with system updates?
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.
deb - 5mb, appimage - 40mb
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.
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.
Struggled with snap and flatpak yesterday. Lot of problems with permissions and still user unfriendly. I will try App image some time later. I think I these technologies are still blossoming, some more time to go before they remove bugs and work as smoothly as deb/rpm package.
Or you can just install flatseal if you dont want to configure permissions on cli. On flatseal you have a gui and all permissions are listed there, just need to click on the sliders to give or revoke permissions....
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.
Hey DT, do you know of any FOSS tax software similar to TurboTax?
The reason why Flatpak is the best is that it's professionally written, made with desktop apps in mind and integrate well with DEs with sorts of cool feature like sandboxing. AppImage feels to DIY, and yes I'm RedHat fan.
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.
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)
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.
Great work 🥳 Thank you 💜
i use the AUR for what i need......i've used some flatpaks and appimages depending what it was.