I have yet to see a single windows program that required me to click next ten times or bypass "prechecked crapware" or whatever that is. I'm starting to think you have never used windows in your whole life.
@queerdo Sorry, i don't install blatant malware from shady websites. In fact, i don't install anything, because i use winget, which is like Flatpacks but with automatic updates, and i use PortableApps, which is like AppImages, but with automatic updates. Linux still has no alternative to this.
I think an important advantage of Flatpak that's rarely talked about is de-duplication. In addition to shared runtimes, Flatpak uses a special technology called OSTree, which means any duplicate file or library across your entire Flatpak installation (apps + runtimes) will only be downloaded and stored once; this is called de-duplication. This is why, when you install a new app, Flatpak will sometimes download less than the total size of the app, because some files or libraries were already present on your computer. This is also why Flatpak updates tend to be really small, as only new or modified files get downloaded during updates.
De-duplication is a powerful feature of Flatpak that helps optimize storage space, reduce bandwidth usage, and make updates more efficient, ultimately providing a more streamlined and efficient user experience
I have the opposite experience I tried downloading a 30mb file and flat pack proceeds to download 1gb And apt only downloaded 8mb for the same file So I don't really think de-duplication or whatever is unique to flatpak Only modified files being updated is pretty much the standard for most package managers
I like that you tell people "use whatever you like". They're all used so widely that... I think they all have something that is compelling enough to people. It's been a theme with your channel throughout. I think it creates less toxicity and more enthusiasm for the possibilities Linux has to offer for users without making them feel like they should be ashamed for what they're using.
@@TheLinuxEXP It's a nice contrast... but to use apple phones for example, even though you seem to care about privacy? Especially with how against repair they are, which creates just so much e-waste. Apple is just about as bad as Microsoft.
@@elecbaguette Choosing phones is like electing a US president, though. It’s not about which one is the best, but rather which one is the least bad. Both iOS and Android are privacy nightmares, and using any «alternative» phone OS will throw you into usability issues from the get-go as of now.
@@elecbaguette apple recently restricted Chinese users airdrop function to negatively influence a massive protest against co-vid policies. Apple has turned into a political pos company.
This clears up a lot. I've been using Mint for about 6 years now and have generally stuck to their package manager for apps, but have successfully used Flatpak and Appimage packages. The recent Flatpak support in Mint's package manager works very well.
I wonder if Nix and source packages could have been included in this video, but, well, from source is not really what this targets, but I could still see Nix packages included in there, they can be pretty cool
My biggest issue with Flatpak is that IDEs don’t have access to your console (there are some ways that sometimes work but they’re timeconsuming and non-trivial) which can be really annoying for developers As for AppImages: If you‘re using Wayland, there‘s a big chance that they require you to run XWayland since there is still no convenient way for developers to create an AppImage with native support and the creator of AppImage seems to be on a personal agenda against Wayland (and everything associated with Red Hat) so I prefer native and Flatpak over AppImages
One disadvantage of container formats (flatpak, snap, appimage, etc) that Nick didn't mention - which is also an advantage or system packages (RPM, DEB) is that if a library has a security issue, and the library developer fixes it, then they can release an updated DEB or RPM package that will get applied to your system and all depending applications will be immediately updated, but for applications in containers - you have to wait until the app developer updates their application - which may take a long time, possibly years, or it may never be updated: for example, the popular GNOME git client - gitg - has an official flatpak that was last updated December 2021 and still carries an old version of libssh with a serious security flaw that was fixed back in 2019. For some other security concerns, read "The sandbox is still a lie".
Responsible for the application is its developer, so if you create and distribute an application it is your responsibility to update it. Furthermore, I assure you that above all the fix release distributions are not so quick to update a vulnerable library, especially if used by non-prominent applications, indeed sometimes they are not really fixed. The case of VLC from some time ago on Ubuntu is proof of this.
Yeah, this security update of a dependency also breaks your app and good luck if you don't have time to look closely at what the developers of 894 Linux distros are up to. Really a paradise for an app developer. I link everything I can statically. It just saves me too much trouble when developing stuff where safety is not a primary concern. And if you don't want me to do it, then someone tell the distro devs to STOP BREAKING MY SH#T.
But that's not how distributions work, only rolling releases do it, the others at the limit make backports, but it is not said that they do, because it is always necessary to evaluate their impact and difficulty.
THANK YOU! I was a casual Linux user a long time ago, and then with Windows 11 being the metaphorical straw that broke this camels back, I am slowly moving my daily drive over to Linux, Mint 20.3 for now, and was hit with all this and see these messaged in Linux videos with no explanations. You saved my To Do list of looking this up that only had SNAPs checked off. Saved me time and was to the point. Thanks again.
As a ubuntu user, i have recently noticed that in my ubuntu 22.04 system, snap apps are launching very fast!! Sometimes snap apps launch with the same speed as flatpaks launch. This is a great sign that snaps are now improving, and we can see it 👍
That’s because Ubuntu 22.04 recently upgraded its kernel to 5.19. This new kernel adds a change that makes squashfs use multithreaded decompression. Previously it was just single core.
Yes, Canonical is improving them all the time. It just depends on the snap package you are using because they can rely on different core bases which utilize different tools and libraries to be run. If the developers behind the application update all of that, snaps shouldn't perform much different than flatpaks. The permissions work quite a bit different though. So sometimes either the flatpak or the snap can be somewhat broken or less secure than the other because of that.
That's good news! I left Ubuntu, when they went to the new LTS release last summer. I wanted to try Pop!_OS and I preferred it. The Ubuntu that has caught me eye is the new Unity spin. Looks like it could be cool and their new stand out project.
I'm an ubuntu user. I've seen many threads about the best linux app packaging format. The pros and cons, mostly said snap is suck, but sometimes leaves me confused. So rather than join the debates, i decided to use all those 3 snap, flatpak, and natives deb/dpkg/apt. Interestingly, i've found that every app can runs better in every different format. For example, Firefox runs overall better faster on flatpak, Steam app and games run overall better faster on native dpkg, and Spotify sound output is overall better on snap. So if i want to install an app i will install from all those 3 formats, compare and pick one which runs better. Now i'm relieved 😌
As someone new to Linux and on the verge of finishing a PC build to run Mint, this was incredibly helpful to understand the differences. Especially given the recent Flathub chatter on the interwebs.
As a new user, you dont have to get too deep into that discussion. It's mostly politics/philosophy discussed by overly dramatizing enthusiasts. You should simply focus on what works for YOUR use case scenario 💪☺️
As a long time linux user i prefer the native formats. They are the best. Doesn't takes up much space, uses less data (i am a mobile data user), best integration.
@@MrinmoyHaloi i use snaps (and it's documented on the web) so i can tell that snaps use delta upgrades just like rpm i suppose........granted fedora is considering to drop delta updates
"Flatpaks are only meant for graphical applications: they aren't a way to distribute libraries, or command line apps." There are some actually, but not convenient, so the point stands. Some crazy people (we all know who 😄) even packaged stuff like distrobox and alpine in it.
I use Flatpak and RPMs on my system. Both of them work quite well (sometimes I actually have to look it up if the application in question is an RPM or Flatpak), I find RPMs a bit easier to handle, especially when creating shortcuts manually or using the command line to launch/update it. I never install applications outside of the Fedora repos or the Flathub for security reasons
You didn't mention the biggest drawback of appimages: there is no centralized way to update them, you have to check every program manually for new versions and then download them.
5:28 There are some command-line tools distributed as a Flatpak, and they work just fine in my experience, though most non-graphical apps usually prefer being shipped as Snaps EDIT: But it can be annoying to have to do `flatpak run something.something.theapp.something`, but I think that if everything is configured properly and that you don't also have the app installed natively, you can just run it with the name of the app, but I don't really know as I have a custom menu for all my programs in any format I like
AppImages are so nice when you test development versions of new software. It's so helpful that they will run regardless of your system and the libraries you have installed.
Also being a MacOS user (oh, the horror), the ability to easily add & remove applications is nice too (as it works like AppImages) - plus being able to run 2 versions of the same app, means you can try before you upgrade/migrate. I feel like AppImages could have been (& still could be) the solution that negated Snaps & FlatPacks.
*appimage is based on the deprecated libfuse2 (it hasn't seen an update since 2013) ubuntu ships libfuse3 by default not the vulnerable libfuse2 ;) It is on the developer of appimage to fix it ;)
You can run Flatpaks from the command line it just requires typing flatpak run package_name [arguments]. So it is tedious. I suppose you could setup an alias so that flatpak-builder = flatpak run org.flatpak.Builder
Imho libraries are meant to be widely backwards compatible, so if you install libXY.3.7, every program which uses libXY.3 should be able to use it - maybe with bugs in 3.6, 3.5 and so on till 3.1. If your library change is breaking backwards compatibility, you should versionize it as libXY.4.0 - then incompatibilities are to be expected. And if a very program depends on libXY.4.*, you may install that single program by hand to /usr/local, so multiple versions of a software/library can coexist.
There's a major difference between snaps and flatpak. By default, nothing restrict the app to access the host file system. Flatpak is the opposite, by default it will block the access to the user's host file system. This is not that important for apps from big players like Canonical or Red Hat, but I personally believe that flatpak is much more secure for third-party apps, forcing the developer to ask for access to the host's file system.
I love Flatpaks, and honestly think they should become the first-class citizen for graphical applications going forward. I see Flatpaks as especially promising for gaming, as well as for productivity suites like Adobe and Affinity (Serif)... if they would ever get their acts together and show Linux some love, that is! That said, there have been situations in the past where AppImages were indispensable diamonds in the rough. So, yeah, there's definitely a place for all of them.
flatpaks and appimages are fantastic. a reduction in dependency hell. no longer need to add third party PPAs just for that one app because their distro is too slow to update the software. The sandboxed nature of flatpaks is also much added bonus. downside is the extra size, but space continues to get cheaper. there needs to be more support for an appimage central hub like flatpak
Thank you, Nick. I really like Linux, but sometimes feel lost as I learn this new environment. Your videos help a lot, and I've even been able to help answer questions for a couple other people now.
Oh thank you Nick for making this video when I want it the most Was learning how to install fedora after using Ubuntu for 6 months This video helped me a lot
13:03 Ubuntu doesn't prevent the installation of Flatpak. Some flavours just don't have it enabled by default anymore (Ubuntu never shipped flatpak by default). You can still enable it if necessary
You cleared one thing up for me, I could not understand why some updates I had to put in my su password and other time I did not. I did not know flatpack ran under just user.
1) Regular Package 2) Flatpak 3) Snap (if it is a command line tool or it is not available in flatpak) 4) AUR (at last because you never know, and I don't trust it much) If it is not an Arch derivative, I may prefer flatpak or snap over regular package for some app to get the last updates. I don't use appimages.
Great job summarizing the dizzying array of package types on Linux. And I think it's great advice to just "go with the flow" and use whatever package manager your distro encourages. Unless you're a developer in which case you'll have "special needs" and end up using them all...
I'm glad about Flatpak, because I prefer Debian, but in the past I had to use PPAs for things, and Debian didn't allow those for security reasons, but Flatpak is great. On two of my machines I run Mint's LMDE 6, and my old Chromebook I modified the UEFI/BIOS to run Linux on is now running Debian 12.2 Cinnamon, and it runs great.
Great video, thanks! There's not always much opportunity to come across this info, and realise what you don't know, if you're not deep into the linux world
In fact I would like to see more app images. I seriously like Windows' way of handling data (unpopular oppinion, I know) 🫡 and your description at 4:06 perfectly shows that, and I feel like app images comes closest to this 🙏
Not really. App images are more like portable all-in-one exe files on Windows, which are quite rare to find nowdays. Snaps and fltapacks are actually closer to Windows idea of installing software - because there're some libraries which are unique to this software (and usually they are installed to c:\program files\) and some are shared like msvc redistributable or directx which is installed systemwide and once-and-for-all
First thing I do after an Ubuntu install is sudo apt purge snapd. I occasionally use flatpack and appimage, but for the most part I use the apt repositories and developers sites...
I've been using Nix and Conty a lot since I use Vanilla, they're pretty good. Nix was confusing at first but itsfoss has a good introduction to it, I'm currently learning home-manager for it as it sounds super convenient for distro-hopping. But it isn't as comprehensive as AUR and Conty can help with some of that, especially for gaming as it compress a lot of stuff into a surprisingly small executable, and they include Steam, Bottles, and many emulators with the help of chaotic-aur. Add distrobox, flatpak, and appimage, surprisingly I don't need to use traditional package management on host all that much.
Reposting because _of course_ RUclips shadown-banned my comment for no reason. I think Richard Brown compared these really well in his 2023 Fosdem presentation. He explained some technical reasons why Flatpak is the better option as a software maintainer, it was really interesting.
I wish Canonical just gave up on trying to force snap on desktop linux. It really is a great tool for servers, and it shows that it was designed for servers in the first place. But for desktop flatpak is the clear winner even with it's small problems.
Back in the Amiga Workbench days programs would check for a minimum version of a library or file and so long as it met that requirement it would run. No dependency hell just a min version required, so you'd thing that in 2023 linux would use something similar.
not sure if i really understand it all just yet but to me ‘packages’ sounds like the best thing for the future. As an admin in a windows environment we’ve been using App-V for many years now. Application virtualization. Microsoft tech that sits between the ‘package’ and the OS to make sure everything works. instead of installing an application we just copy let’s call it an advanced zip file, that contains everything it needs, onto our machines (created via a wizard) . 1 application can no longer mess up another one.
By the way flatpaks and snaps can even be less secure depending on the attacker. Because with flatpaks you rely heavily on the maintainer to not just maintain the application itself to build properly but also all of its dependencies which are not inside a runtime. Then even if they are inside a runtime, they have to manually update the runtime they rely on as well. So it's actually possible that you install a flatpak which uses less updated/patched dependencies than you would use within your distribution via .rpm or .deb packages, potentially containing security vulnerabilities. In worst case this leads to sudo privileges escalation, making the fact you don't install them as root user irrelevant. That's why I would never blindly trust flatpaks or snaps. With snaps I think that's more unlikely than with flatpaks because you don't need to take care of as much dependencies on your own as maintainer (you can actually use .deb packages inside snaps). But the same mindset should still apply. So if anything I would mostly trust the packages coming from my distribution and their maintainers. Because most distributions rely on open-source software here. Therefore you could verify whether anything sketchy runs with sudo privileges but also the maintainers of your distribution do that (in theory). With flatpaks and snaps I have noticed as maintainer/developer that you package can encounter manual validation. But because of their configuration complexity, it's far more likely an attacker could put malicious code inside without them noticing. Also this validation is not mandatory for all releases.
I'm also an advocate for using the traditional packages for the base system, and the third-party package formats for GUI apps. Not to say that you shouldn't be allowed to install a GUI app via traditional means, but I couldn't tell you how many times I have ruined a system by trying to get a new app running through the distro-level package manager, and breaking a zillion dependencies. With packaging like Flatpak or AppImage, there is only so much damage an inexperienced user can do. An inexperienced user probably doesn't want to mess with their base system anyway, so it works very nicely having some kind of delineation between base system and user apps.
Great video! I feel like you explained everything very well, and the transition from flatpaks to snaps was smoother than LTT sponsor segues. Edit: Your sponsor segues are also getting smoother than LTT sponsor segues Edit 2: 18:37 😂😂
Nicely explained! Just the critical differences in method, advantages and disadvantages. PS: EXTRA RELEVANT -- The next uToob vidi I watched after this was Jay LaCroix's latest on his Learn Linux channel titled "New Linux Distro: The "Flatpak Remix" of Ubuntu (22.04)"! Link for download is in the comments section. 😮😁
good stuff... it would be good to mention performance. For example SNAP is definitely SLOWER. I used both the SNAP version of VS code (totally unaware of snap until seeking why it was slow and discovering SNAP and the community hatred for it because of that). I switched to a .deb installation and it was at least 15% faster on load spoeeds. and that matters to me as I hop around to different projects all day. So load times matter. Perhaps it is the somewhat sandboxed architecture of the way snaps operate that you detailed in this video and I had not considered. and perhaps thats the trade off for bassicaly a sandbox on demand when using SNAP apps and I agree that SNAP looks Great on paper... but the real world result in performance need to ramp up.
~ 2:30 - Nick, Nick, Nick - there is nothing to prevent people preparing Linux packages to include crap in them, or Windows *.msi packagers to omit it. As for shared libraries, the purpose and idea behind *.so libraries and *.dll is exactly the same. Problems, too.
From me the best fit is pacman + AUR, and Appimage for the outdated apps. I like Manjaro because they test packages for a while. I don't know too much but Nix seems to be a interesting project.
Hello, some corrections... Deb and Rpm packages are not windows exes equivalents... They're not self executables, they maybe the equivalents to windows cab files... The 'classic' way to install software in a Linux distro relies on its own packaging system, that handles the dependency and depends on the distro community that maintains it... It's security relies mainly on the distro maintainers... and common sense (you cannot mix repositories or install packages from not recommended and untrusted sources, unless you know what you're doing) in a beginning when there were not packages at all the way to install a program in Linux was compiling the source code, get the tarball, read, compile before the dependencies, and that was a lot of work, time, frustration... That is why when the mother distros were born (Debian, Red Hat and Slackware) ideated a solution to that mess, and they got up with a fakeroot based way to install software easier, Debian did it's own way, and Red Hat did its own. If you use a graphical Installer like KDE Discover or GNOME software center, whatever is named, it is just the graphical front end, under the hood, Apt manages it's database of what is installed and not, dependencies, etc. and then it calls dpkg to 'unpack' the Deb files or packages and run the settings it needs, the same is done by Qapt, Gdebi and other graphic tools that installs Deb files 'manually' , Rpm goes a similar way, so Deb and Rpm are incompatible, you may use alien to convert the packages, but today is mostly unnecessary cause by now most distros provide a huge quantity of software.
All have pros and cons, but I believe Appimages or a derivative of the idea is the way forward, not only across linux distro's but also windows and mac. Most software developments are now cross platform linux - mac - windows, it only makes sense to find a more uniform distribution method for all. Freecad (quite a complex app) started focusing primarily on Appimages, yes you can still download via snaps and flatpak but not necessarily the latest version. Would be a breath of fresh air to see linux disro's and developers come together and agree on a road map for the future. What I see now is distro's going off on separate tangents to prove their point (except for Vanilla), such a waste of time and resources.
13:40 I like that actually... makes deleting simple... so many times I would delete something and a bunch of files related to that application are just still on the computer.
I'll be hopping into Linux this year and from what I see I'm feeling flatpaks and DEBs/RPMs. Although I'm a total noob so I'm sure what I feel later will change
I like to use mostly packages in the arch repositories, and if I cannot or do not want to for any reason, I use flatpack or appimages depending on the situation. Snaps just cause issues and don't need to exist.
The "These formats aren't important" section is a very good point to throw in there. Ultimately there's no universally best system. If there was, we'd all be using it and there'd be no discussion. There's only the system that works for you. For me that's a mix of Flatpaks and the traditional packages. Flatpaks do the job and do it well for most uses, but for something like Steam I like a native package minimize overhead.
In fact it seems the Appimage developer is thinking of doing just that he static linking to fuse2. Seems a most retrograde approach to me and a disservice to his own innovative work in developing a potentially very useful format.
The only and best way is put a recall repositories in the terminal sudo install. You want something not terminal based? Then just put a simple visual version of it. If I click then start sudo install. We need a mix between those two procedures: more closer to Homebrew.
1:58 - Windows MSI files are indeed packages just like RPM and DEBs: they are installed using the Microsoft Windows Installer service, which is just another packaging system: it reads a documented archive format (MSI), knows to put files in different places and run custom scripts before, during and after installation and removal - just like RPMs and DEBs. The only major difference between MSI and its Linux counterparts is that while dpkg and rpm enjoy decades of development and experience in supporting complex packaging requirements and dependency management, MSI in kind of a junky 1.0 version, and was never then improved upon - Windows developers are like - installing is hard, I'm just going to let this commercial product that I've learned to use to create MSI packages for me, and its going to hack it to look like those EXE install wizards, and I don't care, and as a result Microsoft's customers for the MSI protocol are just the "install wizard" makers and no one has any incentive to make a packaging format that is flexible, simple and that developers understand.
Wish I saw this video sooner. I remember trying to understand the package formats when I was trying to get the latest version of an 3D printer slicing program called Cura on my laptop running Fedora KDE Spin. The RPM format of Cura from the Fedora app store is incredibly old (v4) and Cura have their v5 app image on their website. It runs just like on Windows however it uses a different file manager and that means I can't save to my SMB share. I did saw/tried other methods but I don't remember as I ended up reinstalling Windows on my laptop for the convenience of an relative who I share this laptop with when he needs to borrow it. But I had been meaning to return to Linux on my gaming PC whenever Microsoft drops support for Windows 10.
what would be nice with the thing you were talking about around the 16 to 16:19 point. It would be nice to be able to have a kernel level tool that could read what a package needs, determine with the advent of things like flatpak & snaps if you have something in another package that could be used for a new package and creates a centralized package that hands those out, basically take the best of both worlds of .deb and all those others and the niceness of packaging everything an app needs in its file in a self-contained unit.
Thank you, Nick. I've settled .debs or, preferably, flatpacks. I'm on POP waiting for the new COSMIC DE to be ready so flatpacks allow an LTS to have the newest version of software.
The Biggest advantage of Linux for me was always that most Times apt-get install was perfect, one to rule them all. Now not only do you need to choose a distro but also a package Manager.
Using SteamOS Flatpak is what you get through Discover. It seems to work fine for my needs. That is my main Linux PC now. Actually seems to have taken over as my actual main PC most of the time... I have not really installed much software on my portable Ubuntu install as that is mostly for troubleshooting and retrieving data from busted OSs. I've also not really used Ubuntu much since my Steam Deck arrived. It just seems to have taken over everything. I still mostly install packages through the terminal though when working or studying. Then again that is mostly on a variety of VMs or an RPi.
Download Safing's Portmaster and take control of your network traffic: safing.io
I have yet to see a single windows program that required me to click next ten times or bypass "prechecked crapware" or whatever that is. I'm starting to think you have never used windows in your whole life.
@queerdo Sorry, i don't install blatant malware from shady websites. In fact, i don't install anything, because i use winget, which is like Flatpacks but with automatic updates, and i use PortableApps, which is like AppImages, but with automatic updates. Linux still has no alternative to this.
you forgot to go over Nix package manager
flatpak is able to run command line apps and there are command line apps available for flatpak like neovim
@queerdo Why install anything from shady sources when Winget allows you to install anything that isn't from a shady source?
I think an important advantage of Flatpak that's rarely talked about is de-duplication.
In addition to shared runtimes, Flatpak uses a special technology called OSTree, which means any duplicate file or library across your entire Flatpak installation (apps + runtimes) will only be downloaded and stored once; this is called de-duplication.
This is why, when you install a new app, Flatpak will sometimes download less than the total size of the app, because some files or libraries were already present on your computer.
This is also why Flatpak updates tend to be really small, as only new or modified files get downloaded during updates.
De-duplication is a powerful feature of Flatpak that helps optimize storage space, reduce bandwidth usage, and make updates more efficient, ultimately providing a more streamlined and efficient user experience
@@x-mishl are you chatgpt
@@Autotrope I hope youngsters aren’t tempted to start typing in poor grammar just to avoid the impression of ChatGPT
I have the opposite experience
I tried downloading a 30mb file and flat pack proceeds to download 1gb
And apt only downloaded 8mb for the same file
So I don't really think de-duplication or whatever is unique to flatpak
Only modified files being updated is pretty much the standard for most package managers
@@JamesQHolden47it's not just the grammar. it's the unprompted paragraph that reads like a wikipedia page.
I like that you tell people "use whatever you like". They're all used so widely that... I think they all have something that is compelling enough to people.
It's been a theme with your channel throughout. I think it creates less toxicity and more enthusiasm for the possibilities Linux has to offer for users without making them feel like they should be ashamed for what they're using.
Yeah, they all work, and they all serve a purpose. Use what works is my motto here
@@TheLinuxEXP It's a nice contrast... but to use apple phones for example, even though you seem to care about privacy?
Especially with how against repair they are, which creates just so much e-waste. Apple is just about as bad as Microsoft.
@@elecbaguette Choosing phones is like electing a US president, though. It’s not about which one is the best, but rather which one is the least bad. Both iOS and Android are privacy nightmares, and using any «alternative» phone OS will throw you into usability issues from the get-go as of now.
@@elecbaguette apple recently restricted Chinese users airdrop function to negatively influence a massive protest against co-vid policies. Apple has turned into a political pos company.
@@bragefuglseth3505 I believe the fairphone is a good alternative, though I haven't gotten one yet.
This clears up a lot. I've been using Mint for about 6 years now and have generally stuck to their package manager for apps, but have successfully used Flatpak and Appimage packages. The recent Flatpak support in Mint's package manager works very well.
I wonder if Nix and source packages could have been included in this video, but, well, from source is not really what this targets, but I could still see Nix packages included in there, they can be pretty cool
Or homebrew for that matter.
Nix is so new, it doesn't even have stacer 😂
Give it some time to get it mature.
Nix also has binary packages so uh yeah xd
@@alwasif it's over 10 years old actually, it has more packages than the aur xd
I can't even build Microsoft-edge-dev in nix os, then I mostly use stacer that is not in the nix stable repo. How may I even start with nix?!
My biggest issue with Flatpak is that IDEs don’t have access to your console (there are some ways that sometimes work but they’re timeconsuming and non-trivial) which can be really annoying for developers
As for AppImages: If you‘re using Wayland, there‘s a big chance that they require you to run XWayland since there is still no convenient way for developers to create an AppImage with native support and the creator of AppImage seems to be on a personal agenda against Wayland (and everything associated with Red Hat) so I prefer native and Flatpak over AppImages
One disadvantage of container formats (flatpak, snap, appimage, etc) that Nick didn't mention - which is also an advantage or system packages (RPM, DEB) is that if a library has a security issue, and the library developer fixes it, then they can release an updated DEB or RPM package that will get applied to your system and all depending applications will be immediately updated, but for applications in containers - you have to wait until the app developer updates their application - which may take a long time, possibly years, or it may never be updated: for example, the popular GNOME git client - gitg - has an official flatpak that was last updated December 2021 and still carries an old version of libssh with a serious security flaw that was fixed back in 2019.
For some other security concerns, read "The sandbox is still a lie".
Responsible for the application is its developer, so if you create and distribute an application it is your responsibility to update it. Furthermore, I assure you that above all the fix release distributions are not so quick to update a vulnerable library, especially if used by non-prominent applications, indeed sometimes they are not really fixed.
The case of VLC from some time ago on Ubuntu is proof of this.
@@carlocoppa5246 I assure you that libssh was updated by all distributions, at least once (*) since 2019.
*) And likely many many more times.
Yeah, this security update of a dependency also breaks your app and good luck if you don't have time to look closely at what the developers of 894 Linux distros are up to. Really a paradise for an app developer.
I link everything I can statically. It just saves me too much trouble when developing stuff where safety is not a primary concern. And if you don't want me to do it, then someone tell the distro devs to STOP BREAKING MY SH#T.
But that's not how distributions work, only rolling releases do it, the others at the limit make backports, but it is not said that they do, because it is always necessary to evaluate their impact and difficulty.
@@carlocoppa5246 another proof was the vpn solution in EPEL. One maintainer, hope you get support etc.. You don't want this. Really you don't.
THANK YOU! I was a casual Linux user a long time ago, and then with Windows 11 being the metaphorical straw that broke this camels back, I am slowly moving my daily drive over to Linux, Mint 20.3 for now, and was hit with all this and see these messaged in Linux videos with no explanations. You saved my To Do list of looking this up that only had SNAPs checked off. Saved me time and was to the point. Thanks again.
As a ubuntu user, i have recently noticed that in my ubuntu 22.04 system, snap apps are launching very fast!! Sometimes snap apps launch with the same speed as flatpaks launch. This is a great sign that snaps are now improving, and we can see it 👍
That’s because Ubuntu 22.04 recently upgraded its kernel to 5.19. This new kernel adds a change that makes squashfs use multithreaded decompression. Previously it was just single core.
Yes, Canonical is improving them all the time. It just depends on the snap package you are using because they can rely on different core bases which utilize different tools and libraries to be run. If the developers behind the application update all of that, snaps shouldn't perform much different than flatpaks.
The permissions work quite a bit different though. So sometimes either the flatpak or the snap can be somewhat broken or less secure than the other because of that.
That's good news! I left Ubuntu, when they went to the new LTS release last summer. I wanted to try Pop!_OS and I preferred it. The Ubuntu that has caught me eye is the new Unity spin. Looks like it could be cool and their new stand out project.
Honestly i think snaps are faster on kde than gnome, but maybe that's just me
Ubuntu isn't sleeping. Of course they work on improving their baby 💪😁
I'm an ubuntu user. I've seen many threads about the best linux app packaging format. The pros and cons, mostly said snap is suck, but sometimes leaves me confused. So rather than join the debates, i decided to use all those 3 snap, flatpak, and natives deb/dpkg/apt. Interestingly, i've found that every app can runs better in every different format. For example, Firefox runs overall better faster on flatpak, Steam app and games run overall better faster on native dpkg, and Spotify sound output is overall better on snap.
So if i want to install an app i will install from all those 3 formats, compare and pick one which runs better. Now i'm relieved 😌
As someone new to Linux and on the verge of finishing a PC build to run Mint, this was incredibly helpful to understand the differences. Especially given the recent Flathub chatter on the interwebs.
As a new user, you dont have to get too deep into that discussion. It's mostly politics/philosophy discussed by overly dramatizing enthusiasts.
You should simply focus on what works for YOUR use case scenario 💪☺️
Please list out your pc components, im planning to build a linix PC too. Thx in advance
As a long time linux user i prefer the native formats. They are the best. Doesn't takes up much space, uses less data (i am a mobile data user), best integration.
Actually snap updates use less data, unlike native packages it has delta updates ;)
@@fuseteam Can't say about snaps as I don't use it. But flatpaks use a lot of data. And rpms also support delta upgrade
@@MrinmoyHaloi i use snaps (and it's documented on the web) so i can tell that snaps use delta upgrades just like rpm i suppose........granted fedora is considering to drop delta updates
This was a great rundown! Flatpaks work so well for me with Mint and their updater. It's great that there's no bad way :)
"Flatpaks are only meant for graphical applications: they aren't a way to distribute libraries, or command line apps."
There are some actually, but not convenient, so the point stands. Some crazy people (we all know who 😄) even packaged stuff like distrobox and alpine in it.
I use Flatpak and RPMs on my system. Both of them work quite well (sometimes I actually have to look it up if the application in question is an RPM or Flatpak), I find RPMs a bit easier to handle, especially when creating shortcuts manually or using the command line to launch/update it.
I never install applications outside of the Fedora repos or the Flathub for security reasons
you can update and launch flatpaks very easily through flatpak cli too. And the slight inconvenience it part and parcel of a sanboxed system.
You didn't mention the biggest drawback of appimages: there is no centralized way to update them, you have to check every program manually for new versions and then download them.
Great explanation, I finally understand what's the deal with flatpaks and why they're taking over the landscape. Thanks!
5:28 There are some command-line tools distributed as a Flatpak, and they work just fine in my experience, though most non-graphical apps usually prefer being shipped as Snaps
EDIT: But it can be annoying to have to do `flatpak run something.something.theapp.something`, but I think that if everything is configured properly and that you don't also have the app installed natively, you can just run it with the name of the app, but I don't really know as I have a custom menu for all my programs in any format I like
In order to not to call it with a long name you can create an alias which will call the package by typing less
You can create aliases to make it easier running your flatpaks from the terminal
alias something="flatpak run something.something.theapp.something"
which cli tools do you use from flatpak?
@egorandreevich7830 It stands for Command Line Interface tools. Basically commands you run in thebterminal
AppImages are so nice when you test development versions of new software. It's so helpful that they will run regardless of your system and the libraries you have installed.
Also being a MacOS user (oh, the horror), the ability to easily add & remove applications is nice too (as it works like AppImages) - plus being able to run 2 versions of the same app, means you can try before you upgrade/migrate.
I feel like AppImages could have been (& still could be) the solution that negated Snaps & FlatPacks.
*appimage is based on the deprecated libfuse2 (it hasn't seen an update since 2013) ubuntu ships libfuse3 by default not the vulnerable libfuse2 ;)
It is on the developer of appimage to fix it ;)
Flatpacks really need to consider adding the terminal type of apps, in the future.
You can run Flatpaks from the command line it just requires typing flatpak run package_name [arguments]. So it is tedious. I suppose you could setup an alias so that flatpak-builder = flatpak run org.flatpak.Builder
It exists, it's just not listed on the website. And they don't push for getting those apps.
Flathub that is
Imho libraries are meant to be widely backwards compatible, so if you install libXY.3.7, every program which uses libXY.3 should be able to use it - maybe with bugs in 3.6, 3.5 and so on till 3.1.
If your library change is breaking backwards compatibility, you should versionize it as libXY.4.0 - then incompatibilities are to be expected.
And if a very program depends on libXY.4.*, you may install that single program by hand to /usr/local, so multiple versions of a software/library can coexist.
There's a major difference between snaps and flatpak. By default, nothing restrict the app to access the host file system. Flatpak is the opposite, by default it will block the access to the user's host file system.
This is not that important for apps from big players like Canonical or Red Hat, but I personally believe that flatpak is much more secure for third-party apps, forcing the developer to ask for access to the host's file system.
I love Flatpaks, and honestly think they should become the first-class citizen for graphical applications going forward. I see Flatpaks as especially promising for gaming, as well as for productivity suites like Adobe and Affinity (Serif)... if they would ever get their acts together and show Linux some love, that is!
That said, there have been situations in the past where AppImages were indispensable diamonds in the rough. So, yeah, there's definitely a place for all of them.
flatpaks and appimages are fantastic. a reduction in dependency hell. no longer need to add third party PPAs just for that one app because their distro is too slow to update the software. The sandboxed nature of flatpaks is also much added bonus. downside is the extra size, but space continues to get cheaper. there needs to be more support for an appimage central hub like flatpak
Thank you, Nick. I really like Linux, but sometimes feel lost as I learn this new environment. Your videos help a lot, and I've even been able to help answer questions for a couple other people now.
Oh thank you Nick for making this video when I want it the most
Was learning how to install fedora after using Ubuntu for 6 months
This video helped me a lot
13:03 Ubuntu doesn't prevent the installation of Flatpak. Some flavours just don't have it enabled by default anymore (Ubuntu never shipped flatpak by default). You can still enable it if necessary
They prevent flavors from preinstalling it
ubuntu server will install flatpak as a snaps package (on the setup screen)
You cleared one thing up for me, I could not understand why some updates I had to put in my su password and other time I did not. I did not know flatpack ran under just user.
1) Regular Package
2) Flatpak
3) Snap (if it is a command line tool or it is not available in flatpak)
4) AUR (at last because you never know, and I don't trust it much)
If it is not an Arch derivative, I may prefer flatpak or snap over regular package for some app to get the last updates. I don't use appimages.
Great job summarizing the dizzying array of package types on Linux. And I think it's great advice to just "go with the flow" and use whatever package manager your distro encourages. Unless you're a developer in which case you'll have "special needs" and end up using them all...
I just use AUR and Flatpak on EndeavourOS and I haven't had any issues. Best combo imo
I'm glad about Flatpak, because I prefer Debian, but in the past I had to use PPAs for things, and Debian didn't allow those for security reasons, but Flatpak is great. On two of my machines I run Mint's LMDE 6, and my old Chromebook I modified the UEFI/BIOS to run Linux on is now running Debian 12.2 Cinnamon, and it runs great.
Great video, thanks! There's not always much opportunity to come across this info, and realise what you don't know, if you're not deep into the linux world
In fact I would like to see more app images. I seriously like Windows' way of handling data (unpopular oppinion, I know) 🫡 and your description at 4:06 perfectly shows that, and I feel like app images comes closest to this 🙏
Not really. App images are more like portable all-in-one exe files on Windows, which are quite rare to find nowdays. Snaps and fltapacks are actually closer to Windows idea of installing software - because there're some libraries which are unique to this software (and usually they are installed to c:\program files\) and some are shared like msvc redistributable or directx which is installed systemwide and once-and-for-all
First thing I do after an Ubuntu install is sudo apt purge snapd. I occasionally use flatpack and appimage, but for the most part I use the apt repositories and developers sites...
I've been using Nix and Conty a lot since I use Vanilla, they're pretty good. Nix was confusing at first but itsfoss has a good introduction to it, I'm currently learning home-manager for it as it sounds super convenient for distro-hopping. But it isn't as comprehensive as AUR and Conty can help with some of that, especially for gaming as it compress a lot of stuff into a surprisingly small executable, and they include Steam, Bottles, and many emulators with the help of chaotic-aur. Add distrobox, flatpak, and appimage, surprisingly I don't need to use traditional package management on host all that much.
Thanks so much for this video, it cleared up several misconceptions I have had.
nice sponsor! safing is actually really cool!
Reposting because _of course_ RUclips shadown-banned my comment for no reason.
I think Richard Brown compared these really well in his 2023 Fosdem presentation.
He explained some technical reasons why Flatpak is the better option as a software maintainer, it was really interesting.
Thanks, I’ll look it up!
.
I’ve recently returned to Linux and this channel has been super helpful in getting caught up on what’s been happening.
Flatpaks vs snaps vs appimage was something I've been interested in for sometime now
Great video! At last these are explained. I am new to Linux and I am so confused. Thank you.
I couldn't explain all of this to anyone. So, thanks so much for this video! 😊
Really nice walk-through. I'll look for your channel in future searches.
I wish Canonical just gave up on trying to force snap on desktop linux. It really is a great tool for servers, and it shows that it was designed for servers in the first place. But for desktop flatpak is the clear winner even with it's small problems.
Thank you for the clear explanation of these technologies. I remember when I would get a tarball and then run configure and make.
Thanks. This made things a lot clearer.
Thanks a lot for these clarifications. With Linux, you learn a new trick everyday!
Back in the Amiga Workbench days programs would check for a minimum version of a library or file and so long as it met that requirement it would run. No dependency hell just a min version required, so you'd thing that in 2023 linux would use something similar.
Great overview! And thanks for going a bit deeper by including the fair warnings about the aur.
Oh yeah, It's basically Wild West 😵💫
@@ArniesTech pretty much. the aur team try their best to keep it together though.
MacOS is the originator of the monolithic app package concept several years before Flatpack or Snap were even a glimmer in anyone's eyes.
not sure if i really understand it all just yet but to me ‘packages’ sounds like the best thing for the future. As an admin in a windows environment we’ve been using App-V for many years now. Application virtualization. Microsoft tech that sits between the ‘package’ and the OS to make sure everything works. instead of installing an application we just copy let’s call it an advanced zip file, that contains everything it needs, onto our machines (created via a wizard) . 1 application can no longer mess up another one.
By the way flatpaks and snaps can even be less secure depending on the attacker. Because with flatpaks you rely heavily on the maintainer to not just maintain the application itself to build properly but also all of its dependencies which are not inside a runtime. Then even if they are inside a runtime, they have to manually update the runtime they rely on as well.
So it's actually possible that you install a flatpak which uses less updated/patched dependencies than you would use within your distribution via .rpm or .deb packages, potentially containing security vulnerabilities. In worst case this leads to sudo privileges escalation, making the fact you don't install them as root user irrelevant.
That's why I would never blindly trust flatpaks or snaps. With snaps I think that's more unlikely than with flatpaks because you don't need to take care of as much dependencies on your own as maintainer (you can actually use .deb packages inside snaps). But the same mindset should still apply.
So if anything I would mostly trust the packages coming from my distribution and their maintainers. Because most distributions rely on open-source software here. Therefore you could verify whether anything sketchy runs with sudo privileges but also the maintainers of your distribution do that (in theory).
With flatpaks and snaps I have noticed as maintainer/developer that you package can encounter manual validation. But because of their configuration complexity, it's far more likely an attacker could put malicious code inside without them noticing. Also this validation is not mandatory for all releases.
Which is great if your distro happens to maintain the software you want to install at the version you want to install it. Otherwise it's useless.
This is great! I didn't understand Snaps vs Flatpaks until this video
Thank you so much for the video, this video helped me a lot to understand the Linux Packaging formats.
Congrats to 250k followers!! 🥳 I've never thought that there is so much interest in Linux
I'm also an advocate for using the traditional packages for the base system, and the third-party package formats for GUI apps. Not to say that you shouldn't be allowed to install a GUI app via traditional means, but I couldn't tell you how many times I have ruined a system by trying to get a new app running through the distro-level package manager, and breaking a zillion dependencies. With packaging like Flatpak or AppImage, there is only so much damage an inexperienced user can do. An inexperienced user probably doesn't want to mess with their base system anyway, so it works very nicely having some kind of delineation between base system and user apps.
Agree with this completely. Arguably package managers shouldn't even try to offer access to GUI software.
@@jez9999 Interesting. What about base desktop stuff?
Great video! I feel like you explained everything very well, and the transition from flatpaks to snaps was smoother than LTT sponsor segues.
Edit: Your sponsor segues are also getting smoother than LTT sponsor segues
Edit 2: 18:37 😂😂
AppImages can be sandboxed with firejail. Not easy for many users, but at least it is possible.
I'm looking into it now, as a non-technical user, been away from Linux a spell. I am hopeful. Firejail seems so useful for my use case.
Nicely explained! Just the critical differences in method, advantages and disadvantages. PS: EXTRA RELEVANT -- The next uToob vidi I watched after this was Jay LaCroix's latest on his Learn Linux channel titled "New Linux Distro: The "Flatpak Remix" of Ubuntu (22.04)"! Link for download is in the comments section. 😮😁
Thank you so much for explaining all these formats.
Отличное видео, быстро и по делу.
Great explanation! Thank you for creating this video.
Thanks Nic!
Really enjoy and learn from your show!
Thanks, Nick. Always worth the time!
Long Life to App Image...They are Right...
For command line apps, would be nice a mention of Homebrew, pip and npm.
I find nix better than homebrew. there is even a portable version where you don't need permission to install it.
You probably even want to use toolbx or distrobox for that, instead of polluting your Main System
@@razzeeee You are right, I didn't know much about those at the time. Also, now would be pipx instead of pip
good stuff... it would be good to mention performance. For example SNAP is definitely SLOWER. I used both the SNAP version of VS code (totally unaware of snap until seeking why it was slow and discovering SNAP and the community hatred for it because of that). I switched to a .deb installation and it was at least 15% faster on load spoeeds. and that matters to me as I hop around to different projects all day. So load times matter. Perhaps it is the somewhat sandboxed architecture of the way snaps operate that you detailed in this video and I had not considered. and perhaps thats the trade off for bassicaly a sandbox on demand when using SNAP apps and I agree that SNAP looks Great on paper... but the real world result in performance need to ramp up.
thanks. as a newbie, these vids are highly valuable to me
I was just missing the NixPackages. They are very interesting because they are totally different.😉
Thanks a lot for this, I'll have to rewatch it a few times, this has been the most confusing thing after returning to Linux in around 5 years O_o
There's a way to make a perfect solution. What a shame nobody can cooperate to remove all this mess.
I like flatpaks and i hope it becomes the norm. Mainly because it just works everywhere. It is not perfect but could be worse.
~ 2:30 - Nick, Nick, Nick - there is nothing to prevent people preparing Linux packages to include crap in them, or Windows *.msi packagers to omit it. As for shared libraries, the purpose and idea behind *.so libraries and *.dll is exactly the same. Problems, too.
Two sopnser in a video!
Great job man, Linux RUclipsrs need this growth🎉
From me the best fit is pacman + AUR, and Appimage for the outdated apps. I like Manjaro because they test packages for a while.
I don't know too much but Nix seems to be a interesting project.
Hello, some corrections... Deb and Rpm packages are not windows exes equivalents... They're not self executables, they maybe the equivalents to windows cab files... The 'classic' way to install software in a Linux distro relies on its own packaging system, that handles the dependency and depends on the distro community that maintains it... It's security relies mainly on the distro maintainers... and common sense (you cannot mix repositories or install packages from not recommended and untrusted sources, unless you know what you're doing) in a beginning when there were not packages at all the way to install a program in Linux was compiling the source code, get the tarball, read, compile before the dependencies, and that was a lot of work, time, frustration... That is why when the mother distros were born (Debian, Red Hat and Slackware) ideated a solution to that mess, and they got up with a fakeroot based way to install software easier, Debian did it's own way, and Red Hat did its own. If you use a graphical Installer like KDE Discover or GNOME software center, whatever is named, it is just the graphical front end, under the hood, Apt manages it's database of what is installed and not, dependencies, etc. and then it calls dpkg to 'unpack' the Deb files or packages and run the settings it needs, the same is done by Qapt, Gdebi and other graphic tools that installs Deb files 'manually' , Rpm goes a similar way, so Deb and Rpm are incompatible, you may use alien to convert the packages, but today is mostly unnecessary cause by now most distros provide a huge quantity of software.
All have pros and cons, but I believe Appimages or a derivative of the idea is the way forward, not only across linux distro's but also windows and mac. Most software developments are now cross platform linux - mac - windows, it only makes sense to find a more uniform distribution method for all. Freecad (quite a complex app) started focusing primarily on Appimages, yes you can still download via snaps and flatpak but not necessarily the latest version. Would be a breath of fresh air to see linux disro's and developers come together and agree on a road map for the future. What I see now is distro's going off on separate tangents to prove their point (except for Vanilla), such a waste of time and resources.
13:40 I like that actually... makes deleting simple... so many times I would delete something and a bunch of files related to that application are just still on the computer.
While you mentioned AUR you should have mentioned DUR as well, although it is still pretty small but I believe it will take off with time...hopefully😅
As always writing a comment to support the channel
I'll be hopping into Linux this year and from what I see I'm feeling flatpaks and DEBs/RPMs. Although I'm a total noob so I'm sure what I feel later will change
I like to use mostly packages in the arch repositories, and if I cannot or do not want to for any reason, I use flatpack or appimages depending on the situation. Snaps just cause issues and don't need to exist.
MANNNNNN I really needed to see this video!!!
The "These formats aren't important" section is a very good point to throw in there. Ultimately there's no universally best system. If there was, we'd all be using it and there'd be no discussion. There's only the system that works for you. For me that's a mix of Flatpaks and the traditional packages. Flatpaks do the job and do it well for most uses, but for something like Steam I like a native package minimize overhead.
Soon (March 26) Garuda Linux makes 3 years 🎉 Maybe worth a video about it, especially on a laptop. 😇
Thank for the video! Great work!
Appimages...sounds like a reversion to 35 yrs ago when you would decide if you are going to use static linking or dynamic libraries in your compile.
In fact it seems the Appimage developer is thinking of doing just that he static linking to fuse2. Seems a most retrograde approach to me and a disservice to his own innovative work in developing a potentially very useful format.
The only and best way is put a recall repositories in the terminal sudo install.
You want something not terminal based? Then just put a simple visual version of it. If I click then start sudo install.
We need a mix between those two procedures: more closer to Homebrew.
Using snap you can pin a specific "release channel", like a major version. So, when a new major version comes your app will not be updated to it.
1:58 - Windows MSI files are indeed packages just like RPM and DEBs: they are installed using the Microsoft Windows Installer service, which is just another packaging system: it reads a documented archive format (MSI), knows to put files in different places and run custom scripts before, during and after installation and removal - just like RPMs and DEBs.
The only major difference between MSI and its Linux counterparts is that while dpkg and rpm enjoy decades of development and experience in
supporting complex packaging requirements and dependency management, MSI in kind of a junky 1.0 version, and was never then improved upon - Windows developers are like - installing is hard, I'm just going to let this commercial product that I've learned to use to create MSI packages for me, and its going to hack it to look like those EXE install wizards, and I don't care, and as a result Microsoft's customers for the MSI protocol are just the "install wizard" makers and no one has any incentive to make a packaging format that is flexible, simple and that developers understand.
Wish I saw this video sooner. I remember trying to understand the package formats when I was trying to get the latest version of an 3D printer slicing program called Cura on my laptop running Fedora KDE Spin. The RPM format of Cura from the Fedora app store is incredibly old (v4) and Cura have their v5 app image on their website. It runs just like on Windows however it uses a different file manager and that means I can't save to my SMB share. I did saw/tried other methods but I don't remember as I ended up reinstalling Windows on my laptop for the convenience of an relative who I share this laptop with when he needs to borrow it.
But I had been meaning to return to Linux on my gaming PC whenever Microsoft drops support for Windows 10.
very informational video, thanks nick
what would be nice with the thing you were talking about around the 16 to 16:19 point. It would be nice to be able to have a kernel level tool that could read what a package needs, determine with the advent of things like flatpak & snaps if you have something in another package that could be used for a new package and creates a centralized package that hands those out, basically take the best of both worlds of .deb and all those others and the niceness of packaging everything an app needs in its file in a self-contained unit.
Thank you, Nick. I've settled .debs or, preferably, flatpacks. I'm on POP waiting for the new COSMIC DE to be ready so flatpacks allow an LTS to have the newest version of software.
I finally understood the Snap situation.
The Biggest advantage of Linux for me was always that most Times apt-get install was perfect, one to rule them all.
Now not only do you need to choose a distro but also a package Manager.
Nah not needed, zypper, apt all suffice tbh
It's not like apt-get has gotten worse
Using SteamOS Flatpak is what you get through Discover. It seems to work fine for my needs. That is my main Linux PC now. Actually seems to have taken over as my actual main PC most of the time...
I have not really installed much software on my portable Ubuntu install as that is mostly for troubleshooting and retrieving data from busted OSs. I've also not really used Ubuntu much since my Steam Deck arrived. It just seems to have taken over everything.
I still mostly install packages through the terminal though when working or studying. Then again that is mostly on a variety of VMs or an RPi.
I generally stick to the terminal for installs via "apt install" and "apt upgrade" (on Mint).
Try installing an app that isn't in the mint repos or a different version to the one in the repos.
@@jez9999 You can add repos to the list.
Great video Nick!