Flatpak vs Snaps vs Appimage vs Packages - Linux packaging formats compared
Вставка
- Опубліковано 6 чер 2024
- Visit linode.com/linuxexperiment for a 20$ credit on your new Linode account !
Linux often gets a bad rap when it comes to installing software, and this is mainly due to the fact that we have so many different application distribution formats. Most of them also are misunderstood, or have preconceived notions attached to them, so I think it’s time to take a look at the differences between the various packaging formats !
Support the channel on Patreon:
/ thelinuxexperiment
Follow me on Twitter : / thelinuxexp
My Gaming on Linux Channel: / @thelinuxgamingexperim...
Follow me on LBRY: lbry.tv/@TheLinuxExperiment:e
There are 2 main package formats here: the DEB and RPM. Debs are used by Debian and debian based distros like Ubuntu, and RPMs are used by Fedora, Red Hat, or OpenSUSE. Both of these formats are usually pulled straight from the distribution’s repositories, or can be installed manually. They contain a binary version of the application or library you’re trying to install, so it’s already compiled for your system’s architecture.
These packages come with a descriptive file that also includes all the various libraries and other applications your program needs to be able to run.
These DEB and RPM packages have advantages: they’re fast to install, they’re already compiled for your architecture, and they pull all your dependencies immediately if they’re available. They do have problems though: first, since these packages are distro-specific, app developers need to package their app for multiple distros, multiple versions, and architectures of these distributions.
To fix these problems, the Flatpak format was created. This one differs from the packages in a very important way: while flatpaks are also shipped as binaries, so no compilation needed, they also embark all the libraries they need directly in the package. They can also used shared libraries provided in other flatpaks.
Flatpaks are also relatively quick to install, and can be pulled from repositories called remotes. The biggest one out there is Flathub, which sources most available flatpak applications.
Flatpaks also introduce some issues, mainly in terms of security: while flatpaks are sandboxed, they still can provide outdated versions of libraries that light or might not be kept up to date by the developer.
They also use up more space. Flatpaks can run on any distro that have the flatpak package installed, and can be downloaded from most distro’s software centers if they have added the flathub remote.
Snaps are based on the same model generally as flatpaks: they are binary applications shipped in a single package with their own dependencies. They can also make use of runtimes, and are sandboxed as well to avoid the snaps being able to see or read everything you have on your system.
Snaps have an interesting difference though: they can also ship server stuff. While flatpaks are mainly geared towards graphical applications, snaps can contain pure command line packages. Another difference is that snaps can be updated while they are in use, and can receive delta updates. Snaps can also revert to the previous version easily.
Snaps do have some problems though: first, they don’t make use of the system theme. Second, they can’t use external repositories: all snaps are shipped through snapcraft, which is the “official” distribution center for these.
Snaps also tend to be bigger, and slower to launch than flatpaks or regular packages. Snaps can run on any distro that have access to snapd, the backend part of snaps.
Appimages are yet another way to distribute applications in a single contained package. They use the “one app one file” method: an appimage ships all the files needed, and all the libraries as well, in a single file. They are not downloaded from a repo, but there is AppImage hub, a website that lists most if not all of the available Appimages.
These can just be downloaded manually and started immediately, wherever they are located on the system. No need to install runtimes, or shared components like Snaps or Flatpaks, you can just put your appimage anywhere and run it.
This means that appimages are super portable: to keep all your apps, you can just copy / past the appimages and you’re good to go.
This a a big advantage, but there are some issues there as well: first, you can’t update an appimage without downloading the new version yourself, so it’s a bit like apps on windows.
Appimages also don’t respect the system’s theme at all, and can get pretty big, since they don’t make use of share runtimes at all. Appimages can run on any distro, they don’t need any specific plumbing to work. - Наука та технологія
1:18 Packages
4:05 Flatpak
6:42 Snap
9:31 AppImage
11:02 Source code
I always prefer native packages. They're faster, smaller, and best respect the desktop theme; it's a no-brainer.
My only exception might be if an app is no longer maintained but users still want to install it on modern systems. In that case, I think it makes sense to "preserve" the app as something completely self-contained & guaranteed to run like an AppImage, so the developer never has to touch it again but users who want it can keep using it forever.
Obviously, as long as you habe the package you're looking for in the distro repos. Cross-distro packages only become relevant to me if I need stuff that my distro doesn't provide
@Andrey Shafar They do not respect your GTK+ theme (in my case anyway).
Andrii Shafar First impressions. With font-cache being created on first start, ppl may tend to believe it’s slow in general.
@@ryan1696 GTK has no themes anymore. Just like windows and macos, it's over.
@@bennypr0fane imagine having stuff your distro doesn't provide (this post was made by arch or gentoo gang)
One good thing about AppImage that you forgot to mention is that you can have multiple versions of the same software. meaning rolling back is basically just closing this one and opening the previous one. I always keep the previous working version just in case.
Other than AppImage and rpm/deb, Flatpak seems to be the most solid one as you can also make your own Flatpak of let's say LibreOffice or Slack with specific permissions and etc.
I keep a the snapshot of my AUR packages in case it disappears off the AUR. a couple of games and some security tools. I doubt that opensnitch and snort are going to be orphaned. pacman doesnt throw anything away until you tell it to.
About delta updates... Flatpak also has delta updates, not only Snap :)
Aaaand the problem with custom themes also occurs on Flatpak, but it's easily fixable with a single command
`sudo flatpak override --filesystem=~/.themes`
Oh thanks! I'll try that!
How to override on a per app base?
But custom themes are pretty much old fashion. Nobody is theming anymore on the real OS (macOS, windows, iOS, Android)
RPM also has this
+1 for flatpak deltas. Also it's possible with flatpak to rollback at any time to previous version.
weeb. comment discarded.
Packages in Arch's default repo are precompiled binary downloaded by Pacman. The ones in AUR are to be compiled locally. You also have *-bin for many AUR packages which just downloads the precompiled binary and just moves them to the respective folder.
thank you for detail explanation in simple English and providing both Cons and Pros for every format. I am new to Linux and every time I search for difference, it seems 'Experts' only either completely criticizing one format or another.
Absolutely. The bane of the Linux community is that people pass opinions as "advantages" or problems. Not a lot of people are objective, and I get it, it's hard to be, but Linux guys are more opinionated than most 😅
imagine having a streamlined way of installing and updating basically any program you want, instead of scavenging 700 websites for installers
@Sifat Ullah exactly
Imagine needing a program that isn't in these package installers, and having to visit 700 websites to figure out the terminal commands to install it with all dependencies just for it to function correctly.
@Sifat Ullah its more about determining which Download button is the legit one.
Imagine scraping github scripts for your hardware but left with more problem bcs obsolete or conflicted dependencies
Imagine Arch Linux pacman and AUR does it... Oh it already does!
I just found your channel. Great work! Most people are not good a explaining Linux concepts but your videos are awesome. Keep it up.
Thank you so much :)
Arch uses pacman, which does download the pre compiled binaries. Yay/Yaugurt(like pacman, but for AUR packages) does download and compile the packages and is optional.
Was going to comment this.
It really installs the packages.
Behind the scene, they are still the packages. I love Arch. Everything is smooth. But I want to use official packages from developers. AUR is community repos
@@dangminhngo277 Despite what is stated in the video, RPMs and DEBs are created mostly by Distro admins. That's also how you know they're curated.
@@diederick76 i believe most of the main aur is curated to an extent
My preferences:
1) native package
2) source code
3) AppImage
Bang on.
why AppImage is better than FlatPaks?
@@linux4868 I just prefer formats that aren’t controlled by canonical (snap) or RedHat/IBM (flatpack). I also like the appimage just being a file (like a dmg file on MacOS) Where all you need to do is give +x perms to and launch. Neither is perfect. I also find AppImages work better with firejail as well. Not always. But more than likely to work than not.
@@JosephSaintClair Jesus!! didn't know flatpaks were from IBM. I will ditch it then.. I will stick with AppImages and use Appimagelauncher to install it as if it was from system.. Thnx
@@linux4868 well. IBM bought RedHat for US$34Bn in late 2019. Not to say flatpacks are wrong or bad... but when you have in essence one company steering the direction of an open source operating environment (for good or for bad), you got to ask what the motives and intentions are.
Whilst I use both RedHat/CentOS/Ubuntu for servers (Ubuntu being more preferable due to how they “volume licence”), the need for choice and the question of vendor lock in comes to mind.
Most enterprises just choose what the vendor tells them, and funnily enough, there’s still 10 year old versions of OS running some pretty critical stuff out there.
Ok /end-rant! Lol. For desktop, for me it’s about freedom of choice. I been using arch based distros for ages and there’s nothing I can’t do.. even for servers on lts kernels. As an example. I have a base arch minio s3 file server that’s about 1GB install, uses less than 80Mb RAM and it’s sole purpose is running s3. I’ve had it for 4 years, never ever failed and is 100% upto date, and possibly one of the most hardened systems you will see (I’m huge on security, like ZT, sandboxing, SDN, full cert usage and device+account authentication/authorisation for even using and invoking a request to a service, use of crypto based network overlays, DHT based dns, etc.. I even go as far as enabling memory encryption for pids, VMs and containers)!
Anyway. Hi :)
Amazing job on highlighting the pros and cons of each format!!! Usually when people talk about each format they overly emphasize on the strenghts of the formats they enjoy the most and make the other formats seem worse than they are.
Arch Linux does have a package system with precompiled software. There is a separate set of tools that automate the building process for software that isn't in the repos.
It should have the app on the repo anyway. Ubuntu never fails.
Linux definitely needed a format like AppImage, but I think it was needed more in the 2000s, not so much in 2020. That said, it’s always good to have more options, and being able to just drop an app on a flash drive and take it to an isolated machine is very valuable, no matter what the year.
It is and it's also useful to be aware that you can do this with snaps as well, although it's not as user-friendly. You can use the "snap download" command to download a snap and its assert. The snap file can simply be mounted and run using "sudo mount -t squashfs *snap /mnt && /mnt/usr/bin/vlc". It obviously won't support shared dependencies and they'll run without protection, but it works very well for apps like VLC.
Thank you Nick, the video is detailed but not too tecky, exactly what I needed to understand the topic in less than 15 minutes. Grat job! While I'm here I'd like to thank you also for the interview you gave at BigDaddyLinux's Spotlight, that I watched yesterday, it was nice to get to know you a little bit more from a personal point of view. Keep up the good work! :)
This is a really good video especially the Snap part.
Thank you for your time! I am your fan now;)
Thanks a lot, and thank you for watching :)
This is an excellent video!
You have just done a great service to a lot of Linux users out there, whether a starter on Linux, intermediate or advanced user, the various package formats can at times be confusing to all of us. In your video you simply lay it all out. Thank you sir. (Thank god, UTube can still have some serious, informative uploads!)
Thank you for watching :)
I try to make stuff that helps people learn, there might be some.simplifications here and there, but the goal is not to turn people into experts :)
As others already mentioned, Arch does not need you to compile alle packages on yout computer. Arch has repositories with pre-compiled binaries like everyone else. It's just AUR where you'll find a lot of source-code-only packages that will compile on your system, but it's also mostly just a a click to make that happen - it just takes much longer than installing pre-compiled binaries
PKGBUILD scripts make this a lot easier.
Even more if up you use an AUR manager, like Yay.
also awesome video. I'm glad you are making these as I'm near the time of year when I do a lot of system upgrades. I shall stand by my rants on your ubuntu video but regardless, the effort you're putting in is much appreciated
Hey no problem, we can have different opinions on things and still enjoy Linux :)
Thanks for watching what I make !
Both flatpaks and appimages (appimageupdate to be precise) have delta updates
he mentioned appimageupdate having delta updates tho
I really appreciate your clear explanations of the basics of Linux. I’m new to my Linux Mint 20 and have been really confused by some of the jargon - debs, flat packs, Snap, snaps, repositories, distressed etc - and your videos have helped me through the forest. Thank you. I wish you’d talk a bit slower, though! You talk like a text almost ignoring punctuation. Commas, paragraphs, full stops and colons are all there for different reasons but basically to help someone like yourself read things clearly so others can follow it easily.
Very good. I've been looking so hard for someone that would create a video about all of Linux repository system(s). You may not have hit everything, but you covered 90%.
Fantastic video. Thanks for breaking this down so clearly and in detail. Love this channel.
Thanks!
Fantastic video! Informative and understandable. Content of this quality is hard to find!
Thank you!
Clear and comprehensive distinction. Thank you so much 😍😍
Great video as always. here is the hole universal package format story :D
Linux people: We need a universal package format.
Dev's: Let's make our version of it, and how we see it being manage.
Linux people: Let's fight over why one is better then the others, and that we all should just use deb's and rpm's anyway.
Gotta love people :D
society in resume, whitout the opensourcenes of course
Well, snaps existance is totaly unnecesary, change my mind.
@@MrREALball I don't care, change my mind lmao
@@KentsTechWorld: Beautiful response! :)
Basically XKCD 927
This is way too good, to keep learning how these parts of GNU/Linux work. Suscribed and gonna keep watching your videos, dude!
THANK YOU for your EXCELLENT videos/reviews, etc. I learn a lot from yours. I'm 65, not in best health- and find it hard to "retain" a lot any more-- and hard to pick up new stuff-- but for some reason, your videos always teach me a lot- and it STICKS.. I think it's your simple style--- no fluff, no muss or repeating the same thing over and over in different words..and a lot of BS that some put in.. just SIMPLE fact- stated in simple ways--- EASY. THANK YOU again.. excellent videos. (They'd work well in a classroom--- maybe think about putting them all together in a "basic course" for newbs.. )
Thank you! This explanation was quick and effective. I appreciate the clarity.
Great video for Linux beginners. Just started using Kubuntu at work and this subject was really confusing me. Thanks a lot!
Thnkx for the video it was help ful waiting for a video with comparison of installation time for all the package installer
From a enterprise server point of view, I can see why Ubuntu opted for Snap packages to just have one single central repo. If you want to avoid people from packaging compromised libraries in their packages, at least this way when things goes wrong, Canonical would be responsible.
Arch does have a packaging system with precompiled packages
If you compile it on your system it works on your system 😂😂 Arch is great and easy (Debian based systems are just so scattered i want to get all my packages from one place not manually insert a ppa)
Yeah he really means AUR and even then its not necessarily from source.
@@dordly I don't think that Arch is outdated in any way. But Arch is for a very specific public. Like gentoo, I only see arch if you need or want to customize every bit of the system or learn how an OS really works.
I've never had an issue with outdated things or weird firmwares. Furthermore, normally y found that kind of things more up to date and faster in Arch than in any other distro.
The only thing I agree with you is the Arch Wiki. It's by far the best wiki, manual and learning source of all Linux. Is the more complete, detailed and well explained. But it's outdated as hell. Is sad that the best Linux wiki is an outdated one.
Also, to finish, if we enter in a rant of personal experiences I can perfectly say that Debian is bullshit because it installs slow as hell and in two of my computers it doesn't even run, because some fundamental drivers doesn't even exist in Debian, but they exist in Arch and other distros. I pesonally think plain personal experience is not the best way to evaluate a distro. It can fail to you, but that doesn't mean it's a bad distro in any way.
@@dordly Man, I'm with you. Manjaro KDE was only headache to me. It broke itself on an update.. I'm not so noob but it really brakes by itself and it sucks.
@@linux4868 That's cool but what does Manjaro being a broken pile of shit have to do with Arch. @Shaman was completely incorrect about everything he said, I've rarely seen someone be this wrong.
Thank you. It was very informative and cleared things up for me.
The video seems to gloss over so many difficulties. Most apps that I might use are not yet in these new packages. The latest versions are not usually. qbittorrent, luckybackup, slimjet, grub customizer, gkrellm, ...
Some Linux operating systems now are in the dark themes. These new packages often have trouble fitting these default themes, or whatever the user chooses. Now we have HiDPI monitors, which may be used simultaneously with standard or low DPI monitors. Sometimes an external monitor might be portrait mode, when the others are Landscape mode. These then have massive incompatibilities.
Hey Nick, this is the best and most detailed explanation I have come across talking about the differences on all the Linux packaging formats out there. I am going to refer the link to this video to any of my friends who are new to linux and curious about the different types of packages. Also, I have a question, I have seen you using the customised version of Firefox theme with the URL bar on top and tabs below in many videos, please make a video on how to do this. Keep up the good work. !!
Thanks ! I have an article on how to do it on my website (thelinuxexp.com)
@@TheLinuxEXP Thank you !!
Awesome video man, I'm new to the linux world and this helps a ton!
I switched to Linux about 18 months ago and I remember how confusing it was in the beginning. Nowadays I use all the methods but there are some problems with flatpaks and maybe snaps too. For example, is there anyway to install Gimp plugins such as g'mic on a flatpak? I don't believe so.
Thanks Nick for the explanation ! Because I get little confused between Flatpak, Snappack and Appimage, and I expect I'm not alone.
Repo packages are the only choice for me, I don't want to fragment my system between different package managers.
The sandbox is a feature of flatpack, but it's an optional feature. So an application can ship with loose constraints, and the user will have a false sense of security thinking the sandbox will save the day.
From a technological POV I prefer snaps.
From a policy and "vision" POV I prefer flatpak.
From a portability POV I prefer AppImage.
IDK, From a technological standpoint, they have been "working" on getting those extremely slow startup times fixed for years now and it doesn't seem to be going anywhere. Seems like they're fundamentally flawed, as Nick said, in 2020 on M2 SSDs, waiting 10 seconds for software to open isn't acceptable...
Obviously their policy and vision is even worse.
Found the centrist lol
@@markopopovic4068 VS Code opens in 3 seconds or less. Android Studio takes a log longer.
From a security POV they are all crap
@@Lestibournes 3 seconds for code is nothing to brag about
Thanks for this video, very well explained, very professional , keeep working on this way,
Thanks :)
This is the best video I've seen on this topic!
Thank you :)
To all the people saying AUR:
Flatpaks, snaps and appimages are cross platform, whereas the AUR is locked to Arch.
Solution: Use Arch xD
Kommentator No I’m not using that hellhole, it’s a pain to get packages from the AUR, they don’t even consider the idea of using installers, it’s a mess.
@@imnotfuckingusingthisaccou2574 That's not a mess. I installed Arch again yesterday (sending this from that installation) and it took me less than an hour... Why an installer when pacstrap already does most of the work? The AUR is not an officially recommended way to get applications, but it isn't a mess either. If you review the PKGBUILD file before installing, it's perfectly safe and an excellent way to install packages. You can also install "*-bin" packages if you don't want to compile from source. And if you don't want to use the AUR, just use Flatpaks or snaps or whatever else. Don't call a distro a hellhole just because it didn't work for you.
@@imnotfuckingusingthisaccou2574 You can always use Yay or another helper.
Maxor Ignoring my other reasons. Is that all Arch fanboys do?
this is the one that i was looking for
Great video! Thanks!
Thanks. I appreciate your content. I am using Linux Mint Debian Edition cinnamon. Would you suggest using flat pack via my browser or downloading and installing from manager
Thanks fr a good explanation of how these all differ.
Good basic overview.
1. Flatpack, Snap and AppImage also include a stub of an entire OS including kernel to support each app, which makes them pretty big although they solve the multitude of problems running code universally.
2. Just dropping a note to Developers... Although Flatpack, Snap and AppImage are the "Universal Installer" approach,
If you prefer the native package experience for the User, you have a really nice solution to build packages targeting everything you can imagine... the Open Build Service (OBS). Although sponsored and supported by SUSE, as a Developer you can submit one common source and through a menu-driven process, with a single click build to any Distro, Distro version, Architectecture or Hardware Platform. Check it out!
Flatpak, Snap and AppImage do not include a "kernel". I can only speak for AppImage and that is literally just a file that includes the executable and the required libraries.
Loved it! Nice explanation.
Thank you :)
Flatpak is best pak! :D
(Unless a repo package is available, then I'd probably choose that over any of the other choices.)
Flat is justice.
Great primer - Thanks !
You explained the best among all the other videos. Thanks.
Great explanation, thanks
Thank you! All that I wanted to know!
hey, this might be a stupid question but if i get the source code for a usually amd-64 application and compile on an arm system, will it compile to an arm binary or is the code specific to amd-64?
About 13:02: What is a bit confusing for me sometimes is then I want to look where which software is installed. Is there a way to have an overview of all software installen in Flatpak, Snapstore and AppImage at once?
I don’t know about appimage, but you can run the command “snap list” to list snap packages and “flatpak list” to list flatpak applications.
I would like to add that RPCS3 can be updated through the app using Appimages without the need to go to the site to manually download it, it adds old at the end of the original file.
Problem is that it doesn't rename the new file to the version that was just downloaded.
Inn personal, I have a hierarchy on that: Repo > Flatpak > AppImage > compiling.
I prefer repo becasue it has the automatic update option bundled with the system update (and despite me liking GUI's, I prefer to update via terminal just to see in detail the progress of the upgrade). Also it provides the best theme support (BC since the demise of the Adapta theme I now use non-popular themes) and it is the most economic in terms of space.
In case the app isn't on my repos I check flatpak. Despite the lack of themes I mostly don't care becasue the apps I have via Flatpak usually have custom themes that override the system one.
Same things can apply to AppImage. I consider it the manual-update, manual-install sibling of flatpak. I used to put them in /opt and then using the system integration dialog to make them available in the menu, but since that feature is now depreciated I now use AppImage integrator with the files in ~/.local/bin
At last, if there isn't any option (and I don't consider snaps), Good ol' compilation. Despite having support for themes, It still requiers manually searching in your repos for the dependencies, and manually checking for updates.
Slackware has the most options. You can install packages with the Slackware format from official repositories. You can create a package based on a Slackbuild. You can compile the traditional way with ./configure, make and as root make install. But Slackware has two gems: rpm2tgz to convert any rpm into a package with the Slackware format and src2pkg which can convert a source package, a deb package, an rpm package, a SliTaz package or a Puppy package into a package with the Slackware format.
And don't forget that you can install a deb package on ANY Linux distributions.
On Slackware you can also use AppImages or flatpaks if the package you need/want is only available as an AppImage or a flatpak. I have no concrete example till now.
Great content as always. Thank you.
Thanks :)
To demystify something: Snaps are not proprietary! It's just Snapcarft that is a service exclusively by Canonical, anyone can create a different file server and have that be a different snap repo, also the Snap store is not "heavily curated", your program will only need to be checked if it is a program that requires total access to system resources
It still doesn't make me like it though, I simply find annoying the '/snap' folder they put in your /home "by design", I'll only use it when they change that (probably never) and when there are a few different snap repositories. Tough in general I prefer just using the default Arch [Manjaro tbh] packages and going to the AUR when necessary, with helpers like yay it's quite painless
Exactly! Tired of this "snap is closed source"
actually the "~/snap" folder is kinda useful as it contains any data you create in your snaps like a video rendered in kdenlive.
and there being one snap repo is actually a good thing :v
for example we linux users always complain that software vendor ignore linux, but when they ask "how should publish my app" we would answer "you can debs, red hat rpm, opensuse rpm. and then you can apply to get in repo a b c d and e after few years they'll be included and kept working on the distros"but with a central snap store we can just say "you can just publish to the snap store"
This video was super helpful and informative. One of the best ones to understand the differences between the different formats and their pros and cons.
une des seules vidéos claires sur le sujet ! bravo et merci !
Merci a toi:)
thank you for your good explanation
thanks for sharing 👍
You were so serious Nick!
Regarding appimages: They don't automatically get put into the application launcher. And also I have used some appimages that follow the computer's theme (on KDE Plasma, OpenRocket used the GTK theme that I chose)
I just use AUR most of the time. Feels like it has the most complete and best integration of them all. The exception seems to be certain apps with paid options. But that's why I use Manjaro, it can handle all of them out of the box so that's cool.
Great video, thanks
Thank you for watching :)
what about the mentioned security flaws using flatpaks with outdated libs (which come shipped with the app).. this wasn't mentioned with snaps (or i missed it?), but the case might be the same here, right?
Very informative. Nice video. Keep up the good work!
Thank you :)
Thnaks a lot for this video
I have one doubt, If I have several of these then how am I supposed to update those applications. Does, sudo dnf update (or) sudo apt update ;update them all?
I'm not comfortable with packaging for DEBs, snaps or flatpacks. I just put binaries in Github with a Shell that call git pull to update the app (delta updates for free 😜). But still working on dependency resolving. Compiling everything to webassembly looks great so far 🤩
Great vid, but AppImages do support the system theme unless they get sandboxed. When running normally, it has filesystem access just like traditional programs.
The topic of the video is super cool
Thanks :)
Thanks for explaining, im new to linux
I think it's important to note when to use these alternative/universal package managers. It might be obvious, but not to everyone.
If you can't find what you're looking for with apt/rpm, use flatpak/snap/appimages.
If you still can't find what you're looking for, build from source and hope for the best.
The point is that these alternatives are a second resort, after your distro's main package manager. If a distribution checks, say, snaps before apt, that's sketchy and you should shop for another distro.
I think this is great advice for newcomers or anyone looking for a simple approach to their package management
I understood these Universal packaging systems, but still don't know what does "apt" do?
Which type of package apt installs by default?
I'm a new Linux Mint user, so if a program isn't already contained in the 'Software Manager' I can't install it. For example, I want to install Gimp 2.8 (an older version) and I've downloaded the flatpak for it to my downloads folder, but I've got no idea how to install it.
How do we install flatpaks that we've already downloaded?
Arch does have a package system: pacman. It also have a source code user repository: AUR.
A question concerning packaging formats that lug all the shared libraries needed: why not just link the binaries statically? The whole point of shared libraries is that they are, well, sjhared; if it is not convenient, you can always, with a trivial change in makefile(s), instruct the _ld_ to extract all the referenced modules from (static versions of) libraries and bundle them with your object files into one (often large) executable.
Granted, delta-updates are not possible this way, but only flatpak uses it, anyway.
What am I missing?
To me it seems the best packaging system would be the one that could determine a packaging strategy on case by case basis. So for example the main app could be pulled as a binary, one of the libraries used from what is already installed, second downloaded specifically for this app, and third compiled from source, because there happens to be no binary available for current architecture. That way we get best advantages of all these systems.
What about Alpm, SBo, AURpkg, puppypkg and other packages?
Random observation. Audacity 3.1.2 noise reduction runs a factor of a several slower when installed as a Flatpak compared to apt install. Is there any obvious reason for this?
Most source code programmes are three steps away. Cmake, make, make install. With the occasional cofig file changes.
The issue with them is with their compilation time. I remember first time I installed openCV, and saw the size ~50MB I thought it would be quite quick... It took 4 hours to compile and copy.
Thank you for clarifying a (for me) very confusing situation.
Arch does have a package manager. But it also does have a somewhat official unofficial arch user repository.
It's not really packages, it's more building / compilation scripts isn't it? It works as packages, but you still compile stuff
@@TheLinuxEXP Packages from the Arch repos (archlinux[dot]org/packages) are binary packages, just delivered as normal .tar instead of something like .deb. Packages from the AUR (aur[dot]archlinux[dot]org) are build scripts, that are generally source to compile, but some programs have a binary version
@@wacesferpit There are even community maintaned proprietary applications in the AUR which are binary of course. Most of the time they download all the dependencies and install the app.
@@TheLinuxEXP I don't think there is even any '-git' package available in the arch linux official repository archlinux.org/packages.
That compilation script thing you said may be AUR. The Arch User Repository that people has been blabbering about. It's great that you don't have to manage unofficial packages that you need, even if you technically build the package from source.
@@TheLinuxEXP You can find binaries, but honestly, the AUR is just a wild place, can be the best and the worse.
Thanks. I didnt know all of this.
I had to symlink my /var/lib/flatpak out of my /var partition due to how big flatpaks are. I'm still a fan of traditional debs.
I'm a noob From my point of view any application that is user friendly is always welcome to my device. Personally I like Appimage more than the other options but that's just my totally irrelevant opinion nice video tutorial teacher 🥳 👍
Please correct me if I am wrong, I am a noob. App Images is similar to .exe or .dmg files on Windows and Mac, respectively. They are downloaded from the web, mostly self-contained and need some kind of Update Daemon to keep them up-to-date. The advantage of binary packages on Linux (e.g. a .deb package) is that they are written for the OS, they are lightweight, and they can be updated without having to close the application or shutdown the system. Is my understanding correct?
Absolutely
Thanks 🙏
You’re welcome :)
Great topic
Thank you!
Hey Nick... Thanks for the video. BTW I'm new to the channel. Which program you use to edit your videos???
Davinci Resolve :)
@@TheLinuxEXP Thanks for the reply. I have heard Davinci Resolve is a little bit pain in the ass in Linux... Is it true??? Or did I just hear some non-sense??
It’s tricky to get running depending on your distro. You need an Nvidia GPU with the proprietary drivers, openCL installed and te hen it should run :)
@@TheLinuxEXP Looks like I'm better with Kdenlive :(
Good video.
Appimage is the only one of these I've found to be stable. Every flatpack Ive tried was shite, and the only Snap I tried to install got cancelled when a small utility got to 1GB of downloads. Totally insane.
my only issue with flatpak so far has been because of the drivers for my capture card not being allowed to be packaged in via flatpak OBS without breaching license
Flatpaks can also do delta updates through OStree.
been using apt both Debian now im on Ubuntu. Snap also good