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 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.
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.
@DidacticDumbass
You can set Debian to prefer installing from stable unless you explicitly request otherwise. That works on a per-package basis.Presumably you could do the same with any apt-based distro, but I’ve not tried it.
@agelordFlatpak is the simplest solution for me.
I usually use the terminal, so that is something I need to make sure of. Otherwise, using the Software Store I can explicitly choose which version to use.
@DidacticDumbass
This runs you through the setup: https://unix.stackexchange.com/questions/8049/how-to-install-some-packages-from-unstable-debian-on-a-computer-running-stabl#8051Once it’s in place, I’ve had no issues.
Neat. I was wondering how to do that.
Debian stable + flatpaks.
I want to be on the latest Firefox and to have the latest LibreOffice and some other apps. I want the latest applications, but I don’t want them come at the expense of having my system randomly lose its Wifi at the next boot or some other trash.
FreeBSD had this figured out 25 years ago. Separate the base from the user apps. When I was a teenager, I built -current ports on top of -stable FreeBSD and it was fine.
Now we have the equivalent option in Linux, and it comes from a centrally managed repository i.e. I’m not downloading tarballs and managing my own packages. I’m too old for that crap.
I’m glad to see you’ve gotten a ton of feedback here, and I just wanted to add another comment in support of flatpaks and image-based computing. I’ve been using Linux extensively for about 15 years now, mostly Arch and Debian Sid. I’ve been a distro packager, and I’ve compiled plenty of my own apps over the years.
This past year I took Fedora Silverblue for a spin after following the project for quite some time, and I am convinced that the image-based system approach, coupled with containerized and sandboxed userspace applications, is the future of Linux for most users. It makes so much sense from nearly all perspectives; whether security, reliability, or flexibility.
Integral parts of the system are mounted read-only by default. Simple commands can rollback unwanted changes, upgrade to a new distro release, or even sideload an entirely different OS. System updates are automated, as are flatpak updates, and there is little-to-no risk to stability due to the very nature of the essentials-only system images. And if something catastrophic did happen, you’re just a reboot away from rolling it back.
Consider for a moment the collective energy and time that distro package maintainers must undertake on a weekly basis. Much of it simply repeated by each distro, building the same applications over and over again. Flatpaks are built once and deployed everywhere. Think of the collective potential that could be directed elsewhere.
Couple this with containers and the choice of distro matters even less. Arch, Debian, Ubuntu and Fedora are just a keystroke away. Yes, you can run containers on any distro of course, but you don’t gain any of the other ostree benefits mentioned above.
I have since moved all of my workstations to Silverblue and I don’t see myself ever going back to a traditional system again. If anything, I may start automating my own image deployments, similar to Universal Blue.
Yes, flatpak as a platform still needs some work, and so does ostree, but both are evolving quickly and will only get better with time.
To others who complain about needing Flatseal…in my opinion, this is a feature to be embraced, not loathed. Sane defaults are rarely sane for everyone, and Flatseal exists to give you complete control over what an app can or cannot see and do.
Thank you for writing all this! Innovation is absolutely necessary not just in Linux, but all computing. People are comparing this to Window installs, and honestly it is probably more similar to MacOS installs. Yet, the difference is that the packages are audited by a community, and are not proprietary wildcards that might bite you in unexpected ways. Flatpaks are an options, not a replacement.
Dealing with software that does not work first try is a loathsome experience. Many people here are wearing their gray colored classes, opinions influenced by decades of tinkering, and are forgetting about the curse of knowledge.
If we want more people to adopt linux, Flatpaks absolutely help.
Lastly, saying image-based reminds my a lot about Smalltalk, which is nice. I like the idea of having hot-swappable operating systems to switch between that have all the work isolated in that image. Great for experimentation, and perhaps security.
I will definitely be checking out Fedora Silverblue. Going to download and make a VM for that now.
I’ve been using NixOS with flatpaks and distrobox and have had pretty much the same experience. NixOS provides rock solid base system, services, and CLI tools that are easy to configure and flatpaks provide the rest of the desktop applications.
One neat feature of installing eveything through flatpak is that you can update applications individually without having to upgrade the whole system.
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.
For convenience, it’s great. The sandboxing is good as well. Flatseal is a must have for me, though.
Probably never. They’re my third option after native packages and built-from-source packages/installs either manually or using the AUR. They’re convenient and the only option I tolerate of those newer package styles (Flatpak/Snap/AppImage), but seemingly having to download a new 800+MB runtime for small 32MB applications is ridiculously wasteful and I wouldn’t touch them if I didn’t have at least a TB of storage.
That is a fair take. The universal package systems seem to disregard space outright, which is unfortunate.
Yeah, having apps updated in the last year is enjoyable
Hahaha! I think developers seem to prefer it? My uses cases are 3D modelling and game engines like Blender, Cura, and Godot.
All those need to be the latest because often the updates are tremendous (as in great or awesome), making the software so much more functional and better to use.
Yeah, it also lets us ship working environments. At [email protected] we have been shipping our flatpak with an old environment because there was a regression in recent mesa versions that caused graphical issues on amd. We could simply deploy an update to resolve the issue for everyone instead of making everyone downgrade their system mesa…
That is a cool use case! I am learning so much about the benefits of Flatpak, not just an easy way to get software.
I use Flatpaks for everything I can. I like how Flatpak keeps apps in a container isolated from my system. Also, Flatpaks contains every lib in every version I need for my installed apps, which means It does not rely on my system libs, and I like It, cause my system libs is to make my system works only.
Flatpaks are just the future of packaging
Great explanation and rationale for using Flatpaks! I hope others with questions see this.
I understand how people may be annoyed by the redundancy of every app packaging their own lib, but I swear those are measured in kilobytes, and people tend to be so obsessively minimalist it is a non-issue. Then again, minimalist are probably compiling their software.
I disagree. The other day I wanted to install some audio app that came in flatpak install format (I’ll check and add the name later). The app was less than 30MB in size, but the installation included 300MB of a previous version of org.freedesktop!
I think that is one time download of a library so the app can run. Also, any other app that needs it.
It seems to me that the biggest complaint people have with flatpaks are the space it takes.
I wonder if the blow up in GBs was an early buggy behavior?
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.
I use system packages for everything unless I need a newer version of a specific package for some reason.
Most software does not change that significantly, so there is no loss in holding back, and usually just the benefits of not breaking your workflow, or your system.
I didn’t like them before I used flatseal. Now I love them.
That extra bit of control is definitely a deal maker.
For a long time now, if a flatpack is available and maintained, I use it.
Same. Better stability, frequent updates, no building from aur, and permission management with flat seal are great.
If you use mostly flatpaks they share packages which means they don’t take nearly as much space overall as single packages do.
Updates with only downloading diff’s is fast and works well.
I also like them just for the sake of tidiness. Some apps like Steam tend to make a big mess of dependencies all over the place, so it’s nice to have that all contained in one place. It does take up more space but I have a reasonably big hard drive so it’s kind of negligible for me.
I briefly considered getting into Fedora Silverblue, and I still may for this very purpose.
I’m getting into OpenSUSE Aeon (MicroOS desktop) and it’s been really great with Flatpaks and Distrobox. You should consider that one too :)
Sounds dope. I love OpenSuse. I almost made it my main OS, but got kicked in the ass installing graphics drivers and the fixes were many and too annoying.
MicroOS. Never head of that. I am excited now.
I had a reasonably good time getting NVIDIA drivers installed. I found the instructions here. I installed the newest drivers using the following command + a reboot.
transactional-update -i pkg in nvidia-driver-G06-kmp-default nvidia-video-G06 nvidia-gl-G06 nvidia-compute-G06 nvidia-utils-G06 nvidia-compute-utils-G06The OpenSUSE guide doesn’t include compute-utils, which is needed if you want to run nvidia-smi. I haven’t tried installing a full CUDA SDK, so ymmv there.I think I just need to follow the guides more closely. I must have missed something.
It depends. Kind of prefer Flatpaks as they are always working as expected on any distro, but some of them are giving me just too much struggle.
For example, dealing with sandboxing, or especially VSS code app. Yes, there are instructions, but then I install Golang SDK via Flatpaks the hard way (using CLI) for Go development, then having a nightmare trying to setup everything in vss code. Then how tf should I access go binary within my host terminal?
On Arch Linux I just tend to install from official repos, while the rest of apps - from Flatpaks.
Personally I don’t like the way they are sandboxed, bit as long as it works I am fine.
That seems to be the running theme, the defaults for the sandbox seem to be wrong for some people and there is no easy way to change them.
Also, I am sure I would like Arch, my problem is that I was using Manjaro, which is the distro I originally fell in love with and basically converted me to using it full time, but a long time ago. Now it sucks.
Anyways, that is the best, official Arch repos.
Simple example when I wanted to install the latest version of Okular, which came as flatpak. Owing to sandboxing it couldn’t do the inverse search from a pdf, calling Emacs to open the tex file that generated the pdf. My workflow was broken. After spending half a day in forums trying to understand how to give more permissions to the flatpak, I finally ditched it and am using the older version from apt. Works seamlessly.
I use flatpak first for everything, but VSCode was one that I absolutely installed the old fashioned way. It just needs to much system integration and I couldn’t figure out how to let it out of the sandbox enough to make it work reliably. But it is the exception.
Absolutely not, and this article goes into quite a few reasons why:
https://blog.brixit.nl/developers-are-lazy-thus-flatpak/
Sadly there’s reality. The reality is to get away from the evil distributions the Flatpak creators have made… another distribution. It is not a particularly good distribution, it doesn’t have a decent package manager. It doesn’t have a system that makes it easy to do packaging. The developer interface is painfully shoehorned into Github workflows and it adds all the downsides of containerisation.
While the developers like to pretend real hard that Flatpak is not a distribution, it’s still suspiciously close to one. It lacks a kernel and a few services and it lacks the standard Linux base directory specification but it’s still a distribution you need to target. Instead of providing seperate packages with a package manager it provides a runtime that comes with a bunch of dependencies.
If you need a dependency that’s not in the runtime there’s no package manager to pull in that dependency. The solution is to also package the dependencies you need yourself and let the flatpak tooling build this into the flatpak of your application. So now instead of being the developer for your application you’re also the maintainer of all the dependencies in this semi-distribution you’re shipping under the disguise of an application. And one thing is for sure, I don’t trust application developers to maintain dependencies.
Even if there weren’t so many holes in the sandbox. This does not stop applications from doing more evil things that are not directly related to filesystem and daemon access. You want analytics on your users? Just requirest the internet permission and send off all the tracking data you want.
Developers are not supposed to be the ones packaging software so it’s not hard at all. It’s not your task to get your software in all the distributions, if your software is useful to people it tends to get pulled in.
Another issue is with end users of some of my Flatpaks. Flatpak does not deal well with software that communicates with actual hardware. A bunch of my software uses libusb to communicate with sepecific devices as a replacement for some Windows applications and Android apps I would otherwise need. The issue end users will run in to is that they first need to install the udev rules in their distribution to make sure Flatpak can access those USB devices. For the distribution packaged version of my software it Just Works™
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.