@TechHut there is programs for all the need of appimages, installing them and make the desktop images and there is a repos, with package manger for Appimages
An Applications folder like MacOS has that you can drop AppImages into would be fantastic if a distro or DE could integrate them. The AppImage could state what category the program is, Internet, Multimedia, Office, Utility, ect. and the DE would automatically add it when dropped into the Applications folder.
I always prefer to use the distro's repo's cos they're better intergrated into the system but if there's an app i want the isn't in the repo's i always use flatpak.
Great Video! Even if I'm an Appimage user, I was blown away with these results! for me Appimages + Appimage Launcher makes my life so much easier especially when upgrading an OS.
I feel Appimages are extremely underrated. Backward compatability is lowest priority in many applications, combined with the fact that not all parts of the app is regression tested, I may want to have a stable, self contained applications. I had lost many kdenlive projects due to snap auto update.
I like the idea of appimages, but my understanding is they're kinda barebones and may actually not provide all the necessary libraries, like the recent issue of it depending on the system libfuse. They could be good but I think they aren't much more than someone's hobby project that they can't dedicate enough time to.
This is Actually an accidental good feature...why? because alot of times you update an app, it copies over the old one and then you discover Features were removed! HELL NO! this has hapened too many times... I just manually download the Latest, and also keep the previous in the same folder I put all my AppImages....and I can use Both! Often I keep 4 previous versions because it seems to be common the Newer the App, the heavier and bigger it is.... this pisses me off as it slows down your computer more and more....then becomes a problem when you have to perform publicly and need 3 apps open that happen to be AppImages and they no lobger work smooth together because they are all heavier. Nope! hell no. I keep my old versions. With Flatpak and SNAP, they erase your old versions.
@@serifshen938 for apps which are difficult to build or harder to compile, I install the flatpak version or alternatively the snap, an Appimage all the better if available
Just ran the gimp lava test on endeavourOS and my results were similar to yours. Took 26+ seconds to run natively, and only 17+ on the appimage. So I'm switching to the appimage.
Good start on this. But I might recommend also doing a bit more profiling with the apps. IE, differences in CPU and memory usage, and looking at I/O activity. Also, your tests are very display centric... You should probably consider some other types of benchmarks: recalculating a large spreadsheet in Line Office Calc, generating a large pdf in Libre Office Write, and zipping & un-zipping large archives in 7-Zip would be good tests (and I think these apps are available in all package formats). I think tools like perf and/or system tap will help you capture some interesting information about system resource usage as you run the tests.
Just upgraded Ubuntu and was amazed they decided it would be an improvement if their default web browser took an eternity to launch. Browser is one of THE most used apps on any system. Who signed off on this?!
Great experiment Brandon! I'm currently using more Flatpaks for general use since I'm on Pop!_OS 20.04 (I need the LTS stability) so a lot of software are outdated on the apt repos and Flatpaks save me a lot of times. Thanks to your video though I'm going to try out AppImages more too!
@@rishirajsaikia1323 tried upgrading to 21.04 back then but I had upgrade issues so I had to revert back to 20.04. Will try again this 22.04 but I'd still go for Flatpaks for most software right now.
I wonder what the actual difference is. Would not expect performance to be different after the app is loaded. I'm thinking maybe maintainers of some appimages just happen to be using different compiler options which are better optimized and more generic stuff from fedora/ubuntu repos is slower
This is great stuff, but why is Flatpak or AppImage so much faster compared to the native package manager in the Motion Mark test? And why is it slower in Kdenlive rendering? What's the technical explanation behind these results?
I found compiling handbrake makes a huge difference, from 40 seconds to 26 seconds to compress a video for example. The same applies for snap version of kdenlive, performs much better than repo version. What would be interesting is to see if you can do this benchmark for kdenlive or some other app but include building the app yourself!
Why does it always seem like whenever Ubuntu gets to a good usable point, they always do something silly that makes a lot of their experienced users angry??
There's nothing inherent to flatpack/snap that would have any impact on these benchmarks. It's probably down to differences in versions and dependencies etc. I'm extremely skeptical that you are measuring anything meaningful in these benchmarks and that they aren't overwhelmed by something else going on. The main performance issues with Snaps has been compression, which effects initial launch times, mainly due to packages that use the slower xz compression scheme and haven't updated to lzo compression.
I think if you're interested in doing a more scientific comparison between the different packaging styles, you could go ahead and take the same exact version of the software with all the same exact configurations and build them into each of the different container types. I firmly believe a large percentage of all the differences you were changing have to do with configuration variances between the applications unless to do with the package types themselves. The fact you had all the package types beating out native installs on the first few examples is highly suspicious and most likely points to a lot of those configuration differences between the applications. I do like the fact that you did compare a couple different application types with different type of functionality, but I think it would be Saturday more interesting instead of focusing on different software categories, focus on different forms of IO under those applications. For instance, focusing on GPU acceleration for one test, on CPU utilization for another, intensive RAM operations for another, network communications as another, file system IO, and the one that everybody seems to miss is USB I/O operations, for both USB thumb drives, but other USB devices that does intense IO like image capture or software-defined radio. However that would all be a lot of work, and I think that's the reason why nobody ever does a really great comparison between the different package types. But until we have that level of care given to the creation of the tests, I think that we should be very careful with reading too much into any of the results you or other people with similar tests have provided.
I was about to post the same thing, but saw your comment which says it better than I can. At the very least, the comparison should be using the same version of the software. Running a benchmarking suite that tests the different components separately would be tell us a lot more than the tests in this video.
Why we can't just appreciate the fact that all these different formats were created for a reason.. This reason being: as an alternative to the deprecated software that some distros are serving, no matter what the state of that distro is. eg. Someone can run the most recent piece of software, even in a very old Ubuntu LTS distro, that's fantastic ! Let alone security, less system maintainance, ease of distribution from the software developers (upstream) etc. It's a great thing to have !
Great video, this provides really invaluable insight. I would be interested to see how the AppImage times compared if it was also in a sandbox (since with the standard use of it you're not testing this, whereas the other two, flatpak and snap, do use a sandbox). Sandboxing seems pretty wise in general to avoid the apps being able to do things they shouldn't (and if mobile apps taught us anything, it's that they will do stuff they shouldn't, often aggressively!!)
Appimage for the win. Even when I was a Win user I always opted for a portable version of an app. It saves time, it saves space, it's easier to manage (move, share, delete / no registry littering and other traces of the app I might not need and files that would otherwise just take space for no reason) and yes I'm ready to compromise on performance and launch time if it means the app is easier to manage.
If someone built a distribution around it, appimage could be used to create a Mac-like way of dealing with installed software by having an Applications directory where you can put appimages to "install" them like .app files on Mac OS.
An interesting test! Out of consistency, I anyways use flatpaks for most applications whenever I can. And though I do work now and then with apps like Gimp, Inkscape and rarely Kdenlive, I do not care too much if some things are taking longer. E.g. I do not care too much if I have to wait 10 min or 15 min for a video to render. But my hope is, that habitually using flatpaks makes my debian-based OS installs more up to date and my arch-based OS installs less likely to brake. Also this way I can use a debian-based system and an arch-based system and barely notice a difference ;)
You could use Fedora or Manjaro to have near bleeding edge with very good stability. I only run Debian on servers these days. Btw, met a guy who is using Manjaro in production for 5 years now without major incidents.
@@emeukal7683 Yeah, last week I bought a RX6600 card and with that Manjaro xfce wont work. Was using it for almost 2.5 years. And the problem with that card is a known issue in the Manjaro forum without a solution. So now I am using MX Linux xfce for my everyday gaming setup. Manjaro Gnome works and I have that on my second drive. Fedora is on my work desktop. And of course I know, that there are distros that want to provide a stable up-to-date experience with their distro repos, but my point in my comment is, that with flatpaks you need less to worry about that anymore and even distros on opposite ends both can appear similar stable and up-to-date... to a certain extent of course.
@@Beryesa. Exactly! And that is again something that brings distros closer together. I mean, I barely notice whether I use Gnome with Material-shell extension on Fedora or Endeavour. And then most software is handled with flatpaks...the same. And then the only difference is, whether I type "yay" to update or "sudo dnf upgrade". Though you do see a huge difference in system resource usage between those two distros, if you bother to look :D
I just watched a Chris Titus Tech video showing how slow Firefox starts up in Ubuntu as a snap app vs. Firefox in his Fedora Linux installation. It was a night and day difference with Ubuntu's Firefox Snap app taking almost 4 seconds to start every time he would try loading up the application.
I love your benchmarking videos. it would be really great if you released another video that compares the resource usage as well as boot-time differences of the applications after cold boot and relaunch.
Thanks for researching this and helping us consider this technology topic. Yes, I've wondered about this exact question, but looks like it does matter on some & not on others.
I had a question, how did you manage to turn on fractional scaling for fedora on Wayland since many X11 applications that run on Wayland and are not yet ported to it use "xwayland" and xwayland for me causes the overall UI of the apps to be blurry, was it for you as well or did you find a solution for it?
If what he said is correct that makes perfect sense, as they don't seem to have any isolation. All they seem to do is bundle in typically dynamically linked libraries, otherwise they're native. That btw would be my running theory for the cases where these container images were faster than native packages, that they bundled libraries that were in some way better for performance than the libraries on the system, that are shared between all applications. I've seen something like that in action at least once, with a Rust Web-Application. If you link it to musl vs glibc than you get a static binary vs one with a dynamic link dependency, but in speed tests it was significantly slower than the glibc version.
Thank you. Been contemplating between using Snaps or Flatpaks for general use applications like web browsing and music player and after watching this, I'm going with Flatpaks.
Maybe I missed it in the video but as far as I know: Snaps only download dependencies if you don't have them already. So one dependency is for all the snap programs. Flatpaks on the other hand download dependencies multiple times so for every program all dependencies whether you have them already or not.
That's an issue with poor package writing, not Flatpak - if people made their package metadata for dependencies depend on a series of versions of dependencies rather than just the one version of them the issue wouldn't occur since Flatpak would know the version of that dependency already installed is fine for usage on the new package according to its dependencies.
@@jeschinstad Wdym, here is the answer from 2018: "Deduplication at a file level across snaps is not happening. If you put many copies of one file into one snap then yes, those are de-duplicated. If you have a need of sharing larger amounts of things among a set of snaps then please use the content interface. Lastly we have base snaps that lets one change the root filesystem (to contain any set of extra libraries) but this feature is a little bit immature across the stack (snapcraft and snapd)."
@@Beryesa.: I don't know who answered your question in 2018, but the answer is totally wrong. SquashFS does not allow deduplication of files, so that cannot happen in Snapd until SquashFS is replaced with a COW filesystem like Btrfs or ZFS, both of which are open opportunities. But bind mounting is an old Unix thing. Snap simply makes use of them.
About the apps running in a sandboxed environment without the danger of interfering with the rest of the system, this is a desirable, not an enforced requirement. For instance, flatpak restrict access by default to several resources and syscalls, but whoever builds one can loosen these restrictions at will (as the application otherwise may not work): "Most applications will need access to some of these resources in order to be useful. This is primarily done during the finishing build stage". As someone else mentioned macos app bundles behave better and sandboxing is actually enforced at various levels. Said that, thanks for the video, I always wondered how different solutions behaved in terms of performance. 👍🏻
There should not be such massive speed differences between those 4 app installation options. This means there is an urgent need for optimisations for the ones who lags behind at the benchmarks
Indeed. I can immediately see why first run startup can differ between these solutions. And speeds could differ because you get different versions with all of these packaging formats. But I'm surprised that the same version of Firefox doesn't run at more or less the same speed after install with all of those formats.
Snap doesn't get enough user base and so Snap doesn't get to improve as much as flatpak. The fault is with Canonical. Many users doesn't use Snap just because the Snapstore is proprietary.
EXACTLY! I have like 100 apps in Appaimge format and can instantly get up and running a new system with a 100 new apps in seconds by just dragging them on the new system.
What's the difference(s) between apt/dnf programs and .appimage programs? I always thought they were synonymous terms. But your chart at 5:38 lists them separately.
Interesting. I had been against all-dependencies-included packages as they use more of my SDD - except where there was no practical alternative, e.g. new versions of Thunderbird available much quicker with snap than apt. Now I will be more judicious - especially with Firefox and FFDE. Thanks, Hutman *EDIT* Replaced APT Firefox with Flatpak Firefox. Not the 20% increase I'd hoped for but a bit quicker at the same time.
Since Storage are getting cheaper, i would prefer larger file with fast execution and all dependencies included and run at demand like it wont hook into the background if its an Appimage (i think). It would fit in my use case
Great video, congratulations, if possible you could include in other video the native apps (deb and rpm format) and compare with snap/flatpak/appimage.
You forgot the one and a half years it takes to start the flatpak versions in the first place. Jokes aside, great video. Do you know if switching to an SSD would improve Flatpak's loading times?
@@emeukal7683 the first reason is: i'm poor. The second reason is: my neoliberal goverment is letting the dolar float freely so it is about $45 for a dolar. The third reason: salaries have been growing at a slower rate than inflation for the last 2 years, with no expectation of growing any time soon, so i can buy less things for my money with every passing minute
This was excellent. Thank you. As a follow up, did any of the formats show different system usage? Does the isolated flatpack require any more overhead to run in a sandbox; for example?
Without understanding WHY the firefox in packaged-form was faster than native, we really can't conclude anything. Good vid tho' - it shows the issue well.
Why people never talk about Flatpak having built-in permission. All other would require a firejail or similar to achieve the same. Could you do a test adding firejail to appimages so we can check if they get slower?
I'm so happy with Appimage that is the dev give me that I try no else. 😃 Otherwise, I try the system package or, least, flatpack. Snap only if there is no other choice, with is so rare, I only had 2 nowadays. I'm on Mint, by the way 😁
Why would the apt/dnf version be slower? Isn't this just installing it directly? Maybe it's not... Does that mean it will run faster if you build the code yourself directly on the system you are installing it in instead of using any of package managers?
I use Appimages mostly. I do have 2 Flatpak because the Appimages are way out of date and that the one issue with Appimages. I also install the repos version sometimes too. I like the portability of Appimages. just copy it to the next computer and use it... :-) LLAP 🖖
4:37 -- But it's actually the Speedometer test that you end up doing anyway. Weird that it made its way into the video judging by how incorrect the statement was.
Damn they are all so different! But snaps never had any substantial lead over others, so I'm not regretting not using them. Thanks for the wonderful video! :D
Statistics need to be taken about app deps, so heavily used deps can be shared and the rest bundled with the app they're for ( most efficient resource use ).
Was it the only run per each different distribution method or multiple ones? When you’re dealing with such a waxy substance as IT you cannot rely on a single try
WHAT do you do if you have , say- NETRUNNER-- which is ALL Appimage based- and you need software that is NOT available in an appimage??? Will flatpaks work as well? I tried Netrunner and had issues-- several of them- and I think that maybe that was because I did something wrong with the flatpaks I installed...not working well with the appimage ones..??? who knows..
Great explanation. Do you think the results in something like Manjaro would be different? I generally try to download officially repository stuff, or aur library if it isnt there.
you might dislike snaps, but they're not as bad as it seems. snaps are great for server use: simply install and never care about updates again, they're completely isolated from any other dependencies or the system. and the benchmarks show that even on Ubuntu desktop, they outperform the apt packages quite often because they seem to have the dependencies better under control as well. so I understand why cannonical is pushing them. if Adobe ever were to release their software for Linux, it'd be as snap packages.
yeah I just install the native if possible and then if I want more privacy or control over an app I then use flatpak, and then appimage if I want it to run without installing it over and over
It is so unfortunate that Surfshark is advertised on a Linux channel. It doesn't even have a GUI for Linux and nor does the other features, like Wireguard and Killswitch, work on Linux.
How can the same version for Firefox run (much) slower as a "native" system binary than via a sandboxed environment? How can an additional software layer speedup a process?
Probably has to do with the dependencies. Performance improvements in libraries will show in the generic packages because the developers choose which versions to use whereas the native package uses shared libs already installed through the distribution’s package manager.
Question: Kdenlive runs better on apt/dnf installs but aren't they usually way older than the latest release? How can you have the latest packages with apt/dnf?
I have a question what does the native gui appstore use ? Like for popshop what package manager it uses? Or can I change it to whatever package manager I want? I m beginner. And nice video brandon.
Graphical interface doesn't matter, your distro does. Debian and Ubuntu family uses apt, Fedora uses dnf, arch uses pacman. Flatpak is a distro-independent package format and can be installed everywhere. Appimages are just static executables (like portable .exe executables), should work on any distro released after 2014
Old Network/System Admin here.... Interesting Video.... But... I assumed you used fairly modern PC components with plenty of RAM in these tests. How about running these tests again on older hardware? I suspect you are going to see different results with systems with 2 to 4 CPU cores and less then 2GB of RAM. I stick with traditional APT packages period for security reasons. But.... I have tried SNAPS on older hardware desktop setups. And I can tell you... Waiting 5+ seconds to just open a SNAP WEB browser is very painful.
I've never liked SNAPS--- and recently- got a home alarm system that requires ANDROID-- so installed a SNAP of Blink for the software to monitor it. I've had NOTHING but issues since I installed that--- it's made all kinds of things NOT WORK-- and I know you guys say it can't-- but it DID.. and I finally took it off- reloaded everything and it's fine now-- no issues at all.. SO I"LL NEVER use another snap...
I'm running kubuntu ATM and RetroArch snap that's recommended doesn't detect my secondary hard drives. Now I'm torn between appimage QT or flatpak. Or screw it all and go nightly 🤷♂️
View the transcript and charts:
medium.com/@TechHutTV/flatpak-snap-appimage-linux-benchmarks-df2bc874ea0b
@TechHut there is programs for all the need of appimages, installing them and make the desktop images and there is a repos, with package manger for Appimages
May you do a video on cgroup v2?
Maybe next time do fedora vs Arch based as no one should be using ubuntu distros at this point.
An Applications folder like MacOS has that you can drop AppImages into would be fantastic if a distro or DE could integrate them. The AppImage could state what category the program is, Internet, Multimedia, Office, Utility, ect. and the DE would automatically add it when dropped into the Applications folder.
well and an easy update system. The argument about diskspace is a bit meh.
there is a program for making the desktop icons, and there is a package manager for appIamges..se DT video on appImages
There is a project called AppImageLauncher which does exactly that
The BSD OS HelloSystem is doing something like this.
A simple right click + install would do but nah guys we need to make it as complicated as possible!
I always prefer to use the distro's repo's cos they're better intergrated into the system but if there's an app i want the isn't in the repo's i always use flatpak.
same here.
If you use flatpak only for one app or two, initial runtime space usage will not pay itself until you really make use of it more (5 or more apps)
Also they share stuff so I think it's best for general system performance.
I prefer to use flatpaks for everything. If there is no flatpak option available, then I go to the native package.
@@Deplissee Flatpacks also share stuff with each over but just there is not sharing much between system apps and flatpacks.
Great Video!
Even if I'm an Appimage user, I was blown away with these results!
for me Appimages + Appimage Launcher makes my life so much easier especially when upgrading an OS.
I feel Appimages are extremely underrated. Backward compatability is lowest priority in many applications, combined with the fact that not all parts of the app is regression tested, I may want to have a stable, self contained applications. I had lost many kdenlive projects due to snap auto update.
Exactly! SNAPS were updating behind my back ruining my system. I dont use them anymore. I use Flatpak and Appimage and Binary and Debs
I like the idea of appimages, but my understanding is they're kinda barebones and may actually not provide all the necessary libraries, like the recent issue of it depending on the system libfuse. They could be good but I think they aren't much more than someone's hobby project that they can't dedicate enough time to.
Appimages don't work on Linux distro's without "system-d" ....that's a very big minus for me...I switched to Flatpak because of it
Appimages are great until you have to manually update every one you have if you want the latest update
Appimages can be auto updated, But it is up to the developer to implement it. Lbry Appimage automatically update itself.
So basically the classic Windows way of doing things.
@@nabildanial00 yes and none of us would want to return to the dark ages I would imagine
This is Actually an accidental good feature...why? because alot of times you update an app, it copies over the old one and then you discover Features were removed! HELL NO! this has hapened too many times... I just manually download the Latest, and also keep the previous in the same folder I put all my AppImages....and I can use Both! Often I keep 4 previous versions because it seems to be common the Newer the App, the heavier and bigger it is.... this pisses me off as it slows down your computer more and more....then becomes a problem when you have to perform publicly and need 3 apps open that happen to be AppImages and they no lobger work smooth together because they are all heavier. Nope! hell no. I keep my old versions. With Flatpak and SNAP, they erase your old versions.
@@eijentwun5509 can't you roll back flatpaks in the same way as native packages?
Each one is useful in it's own way. For some apps I prefer the flatpak version, for others I prefer either snaps or Appimages
What are the determining factors?
@@serifshen938 for apps which are difficult to build or harder to compile, I install the flatpak version or alternatively the snap, an Appimage all the better if available
100% agreed
GIMP icons look normal with snap and a bit smaller with flatpak
@@skelebro9999 you know you can just change that ??? it is just a file on your system.
@@zeocamo idk :p
Just ran the gimp lava test on endeavourOS and my results were similar to yours. Took 26+ seconds to run natively, and only 17+ on the appimage. So I'm switching to the appimage.
Good start on this. But I might recommend also doing a bit more profiling with the apps. IE, differences in CPU and memory usage, and looking at I/O activity. Also, your tests are very display centric... You should probably consider some other types of benchmarks: recalculating a large spreadsheet in Line Office Calc, generating a large pdf in Libre Office Write, and zipping & un-zipping large archives in 7-Zip would be good tests (and I think these apps are available in all package formats).
I think tools like perf and/or system tap will help you capture some interesting information about system resource usage as you run the tests.
Just upgraded Ubuntu and was amazed they decided it would be an improvement if their default web browser took an eternity to launch. Browser is one of THE most used apps on any system. Who signed off on this?!
And be prepared, I've heard that the next plan of Canonical for the next release of Ubuntu is to be all snaps
So, appImages sound and look great, but having to check for new versions manually sounds boring to me..
I'd go for a package manager/flat mix 🙌🏻
Great experiment Brandon! I'm currently using more Flatpaks for general use since I'm on Pop!_OS 20.04 (I need the LTS stability) so a lot of software are outdated on the apt repos and Flatpaks save me a lot of times. Thanks to your video though I'm going to try out AppImages more too!
Or you can just use the 6 months release version.
@@rishirajsaikia1323 tried upgrading to 21.04 back then but I had upgrade issues so I had to revert back to 20.04. Will try again this 22.04 but I'd still go for Flatpaks for most software right now.
⏰STARTUP time - You forgot to benchmark the average application startup time 😎
Specially for the first run
@@rauli386 yeah - both the slow first run, but also the second not so slow run :D
I wonder what the actual difference is. Would not expect performance to be different after the app is loaded. I'm thinking maybe maintainers of some appimages just happen to be using different compiler options which are better optimized and more generic stuff from fedora/ubuntu repos is slower
This is great stuff, but why is Flatpak or AppImage so much faster compared to the native package manager in the Motion Mark test? And why is it slower in Kdenlive rendering? What's the technical explanation behind these results?
I found compiling handbrake makes a huge difference, from 40 seconds to 26 seconds to compress a video for example. The same applies for snap version of kdenlive, performs much better than repo version.
What would be interesting is to see if you can do this benchmark for kdenlive or some other app but include building the app yourself!
Fun fact the guy who made that blender file you used for testing, Erindale on youtube, uses manjaro on his laptop.
Why does it always seem like whenever Ubuntu gets to a good usable point, they always do something silly that makes a lot of their experienced users angry??
There's nothing inherent to flatpack/snap that would have any impact on these benchmarks. It's probably down to differences in versions and dependencies etc. I'm extremely skeptical that you are measuring anything meaningful in these benchmarks and that they aren't overwhelmed by something else going on. The main performance issues with Snaps has been compression, which effects initial launch times, mainly due to packages that use the slower xz compression scheme and haven't updated to lzo compression.
Is it the compression? I would argue that most don't even need compression nowadays. 1Tb is cheap
Either way I totally agree. Just testing differences in version
Would have to test the same version of the same software
I think if you're interested in doing a more scientific comparison between the different packaging styles, you could go ahead and take the same exact version of the software with all the same exact configurations and build them into each of the different container types. I firmly believe a large percentage of all the differences you were changing have to do with configuration variances between the applications unless to do with the package types themselves. The fact you had all the package types beating out native installs on the first few examples is highly suspicious and most likely points to a lot of those configuration differences between the applications. I do like the fact that you did compare a couple different application types with different type of functionality, but I think it would be Saturday more interesting instead of focusing on different software categories, focus on different forms of IO under those applications. For instance, focusing on GPU acceleration for one test, on CPU utilization for another, intensive RAM operations for another, network communications as another, file system IO, and the one that everybody seems to miss is USB I/O operations, for both USB thumb drives, but other USB devices that does intense IO like image capture or software-defined radio.
However that would all be a lot of work, and I think that's the reason why nobody ever does a really great comparison between the different package types. But until we have that level of care given to the creation of the tests, I think that we should be very careful with reading too much into any of the results you or other people with similar tests have provided.
I was about to post the same thing, but saw your comment which says it better than I can. At the very least, the comparison should be using the same version of the software. Running a benchmarking suite that tests the different components separately would be tell us a lot more than the tests in this video.
Why we can't just appreciate the fact that all these different formats were created for a reason..
This reason being: as an alternative to the deprecated software that some distros are serving, no matter what the state of that distro is.
eg. Someone can run the most recent piece of software, even in a very old Ubuntu LTS distro, that's fantastic !
Let alone security, less system maintainance, ease of distribution from the software developers (upstream) etc.
It's a great thing to have !
Great video, this provides really invaluable insight.
I would be interested to see how the AppImage times compared if it was also in a sandbox (since with the standard use of it you're not testing this, whereas the other two, flatpak and snap, do use a sandbox).
Sandboxing seems pretty wise in general to avoid the apps being able to do things they shouldn't (and if mobile apps taught us anything, it's that they will do stuff they shouldn't, often aggressively!!)
Appimage for the win. The answer is right in front of our faces.
Appimage for the win. Even when I was a Win user I always opted for a portable version of an app. It saves time, it saves space, it's easier to manage (move, share, delete / no registry littering and other traces of the app I might not need and files that would otherwise just take space for no reason) and yes I'm ready to compromise on performance and launch time if it means the app is easier to manage.
If someone built a distribution around it, appimage could be used to create a Mac-like way of dealing with installed software by having an Applications directory where you can put appimages to "install" them like .app files on Mac OS.
For those of you missing it:
Hello everyBODY, this is Techhut and what we are gonna to today is ...
@NFKRZ Hi! HLPLZ
Idk @ moving forward
Thanks man, that was a very useful comparison of Linux packaging formats.
An interesting test! Out of consistency, I anyways use flatpaks for most applications whenever I can. And though I do work now and then with apps like Gimp, Inkscape and rarely Kdenlive, I do not care too much if some things are taking longer. E.g. I do not care too much if I have to wait 10 min or 15 min for a video to render.
But my hope is, that habitually using flatpaks makes my debian-based OS installs more up to date and my arch-based OS installs less likely to brake. Also this way I can use a debian-based system and an arch-based system and barely notice a difference ;)
Well you can absolutely notice the DE versions though 😅
You could use Fedora or Manjaro to have near bleeding edge with very good stability. I only run Debian on servers these days. Btw, met a guy who is using Manjaro in production for 5 years now without major incidents.
@@emeukal7683 Yeah, last week I bought a RX6600 card and with that Manjaro xfce wont work. Was using it for almost 2.5 years. And the problem with that card is a known issue in the Manjaro forum without a solution. So now I am using MX Linux xfce for my everyday gaming setup. Manjaro Gnome works and I have that on my second drive. Fedora is on my work desktop.
And of course I know, that there are distros that want to provide a stable up-to-date experience with their distro repos, but my point in my comment is, that with flatpaks you need less to worry about that anymore and even distros on opposite ends both can appear similar stable and up-to-date... to a certain extent of course.
@@Beryesa. Exactly! And that is again something that brings distros closer together. I mean, I barely notice whether I use Gnome with Material-shell extension on Fedora or Endeavour. And then most software is handled with flatpaks...the same. And then the only difference is, whether I type "yay" to update or "sudo dnf upgrade". Though you do see a huge difference in system resource usage between those two distros, if you bother to look :D
I just watched a Chris Titus Tech video showing how slow Firefox starts up in Ubuntu as a snap app vs. Firefox in his Fedora Linux installation. It was a night and day difference with Ubuntu's Firefox Snap app taking almost 4 seconds to start every time he would try loading up the application.
I love your benchmarking videos. it would be really great if you released another video that compares the resource usage as well as boot-time differences of the applications after cold boot and relaunch.
That's exactly what I was going to say.
Thanks for researching this and helping us consider this technology topic. Yes, I've wondered about this exact question, but looks like it does matter on some & not on others.
Flatpak is the future **they say that**
To be fair, its success is all but confirmed if the Steam Deck is successful since it's the only way to get packages without devmode
I had a question, how did you manage to turn on fractional scaling for fedora on Wayland since many X11 applications that run on Wayland and are not yet ported to it use "xwayland" and xwayland for me causes the overall UI of the apps to be blurry, was it for you as well or did you find a solution for it?
I got the same issue too
@@virgileandanurrifqhi8364 see my comment above.
Dimmed overlay
Appimages just running a lap around the other formats in some of these tests is kinda funny to me. They were literally the dark horse in the race.
If what he said is correct that makes perfect sense, as they don't seem to have any isolation.
All they seem to do is bundle in typically dynamically linked libraries, otherwise they're native.
That btw would be my running theory for the cases where these container images were faster than native packages, that they bundled libraries that were in some way better for performance than the libraries on the system, that are shared between all applications.
I've seen something like that in action at least once, with a Rust Web-Application. If you link it to musl vs glibc than you get a static binary vs one with a dynamic link dependency, but in speed tests it was significantly slower than the glibc version.
Thank you. Been contemplating between using Snaps or Flatpaks for general use applications like web browsing and music player and after watching this, I'm going with Flatpaks.
Maybe I missed it in the video but as far as I know: Snaps only download dependencies if you don't have them already. So one dependency is for all the snap programs. Flatpaks on the other hand download dependencies multiple times so for every program all dependencies whether you have them already or not.
That's an issue with poor package writing, not Flatpak - if people made their package metadata for dependencies depend on a series of versions of dependencies rather than just the one version of them the issue wouldn't occur since Flatpak would know the version of that dependency already installed is fine for usage on the new package according to its dependencies.
It's vice versa lol. Flatpak does proper de-duplication if they're the same file. Snap has multiple copies for every package.
@@Beryesa.: That ended in 2014. Snaps share dependencies.
@@jeschinstad Wdym, here is the answer from 2018:
"Deduplication at a file level across snaps is not happening. If you put many copies of one file into one snap then yes, those are de-duplicated. If you have a need of sharing larger amounts of things among a set of snaps then please use the content interface. Lastly we have base snaps that lets one change the root filesystem (to contain any set of extra libraries) but this feature is a little bit immature across the stack (snapcraft and snapd)."
@@Beryesa.: I don't know who answered your question in 2018, but the answer is totally wrong. SquashFS does not allow deduplication of files, so that cannot happen in Snapd until SquashFS is replaced with a COW filesystem like Btrfs or ZFS, both of which are open opportunities. But bind mounting is an old Unix thing. Snap simply makes use of them.
Is this possible:
Partition 1 Debian
Partition 2 OpenSuse
Partition 3 Data/Flatpaks
Use the same Flatpaks with both Distros?
About the apps running in a sandboxed environment without the danger of interfering with the rest of the system, this is a desirable, not an enforced requirement.
For instance, flatpak restrict access by default to several resources and syscalls, but whoever builds one can loosen these restrictions at will (as the application otherwise may not work): "Most applications will need access to some of these resources in order to be useful. This is primarily done during the finishing build stage".
As someone else mentioned macos app bundles behave better and sandboxing is actually enforced at various levels.
Said that, thanks for the video, I always wondered how different solutions behaved in terms of performance. 👍🏻
There should not be such massive speed differences between those 4 app installation options. This means there is an urgent need for optimisations for the ones who lags behind at the benchmarks
Indeed. I can immediately see why first run startup can differ between these solutions. And speeds could differ because you get different versions with all of these packaging formats.
But I'm surprised that the same version of Firefox doesn't run at more or less the same speed after install with all of those formats.
Snap doesn't get enough user base and so Snap doesn't get to improve as much as flatpak. The fault is with Canonical. Many users doesn't use Snap just because the Snapstore is proprietary.
Arch2Appimage and Firejail are my go-to for isolated portable apps. Great video!
I had to reload my OS one day with No internet .so I copied my backed-up Appimage and got some work done.. As a new to Linux user this was easy ..
EXACTLY! I have like 100 apps in Appaimge format and can instantly get up and running a new system with a 100 new apps in seconds by just dragging them on the new system.
What's the difference(s) between apt/dnf programs and .appimage programs? I always thought they were synonymous terms. But your chart at 5:38 lists them separately.
Interesting.
I had been against all-dependencies-included packages as they use more of my SDD - except where there was no practical alternative, e.g. new versions of Thunderbird available much quicker with snap than apt.
Now I will be more judicious - especially with Firefox and FFDE.
Thanks, Hutman
*EDIT*
Replaced APT Firefox with Flatpak Firefox.
Not the 20% increase I'd hoped for but a bit quicker at the same time.
Since Storage are getting cheaper, i would prefer larger file with fast execution and all dependencies included and run at demand like it wont hook into the background if its an Appimage (i think). It would fit in my use case
One huge point for snap is their support for non graphical applications.
Flatpak also does but not designed for, so not that convenient.
@@Beryesa.: But it does require a desktop system, so you can't use it on servers. For that, you are supposed to use something like RPM-OSTree.
On Arch based systems, many if not most AppImages are available on the AUR.
Arch2Appimage is fantastic
Not all app images are the same. Some check for and update automatically. pCloud is one of my apps that updates itself and works great.
I'm new to linux thanks to the steam deck, thanks for making this vid. Seems to me appimage is the best option, I hate broken updates.
Debian's and Fedora's package managers are, respectively, DPKG and RPM, not APT and DNF.
How in the heck is flatpak etc. slower than native apt packages? Are they compiling the .debs for i686 or something?
One test I am interested that I did not see: How about native compiled from source code?
Results will depend on your compilation flags
Great video, congratulations, if possible you could include in other video the native apps (deb and rpm format) and compare with snap/flatpak/appimage.
Really wished that you add Arch based distro to that benchmark experiment
Doing benchmarks like this takes a REALLY long time.
You forgot the one and a half years it takes to start the flatpak versions in the first place. Jokes aside, great video.
Do you know if switching to an SSD would improve Flatpak's loading times?
SSD is tue big factor, for whatever reason that u aren't using one this is the first upgrade u should make.
You forgot the "decade" for Snaps! 😉
@@emeukal7683 the first reason is: i'm poor. The second reason is: my neoliberal goverment is letting the dolar float freely so it is about $45 for a dolar.
The third reason: salaries have been growing at a slower rate than inflation for the last 2 years, with no expectation of growing any time soon, so i can buy less things for my money with every passing minute
There's no difference in startup time between flatpak and native packages
This was excellent. Thank you. As a follow up, did any of the formats show different system usage? Does the isolated flatpack require any more overhead to run in a sandbox; for example?
2:23 Wow, how did you get the bar on the top right like that. Looks nice. Any video on this?
Great review, thanks so much... I was wondering if there was a noticeable difference between the different package formats...
Without understanding WHY the firefox in packaged-form was faster than native, we really can't conclude anything. Good vid tho' - it shows the issue well.
Why people never talk about Flatpak having built-in permission.
All other would require a firejail or similar to achieve the same.
Could you do a test adding firejail to appimages so we can check if they get slower?
I'm so happy with Appimage that is the dev give me that I try no else. 😃
Otherwise, I try the system package or, least, flatpack.
Snap only if there is no other choice, with is so rare, I only had 2 nowadays.
I'm on Mint, by the way 😁
Awesome.
Very enlightening video.
Kudos and thnx for the share!
Liked appimages prior; now, like them even more.
Why would the apt/dnf version be slower? Isn't this just installing it directly? Maybe it's not... Does that mean it will run faster if you build the code yourself directly on the system you are installing it in instead of using any of package managers?
I use Appimages mostly. I do have 2 Flatpak because the Appimages are way out of date and that the one issue with Appimages. I also install the repos version sometimes too. I like the portability of Appimages. just copy it to the next computer and use it... :-)
LLAP 🖖
Regardless of linux distribution? what about Kolibri OS on an old PC?
4:37 -- But it's actually the Speedometer test that you end up doing anyway. Weird that it made its way into the video judging by how incorrect the statement was.
Damn they are all so different! But snaps never had any substantial lead over others, so I'm not regretting not using them. Thanks for the wonderful video! :D
Statistics need to be taken about app deps, so heavily used deps can be shared and the rest bundled with the app they're for ( most efficient resource use ).
Was it the only run per each different distribution method or multiple ones? When you’re dealing with such a waxy substance as IT you cannot rely on a single try
When I see " Canonical", I recoil.
THAT makes sense-- that it would perform BETTER with software curated by the system- rather than a general system in a container...
For context - MacOS (or whatever it's called this week) has had 'fat binaries' (appimages) for decades ...
WHAT do you do if you have , say- NETRUNNER-- which is ALL Appimage based- and you need software that is NOT available in an appimage??? Will flatpaks work as well? I tried Netrunner and had issues-- several of them- and I think that maybe that was because I did something wrong with the flatpaks I installed...not working well with the appimage ones..??? who knows..
Is there a reason why Nix packages aren’t considered in the mix with these 3? It seems to me like they are similar enough.
how is it possible that appimage and flatpaks are more performant than natively installed apps?
Great explanation. Do you think the results in something like Manjaro would be different? I generally try to download officially repository stuff, or aur library if it isnt there.
I love learning all this...........stuff.
you might dislike snaps, but they're not as bad as it seems. snaps are great for server use: simply install and never care about updates again, they're completely isolated from any other dependencies or the system. and the benchmarks show that even on Ubuntu desktop, they outperform the apt packages quite often because they seem to have the dependencies better under control as well. so I understand why cannonical is pushing them. if Adobe ever were to release their software for Linux, it'd be as snap packages.
That's nice to see a comparison like this
1:24 by a little bit he means gigabytes of difference in size :)
I would love to see NixOS native install vs those, maybe even vs pacman vs apt. NixOS seems very efficient, should result in speed.
Interesting. Great video dude. 👍
yeah I just install the native if possible and then if I want more privacy or control over an app I then use flatpak, and then appimage if I want it to run without installing it over and over
Yay! I really thought using the pacman (teehee) would result in better performance than flatpak/snap. I've been like an octopi at the Konsole til now
Great video!!!
It is so unfortunate that Surfshark is advertised on a Linux channel. It doesn't even have a GUI for Linux and nor does the other features, like Wireguard and Killswitch, work on Linux.
it has now....at least for ubuntu/debian
Proton has good support for Linux too
How can the same version for Firefox run (much) slower as a "native" system binary than via a sandboxed environment? How can an additional software layer speedup a process?
Probably has to do with the dependencies. Performance improvements in libraries will show in the generic packages because the developers choose which versions to use whereas the native package uses shared libs already installed through the distribution’s package manager.
@@DigitalMoonlight makes sense, thanks for the reply
Question: Kdenlive runs better on apt/dnf installs but aren't they usually way older than the latest release? How can you have the latest packages with apt/dnf?
Just build it yourself, or use a Containerized Format
@Fashinqu A. so how did he compare?
@@keit99 that would be a full time job to build every app yourself every time there is a new version.
@@xperience-evolution yes it is quite impractical
I have a question what does the native gui appstore use ? Like for popshop what package manager it uses? Or can I change it to whatever package manager I want?
I m beginner. And nice video brandon.
Graphical interface doesn't matter, your distro does. Debian and Ubuntu family uses apt, Fedora uses dnf, arch uses pacman.
Flatpak is a distro-independent package format and can be installed everywhere.
Appimages are just static executables (like portable .exe executables), should work on any distro released after 2014
That was nicely explained.
Very informative. Thank you.
Old Network/System Admin here.... Interesting Video.... But... I assumed you used fairly modern PC components with plenty of RAM in these tests. How about running these tests again on older hardware? I suspect you are going to see different results with systems with 2 to 4 CPU cores and less then 2GB of RAM. I stick with traditional APT packages period for security reasons. But.... I have tried SNAPS on older hardware desktop setups. And I can tell you... Waiting 5+ seconds to just open a SNAP WEB browser is very painful.
Um. Could you try on Arch maybe? I'm kinda thinking that it might have something to do with the libraries too.
Honestly I would love to use Flatpak more if not for the crazy amount of hassle one needs to go through to get their preferred GTK/QT theme working.
As a programmer I can tell you that theming is a hassle. Qt is moving away from it because most programs move to custom UIs.
I've never liked SNAPS--- and recently- got a home alarm system that requires ANDROID-- so installed a SNAP of Blink for the software to monitor it. I've had NOTHING but issues since I installed that--- it's made all kinds of things NOT WORK-- and I know you guys say it can't-- but it DID.. and I finally took it off- reloaded everything and it's fine now-- no issues at all.. SO I"LL NEVER use another snap...
I'm running kubuntu ATM and RetroArch snap that's recommended doesn't detect my secondary hard drives. Now I'm torn between appimage QT or flatpak. Or screw it all and go nightly 🤷♂️
Any ideas on why these performance differences are there ??
Is there a part 3 coming for the ultimate jellyfin server?
Yes sirrrr
Thank You
AppImage is great. Too bad it's the least popular kind of format.
I really don't mind which one I use, as long as it works.