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 also 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
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.