I am currently using Linux Mint (after a long stint of using MX Linux) after learning it handles Nvidia graphics cards flawlessly, which I am grateful for. Whatever grief I have given Ubuntu in the past, I take it back because when they make something work, it is solid.
Anyways, like most distros these days, Flatpaks show up alongside native packages in the package manager / app store. I used to have a bias towards getting the natively packed version, but these days, I am choosing Flatpaks, precisely because I know they will be the latest version.
This includes Blender, Cura, Prusaslicer, and just now QBittorrent. I know this is probably dumb, but I choose the version based on which has the nicer icon.
I don’t like flatpak or snap or any of them. System libraries exist for good reason, just because your computer is stupid fast and you have enough disk for the library of Congress a couple times over doesn’t mean you should run a veritable copy of your whole operating system for each program. IMO it’s lazy.
Sandboxing is a different thing though, if that’s the purpose then it’s doing it right.
Yeah, that’s why Arch is almost the only distro that keeps everything installed natively. All other distros either have a troublesome workaround or only support flatpaks.
Rolling release just keeps everyone on the same pace. Yes, they break sometimes, but on the long run it just works.
I see your point, and I agree. No need to spend resources just because we have them.
Sandboxing is definitely a benefit, but alas as I am learning I have no control of it’s permissions, so that can potentially go wrong.
I have a ton of flatpaks which means packages are shared between them, so no it’s not lazy or a copy of the whole system. It makes a ton of sense for stability.
Updates are diff’s so downloading and updating is fast. Not entire packages.
Making every package work with only a certain version of a dependency and hoping it is stable doesn’t make a lot of sense.
You’ve just moved the packaging problem from distributions to app developers.
The reason you have issues is historically app developers weren’t interested in packaging their application so distributions would figure it out.
If app developers want to package deb, rpm, etc… packages it would also solve the problem.
Sure. Except you gain universal compatibility for all distros that have flatpak and aren’t building all the different package formats. Makes it much more attractive for actual developers to package since it’s only done once.
There’s no right answer here, but there are definite benefits.
I’ve had many little issues since I moved to Linux years ago, most of which would never have been an issue if flatpaks were there at the time. My experience has been better with them.
I like them for the opposite reason. I’m still quite new to Linux, so I’m figuring out which software is best for me. I set up my server with Xubuntu and installed everything through Apt. I uninstalled a lot of software, but inevitably missed some things like libraries and config files.
Using Flatpak seems to keep track of everything, so uninstalling gets rid of everything that I would otherwise miss.
If it’s doing what it says on the tin, Flatpak is making my life much easier :)
Trying to purge orphan dependencies is absolutely annoying. Talk about wasting space!
Quite the opposite, after fiddling with it for six months I fully uninstalled flatpak and deleted the directory to get away from the fact it kept downloading copies of nvidia drivers when I had moved to an AMD a year ago, and the drivers were locked from being manually removed even after I uninstalled all flatpak packages.
I’m an Arch user, trust me when I say I read the documentation.
After wasting hours on it I nuked it.
Damn, alright. I am starting to get the hate for it. I think I am blinded by the sheer convenience of it. Also, I am probably sleeping on more up to date repositories that gets me what I want without using flatpaks.
Linux Mint has been babying me though. I love the comfort, and cinnamon is everything I need in a DE. I will need to see what I can do.
Mint is an excellent starting point, and there’s good reasons to use flatpaks. If it works for you use it until it doesn’t.
I have been using Linux exclusively for maybe 8 years now? I just never dived to deeply into power user territory. I can get around okay, and am comfortable with the terminal and all that, I was just never interested in spending too much time trying to customize everything.
For a period I was obsessed with alternative operating systems. I read that Haiku is basically ready for evey day use. I wonder how Redox is coming along…
Anyways, I hope flatpaks keep working.
I accept that I’m in the minority on these things, but I value simplicity really highly, and I mean “simple” as a very specific concept that’s different from “easy”. It can be harder to resolve library dependencies on a system where everything is installed using the native package manager and common file systems, but nothing is as “simple” as ELF binaries linking to .so files. Nested directories branching off of
/is “simpler” than containers.Do I have any practical reason for preferring things this way? Not really. There are some ancillary benefits that come from the fact that I’m old and I already know how to do more or less anything I need to do on a Unix system, and if you tell me I need to use flatseal or whatever, I’d rather just use users and groups and tools that have been fine for me for 25 years. But that’s not really why I like things this way. I have no issue with embracing change when it otherwise appeals to me --I happily try new languages and tools and technology stacks all the time. What it really is is that it appeals to the part of my brain that just wants to have a nice orderly universe that fits into a smaller set of conceptual boxes. I have a conceptual box for how my OS runs software, and filling that box with lots of other smaller little different boxes for flatpack and pyenv and whatever feels worse to me.
If they solved practical problems that I needed help solving, that would be fine. I have no problem adopting something new that improves my life and then complaining about all the ways I wish they’d done it better. But this just isn’t really a problem I have ever really needed much help with. I’ve used many Unix systems and Linux distributions as my full-time daily use systems since about 1998, and I’ve never really had to spend much effort on dependency resolution. I’ve never been hacked because I gave some software permissions it wouldn’t have had in a sandbox. I don’t think those problems aren’t real, and if solving them for other people is a positive, then go nuts. I’m just saying that for me, they’re not upsides I really want to pay anything for, and the complexity costs are higher than whatever that threshold is for me.
Your knowledge of Unix systems is incredibly powerful, and I highly respect that. You are in control of your system, which is the ultimate goal of personal computing. It is even more powerful that your mental models are reflected in your system. That is super cool, I hope to get their some day.
I am also very happy you enjoy trying out new technologies, and don’t have the grumpy jadedness of just using what you always use.
For me I thoroughly enjoy learning new skills that unlocks the power of all my many computers, and put them to use. Computing should be fun and empowering, and too often people deprive themselves of fun.
I too have been using native packages for 25 years and I wouldn’t say it have been “fine”.
I’ve had to deal with outdated packages, where to have the latest version of a software you had to compile from source.
I had to deal with 3rd party repositories that broke my system.
I had to deal with conflicting versions of a library.
I had to deal with the migration from libc5 to glibc and God that was horrible.
So yes containers might be a little more complex in its implementation, but it means I can install apps from third parties without touching my system and I love that. My OS stays clean, and my apps don’t mess with it.
It’s not that I’ve never had any problems. It’s more that those are infrequent one-time problems, and if something happens once every two years that takes me 30 minutes to solve, I’m willing to do that if it makes the day-to-day use of my system smoother. Flatpak feels like I’m rubbing just a little bit of sandpaper across my face 20 times a day, and the promise is, “yeah, but look how you’ll never have to solve this minor one-time things again”, and that’s just not a trade I want to make.
I like flatpak because it keeps everything more orderly. My OS fits into one box, and my userland applications all get their own little box. I don’t have to worry about the choices I make for my OS dictating the options I have for applications. And I don’t have to worry about installing an application polluting my OS with libraries that only it will ever use.
The same is true with containers like Docker. Sure, I could install web apps directly on the server, or make a VM for every service I wanted to spool up, but with Docker Config(or the many other ways to wrangle docker) I have a predictable input/output. I never have to worry about the requirements of one service conflicting with another. And the data and logs generated by the service rest in an exact place that I can ensure is uniform for all services, even if the developers do wacky things.
Taken to the extreme you get NixOS, which I really like the concept of, but can’t bring myself around to learning, as I know it will take over my life.
/var/lib/flatpak/app/org.gnu.emacs/current/active/export/bin/org.gnu.emacsis not what I expect a Unix system to want me to type if I want to run Emacs. Nor isflatpak run org.gnu.emacs. These are tools built by someone whose mental model of running Unix software is “click the icon in the Gnome launcher”. That’s one aspect what I’m describing as not being “simple”. I don’t want my mental model of how to run Unix software to include “remember how you installed it and then also remember the arbitrary reverse-FQDN-ish string you need to use to tell flatpak to run it”. If I’m honest, that alone is sufficient to signal it wasn’t built for me. I could work around it for sure with shell aliases, but I could also just not use it, and that seems fine for me.This. Having to open a console to run a flatpak in bspwm is annoying as all hell. PWA’s are just as bad, I ended up writing a script I could run from dmenu:
#!/usr/bin/env bash PWA_PATH=${HOME}/.local/share/applications for app in $@ do DESKTOP=$(grep -i "Name=.*${app}" -lm 1 ${PWA_PATH}/*.desktop) if [ ! -z ${DESKTOP} ] then APPID=$(basename ${DESKTOP} | cut -d- -f2) /usr/bin/google-chrome --profile-directory=Default --app-id=${APPID} & fi doneI agree that launching flatpaks outside of a GUI is stupidly verbose. I certainly would never use flatpak for cli tools, and I think that is a problem for it. I would love to see more tools bundled up that way, but flatpak is far from the solution. And Docker has the same or bigger problems.
And in a way, everything is a CLI tool on most normal systems. Evince or Acroread or whatever you prefer to read PDFs is not “a CLI tool”, but if I want to use LaTeX to create a document, I want to be able to do something like
$ xelatex myfile.tex $ evince myfile.pdf &I don’t want to have to build my document, bring up my app launcher, click on the Evince icon, hit Ctrl-O, navigate to my pdf file, and double click it.
That is a great point. I use the shortcut ‘code .’ to launch VSCode when I’m on the terminal a lot. Can’t do that with flatpak without an alias. I don’t live on the terminal though, so it is rarely an issue for me. It is a problem flatpak should solve though. Seems like they are focused on GUI apps and GUI launching.
ag to be honest I’m so frustrated by having to remember what package manager was used for installing which binary. I don’t have time for this horse shit
Man, no one’s got time for anything.
9/10 desktop applications I use are flatpaks. Am on Arch and even when there’s an AUR for a package I’d prefer to use Flatpak. Just so I can use Flatseal to control permissions access on my applications.
Love it! I am starting to feel good about this then.
I want a stable OS, but I want the latest versions of applications (programs) without messing up anything. For me flatpak and snap meet that need, but I prefer flatpak.
It seem that whatever problems Flatpaks may have, due to sandboxing, is truly isolated. I think as a non-power user, I do not have strong opinions about any kind of technology, I just enjoy the magic of things working without effort on my part. I will dive deeper as my needs change, but my needs are kind of simple too.
Yes, but only for apps that which I want to be on the very latest versions. One might ask why I don’t use a rolling release distro, that’s because I prefer a solid LTS base.
That is absolutely the best usecase. There are only a handful of apps I need to be the latest version.
I am mostly using native packages.
I had fedora installed the last few years, and was digging flatpak… until I wasn’t. One day I ran out of disk space - 230 Gb of flatpak dependencies. I run a pretty slim system, so what the actual heck? Did some research, learned how to flush cached and redundant packages, shrunk my flatpak deps to… 150 Gb
I’ve since been trying Endeavor
That is unreal. I had no idea it can get that bad. Makes no sense, honestly.
It was likely the build up of a few years’ packages, updates, and so on, but it eventually came to a head and I had to wipe and load. Maybe it’s better now, but I think I started that install around Fedora 34? So not too long ago
Weird. That is unfortunate, and I hope it was just an ugly bug that unfortunately effected you.
I still favor native packages, but I don’t have a problem with Flatpaks. I’ll use them when a program isn’t available in the repo or there’s a compelling reason to have a never version of an application. I’m on Debian Stable, so I’m obviously not obsessed with having the newest, shiniest version of everything.
I mean, not every shiny version is a mere gimmick. Cura just added improved tree supports, which are a great quality of life improvement.
I will not deny that having a robust stable system will always be better than having every package the newest version.
I personally still prefer native, but flatpak is my goto for whenever something isn’t working or when the official repos are outdated.
The other day I tried to use Malt for blender but it wouldn’t work on the native version because it was using the wrong version of python. The flatpak version works perfectly with Malt, but for some reason I don’t feel like troubleshooting, the OptiX denoiser doesn’t work.
Still though, flatpak is a welcome option and is way better than snap.
That is so strange. I think people are underestimating how important up-to-date packages are for certain kinds of workflows, and short of reinstalling everything onto a rolling distro, the only sane solution is something like Flatpak, or directly installing every new binary as it comes out, which can suck and does not guarantee having all dependencies.
Nope, don’t like them. Nor snaps. I find the sandbox nature annoying and many developers don’t actually seem to understand it correctly anyway meaning you have to use flatseal etc. Then having to deal with some apps writing config within the sandbox and some writing it outside the sandbox…
My order of preference is generally I pick the “official” supported version as opposed to any community maintained ones. Then within that:
- Install via the language’s package manager (cargo, npm, pipx, cabal etc.)
- Appimage
- Native package (.deb, .rpm etc.)
- Plain binary
- Build from source
- Snap
- Flatpak
True. I have run into a lot of dumb issues with sandboxing, mostly in choosing a folder other than downloads for file interaction.
I have overlooked Appimage, and I will consider it. I am intrigued that you put it before native package. I had not considered using the package manager of the language it is built in, which honestly is probably the optimal way to install a package.
Alright, I have some reading to do. I love learning new ways to do things. I am glad I asked!
There is a bit more nuance to it I suppose - I like Appimages for “complicated” apps, i.e. big GUI apps like Inkscape where I prefer native packages for terminal tools. The nice thing about Appimages is that there just isn’t much in the way of integration and therefore its really easy to just try something out with no risk of installing a bunch of extra dependencies and no way of breaking your system - I use Appimagelauncher for managing them but have been considering swapping to something like Appman/AM.
The other thing that sometimes puts me off of native packages is having to deal with excessive numbers of PPAs or other repos when they aren’t in the main ones.
That is a great consideration that I have not looked into in awhile. It seems to be the ultimate third, or perhaps second, solution for getting software to just work. I will look into Appimagelauncher, and try out that version is native or flatpak fails me somehow.
Yeah, user submitted packages are such a risk sometimes.
This is exactly what flatpaks were meant to do. Simplify the program deployment across all distros
It certainly has simplified things for me! To get anything so up to date, I would need to use something like Arch or the AUR, which is fine but I find unappealing (using Arch).
Nope. I’ve been running Debian for the past six years after I got tired of messing with arch. I’m over my shiny new thing syndrome and am happy with old but stable software. I’ve tried some flatpaks but the only two that I use are Spotify and signal. They take a lot of space and updating is slow.
I agree that stability is important, perhaps paramount, in a computing system. Still, some software like Cura, improve with every release, and it is worth upgrading for every new feature.
Anyways, I have never been concerned with space. On the whole programs don’t take up that much space compared to everything else I would put on my system like games. Also, I am the kind of person who wants all the software they would ever use installed on their system. I want my computer to be useful even when the internet goes out.
If you’re playing games, then latest software in terms of kernel and libraries are important. There’s a reason why valve switched to arch as a base for steamos. For my use case, I do a lot of coding in C using emacs so thing don’t really change that much. To each their own, that’s the beauty of Linux!
Thank you for saying this! The negativity here has been jarring. I understand preferences, but no reason to be mean about them.
I wanted to stay with Arch awhile back but I kept messing up the install of Nvidia drivers in like every distro, so I just have a lot of apprehension. Maybe it is better now. Still, I am in a good place distro wise.
Emacs the portable lisp machine that can do virtually everything. That must be so fun.
i avoided flatpacks before.
but now that i tried out silverblue and had to rely heavily on them,
i have to admit that flatpacks are not nearly as bad as i thought.the only issues i encountered are with steam (might not start propperly on first launch)
and with ides(terminal starts inside the sandbox)other than that it works great.
Yeah, interactions with software outside the sandbox can be annoying, but I am glad it is flexible enough to overcome those problems.
When using Fedora Silverblue, there is no other option, which I do!
But there are other options with Silverblue.
