Why I No Longer Use Flatpak

[@TheLinuxCast]

I now have an amazing store that has all sorts of awesome things. All sales go directly toward making more Linux content for you guys. shop.thelinuxcast.org

[@Timely7]

One thing I do want to say is that I am using Fedora 39 which uses Wayland and After installing OBS it worked out of the box. They have added Wayland support I believe as next to some of the buttons especially record it says (Pipe wire). I did just want to say this as to inform you and not to say I know more than you or are better than you as I am quite new to Linux. But I just wanted to say that I do believe that they have updated it to be more integrated into Wayland which is very good.

[@CosmicChew]

What is that cube on your other computer desk? I want to pick one up.

[@TheLinuxCast]

@@CosmicChew Amazon search Davoom. That's the company that makes it.

[@CosmicChew]

@@TheLinuxCast I appreciate it.

[@damianateiro]

Using flatpak to snaps or appimages as your official way of distributing your app is to save having to maintain other formats and by having a way in which anyone can install no matter where they are from, I see it as much better than dealing with problems that have arisen. caused by the maintainers of a distro, whether they do it well is another thing

[@lovebaranus9800]

Most real take. I think it's unfair that devs have to deal with the bullshit that is packaging on linux themselves, and flatpak is really getting closer to solving it everyday. And distrobox, while being awesome, isn't more of an alternative than say, a VM, or using docker directly, if anything running (almost) an entire OS inside your OS is FAR more bloat than whatever space 40 flatpaks may be using. It only makes sense if you are the target audience of docker/distrobox, a software dev, but otherwise then it's just unnecesary complexity.

[@survivor303]

If you want that people using your software, you make then sure it is available in every damn format. You dont need to make the work, you just ask community to build and update those random ports, but let face it, it is easy now days to just make those damn packages directly from the ide, the whole argument that it is burden to devs is old.

[@survivor303]

@@lovebaranus9800 you code for linux then play the damn rules, otherwise, code for windows.

[@tomasruzicka9835]

​@@lovebaranus9800It's interesting. Because Windows actually forces the dev to distribute the app. Linux app repositories actually in principle take the burden away from the developer. But it's interesting that in practice it does the exact oposite.

[@notuxnobux]

I use flatpak for my software, and one of the best reasons for me is that I can keep it up to date. Some distros are very late at updating software even if the software has bugs (that may have been caused by external updates such as gpu driver update). If i put it on flatpak it's pretty much guaranteed to work for everybody regardless of the distro they use.

[@arimil.]

I do think the size argument is a bit redundant considering distrobox installs an entire other OS which is likely to be several times larger than whatever flatpak and all of it's dependencies were.

[@uuu12343]

Distrobox doesnt install another OS, it is a container like docker where it uses the host kernel as a baseline, and it pulls the package managers

[@RedBearAK]

Not true. Flatpak support runtimes can be quite large, although they are shared. Containers use a minimal framework to support the packages installed in the container, and multiple containers with the same base OS inside will share layers to reduce the amount of space needed. There is no simple answer to which will ultimately take more space.

[@arimil.]

@@uuu12343 Yes but it still installs another OS, you don't just use the Ubuntu image for free, you pull down an image that is an instance of that OS's configs, combine that with keeping all the relevant packages up to date in those containers you could easily end up vastly exceeding the flatpak size. Not only that but you'll end up pulling in similar dependencies via using another distros package manager.

[@arimil.]

@@RedBearAK Yeah I wasn't saying flatpak is better, my point was that it's more of a lateral change depending on how you use them.

[@b0t123]

And to be fair storage is getting bigger, i mean, do you remember the size of flop disks?

[@softwarelivre2389]

Flatpaks use runtimes in order to deduplicate dependencies and reduce file sizes. That's actually a feature. What you were suggesting at 2:50 looks more like what AppImages do stuff, which is not efficient.

[@angeldude101]

But it only works on the level of runtimes, right? So you'd still have duplication of individual binaries and libraries between runtimes, on top of having to install the entire runtime rather than just the parts the package links to.

[@softwarelivre2389]

@@angeldude101 If I remember correcly, runtimes also deduplicate files between themselves through some form of tagging, and runtimes themselves are based on the freedesktop runtime, which is the "base model" that contains essencial packages and dependencies, from which other runtimes link into.

[@hamobu]

Making computers run more efficiently can cost you way more in user and developer time. It's always better for a computer to do a lot more work to save the user a little bit of time.

[@softwarelivre2389]

@@hamobu is it the case here tho? I don't think it is. What makes flatpak harder to use is the sandbox and permission system (which is where most problems come from), not the deduplication part.

[@softwarelivre2389]

@@hamobu but actually I have to agree with you, I have some programs having a lot of trouble when more than a locale is installed at a time for some reason. It happens every couple of months.

[@Berecutecu]

Matt, in this one I disagree. Flatpak is a path to reduce package management in multiple applications managers. Distrobox is the opposite, it encourages the fight of multiple package managers. This is a time waste for distro managers, they could be improving features instead of packing apps and this is the whole point of the discussion here

[@TheLinuxCast]

You don't have to use more than one distrobox to get where you need to go. And until you've used distrobox and found something that it makes possible for you, it does seem useless. But I assure you it is not.

[@mckendrick7672]

@@TheLinuxCast But this still ignores the problem of packaging the same application multiple times. Sure, for you you only see a single package from within an Arch box, but the maintainers of other distributions are still managing duplicate packages which you can find in other distributions because "just use distrobox with x other distribution" is not a solution. Flatpaks put the power of distribution directly in the hands of the developer, rather than relying on third party packagers to screw up with the wrong dependency versions.

[@TheLinuxCast]

@@mckendrick7672 This is going to sound bad, and it is, but I'm not a developer. Sure, it's good that flatpak is easier for them, but it's not my job to care about that, to be honest. Maybe I should, but I don't really. Selfish man that I am

[@mckendrick7672]

@@TheLinuxCast The point that I'm making isn't that you should care about the developer, the point is that distrobox doesn't solve the problem of enormous time waste within the Linux ecosystem with every package being unnecessarily repackaged multiple times on multiple distributions, ultimately meaning less time can be allocated to improving Linux for everyone. Distrobox just moves the problem to "X package manager from Y distribution might be able to install Z program correctly, and X1 and X2 package managers also package it well, but X3 package manager sucks for this program" which is a complete mess.

[@Henry-sv3wv]

@@mckendrick7672 Everyone should just use pacman or apt. problem solved, only two packages for a bleeding edge and a stoneage edge. flatpak is just a trojan package manager that says: me am the new only true package manager and i bring my own linux distribution with me, i just call it runtimes.

[@survivor303]

Im old and i just use debs :) these new package formats give me so many questions :) apt is fine and i don't understand why people are against it or any other distro based managers.

[@rubisetcie]

I'm young and i just use debs too :)

[@survivor303]

@@rubisetcie 😂

[@jvkanufan8115]

Yep - Debian using debs. Good enough for me.

[@FengLengshun]

I don't like debs, I can't manage it declaratively. Flatpak at least I can stick in to declarative-flatpak HM module so Nix can manage it. In addition to knowing exactly what I have installed and how, they also work well in immutable systems and I can use a single repo to manage what's installed for all of my systems and users.

[@survivor303]

@@FengLengshun what? You can do this all with debs, you dont need to install them system wide, even it is default action of it, you can see what you are installed with dpkg, anything else, i dont know what you talking about :)

[@darkphotonstudio]

They work ok for me. If it makes it easier for devs to distribute their software, I don't see the problem.

[@danr8472]

This guy has no clue what he is talking He is a new linux user and talks out of his ass about containerised apps.

[@sixdroid]

and some programs are flatpak only like the good stuff program "bottles" and many more stuff

[@DashieTM]

100%, the very moment I am expected to first fix broken permissions for software before using it, it's no longer just containerization but just plain broken and needs to be fixed. A dynamic permission system is needed, what we have right now is frustrating at best.

[@TheEvilSkelly]

> dynamic system is needed That's called XDG Desktop Portals. The permission system was already addressed by it in most common cases, but we need every piece of software to use that standard.

[@DashieTM]

@@TheEvilSkelly Awesome to hear that it exists, I just checked your blog to see if it might be a missing feature on my end, sadly no, this (decoder example from the blog) is the first time any flatpak ever gave me a popup for any permission. Figuring from the lack of good results when searching about dynamic permissions, many probably just don't know about it?

[@TheEvilSkelly]

​@@DashieTMYeah, that's what I believe. There are so many misconceptions about Flatpak that it's not even funny anymore. I've written several articles about Flatpak on my blog that go over the misinformation/misconceptions, especially the responses. Sadly, I don't want to go over them on KZbin, because my comments almost always get deleted/hidden for whatever reason. I suggest you to read my articles, because I do believe that they do a decent job explaining almost everything.

[@TheEvilSkelly]

​​@@NixperienceI posted another comment before. If you don't see it on your end, then it was deleted by KZbin, which I have no control over it.

[@mckendrick7672]

You aren't really expected to fix broken permissions - you should report it to the package maintainer if the permissions are broken for reasons that aren't specific to your own system's setup. That said, there is a dynamic permissions system in XDG portals as mentioned, but it needs programs to be written to take advantage of it. These things just take a little time to cook.

[@themisterchristie]

My preference is for Flatpaks as, normally they are more up to date than my distro's repos. My problem with flatpaks is actually a few things. 1. To launch from the command line is difficult, requiring you to remember a criptic command. 2. Using add-ons that usually go in the apps folder in .config, it's not clear where to put them. An example, the NDI Stream plug in for OBS, I couldn't figure out how to use it in the Flatpak version of OBS. 3. Trying to find the user configuration files, those normally in .config, is so difficult and it drives me nuts.

[@talkysassis]

If the app doesn't have a navigation for plugins like blender, then it's a bug or missing feature.

[@galvanizeddreamer2051]

While likely a pain to do it manually for every single program, you can set up aliases in ~/.bashrc to run it from the terminal as you would any other package. Need to do further research regarding config file locations. At the end of the day, it will always be at the end of a file path, no different than even windows. Now where that file path is, that is another question.

[@galvanizeddreamer2051]

I just did it, and it is a pain, but if you know programming you could likely do an automated version. You are already likely aware of how to do this, but incase anyone else cares: Run the Flatpak list command into a text file (flatpak list > something.txt) Copy that list into .bashrc, and trim out any you don't want, such as dependencies or codecs. Also trim off the version number and anything in the line after that. I would also suggest changing the names to something you can type out, such as all lowercase. GIMP also has it's full name in this list (GNU Image Manipulation Program or something), so keep an eye out for that kind of thing for other programs as well. What you have now is a column on the left of the English names of these programs, and the right column is the flatpak IDs. After that, go through and make every line into this format approximately (I don't think use can use spaces in the alias name, but I have not checked): alias programname='flatpak run flatpak(DOT)id(DOT)longform' (those are single quotes btw, and the DOTs are because otherwise YT is going to think this is a link and delete my comment as spam.) So for the Falkon browser you would have this: alias falkon='flatpak run org(DOT)kde(DOT)falkon' After that, save and restart your terminal. You should then be able to run the programs by the alias you gave them in the .bashrc file.

[@kuhluhOG]

about the config being hidden: if the app didn't implement this correctly (for whatever reason) or doesn't actually want you to mess with these files (for whatever reason), if they aren't in their usual place, they can be found under ~/.var/app//

[@themisterchristie]

@@kuhluhOG good to know, but like I said, it's not clear. And that is apps that, if you install from the distro's repository the same app uses the usual .config location.

[@awa0927]

My lovely opinion on Snaps, Flatpaks, and appimages: Appimages are nice but don’t always preform well. On top of that finding appimages can be a pain and they aren’t always available. Flatpaks use a hell of a lot of disk space especially when updating them. Though Flatpaks are always available and don’t preform with any lag. Snaps open slow and are kinda annoying to use.

[@Wkaelx]

Bro, we have hundreds gigs of storage, a few megas or gigas wont kill you, fr.

[@awa0927]

@@Wkaelx Last time I ran a 'flatpak update' on my Debian system it took up 60GB of my 512GB SSD NOT just "a few megas".

[@jackelofnar]

You really should talk to the creators of bottles as flatpak is the only distribution method they want to support

[@TheLinuxCast]

Yeah, I know. It's why I won't be using bottles.

[@lovebaranus9800]

Interesting that you mentioned bottles, Brodie *JUST* released a video where he highlights the packaging conflict going on between bottles and fedora maintainers, and the bottles devs give actually really strong and valid reasons to use flatpak, you should watch it.

[@lovebaranus9800]

@@TheLinuxCast I know you're using tumbleweed, but you should at least try bottles trough the AUR package. It's not official, but it's the most up-to-date unofficial package, and therefore the least problematic out of all of them. It's distrobox levels of quality (arguably higher quality, since distrobox is ultimately just a bunch of scripts for docker/podman) but for windows instead of distros. In my experience i was able to go from nothing to running ULTRAKILL (stupid fast shooter) with no lag or framedrops following the arch wiki guide!

[@softwarelivre2389]

​@@lovebaranus9800and actually the Bottles devs used a TheLinuxCast video to justify not wanting any packaging that is not flatpak

[@83RhalataShera]

Lutris is better at what Bottles does anyway.

[@Visentinel]

Honestly I haven't noticed any performance issues with flatpaks...

[@donpeer4477]

As I understand these self-contained packages: AppImages exist just in its own folder. Delete folder to remove. Flatpaks put data outside its folder; this requires you to use --delete-data to cleanly remove. Snaps spread themselves throughout the OS ala M$ Windoze. I doubt if they're ever really gone...

[@mckendrick7672]

AppImages are not sandboxed, they will store data and configs on the system the exact same way the program would if it were natively installed (somewhere in your Home directory). The difference with AppImages as compared to native is it bundles dependencies which the system may not have the correct version of into a single compressed archive. Flatpaks are sandboxed so they generally store data and configs inside their own directory within ~/.var/app unless explicitly allowed to store data elsewhere, so you can easily remove leftover flatpak data after removing the flatpak itself without using the flag. Snaps... I have no clue, I refuse to touch them.

[@tambuchalinux]

Great points in this video. Although I actually don't use very many flatpaks, the REALLY slow flatpak updates are true for me. This video has convinced me to look to distrobox. But I think most users, especially newer users will use flatpaks because they are integrated into the more user friendly software stores.

[@leevi6026]

It seems all those OBS Studio issues are related to using window manager, because under KDE wayland session everything works out of the box. I just tried it because I happen to have pretty fresh openSUSE installation, so I'm sure there is nothing special already done. Screen and window capturing works without any permission or other configurations at all (via pipewire). And one thing what is better in flatpak version of OBS Studio is that it has browser source already installed, which has not been the case at least in the past with versions from repositories.

[@phonemophoneko]

This is true. DE is supported.

[@that_leaflet]

Not even just a WM thing. I installed Sway on my Fedora Silverblue system and the OBS just works. I actually edited the permissions to be more strict since OBS doesn't need network, X11, Inter-process communications, all devices, and host filesystem access. At least for my needs. All device access may be needed for mic and webcam if OBS doesn't use the right portals.

[@talkysassis]

@@that_leafletOBS do need network if you stream with rtmp

[@Skelterbane69]

I primarily use flatpaks. Very few packages are installed through pacman,making my arch install very stable, I feel

[@ppaliwal89]

What is the actual work that you do apart from producing videos? coz majority of your videos are I switched from X to Y and two weeks or maybe a month later I switched from Y to Z. Every video has a different rice (I hope that's what the customisations are called) so it kinda feels like that's what your main thing is. As a consumer of your content, I would love to get a clarity if this is going to be the content theme for this channel?

[@lennylizowzskiy]

> What is the actual work that you do apart from producing videos? As far as I remember he is writer or editor of some historical journal. Also, afair he is using vim as text editor for that work

[@lowzyyy]

To me it seems that he is professional distro hopper. Never satisfied and always angry

[@JodyBruchon]

I won't use any of these new stupid formats.

[@Kneedragon1962]

Interesting to hear somebody else share roughly my own concerns. I recently upgraded to Mint 21.2. Obviously, from 21.1 ... So, toward the end of the 21.1 cycle, I got fed up with flatpack and removed it. Since installing point two, I have not added a single flatpack and nor has Mint. Far as I can see, there are no flatpacks installed. That's fine by me. Mint resisted Canonical's push to snaps, and made a point of disabling them. They included flatpacks. Ok, I can see the problem. So I tried a few pax and discovered several of the issues you mention, plus one other. You have an ap, quite a small ap, based on or following on from something that's been around for 10 years, (let's say an old text editor you like) and to download and install that ap, took about 20 ~ 30 MB. But to download the flatpac, took 600MB. ~ But wait ~ that's not all, so that great plug of dependency, that should include everything ~ right? Well no, once you have and run 3 or 4 flatpacs, you start getting updates to the underlying system, which run into hundreds of MB. Ok, I will sigh and roll my eyes and shut up, but then the next day, you get a newer version again. And 3 days later, it comes down again. And a few days later ... So you put a question out to the nice people at Mint, and they say something along the lines of ~ "No, you're a silly old fart jumping to conclusions. That's not how it works. You are misreading or misunderstanding the introduction." Excuse me, but you didn't read my email. I didn't say to you that I have some fantasy concern about a bad thing that _might_ happen, I'm telling you what I have _witnessed_ on my own machine, at least 6 ~ 8 times! Don't tell me that's not how it works, because brother, I can tell you ~ it _is!_ Since going to 21.2, I haven't seen that happen at all, but I have also been very careful not to install any snaps or any flatpax or any other fancy new-age 'container' things. I do understand the concept, but I think apt and conventional installs are way better. "But that makes things hard for the developers." Ok, fair call, but should developers hand off their maintenance problems to users? I realise it would be a nightmare to maintain something (let's spot vlc as an example) that has to work on Mate, and KDE, on gnome3~50+ (and all the old gnomes) and bloody Window$, and nifty-Russian-desktop and nifty Chinese desktop (do know what Budgie-smugglers are in Australia?) and ... let's not forget the fetish of the last year or two, Wayland ~ I can see how that becomes completely unworkable. But then you hand off a Linux version of DLL-Hell to the end user? That's not the way it should work either. "But I use Arch, actually." Ok, that's fair. You're smarter than I am. And I just stopped using your software. So who's right and who's a fool?

[@markjones2349]

Matt your channel and content are helping so many of us keep up to date with all the newest cool things and I just wanted to say thank you. You're really relatable and seem like a great guy. Just wanted to show some appreciation for what you do man. Thanks for what you do!

[@iitzrohan]

L Take. So you prefer having all the bloat installed as system packages instead of having it installed as seperate runtimes. FYI the so called bloat packages only gets installed the first time you install a package. Then other applications then share the runtimes as long as they are compatible.What do you do when some package installed in system refuses to work because of newer dependencies?? Just wait and hope the package gets updated?

[@OneQuarterLife]

Distrobox

[@iitzrohan]

@@OneQuarterLifeDistrobox is great. But the average users will be scratching their head to install a distro inside it then install the package and then export it so that they can launch it directly via their app-launcher.

[@Absolute_Zero7]

> FYI the so called bloat packages packages only gets installed the first time you install a package. So, the same as native package managers? What's the point of having containerized packages then?

[@iitzrohan]

@@Absolute_Zero7 That you get compatible dependencies automatically installed with the packages. You dont have to tweak any settings to make the package work. Also, you can't see what permissions your system packages have easily, but in case of flatpaks you can easily see and restrict them.

[@TheLinuxCast]

If I have 40 Flatpaks, 1 Distrobox image is going to be less bloat.

[@markjones2349]

I just recently learned how to setup apt pinning on Debian so I could install newer packages from testing and unstable. But just learned how to use distrobox from you and some other youtubers and it's freaking cool. I bought my first home server last year and fell in love with docker on it for all of my services. But when I learned yesterday that distrobox can use docker images for downloading packages from any other distro I was amazed at how flipping cool it is and how easy too. So now I probably will do a fresh install and just use distrobox for everything. I love native linux packages more than flatpaks by far for the same reasons you stated. This is like the coolest technology for linux I love it so much. I'm hoping that someone takes this concept to the next level and lets you run isolated desktop environments without each one cluttering up the app menus of all of the other DEs that you have installed. That would be a dream.

[@tomas-wi8dy]

Thank you. It is one useful video. But my fav is appimages, I really hope that format will be more maintained.

[@CandyCaneChris]

As someone else said I feel like this is more of a lateral move. You are shifting the responsibility for maintaining the package from the flatpak maintainer to the docker/podman maintainer. Building a flatpak isn't hard, but doing it in the best way is hard to nail down. The same way building a docker image is. Distrobox just pulls docker images to my knowledge, so if that maintainer stops earning a living outside of the project, it may fall behind just the same. (Granted most of it is automated for base images like Arch, Debian, etc.)

[@denizkendirci]

instead of using distrobox, just use whatever distro you want with nix package manager on top. it's still a hustle to do certain things with distrobox, for example installing and running a window manager with distrobox needs some tweaking etc. so i am not in favor of using containers to install software to use on host. personally i didn't tried that myself though, because the distro i like to use (which is arch) doesn't have that problem, so i didn't need to. but if i was gonna do it, i'd do it with nix package manager instead of distrobox.

[@MarkusHobelsberger]

I agree with the first point. I use only Skype and Discord as flatpaks and including Flatseal I have 11 flatpak packages on my system that take up several gigabytes... and for every other update it has to update about 1 gigabyte of these dependencies. The programs work well, but things are getting kinda messy.

[@that_leaflet]

I have 86 flatpaks installed, whether it be apps or runtimes. After de-duplication, I have 3.9GB of runtimes and 4.1GB of apps.

[@MarkusHobelsberger]

@@that_leaflet So I guess it scales kinda ok... how much would it be without deduplication? I'd assume most users don't use that feature.

[@that_leaflet]

@@MarkusHobelsberger Flatpak automatically deduplicates. Are you thinking of BTRFS compression? I'm not sure how much extra space is saved when used in tandem.

[@CyberSan7054]

Hey. Could you please take is through a tour of your desktop environment and maybe a tutorial on how you got this? Thank you!

[@damianateiro]

I use what I like or what suits me, it doesn't matter what it is, but I always prefer the native format

[@hecate6834]

I don't want to go back to distro maintained apps, Flatpaks are convenient and generally just work. Distrobox is not a solution for most people (I do use it too for lots of things) although I could see someone turning Distrobox in a sort application runtime haha. - A Silverblue user

[@rhiethreal]

I personally love flatpaks, and I think the support libraries being separate is a good thing. It means they can share, which saves you space overall. Instead of every pak needing to download the same library every time, if they share a library dependency, then they can just share the same install. Like say some hypothetical library was 10 GB in size, just as an absurd example, and I had two flatpaks that needed to use it. I would rather it be separate and have one 10 GB install that they both shared, RATHER THAN then both being completely self contained and needing to waste 20 GBs of space rather than just 10 GB.

[@Wkaelx]

Even if 10GB wasnt a extreme example, nowadays we have hundreds of gigas of storage for cheap, if you dont use a 20 year old pc, that wont run up to date systems that well to start with, it IS NOT A PROBLEM.

[@auntiecarol]

Matt: what are your thoughts about Nix (the package manager) not the OS?

[@nado911]

Thanks for insight on distrobox, im curious about it. However, if youre dependent on distrobox arent you cancelling out why you choose your distro? (to an extent)

[@Flackon]

well, if you don't choose Arch of NixOS, it's always good to have the option to access packages only available for other distros. Even the previously mentioned distros don't have every package available

[@nado911]

Completely agree, you always need alternative means no matter what you distro you use. All i'm saying is if the distro you choose isn't giving you a valid first stab at what you need in a system, why run it? Sure, you can split hairs on features all day, but to me it starts with software availability, if you don't have the tools I need natively (or close to it) more often times than not, its a pass.

[@alexstone691]

2:40 if you shove everything then you need to update whole app to update a possibly exploitable bug in an app that has been abandoned

[@LubosMudrak]

and then a minor library update breaks the app completely 🙂

[@alexstone691]

@@LubosMudrak Possibly, but thats the trade-off

[@SMCwasTaken]

Bros a Discord Mod (IM JOKING)

[@TheLinuxCast]

Bro thinks he's being subtle with his fat joke.

[@nathanael.higgerson]

no, just a linux user

[@moetocafe]

Just wanted to say, the LED Linux Cast mascot in the background looks really nice

[@jo-vrn]

I have always preferred Appimage over all the others. Now I'm trying to configure firejail well.

[@codychan4992]

Since you didn't include a website image in your video or link in the description, is the distrobox you mentioned in your video the same thing as the distrobox I know, which is "Use any linux distribution inside your terminal."? In my opinion, snap/flatpak and distrobox are not the same things. Anyway, looking forward to more content about the distrobox you are talking about.

[@GenoppteFliese]

Remember the static binaries vs shared libraries discussion your un*x granddad had? Now with bigger hard disks we have the same discussion, only on a bigger scale. We are not solving technical problems, but problems related to human nature like "not invented here" and "reinvent the wheel". If a security issue is detected in a library like openssl or log4j I want to install one small Distro package during a small maintenance window on a sunday afternoon. I do not want to ruin my weekends for months by collecting and installing 100 containers delivered over 3 months, all bringing the same bugfix and hunt down 20 abandoned containers where the maintainer lost interest or is busy fighting off invading russians.

[@damianateiro]

I don't like distrobox very much because why do I want to literally install one distro inside another? and even more so if it is one with many packages and relatively updated, I prefer to have one or 2 snaps or appimages flatpaks. I only see real use in distros like void, Slackware or Alpine, and until then I'm considering using distrobox

[@fabiofurtado1058]

The notion of one distro inside of another is a bit uninformed. Distrobox is just abstracting podman or docker to create a very convenient OCI container for you to play with and at the end of the day a container is just another process in your host that your kernel is lying to (just like snaps and flatpaks), not "literally another distro".

[@LinusBerglund]

I am convinced that immutable OSes are the future. I am a recent convert to opensuse microos, and flatpaks are really not bad. The sandboxing also feels good to use,and to be honest I dont use more than 5 apps anyway. Distrobox handles all my CLI needs, but in general I am very happy to just have one stripped down system to care about.

[@sergioc.3194]

For me, the issue of permissions is the least overwhelming, in fact configuring the package according to my needs is something that I have always wanted, especially with regard to network use. The configuration is not very difficult either. The big problem is the dispersion of runtimes, it is always better to install software that uses the same version of the runtime or rely on it to do the update.

[@iibrahimov]

Hi Does SNAPs has runtimes like flatpak?

[@BendyLemmy]

Weird - how would you install Plex-HTPC?

[@shabang71]

I have installed quite a few flatpaks on my Fedora 38 and i have to say that they are not as good as expected in some cases. For example the Zoom client worked fine in Manjaro from the AUR. The flatpak version is a real mess. May be a bad integration with wayland? I don't know. I even struggle to close it in a normal way. I close it with the task manager. And at the end they're very slow to open on lowhand machines.

[@MyReviews_karkan]

I tried using flatpaks, couldn't use them for long. They eat storage like wildfire. They are very hard/tedious to theme with the system theme. They're all around just a mess. I don't know where their configs are, I don't know how to launch them from terminal, they take forever to update... Etc. Thanks to the AUR, I don't use them at all.

[@LubosMudrak]

That is a price for portability across many Linux based operating systems. Unless you are developing for one specific operating system, you don't have any guarantees on the libraries compatibility with your app and no guarantee that some incompetent parody of an operating system maintainer breaks your app.

[@samjohnson5044]

THANK YOU. I was thinking I'm the only geek unhappy with flatpak. I was generally happy with the Ubuntu packages, even though it has its problems. Flatpack seems like we're making a lot of effort to get even farther away from the CPU. I'll give distrobox a try. Nevertheless, is compile from source a good option? I have enough problems compiling my own projects, is it worse compiling someone else's?

[@JamieKitchens6]

Is there a way for the maintainers to weed out and eliminate orphan files, etc.?

[@andre-le-bone-aparte]

Just found your channel. Excellent Content. Another sub for you sir!

[@TheLinuxCast]

Welcome aboard!

[@bluesangel75]

I faced the same issues. Comparing VSCodium to VSCode flatpak size showed the dependencies issue you highlight - I reported a bug as VsCodium size is so big! I'm not happy with Flatpak evolution (bigger, slower to start). I'm also using distrobox & NixOS packages . Both have pros & cons.

[@dansanger5340]

Good information, but I'll definitely continue using Flatpak and trust that the issues will slowly get resolved. Flatpaks seem like the way forward for solving a myriad of problems with app distribution in the broader Linux ecosystem.

[@middle_pickup]

As a new Linux user I have to ask, will we ever get to a point when the majority of distros use a common package manager? What's the point of having all the different ones if you're just going to containerize them?

[@mskiptr]

Dependency bundling and "being a mess" (not following conventions) are my two main issues with Flatpak. (Yes, I know it does support _shared_ layers. But in practice, that's not how people build their Flatpaks.) However, Distrobox also suffers from these (to a smaller extent). Finally Nix solves the first problem and Guix (using similar approach) also avoids being such a mess.

[@TheEvilSkelly]

> (Yes, I know it does support shared layers. But in practice, that's not how people build their Flatpaks.) Nope, the shared layers (runtimes) are literally designed to be built on top of. The base runtime is org.freedesktop.Platform. org.gnome.Platform is based on org.freedesktop.Platform, and most GTK apps are built on org.gnome.Platform. Likewise, most Qt apps are built on top of org.kde.Platform, which is built on top of org.freedesktop.Platform

[@bigpod]

nix brings its own set of problems that are much worse then dependency bundling(which actually isnt a problem its a proper thing to do) or not following conventions

[@mskiptr]

@@TheEvilSkelly Sorry for not noticing your reply earlier, but YT has hidden you comment for some reason. (And I'm also extra late because of some other comment weirdness.) Yeah, I know these layered runtimes are supposed to solve dependency duplication and I was positively surprised this is quite nicely designed. It is even shared for the whole system (lives in /var)! But, in practice a lot of dependencies are still being included at the top level instead of living somewhere lower and being shared between all apps that need it. Unfortunately, most containerization technologies are not very fine-grained in practice and thus quite inefficient. It's not a fault of containerization per se, but since that's the easiest path, it tends to end up that way.

[@TheEvilSkelly]

@@mskiptr sure, but we've put a lot of effort to improve it, through e.g. base apps and shared modules. It's a minor flaw for the amount of effort that was put. Also, how did you find out about my message if it was hidden?

[@mskiptr]

@@TheEvilSkelly Ah, I'm so sorry to leave you hanging for a month. That's fully on me this time. Frankly, all currently available ways of packaging are pretty horrible in their own right. (Like most software out there sadly.) Well, horrible might be a bit too strong of a word. They all have their flaws and fixing it properly would require breaking up with how executables, system state and even file system layout are organized in some fundamental ways. (Yes, I can see that that's kinda what Flatpak is trying to do.) The reason my hope lies with the Nix | Guix model is because it captures the most metadata about the packaged software. Hopefully, it will one day be structured and expressive enough to be used for automatic generation of packages _idiomatic_ to other software distributions. Its other advantage imo is that all the inefficiencies I see happening in other package managers are either non-present, or could in principle be solved rather straightforwardly. This suggests to me that this model is indeed correct and will be sufficient. I guess what I meant in my original comment is that container-based solutions tend to be 'opaque', while it's the opposite approach - well-structured and semantically rich - that is the easiest to work with and maintain. As for how I was able to read a hidden comment: I don't think I got a notification, but using that (or a direct link) would let me see your reply. Besides that YT shows the number of replies and sometimes it doesn't match the actual number of comments you see. Then sorting all the comments 'by newest' typically does the trick. It's all in flux unfortunately and at times these 'YT rules' seem to not be that reliable though.

[@DrWrapperband]

We need an open source LLM agents to manage legacy packages. You should start a foundation, I'm too old now.

[@John223]

Appimages were the real hero all along. The only self-contained packages

[@sixdroid]

your opinion.i prefer flatpaks.

[@The_Lawnmower_Man]

Question: does AppImage have an *unambiguous* definition of which 3rd-party libraries (i.e. shared-objects), data files, etc. from the "host" filesystem an AppImage-packaged application can use, versus which ones need to be bundled into the AppImage in order for the application to use them? (The reason I'm asking this is because Flatpak's concept of runtimes does provide an unambiguous definition of that, and so does Nix's dependencies system.) Maybe (just guessing here, I haven't yet tried this myself) an AppImage package-developer could just decide which ones of an application's dependencies should be bundled into the AppImage by following this rule: if any given file on which this application depends is one that a Flatpak package for this same application would get from one of Flatpak's runtimes, then it should be bundled into this application's AppImage?

[@thingsiplay]

Question: Do I have to update and manage each container and package manager on it's own? And what if I install a KDE application on one container and another one on other container? Won't be the dependencies of KDE Plasma installed and managed twice?

[@TheLinuxCast]

You can have as many distroboxes as you want, no Matter the image and distrobox-upgrade --all will upgrade everything.

[@Waldganger64]

Doesn't kdenlive use QT instead of GTK ?

[@ContraVsGigi]

Actually Snap apps have become way faster in the last year(s). I mean the one that were updated, like Firefox. It starts very, very fast now and everything just works. The main reason for these containers imho is actually not necessary the added security, but helping the software developers. You just make a snap and send it with everything there. No more maintaining for 28 versions of Ubuntu, 17 versions of Fedora etc. No more dependency hell, no more library conflicts and even bricking the system. I saw all of these on my laptops and if the later versions work fine, I don't care about the extra space, but for sure I don't want my "openshot" (randomly selected) to uninstall my other viseo editors because they need a specific library version. And to go back to the developers: we need a more or less universal, simple dostribution system; why on Earth would a Windows developer make a Linux version for a much smaller userbase, but also with a lot of headache coming from all the versions, releases, sibreleases, flavors in the Linux World? We need something more or less unified and probably containerized, as it is the only thing we have for now.

[@warthunder1969]

I've noticed Flatpaks are getting slower and slower to update but I still like them better than snaps / appimages (having to use one full time for our church). I would still choose native > non-native formats for packages.

[@hopelessdecoy]

App Images are literally only meant to be one file that you download, you know where it is and anyone can use and share them. It has always remained my favorite format. Distrobox has the issue of everyone still has to make system specific packages and everyone wants to be the first party packager, not the distrobox adapter.

[@Flackon]

AppImages aren't managed through a central registry though, so they have all the disadvantages of manually hunting and downloading binaries

[@telliott]

The only flatpack I always get over the distro version is Discord because it seems to update instead of giving me the infuriating "This must be your lucky day" dialog, which prevents Discord from running.

[@torsten.breswald]

me on my stable rolling release distro in no need of containerized software whatsoever: oo - - oo

[@bellissimo4520]

Yeah, I also noticed that flatpaks sometimes are insanely big. You download something as debian package - size 80 mb. Then you download the same as flatpak - half a gigabyte. WTF? Seems like many people are probably also no putting effort into trimming down the container.

[@Jeff_Seely]

Thanks Matt! I have always been trepidatious about these container programs. If I have update issues with programs that I've installed using pacman, then I might try reinstalling it as a flatpak. But distrobox is a really slick alternative for sure. I've also had some nice luck with appimages. Thanks for the great video!

[@RawLu.]

*you stop using them because everyone else on here says you should use them! LOL! Your a Rebel! 😎

[@christiansmith2658]

Can't wait for flatpak to package the kernel and then we can all run FlatpakOS lmao

[@schemage2210]

What your actually saying is your not happy with how flatpaks are being packaged! Not with flatpaks themselves. And while this is fair, if the point is to create a single standardised format that companies can latch onto (such as with Discord or Firefox or steam), saying choose whatever native distro format you please "because I have distrobox" is a step backwards. It confuses the point, and while distrobox is great, many don't use it? Honestly, I am ok with a little extra bloat on the flatpaks then having to run everything through distrobox. Distrobox is still an added layer of virtualisation that needs to be set up and also maintained for little gain.

[@gimcrack555]

Since snap, flatpak and appimage appeared. I never went to them. Main reason slow and big in size. I just shrug my shoulders. And I just kept using my normal maintain repositories by the developer and just use the normal package manager. Like I been doing since day one. Never had a problem doing so, so I ran with it and it just works. Anything outside my repositories. I just build from source. That's my second go to. If not in my repositories I build it from source. Its a great skill to have and to understand your package through and through. It's had to teach a old dog new tricks.

[@agenerichuman]

I get your frustration. But for me, the format I use depends entirely what I intend to use it for. I don't use one single solution across the board. Sometimes I want things to be contained and sometimes I don't. Plus some apps just work better on certain formats. Though with my Steam Deck, I stick mostly to flatpaks.

[@slawtul]

You are right about flatpaks. There are extremely big. Now I use flatpaks as a last resort.

[@nado911]

If a distro was a cable subscription, I would hope that it would have most (if not, all) the channels I care for. Or I could roll in a new tv for each channel that I want to watch. 😛

[@raughboy188]

have you ever heard of xwayland? Obs would wok wiithout fuss with wayland if you use xwayland.

[@motoryzen]

When I cannot get the job properly. Done with a deb package or up image comma that's where flatpaks...ALWAYS save my bacon..

[@Nick_Lavigne]

3rd? Is appimage in 4th for you?

[@thoaihoquang1578]

I see your points, but right now flatpak very solid for me

[@anon_y_mousse]

The way I look at it, we need an alternative to distro packages that is platform agnostic but still capable of resolving package dependencies without stuffing what you need into every single package. I figure a package system that starts with LFS as its base might actually work in that regard, but also to never resolve dependencies generically, as in never using libfoo and instead favoring libfoo-1.2.3 always. That might make things annoying if things aren't updated at the same time, and it might lead to more wasted space when a dependency is compatible between multiple versions, but it would also prevent version mismatch breakages.

[@mgord9518]

Like Nix?

[@anon_y_mousse]

@@mgord9518 I'd have to look into what Nix does to know for sure. If it can work on any distro then there's a chance.

[@lennylizowzskiy]

@@mgord9518 Nix suffers from version mismatch breakages

[@rjawiygvozd]

I've also recently had to move my steam/lutris/heroic from flatpak to distrobox because xdg-document-portal has a memory leak that made my system go OOM after playing Baldur's Gate 3 for a while and I assume it actually applies to literally every flatpak that has to open files and load a lot of data

[@obsoletepowercorrupts]

I'd cut flatpaks a wee bit of slack here because there is bound to be something of a bleeding-edge version versus an LTS, so the dependency erosion is inevitable in these formative stages which after all are an exciting time to be in on this. As a segue, it is worth adding you have a drama-thumbnail worthy of attention grabbing _(which worked because, well, we're here)._ Not to digress, it's a reasonable forecast to forsee a time when some such container softwares end up with a "most-popular" retrospective charts-hits for software gets released as say an annual or 5year-plan release boiling down all dependencies to a tree in the fashion of the old days _(which btw lends credence to telemetry and popularity-contest options in distros)._ So in other words there would be a "kinda NixOS" _(which I trust we are all pronouncing "OSS" not "O.S." by now),_ legacy dependency-tree style version except retrospective release such that future flatpaks are better optimised over time, especially if the retroactive distro is torrentable. It'd be dead like dead-language-latin but a dependency heaven, notwithstanding _(but its known-quantity nature thereby means hashes are usable and handy)._ That'd be where the streets of utopia are paved with install script gravestones of yore. That'd help advise for rollback and ENV metadata in VM. Hashes for decisions would help. Well anyway, congratulations on bringing by piss to a boil with your thumbnail evoking me to comment. It's the basement IT culture's equivalent of _"Why I deservedly dumped the beatch to the streets"._ Good video. Thumbs-up. My comment has no hate in it and I do no harm. I am not appalled or afraid, boasting or envying or complaining... Just saying. Psalms23: Giving thanks and praise to the Lord and peace and love. Also, I'd say Matthew6.

[@phonewithoutquestion80]

From what I've read, the BSDs of the world had already got around the issue of dependencies effects on userland, if not less convolution than we have with current package managers. That being said, flatpaks really are a "justworx" method that tends to overhype itself. I say this as I currently use flatpaks on Debian...

[@AlanTwoRings]

How did the BSDs approach the problem?

[@phonewithoutquestion80]

In short, the user-facing software and system configurations are separated into their own directories, while the kernel-facing stuff and other critical states are in their own individual paths. Linux tends to intermingle lower level and top level configurations. BSDs methods are not impervious to fault, but generally speaking the filesystem hierarchy is much sturdier, eliminating the need to rethink package management.

[@AlanTwoRings]

@@phonewithoutquestion80 Thanks. Do they address the issue of two user-space applications needing two different versions of the same user-space dependency? I think this is the main problem that containerized packaging is supposed to address.

[@phonewithoutquestion80]

@@AlanTwoRings I need to read more into that but I *highly* implore you to read up on BSD Jails (read: containers), since those can be useful for running specific versions of applications in an isolated and tightly focused environment.

[@catchnkill]

@@phonewithoutquestion80 Flatpaks are itself containers. Thus BSD Jails and Flatpaks are doing the same thing!

[@MrCradleman]

Arch Linux and AUR is the best choice, because AUR package format is very easy to make yourself and support orphan packages if you need it. It basically always repeat official build guide and produce native package. I have my own collection and I package my pet projects too. No other packaging system let you create your custom packages

[@jamesyoung151]

Portage (Gentoo) does allow you to create your own repository and you can create custom ebuilds for packages you use that's not in the official distro.

[@bjbboy71697]

As a Gentoo user I am also in love with the idea of a package simply being effectively a script to download, compile, and install the software rather than being a bundle of software itself. It's sort of meta in a way in that it's not THE software but rather a pointer TO the software with some instructions on what to do with it. Makes it very transparent, debuggable, configurable. Updating a package is often as simple as renaming the build script (since the script can reference the file name to extract the package version and use that to build the URI of the sources that it downloads. If that's not enough you usually just need to bump the versions of some dependencies or add a use flag or something like that. And you can even drop a patch file in a specific directory and the package manager will see it and automatically apply it in the src setup phase. So any distro specific modifications to the source are separate from the original source and can be easily reviewed. And if you as a user still aren't happy with the package as provided, you can drop your own user patches in a specific directory and it will be picked up by the package manager without having to edit a single config file or script or anything. How cool is that?

[@jamesyoung151]

@@bjbboy71697Dating myself here. This is why Gentoo was my choice after RedHat. I started with Slackware 30 years ago. One unwritten benefit of Gentoo is that you'll find out whether or not the ram installed is bad. I had built a new AM4 system and installed TeamGroup memory. I was installing Gentoo and it kept crashing, I ran a memtest after 3 crashes. Turned out the memory is bad. I RMA'd the memory, I got new memory. It too was bad. I switched to G.Skill, no problems at all.

[@mckendrick7672]

You're completely wrong. You can create custom packages in any packaging system, it's just it tends to be a steeper learning curve, and distributing your custom package may be more difficult. The best example of another distribution which does custom packages is OpenSUSE with their Open Build Service - it not only allows you to distribute your custom build scripts (.spec files used to build RPM packages), but it'll build them for you. If you could not create custom packages, how would those distributions have ever packaged themselves in the first place? Flatpak itself allows custom packaging - and rather it encourages it by design. Also, the AUR, and Arch, cannot solve the issue of two programs demanding two different versions of the same dependency. For programs which are kept up to date this is generally fine because it's unlikely compatibility would break that quickly, but many older programs would become impossible to run. Not to mention, said older programs demanding older dependencies can become security risks, and native packaging provides no sandboxing to help with this.

[@MrCradleman]

@@mckendrick7672 Aur allows you to create packages with different versions. Also I know about possibility to create custom rpm/apk packages, but it's not easy at all. Pacman format is only one declarative file PKGBUILD and makepkg command will build package for you.

[@LedoCool1]

Aren't snaps growing in size too?

[@RealMazharHussain]

It seems like you haven't been introduced to the nix package manager yet. It is an alternative to Flatpak, Snap, AppImage, distrobox, etc. and doesn't do containerization the way Flatpak, Snap and distrobox do.

[@TheLinuxCast]

I've used it, I don't care for the way it messes with the PATH of apps it installs

[@setoman1]

BUT! Can you install distrobox inside of distrobox? 🤓

[@TheLinuxCast]

Probably. Distrobox is just a front end toolset for docker or podman, and you can for sure run dockers inside of other dockers.

[@sourcerer_]

On virtual machine, i installed package via flatpak (First time ever in my life) once. I've got an impression that my gentoo updates are faster.

[@Kelticfury]

Is it because the same software, steam for instance, flatpak is multiple gigs larger than the regular steam install? Edit: Thanks for actually describing your reasoning. It is nice to find someone talking about linux that isn't just reading release notes.

[@GarrettValdivia]

I may just be too stupid to use Distrobox properly, but I've noticed that the apps I export don't integrate into my DE properly (I use Gnome). So, for instance, my dock's launch icon and the running app icon are always separate, my exported browsers can't connect to other apps on my system for launching links (it also doesn't open hyperlinks from external programs), and sometimes my cursor theme is inexplicably not honored (Vivaldi was a notable instance of this, but it wasn't the only one). I love the idea of Distrobox more than Flathub, but so far, I've had more trouble with my distrobox packages than my flatpaks.

[@TheLinuxCast]

Yeah, that's a bug in distrobox and the way DEs pin things to panels. Happens in KDE too. So it's not just you

[@talkysassis]

The problem with flatpak is not about the space (this is the cost to no break programs every year) The problem with flatpak is that it tries to trick the program to think it is running native (this makes development a lot harder). A flatpak program should be a flatpak program, using flatpak libs, like a flatpak-libc, a flatpak-vulkan, a flatpak-tensorflow. Other problem is publishing. Unlike ALL app stores, you can't upload a pre compiled bundle. This is a lot harder for complex packages, and no IDE except Gnome Builder will take care of that for you.

[@walter_lesaulnier]

So far, the Flatpacks in my Fedora install have been fine, but I don't have many extra ones installed. I have CachyOS arch based distro on another computer that I loaded up with extra software and when there's an issue, it is usually the fault of a Flatpack.

[@zacharyhinkle6849]

All the packages I use are already in my distro's repos. Some applications only officially support the flatpak version, and I use flatpak when that is the case. Distrobox is cool, but it provides me nothing.

[@PestisNonSapien_GMO_exHuman]

I don't use distro box. Instead i run kasm on my server and connect to it on my long battery life underpowered Chromebook. You can open single apps in your web browser or entire window managers.

[@limpa756]

When I was in hospital with a damaged pancreas due to alcoholism and had a girlfriend that was just using me this channel helped me with my escapism diving into linux, just sat in that wing on my old x220. Thanks man, lots of love you HUNK

[@MENTOKz]

for u matt i clicked the like button twice hope u like it lol

[@Mallchad]

The "bloat" problem is not that important in my opinion for deduplication reasons other people have mentioned before me making the final install rather small. The much bigger problem is, A, yes, the install times become very slow and cumbersome because flatpak ends up doing huge updates every time you get a single package, B, the entire point of using containers is so software works more often. So, _why is it, that flatpak, works, less often, than native packages_. .-.

[@enhncr]

Using anything outside your package manager repo is in long term a bad idea. The best repos are for Gentoo, Debian and Arch. Why you should avoid “external” packages? Dependencies, mess, etc. Just stick to a good repo. I really use anything additional just only if there is no other way to install it

[@TheLinuxCast]

I don't think you get how distrobox works, but that's okay.

[@sixdroid]

so you never compile stuff from git? are you a genious with that affirmation?lol

[@kintustis]

now theres infinity +1 competing standards

[@michaelandrews4783]

Any linux user that thinks Flatpaks are not neccecery to make it a usuable cohernet experience at some point in the future has no idea what they are taking about in any rational sense.

[@hlomphomota8055]

Personally, I wish there was a tutorial or some way to understand how the whole flatpak world worked and how one can develop on it, that I think would allow us the layman to understand how the whole secret sauce is made. But All your points are valid and I think there needs to be a better understanding on what containerised software works on and how it can be fixed. But my theory is that it gets bloated to accommodate more needs than it need to, so the architecture needs to be reviewed... That's my humble view...

[@talkysassis]

Flatpak has an issue that comes from trying to fake a native environment. Flatpak programs are just regular programs using a runtime. Unlike Android packages that are made with specific runtime libs.

[@hlomphomota8055]

@@talkysassis To which maybe the problem is standards in programming than the design of flatpak per say...

[@talkysassis]

@@hlomphomota8055You can make it work like Android, but Flatpak itself was not made to work like that, so it is a problem.

[@davidcave5426]

I still prefer appimages. Unfortunately, many appimages are no longer being updated.

[@scottr.7077]

Distrobox is no substitute for flatpaks. It's a complicated mess that is tauted as the next best thing. It's like wine - alot of promises but it never delivers.

[@TheLinuxCast]

totally disagree

[@theworldoffun8997]

I dont really mind soft booting 2-3 seconds instead of an instance. Also the package size doesnt seem as a major problem for me too. The only thing i care about is that i used to break them with a flatseal, lok 😂

[@unkown34x33]

the biggest issue I encounter is that a lot of flatpak versions are super outdated, and the devs! refuses to fix it. there's A lot of things missing from them, which I don't understand why it's soo hard to just fix it... 3 years for example