Keep Your Snaps and Flatpaks, I'll Take AppImages!
HTML-код
- Опубликовано: 21 авг 2024
- There is so much discussion about universal packaging formats on Linux. But the discussion always seems to be centered around which is better: Snaps or Flatpaks? It's almost like people don't realize that there is a third option...a BETTER option!
REFERENCED:
► www.appimagehu... - AppImageHub
► www.appimagehu... - AppImageLauncher
► github.com/pra... - AppImagePool
WANT TO SUPPORT THE CHANNEL?
💰 Patreon: / distrotube
💳 Paypal: www.youtube.co...
🛍️ Amazon: amzn.to/2RotFFi
👕 Teespring: teespring.com/...
DONATE CRYPTO:
💰 Bitcoin: 1Mp6ebz5bNcjNFW7XWHVht36SkiLoxPKoX
🐶 Dogecoin: D5fpRD1JRoBFPDXSBocRTp8W9uKzfwLFAu
📕 LBC: bMfA2c3zmcLxPCpyPcrykLvMhZ7A5mQuhJ
DT ON THE WEB:
🕸️ Website: distrotube.com/
📁 GitLab: gitlab.com/dwt1
🗨️ Mastodon: fosstodon.org/...
👫 Reddit: / distrotube
📽️ LBRY/Odysee: odysee.com/@Di...
FREE AND OPEN SOURCE SOFTWARE THAT I USE:
🌐 Brave Browser - brave.com/dis872
📽️ Open Broadcaster Software: obsproject.com/
🎬 Kdenlive: kdenlive.org
🎨 GIMP: www.gimp.org/
💻 VirtualBox: www.virtualbox...
🗒️ Doom Emacs: github.com/hli...
Your support is very much appreciated. Thanks, guys!
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 😅
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
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.
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.
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
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!
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.
For once I totally agree with DT, now that is a first!
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.
AppImage is my favourite for sure
in my book appimages is best
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
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
Flatpak is decentralized, also its the future of Linux.
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 love the "one file equals one program" concept of AppImage. I just wish more apps/programs were available.
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
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.
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.
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.
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).
Appimages are really great for archival. I can copy them to anywhere and it's only one file
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
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.
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
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
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.
AppimageLauncher comes pre-installed in latest releases of Garuda Linux
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.
Thanks for another great video and insight as always Derek. Good to see you my friend!
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.
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
"DT, he is an AppImage!"
Didnt see that one coming 🤣🤣
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."
appimage fan here!
100% agree. I prefer AppImage way more than the other formats.
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....
Thank you. Finally I understood how to integrate the appimages in my menu.
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'd love to see the Linux kernel as an appimage.
I've gotta confess: I've never used an AppImage. But you've convinced me to give them a try.
deb - 5mb, appimage - 40mb
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.
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
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 really like AppImages
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.
saw The Batman, and I noticed a resemblance between the Batcave and your office
Good to hear a different perspective on this for a change!
Time to learn :)
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.
I like Appimages I think they are truely the Universal package and super portable!
Great work 🥳 Thank you 💜
I just realized there is a more up to date appimagelauncher in the AUR called just appimagelauncher.
how should updates be handled, any suggestions?
the αcτµαlly pδrταblε εxεcµταblε format has my curiosity.
i use the AUR for what i need......i've used some flatpaks and appimages depending what it was.
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
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.
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
They should write a cli package manager which has things like updates and stuff for appimages
That's Flatpak, it's decentralized too.
appimages can technically be independently delta updated but it relies on the person maintaining the appimage to provide certain files in the appimage, and many do not. A cli package manager for appimagehub would be nice though.
Keep your package managers, I'll take random EXEs I found online!
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.
thanks for the video. I'm learning something.
I'll happily stick with the apps in the Debian repos.
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
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.
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.
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.
I love appimages. They just work.
Movie monad was there it just didn't have an icon.
hear hear, i prefer the simplicity of appimage too
I always believe in Deb
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
I'm with you! I want and like appimage more than others.
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.
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
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'll take, static executables
Me too. Appimages all the way
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.
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!
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.
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!
THIS.
I fricking hate flatpaks and snaps.
Rule of thumb to what to use
If you dont need latest always --> appimages
else
if the appimage provides delta updates --> appimages
else flatpak
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.
AppImages are great! Love them. Always have.
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.
You're only half right. The only real repository where you can get any real use is the Flathub repository and most people use that repository. So you're just trading one centralized repository for another.
Also, many developers packaging their software as appimage does not provide any method to verify the authenticity of the file you download. It is just the linux version of exe-installation in windows that is already considered to be a very unsafe way of installing software. I would love to see developers uploading their software to the official flatpak repository.
Not true. Try downloading a flatpak, and then install it without using the flatpak cli or a gui manager and see how easy that would be, the same goes for native packages. Launching an AppImage is just download, change permissions and run, it does not get more simple. What it need is integration into the software managers, a proper online repo and maybe some cli command to deal with an online repo from command line. But this has nothing to do with the AppImage format in any way. It's just that no one has done it, but rather they made a new format for which they have made these integrations and tools.
@@danielberglv259 "The problem with appimages is that they are not as simple to install as the rest of apps on Linux."
1. Appimages do not need to be installed! And just this is the main advantage and difference between them and all others.
2. In my opinon it is a lot easier to download an appimage and then use it in different Linux distributions than install the same app (and the dependencies!) separately for every distribution.
@@danielberglv259 really because with snap all you have to do is install and go without changing permissions. Also with snaps it's available for all users, with appimage you don't have that benefit. Also Snaps auto update, appimage doesn't. Snaps are much better and more efficient.
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?
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 don't like how complex the syntax is to run a flatpak package and how clunky snaps are. Appimages are simple and better.
You can just alias the flatpak run command if you really need
You can make an appimage in 5 minutes or less. A Flatpak on the other hand, could take an hour or more to put together. From a technical standpoint, and from the perspective of the end user, Flatpak is superior.
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.