From what I have seen, most of the opposition to Flatpak comes from the same place that the one to systemd: fear of change. Despite being centered around technology, a very vocal part of the Linux community seems to be extremely conservative.
For example Ubuntu is trying very hard to push snaps. In contrast to flatpaks only they can run the store for it so there's clearly a motivation of vendor lock-in.
This kind of thing makes me suspicious and more critical of new tech. I'd first want to see if it offers me any value. In this case I don't see the big benefit even though flatpak doesn't seem to carry the lock-in that snap does. But I like the optimisation of dynamic libraries and the way I can update openssl once and have all the apps patched that use it.
Systemd is a different story. It's open enough but a bit too heavy and complex for my liking. It's not bad though and I use it on some of my boxes. Alpine is working on an alternative based on s6 and I'll probably end up using that when it matures.
Anyway I didn't choose Linux/BSD because I cared about having the same as everyone else :) Being able to deviate from the beaten track is one of the benefits of these. I currently use FreeBSD because it has the least corporate meddling right now.
> From what I have seen, most of the opposition to Flatpak comes from the same place that the one to systemd: fear of change.
This is what pisses me off. You, nor anyone else, can tell everyone else what >I< think or feel. It's not fear, nor fear of change, nor any other dumb ass reason people who think like you think it is. I hate it because it's just a package manager. I hate it because, when all the reasons against it are brought up, something nebulous like "security" or something quazi-psychological like "fear of change" are brought up in defense of it.
The real problem with flatpacks is that they don't solve the real problem, and they do it poorly.
Want to solve the problem of your program not running on multiple distros, or not running in 5 years ? Then look at why that is. For example; it's not that the zip file format will change, so why must i recompile my program every time libzip changes ? Or X11 to wayland transition; why does my program have to even care about that when all i want is a window and an opengl context ? (bdw the solution to the latter is SDL2)
Let's look back when flatpack started. Why did it start ? Maybe because GTK3 changed it's API ever so often ?
Linux doesn't have a good GUI toolkit. THAT is the biggest problem here.
I just fucking hate the "ohh, you just don't like change" people. That dismisses all further discussion. That is the real "hate" that people like you blame others of.
If you don’t mind me asking again, why is it bad? Because the rest of your post certainly doesn’t answer that question.
I understood that you don’t personally like that libraries change. Unfortunately, they most definitely do and no, preventing everyone on earth from ever releasing an incompatible library is not a realistic solution.
> I just fucking hate the "ohh, you just don't like change" people.
Well, you definitely are complaining about change a lot in a very impassioned way.
> Well, you definitely are complaining about change a lot in a very impassioned way.
They are complaining about people who assumed an irrational reason for their opposition to something, while they have a rational one. I find that kind of assumption condescending ("let me, the rational one, explain to you how to get rid of your insecurities so you can appreciate how right I am") and kind of infuriating too.
> I understood that you don’t personally like that libraries change.
If you add breaking changes without maintaining the backward-compatible version for a reasonable amount of time, I'd argue your library isn't fit to be a dependency for anything important. I definitely wouldn't use it.
The Python package ecosystem may be a mess, but I still manage to use dozens of shared packages daily with quite rare breaking changes, even in libraries that see a lot of developments. I would prefer that we focus on improving API stability for shared libraries, instead of giving up and duplicating dependencies everywhere.
A working system calls for a conservative viewpoint. I'm only looking to introduce change if my needs aren't being met.
A lot of the vocal people who pick linux are people who want complete control over their systems. Things like wayland, systemd, and flatpak take away some of that control.
For example, journald. People know and understand "rotated-gzipped text .log files in a /var/log directory." People don't know, but more importantly, don't want to learn, this: https://systemd.io/JOURNAL_FILE_FORMAT/. It's a simple format, that makes perfect engineering sense as a format optimized for the goals it's trying to accomplish. But it's not text — not the thing a greybeard sysadmin has spent the last 40 years working with — so it's "hard."
Instead of just learning this format and writing tools to interface with it, people instead think of this data as being impossible to access, somehow "locked away" behind journald / journalctl, as if there were some kind of DRM put into your OS prevent you from accessing your own log data.
As it happens, though, journalctl already builds in support for manipulating this data with POSIXy text-based tools — getting your journal as JSON is one `journalctl -o export` away.
But nobody knows about these features (I only just learned about it now, from the link above!), because nobody talks about these features, because the tooling already solves 99% of the real-world problems people encounter, and so it's very rare to actually need to script against the journal.
And if you are in that 1% use-case, maybe you're e.g. engineering a distributed log-ingest system for efficiency; in which case you wouldn't use `journalctl -o export` anyway, but would rather link to journald's C API to parse the journal directly, because that's what's most efficient, even if it's less convenient/UNIXy.
-----
This is similar to e.g. how people pushed back against SPDY/HTTP2.0 for being a "less debuggable" protocol, just because it's binary rather than text-based.
Of course, it's extremely rare that anyone needs to actually debug the transport, rather than debugging their own application-layer protocol they've built on the transport. And because every server and client that speaks HTTP2 still also speaks HTTP1, every application-layer protocol flowing over these links can just be debugged using HTTP1 messages.
But even if you have that 1% use-case where you need to debug the transport, there are simple POSIX-pipeline-y tools to bijectively map the binary wire representation to a text-based one.
But again, when you hit that 1% of use-cases, you're probably a professional doing something weird, such that you probably want to pull out WireShark to analyze the complete nested app-in-HTTP2-in-TLS-in-TCP-in-IP-in-Ethernet packet capture in its original binary form.
And so, even though those bijective HTTP2-to-HTTP1 observability tools do exist, nobody thinks they do, because nobody talks about them, because everybody with the 1% use-case is likely solving a large-scope problem for which the simple UNIXy solution is "underpowered."
Systemd was such an improvement over the existing speghetti for folks selling / supporting linux that it was a pretty clear takeoff.
Flatpack seems a bit more focused than snaps. The usability issues with snaps kind of surprising given ubuntu has usually had a good user focus. One thing, Fedora has their silverblue / ostree type distribution initiative, which may reduce their use case for using things like flatpack for printer subsystems etc (snaps seem more flexible). I moved off linux desktop a year ago though so not at all current unfortunatly.
