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
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.
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
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.
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.
@@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.
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.
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...
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.
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.
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.
> (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
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
@@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.
@@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?
@@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.
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.
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.
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
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.
Containers on the desktop is a bad idea. That goes for distrobox. They all need a good soak in gasoline and a nearby match. Who cares how fast an installer/updater is?
Noob here. Researching Linux cuz Windows says my 6k 5yr workstation no longer supported and I'm like well time to start looking for future options. Anyway. The package problem on Linux seems to stem from people making packages but not all make good ones with good practices. Now y'all hating snaps but they were an attempt to get a handle on that. Yes proprietary etc but still. Fascism does have it's advantages sometimes. Like consistency. Freedom is great cuz choices but most people are not consciencious and take easy ways through stuff. Leading to chaos. What's the middle ground? Seems installing a whole new distro is even more bloaty thing to do than flatbloat. As prospective new Linux dude this all seems silly to me but I'm still researching. Hope I will know more as I cont to get to understand all this minutia...
I've never tried Distrobox - does it in any security significant way sandbox whatever it's running? I agree that managing permissions in Flatseal can be annoying, but generally I think it's a big plus if Flatpaks don't just have permission to do anything they please. I'm a long time Windows user and for me a personal firewall was a must for example. It's annoying if every new software has to ask permission to use the internet - on the other hand I liked the idea to decide which software I use actually has a legitimate use case for accessing the internet - and deny the rest. Flatpaks give me a even greater level of control - albeit at the cost of having to tinker with permissions.
distrobox is simply a front end to podman aka a better docker. So it is all containerized. Wont touch your system. There is also supposedly a way it can talk with your Nvidia GPU as well so you can run games as well with full Graphics instead of the crummy opensource drivers
Distrobox explicitly states they do the opposite of sandboxing - they try to integrate as well as possible into the host. It is on the wishlist of things to add, but so far from what I can see they've only added the option to specify an alternative HOME directory.
As a regular guy just want an app to work. Why should i care about this? Flatpak is better option for me. The obs part where you said it doesnt support in wayland it does on KDE and Gnome. And also it offers plugins which is pretty good.
If I wanted the bloat and malware that comes with Mac OS X and Microsoft Windows I'd just have run those systems. One of these days I'm going to release a distribution myself without all this garbage. It's ok for some apps to be rolling, but most of your system should not be rolling as it introduces instability. Hardware/kernel/hplip/xsane/etc should be rolling. Web browsers should be rolling. Instant messaging apps/communications apps/etc should probably also be rolling. Most of the rest of the system should not be rolling however. I've used the same OBS for streaming and making videos for YEARS and as long as OBS, Kdenlive, and OpenShot are stable releases I could care less if I have the latest release. I am far more concerned about security and that's a major problem with snaps and flatpaks. Debian's model is far superior and theoretically should be more stable. Admittedly it's not perfect. The distributions forked from Debian tend to be a bit better once the tweaks are made, but the point remains it's the shiny example of how things should be (with the exception of systemd... if only Devuan was a bit more stable).
Flatpaks aren't meant to not have dependencies. They're just meant to work universally between distributions. Appimages are meant to have all the dependencies included inside one packages.
It is the future. You cant expect your distro to package things for you forever. That should bê the job of the developers of the aplication. A Lot of times the distro developers are wasting time on this for no reason.
@@catoflado4977 Maybe not, but I _can_ expect to be able to manually update the package build scripts if it's absolutely necessary. (I've done exactly this on multiple occasions on my current system.)
Distrobox will never be as supported as flatpaks ou even snaps because it's way too complicated for a non expert user. It's not a package manager, it's literally a distro inside your own distro. So naturally more users will consider flatpak, and therefore the developers will also prefer it. Some distros are even not allowing using its own package manager in favor or flatpak...
I'm pretty sure that the point of flatpaks is that older dependencies stick around for programs that need them. Which could be done with traditional package distribution and sometimes is with dependencies like webkit2gtk. From my understanding Flatpaks are meant to become an optimal vehicle for introducing proprietary software to linux and eventually open the gates for people who are software locked to proprietary OSs, as well as reducing the work for both developers and distro maintainers in order to release a piece of software across all distros. I don't think flatpaks are the future of linux like wayland is the future of linux. Wayland is inevitable, flatpak is for people who's hearts are stricken with fear at the mere invocation of the c word (compile).
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.
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.
@@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.
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.
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.
@@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.
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.
@@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.
@@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.
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.
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.
@@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 :)
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.
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.
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.
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//
@@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.
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?
> 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
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
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.
@@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.
@@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
@@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.
@@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.
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.
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.
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.
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.
@@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!
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.
> 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.
@@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?
@@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 RUclips, 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.
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.
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.
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
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.
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.
@@MarkusHobelsberger Flatpak automatically deduplicates. Are you thinking of BTRFS compression? I'm not sure how much extra space is saved when used in tandem.
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
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".
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.
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.)
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?
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.
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.
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)
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
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.
WHAT is Distro Box...? link? I NEVER used FlatPaks, Snaps or App Images I look at it as a band-aid to fix the Linux GUI's I HATE that there's such a PUSH to use FlatPaks I prefer a Lean Linux!!! I like stuff that runs without a band-aid but... the Linux Mint & Ubuntu Repositories are WAY out of date!!! Enjoy The Collapse 🤪 The Fall Of The Empire 😠😡🤬💥💀
my problem with flatpaks is that they do not work, for simple apps - yes it's great, for anything else - sandboxing breaks application. Installed IDE, installed needed libraries - IDE desn't see my libraries even though they there - wasted hours till I figured out that problem is sandboxing. Installed Steam to play some games, want to use different drive than /home one - that doesn't work because of sandboxing. it's just not user friendly
I'm not using flatpaks, I use snaps, because they are getting faster instead of slower. Besides I run the newest version of Firefox and LIbreOffice in an OS from 2016; Ubuntu 16.04 ESM :)
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.
IF you don't like the "containerization" of flatpaks now-- what about using BLEND or VANILLA and use whatever you like and putting the apps in the containers made by BLEND or VANILLA????/
Wanting an UP TO THE MINUTE software is just GOOFY--- FOR ME (NOT knocking it for others..) and I can see why you would.. Just curious to see what you'll end up recommending..
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?
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.
I'm half through this video and don't understand. Why do you even use Flatpacks if the software is in the repo and works. The whole idea of such containers was to distribute SOME software, especially commercial one. Anyone on a Arch based distro or Nix would have most software, idk about Debian. Also, why does it matter if some companies don't do a good job or if downloads "slow", what matters is to get the software you need, or not?
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_. .-.
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.
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.
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.
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
I forget what flatpak I was installing the other day , but I cancelled it after 550MB download and it wasnt finished yet...Pretty sure it was just a web browser.
You are a hobbyist, nothing will happen to you if your software does not work anymore. Might make you angry for a moment but you can switch to watching TV instead. The problem is with people who build their business workflow with it. They really can't risk anything rolling.
Man, I almost thought I was the only one who hate flatpak I am new to Linux world 6 months of use and I was using native app from package manger until I watch a video talk about flathub and how its the future of apps on Linux I try it and it was disaster when I try to install app it install 1GB of shit for run the app and that fuck my limited internet connection after all that time and internet of installing app the app take so long time for start up just like snap I was thinking the problem was from my pc until I watch your video you are the only one who hate that shit the problem all dev and distro are trying to push flatpak every where
I agree fully. Snaps are absolute trash, and flatpaks are not optimal. The only barrier to entry for Distrobox is that it is currently still somewhat more complex for total noobs who want to get into Linux.
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.
They're not complaining, because they're Apple fanboys. Mac users take a lot of things for granted. We can't seriously compare the Linux and Apple user base. It would be like everyone would blindly follow what Canonical proposes. It's not like that in the Linux world.
Flatpak lost me the first time I tried to use it... I wanted to install AM2R launcher, which is 12 MB in Windows. Flatpak wanted 1 GB of download !!! WTF?? I really hope it's NOT the future of package management.
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.
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.
The thing about AppImage is that it does containerization right, in that it just acts like a downloadable binary. With Flatpak and Snaps, you're effectively side loading a second package manager that exists parallel to your native package manager and just annoyingly segregates your application space.
I can't stand AppImages. Actually like them less than snaps or flatpaks. I really don't want to launch my apps from the file manager or deal with the mess of adding a desktop file to get it to appear where all the rest of the apps reside.
@@Absolute_Zero7 not really, it just put the AppImage into a folder and create lt's .desktop and path. And it's a prompt at execution not a package manager. so it's still a compressed bin just with the shortcuts so you can use it without opening the file manager
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
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.
What is that cube on your other computer desk? I want to pick one up.
@@CosmicChew Amazon search Davoom. That's the company that makes it.
@@TheLinuxCast I appreciate it.
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
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.
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.
@@lovebaranus9800 you code for linux then play the damn rules, otherwise, code for windows.
@@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.
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.
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...
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.
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.
I primarily use flatpaks.
Very few packages are installed through pacman,making my arch install very stable, I feel
I have always preferred Appimage over all the others. Now I'm trying to configure firejail well.
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.
> (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
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
@@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.
@@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?
@@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.
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.
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.
Aren't snaps growing in size too?
have you ever heard of xwayland? Obs would wok wiithout fuss with wayland if you use xwayland.
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
I don't think you get how distrobox works, but that's okay.
so you never compile stuff from git? are you a genious with that affirmation?lol
been on linux for 1 week and i hate how huge flatpacks are, completely filling up my damn drive
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.
Containers on the desktop is a bad idea. That goes for distrobox. They all need a good soak in gasoline and a nearby match.
Who cares how fast an installer/updater is?
I see your points, but right now flatpak very solid for me
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.
Bros a Discord Mod (IM JOKING)
Bro thinks he's being subtle with his fat joke.
no, just a linux user
Noob here. Researching Linux cuz Windows says my 6k 5yr workstation no longer supported and I'm like well time to start looking for future options. Anyway. The package problem on Linux seems to stem from people making packages but not all make good ones with good practices. Now y'all hating snaps but they were an attempt to get a handle on that. Yes proprietary etc but still. Fascism does have it's advantages sometimes. Like consistency. Freedom is great cuz choices but most people are not consciencious and take easy ways through stuff. Leading to chaos.
What's the middle ground? Seems installing a whole new distro is even more bloaty thing to do than flatbloat.
As prospective new Linux dude this all seems silly to me but I'm still researching. Hope I will know more as I cont to get to understand all this minutia...
Actually, I think Snap now is way better Flatpak.
I guess it's time to try distro box.
I've never tried Distrobox - does it in any security significant way sandbox whatever it's running? I agree that managing permissions in Flatseal can be annoying, but generally I think it's a big plus if Flatpaks don't just have permission to do anything they please. I'm a long time Windows user and for me a personal firewall was a must for example. It's annoying if every new software has to ask permission to use the internet - on the other hand I liked the idea to decide which software I use actually has a legitimate use case for accessing the internet - and deny the rest.
Flatpaks give me a even greater level of control - albeit at the cost of having to tinker with permissions.
distrobox is simply a front end to podman aka a better docker. So it is all containerized. Wont touch your system. There is also supposedly a way it can talk with your Nvidia GPU as well so you can run games as well with full Graphics instead of the crummy opensource drivers
Distrobox explicitly states they do the opposite of sandboxing - they try to integrate as well as possible into the host. It is on the wishlist of things to add, but so far from what I can see they've only added the option to specify an alternative HOME directory.
I've had such a bad experience with Flatpak recently that i am actually thinking about tryings snaps. Maybe they aren't as bad as people think
They are better than they used to be, or so they say. I have no recent experience with them outside of a few brief Ubuntu VMs.
Snaps are good for CLI apps, such as neovim or helix text editors
i think you are the firsrt in the world
As a regular guy just want an app to work. Why should i care about this? Flatpak is better option for me.
The obs part where you said it doesnt support in wayland it does on KDE and Gnome. And also it offers plugins which is pretty good.
Put a tutorial on how to use distrobox under opensuse tumbleweed
I neither use snap nor flatpak..i use brew in my pop os 😂
Without even watching the video yet: Something Much Better is probably gonna be Distrobox
If I wanted the bloat and malware that comes with Mac OS X and Microsoft Windows I'd just have run those systems. One of these days I'm going to release a distribution myself without all this garbage. It's ok for some apps to be rolling, but most of your system should not be rolling as it introduces instability. Hardware/kernel/hplip/xsane/etc should be rolling. Web browsers should be rolling. Instant messaging apps/communications apps/etc should probably also be rolling. Most of the rest of the system should not be rolling however. I've used the same OBS for streaming and making videos for YEARS and as long as OBS, Kdenlive, and OpenShot are stable releases I could care less if I have the latest release. I am far more concerned about security and that's a major problem with snaps and flatpaks. Debian's model is far superior and theoretically should be more stable. Admittedly it's not perfect. The distributions forked from Debian tend to be a bit better once the tweaks are made, but the point remains it's the shiny example of how things should be (with the exception of systemd... if only Devuan was a bit more stable).
Flatpaks aren't meant to not have dependencies. They're just meant to work universally between distributions.
Appimages are meant to have all the dependencies included inside one packages.
I have 0 flatpaks or snaps or appimages in my system. I only use my package manager, there's no need for anything else
It is the future. You cant expect your distro to package things for you forever. That should bê the job of the developers of the aplication. A Lot of times the distro developers are wasting time on this for no reason.
I must agree, but sometimes AppImages are just convenient 😅.
@@catoflado4977 Maybe not, but I _can_ expect to be able to manually update the package build scripts if it's absolutely necessary. (I've done exactly this on multiple occasions on my current system.)
Distrobox will never be as supported as flatpaks ou even snaps because it's way too complicated for a non expert user. It's not a package manager, it's literally a distro inside your own distro. So naturally more users will consider flatpak, and therefore the developers will also prefer it. Some distros are even not allowing using its own package manager in favor or flatpak...
I'm pretty sure that the point of flatpaks is that older dependencies stick around for programs that need them. Which could be done with traditional package distribution and sometimes is with dependencies like webkit2gtk. From my understanding Flatpaks are meant to become an optimal vehicle for introducing proprietary software to linux and eventually open the gates for people who are software locked to proprietary OSs, as well as reducing the work for both developers and distro maintainers in order to release a piece of software across all distros. I don't think flatpaks are the future of linux like wayland is the future of linux. Wayland is inevitable, flatpak is for people who's hearts are stricken with fear at the mere invocation of the c word (compile).
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.
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
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.
@@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.
@@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.
And to be fair storage is getting bigger, i mean, do you remember the size of flop disks?
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.
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.
@@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.
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.
@@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.
@@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.
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.
I'm young and i just use debs too :)
@@rubisetcie 😂
Yep - Debian using debs. Good enough for me.
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.
@@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 :)
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.
If the app doesn't have a navigation for plugins like blender, then it's a bug or missing feature.
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.
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.
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//
@@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.
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?
> 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
To me it seems that he is professional distro hopper. Never satisfied and always angry
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
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.
@@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.
@@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
@@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.
@@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.
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.
This is true. DE is supported.
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.
@@that_leafletOBS do need network if you stream with rtmp
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.
You really should talk to the creators of bottles as flatpak is the only distribution method they want to support
Yeah, I know. It's why I won't be using bottles.
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.
@@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!
@@lovebaranus9800and actually the Bottles devs used a TheLinuxCast video to justify not wanting any packaging that is not flatpak
Lutris is better at what Bottles does anyway.
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
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.
> 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.
@@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?
@@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 RUclips, 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.
@@NixperienceI posted another comment before. If you don't see it on your end, then it was deleted by RUclips, which I have no control over it.
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.
They work ok for me. If it makes it easier for devs to distribute their software, I don't see the problem.
This guy has no clue what he is talking He is a new linux user and talks out of his ass about containerised apps.
and some programs are flatpak only like the good stuff program "bottles" and many more stuff
I won't use any of these new stupid formats.
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.
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
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.
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.
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.
@@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.
@@MarkusHobelsberger Flatpak automatically deduplicates. Are you thinking of BTRFS compression? I'm not sure how much extra space is saved when used in tandem.
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
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".
Just found your channel. Excellent Content. Another sub for you sir!
Welcome aboard!
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.
BUT! Can you install distrobox inside of distrobox? 🤓
Probably. Distrobox is just a front end toolset for docker or podman, and you can for sure run dockers inside of other dockers.
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.)
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?
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.
Weird - how would you install Plex-HTPC?
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.
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)
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
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.
WHAT is Distro Box...?
link?
I NEVER used FlatPaks, Snaps or App Images
I look at it as a band-aid to fix the Linux GUI's
I HATE that there's such a PUSH to use FlatPaks
I prefer a Lean Linux!!!
I like stuff that runs without a band-aid
but...
the Linux Mint & Ubuntu Repositories are WAY out of date!!!
Enjoy The Collapse 🤪
The Fall Of The Empire
😠😡🤬💥💀
my problem with flatpaks is that they do not work, for simple apps - yes it's great, for anything else - sandboxing breaks application.
Installed IDE, installed needed libraries - IDE desn't see my libraries even though they there - wasted hours till I figured out that problem is sandboxing. Installed Steam to play some games, want to use different drive than /home one - that doesn't work because of sandboxing. it's just not user friendly
I use what I like or what suits me, it doesn't matter what it is, but I always prefer the native format
I'm not using flatpaks, I use snaps, because they are getting faster instead of slower. Besides I run the newest version of Firefox and LIbreOffice in an OS from 2016; Ubuntu 16.04 ESM :)
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.
IF you don't like the "containerization" of flatpaks now-- what about using BLEND or VANILLA and use whatever you like and putting the apps in the containers made by BLEND or VANILLA????/
Wanting an UP TO THE MINUTE software is just GOOFY--- FOR ME (NOT knocking it for others..) and I can see why you would.. Just curious to see what you'll end up recommending..
Doesn't kdenlive use QT instead of GTK ?
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?
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.
I'm half through this video and don't understand. Why do you even use Flatpacks if the software is in the repo and works. The whole idea of such containers was to distribute SOME software, especially commercial one. Anyone on a Arch based distro or Nix would have most software, idk about Debian.
Also, why does it matter if some companies don't do a good job or if downloads "slow", what matters is to get the software you need, or not?
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_. .-.
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.
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.
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.
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
When I cannot get the job properly. Done with a deb package or up image comma that's where flatpaks...ALWAYS save my bacon..
I forget what flatpak I was installing the other day , but I cancelled it after 550MB download and it wasnt finished yet...Pretty sure it was just a web browser.
You are a hobbyist, nothing will happen to you if your software does not work anymore. Might make you angry for a moment but you can switch to watching TV instead. The problem is with people who build their business workflow with it. They really can't risk anything rolling.
Honestly I haven't noticed any performance issues with flatpaks...
Man, I almost thought I was the only one who hate flatpak
I am new to Linux world 6 months of use and I was using native app from package manger until I watch a video talk about flathub and how its the future of apps on Linux
I try it and it was disaster when I try to install app it install 1GB of shit for run the app and that fuck my limited internet connection
after all that time and internet of installing app
the app take so long time for start up just like snap
I was thinking the problem was from my pc until I watch your video you are the only one who hate that shit
the problem all dev and distro are trying to push flatpak every where
Hey. Could you please take is through a tour of your desktop environment and maybe a tutorial on how you got this? Thank you!
Thank you. It is one useful video. But my fav is appimages, I really hope that format will be more maintained.
Jesus Christ, u all moving to the next package manager off flatpak? I am still using apt and backports for debian 😅
I agree fully. Snaps are absolute trash, and flatpaks are not optimal. The only barrier to entry for Distrobox is that it is currently still somewhat more complex for total noobs who want to get into Linux.
*you stop using them because everyone else on here says you should use them! LOL! Your a Rebel! 😎
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.
you do realize that if you get more dependencies it means it is more shared by every flatpak?
Matt: what are your thoughts about Nix (the package manager) not the OS?
So now we are installing a whole other os instead of just going the appimage route like osX does since forever and their users are not complaining.
They're not complaining, because they're Apple fanboys. Mac users take a lot of things for granted.
We can't seriously compare the Linux and Apple user base. It would be like everyone would blindly follow what Canonical proposes. It's not like that in the Linux world.
We need an open source LLM agents to manage legacy packages. You should start a foundation, I'm too old now.
Flatpak lost me the first time I tried to use it... I wanted to install AM2R launcher, which is 12 MB in Windows. Flatpak wanted 1 GB of download !!! WTF?? I really hope it's NOT the future of package management.
Flatpak is essentially a distro in a distro
Hi
Does SNAPs has runtimes like flatpak?
for u matt i clicked the like button twice hope u like it lol
You'll use flatpack if you cannot compile.
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.
I think distrobox should have named itself distrohop lol.
Flatpaks have won. There is no doubt about it. Distrobox is fot another purpose altogether.
Well, if they won, we might pack it in. no sense in using anything else. That’s why we only ever have one distro that’s all.
Flatpaks are fine!
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.
I still prefer appimages. Unfortunately, many appimages are no longer being updated.
Flatpak just sucks so does Snap.. IMO even Appimage ranks higher for me then either Flatpak or Snap
The thing about AppImage is that it does containerization right, in that it just acts like a downloadable binary. With Flatpak and Snaps, you're effectively side loading a second package manager that exists parallel to your native package manager and just annoyingly segregates your application space.
I can't stand AppImages. Actually like them less than snaps or flatpaks. I really don't want to launch my apps from the file manager or deal with the mess of adding a desktop file to get it to appear where all the rest of the apps reside.
Appimage launcher auto integrate the app to your system.
(.desktop for the app list and path for cmd)
@@ascrassin That kinda defeats the whole benefit of AppImages, and now you have Flatpaks but with extra steps.
@@Absolute_Zero7 not really, it just put the AppImage into a folder and create lt's .desktop and path.
And it's a prompt at execution not a package manager.
so it's still a compressed bin just with the shortcuts so you can use it without opening the file manager