Response to “Developers are lazy, thus Flatpak” | Hacker News Reader

Response to “Developers are lazy, thus Flatpak”

theevilskeleton.gitlab.io

48 pointsjcastro85 comments

> Even with an unusual amount of runtimes and apps, Flatpak somehow manages to use 37.73 GB, even with most browsers installed as a flatpak.

That's a lot. Complete operating systems with similar amount of applications installed can take a fraction of that. That's larger than / partition on my PC used to be not that long ago (until I stopped splitting /home out altogether).

My phone has a 32 GB eMMC. I have just a handful of small Flatpak apps installed on it and Flatpak already takes more disk space than the whole fresh OS did there. The thing is that it mostly scales not with number of apps, but with number of runtimes installed - and you only need a single app to still be on an outdated runtime to make it keep excessive space.

My relatively fresh macbook pro is sitting at a little over 100GB with just a few apps installed (I'm not even using it fulltime yet because not everything is installed). That includes 25GB in the Library directory in my homedir.

On my primary work macbook (which ONLY contains work apps and software dev, nothing else), I'm hitting against the 1TB SSD and have to delete caches to get space back from time to time. The Library directory is currently a whopping 220GB (just checked with du) and I have no idea why.

Windows was a similar experience before I replaced it with a Debian + Steam install.

37GB for an extreme case of 173 large GUI apps built to 97 different runtimes on a system where I can get the latest and greatest version (or older version) of the app without being hobbled by dependency hell seems like a steal by comparison.

I don’t know how you work but in our company (~ 100 people) everybody has a Mac and literally no one has a 1TB drive and no one has issues with hard drive space either (including devs).

Furthermore the Library folder contains application’s data, not applications…

Yup, I was expecting this kind of nit-picking. Bottom line is that 37gb for such an extreme number of apps and runtimes is actually pretty small, and thus Flatpak is doing a decent job (especially compared to everyone else but the fringe systems that regular users don't want).

You can't get to the bottom line of app size from the top line of app data and cache size, clear that fog away to see that the job isn't decent

For what it’s worth, Macs can reboot to previous versions and has many features linux desktops don’t out of the box.

Though I would be interested in a deduplicated nix store of the same number of apps — which is still the best solution imo.

Not sure what you mean by "reboot to previous versions". My macbook can only boot Ventura after upgrading. If I wanted to boot Monterey, I'd have to wipe the drive and reinstall from scratch (or restore from backup). Also, every system has features that other systems don't have out of the box.

The extreme 37gb example is already deduplicated and compressed (from over 100gb of data). Plus it doesn't require learning the user-unfriendly nix (which is absolutely necessary for debugging when things break).

That's unacceptable, it's Windows levels of bloat.

Of course, Windows does something similar to maintain backwards compatibility with apps going all the way back to Windows 3.1, and does so pretty efficiently all things considered. Flatpack seems anything but efficient.

To be fair, the author of the article states that 173 graphical applications take up that much space, not just a handful of browsers. I think gp misses the point the author is trying to make, that over 100 apps takes up less space than expected.

That's not a huge number of applications at all, unless we're talking about asset-heavy things like games. It would usually take about 10 GB or so complete with the whole operating system.

> It would usually take about 10 GB or so complete with the whole operating system.

So it takes around 3.7x the size it should? That's not unusual given that it isolates all dependencies.

It's not unusual, but it's still bad

It's a lot, but I think we've lost that battle and society has collectively decided it's okay to sacrifice untold amounts of storage space in service of things like more stable installations, extra features, etc. It's aesthetically displeasing to install a 10 GB text editor or whatever but I don't think it's generally ideal in application development to optimize for very limited storage on phones either, especially with phone storage presumably just growing bigger over time too.

But this is not the general battlefield, but a Linux niche one, where the sub-society hasn't collectively made a decision yet

That's fair. I figure a lot of the same design pressures apply though, and of course there's a cost to diverging from what the rest of the world is doing.

I have plenty of stuff installed via Flatpak, size is not as nearly as much.

    flatpak list --columns=ref,size

I have 64 apps installed which takes 11GB. And I have Steam with proton and app that uses texlive which combined are more than a GB in size and to my knowledge same on distros. Since OP is a dev for front end for wine which is shipped as flatpak, likely a lot big apps.

It really isn't a lot. Why would you bring up a phone when I don't know of any phones that use flatpaks (or snaps) except very edge case ubuntu experimental phone distros?

Because I use it on my phone?

These days it's often being used on phone distros that have nothing to do with Ubuntu (PureOS, Mobian, postmarketOS, Fedora, Arch...). I have like six or seven apps installed via Flatpak, and about a hundred via regular repos. I'm glad Flatpak exists as it enables some use cases that wouldn't be possible otherwise, but let's not pretend that its disk usage is not a PITA (the way it handles updates is super annoying too, you never know how much free space you actually need to have available for it to succeed).

>My phone has a 32 GB eMMC

And each app has its own copy of any dependency it uses and apps are isolated from each other.

No, most apps come from apt repository and therefore use shared dependencies. I wouldn't mention using Flatpak on my phone if I used Android there.

Games these days are easily 100GB alone. So 37GB is still well within current hardware capabilities.

>I imagine that most users have a small selection of apps installed, which only come with a few runtimes and a version apart, which also means that my setup is possibly one of the worst case scenarios

This seems backwards. The more apps you install, the more likely it is that it will reuse a runtime or otherwise that you already have installed, and hence the less space it is likely to take up.

The traditional approach forces all packages to make do with one version of a library, whereas the flatpak approach encourages them to ignore what other apps in the ecosystem use. The flatpak approach will definitely cause severe bloat in the amount of space used on the system.

> The traditional approach forces all packages to make do with one version of a library,

Yeah, and that means a bunch of them don't work properly. It's unrealistic to expect app developers to support that one version that each particular distro ships.

In general, as long as the major version of a library matches up (possibly with some minimum required minor version), you can use any version of the dependency. So if a developer says "this requires at least GTK 3.16", it should run just fine with GTK 3.24.37. Yes, I know, there are exceptions. Sometimes library authors don't follow established best practices and break ABI (or, more subtly, behavior) without a major version bump. But that's the exception, not the rule.

Ultimately it's up to distro packagers to make sure the API/ABI lines up properly for dependencies. Of course many of them do not go any further than that, so an app that compiles, links, and starts up may have other issues the packager didn't catch.

Yeah, in general, things work out nicely. :) I figure this genre of post and the post it's responding to are mostly about exceptions.

My impression is that exceptions become more and more prevalent as (app?) development practices diverge from the workflow that distros have spent decades optimizing their processes for (ie., apps are developed with package managers that don't map well to distro packaging).

Nobody expects app developers to do that, because app developers aren’t distro maintainers. This is addressed in the post that TFA is responding to.

I'm responding to a comment that expects app developers to make do with a specific version of a library. That expectation seems to be in line with that in the post that TFA responds to, which is unsurprisingly addressed in TFA.

There's a lot of "it's not that hard"s in that post. Of course we all prefer software that just works after being installed with the distro package manager. I don't want to install a container runtime to run grep or netcat or whatever. Meanwhile app developers have to balance their own priorities, it gets complicated, and, I guess increasingly often, "ship X feature to Flatpak users" wins over "make the lives of users/maintainers of Fedora easier". It's just another tradeoff, and sometimes the cost of making do with one version of a library isn't worth it.

At one point we have had to maintain support for 3 different versions of libpng in an application we were working on - just to make it work on 3 different popular distros. (Ubuntu via PPA, Arch via AUR, OpenSuse iirc).

For the popular applications, it maybe that distro maintainers send you the pull request. But for small time applications, all you get are bug reports that the application is crashing on X distro, fix it.

We ended up moving to AppImages to not deal with all these headaches anymore.

Distros themselves run on very few volunteers. So it's usually a painful process to even get your application packaged into distros like Debian etc .. when dealing with public domain libraries that aren't available in their repositories but you aren't allowed to statically link to them.

This sounds susp. Why was there not a common denominator for libpng? Were you using some cutting edge features that weren't back ported?

I think we were using libpng 1.2 because some distros weren't packaging 1.5. Then we decided to move to 1.5 and not care for distros without 1.2.

https://github.com/vovoid/vsxu/search?q=libpng&type=commits

I remember there were some undefined reference errors too that were causing these issues across distros..

But why couldn't you just use 1.2, is the question?

I've been bit by this style thing plenty of times. Just recently, I started a python project and used 3.11, only to realize I was targeting AWS Lambda and at the time 3.9 was the best they offered. I could have tried maintaining two versions and worked around that, or I could change completely to 3.9. (Now 3.10)

Did I lose on some things? Yeah, the switch stuff, in particular. That said, it was far preferable to a complicated build chain that tried to support both.

It was a decade ago, so my memory is a little fuzzy on this.. but that's one of the commits I shared above. Trying to force it to use 1.2. But there was a Gentoo user who ran into issues with that and i had to revert it.

But you do see the problem right? How distros end up creating this weird situation of certain libraries not being available in certain places. They won't even let you statically link your program to those libraries to it into their repositories. It was easier to just give up.

This isn't really a "distros" problem as it is a "dependencies are hard" one. Having many targets for deployment makes it visible, but just look at the complexity of targeting all browsers to see how it is dealt with for ostensibly simpler requirements.

I imagine at some point people were like "is it more work to investigate this (and similar future questions) or switch to shipping AppImages instead". :(

> This seems backwards.

It really depends doesn't it? If there's a small amount of deps then it's likely but at an infinite amount of possible deps it's clearly unlikely. The reality would depend on the ecosystem but my guess is that there's a lot less overlap than one would hope.

The traditional approach makes upgrading a runtime much harder, as everything depends on it.

Whereas the flatpak approach allows any application to define a new runtime version without affecting other applications.

The downside here is increased storage, but I think it’s well worth the stability gains

> The traditional approach makes upgrading a runtime much harder, as everything depends on it

Or just get a package manager that actually solves the problem and can handle multiple versions of every package. Then you get good deduplication, and can still use whatever you wish. Nix and guix are like this.

Isn’t that what flatpak does though? Pretty sure it shares runtimes if they are the same version right?

> Separating every dependency would be really inconvenient, just like managing graphical apps in a Linux distribution. If, for example, a flatpak named XYZ needs 10 dependencies, whereby one of the dependencies changes the version that the developers of the XYZ flatpak have not tested, then it could lead to bugs or even breakages that would make it really difficult for developers to trace back, as they would need to frequently contact each packager and figure out together. So, as mentioned by the author, the solution is to let the developers bundle everything, as they test their apps against an environment that is easier to understand.

So why not just statically link at this point?

> So why not just statically link at this point?

In many cases, you just can't. Other than glibc having issues with static linking, you can't use `dlopen` in a static binary.

For example, if you're building an application which can use OpenCL, you need to dynamically link to the ICD installed on the system. And because `dlopen` doesn't work in a static application, you're stuck with dynamic linking the whole application (or at least with libc). On the other hand, Windows has no issue with `LoadLibrary` in a static binary...

I don't know enough about GUI applications, but I wouldn't be surprised if anything needing graphical output is in a similar boat.

The cherry on top is that glibc doesn't make it easy for an application to be built for an older version of the library. As Linus Torvalds can attest to [https://www.youtube.com/watch?v=Pzl1B7nB9Kc] building for Linux sucks.

You can statically link at least GTK applications (less sure about Qt, never tried), but many build systems don't support it very well and it requires some amount of hackery.

The best trade-off is probably "link against libc, statically link everything else". That gives you dlopen() and some security benefits. But again, build systems don't support it very well out of the box.

I think the outright hostility against static linking has been unfortunate, because now we have a whole bunch of "static linking, but with extra steps" systems to work around it. Dynamic linking is fine for many things, but it's obviously not always the best solution.

It's disappointing that essentially nothing really improved in the 10 years since Linus gave that talk. Okay, there's flatpak and appimage and snap which are an "improvement" of sorts, but it's all pretty complex and half the time when I wanted to run one it didn't work well.

It'd be neat if we could build binaries capable of both static and dynamic linking. Everything would be baked in statically, but you'd have the ability to override static links with system dynamic links at application launch.

I'd like to be able to patch SSL bugs without downloading a whole new binary for everything that depends on it. But at the same time, I probably couldn't care less about other dependencies, and I don't want to sort out version mismatches and deal with system libraries in most cases.

Ideally the operating system itself could help manage this. Know what deps I care to handle myself or override.

> It'd be neat if we could build binaries capable of both static and dynamic linking. Everything would be baked in statically, but you'd have the ability to override static links with system dynamic links at application launch.

SDL works like that: https://github.com/libsdl-org/SDL/blob/main/docs/README-dyna...

One main reason is licensing. Lots of good, basic libraries are lgpl. Like Qt etc...

Also you'd want the basic libraries like glibc, ssl to be provided as shared libraries by the distros for various reasons - including security.

That being said i do appreciate how newer languages like rust, go default to static linking.

> One main reason is licensing. Lots of good, basic libraries are lgpl.

While this might be a little more annoying, you can absolutely statically link a proprietary application with an LGPL library. You do need to provide object files for the proprietary bits so someone could relink it with a different/modified version of the LGPL library, though. Which, yes, is annoying to the point that if I were distributing a proprietary application, I probably would use dynamic linking with the LGPL bits.

There's still some reuse between flatpak apps, and not everything one might depend on necessarily is of the shape of a statically linkable library.

>> That’s completely fair, as you’re entitled to your own opinion. Likewise, I don’t trust the worryingly large amount of non-programmers/developers that package dependencies in larger distributions, especially when they have no real world experience in developing apps.

Sadly I have to agree with this. How many "package maintiners" are just wannabe developers that are just doing a bullshit job. Sure they can edit a .deb or .rpm when someone tells them what needs to be fixed, but they couldn't build an app and create the package in the first place.

Another problem is that library devs don't always maintain compatibility. If you're changing a minor version number you should not break any apps using you lib. Full stop, don't tell me your sob story - you are someone's infrastructure and need to act like it.

Fedora (my fave) should ship the latest gtk3 and gtk4 and no app should have to depend on a specific minor version - 3.12 or later is reasonable if the distro is tracking the latest for example.

There's plenty of responsibility here for app developers, library developers, and packagers. If they would all do their job there would be no problem. The real issue is that nobody is perfect, nor has infinite time, so we keep trying to delegate. Modern software development and deployment is at the edge of human capability. I'm not sure what the solution is, but complex dependency management (npm) is not the answer.

Really, the lack of a stable base platform is what ultimately kills Linux as a commercial deployment platform.

You can’t install a “Fedora 38 SDK” or an “Ubuntu 2023.04 SDK” and reliably build software that will be binary-compatible from that point forward—much less use a mechanism like Deployment Target on Apple’s platforms or whatever Android calls the same concept (API version?) to build binaries that can run across a range of distro releases and use features from newer distros when running on them but gracefully handle the case where they’re not available.

Hence commercial software will target something like RHEL or an LTS release and many users will ultimately wind up running that software in a VM anyway as time goes on and binary compatibility isn’t maintained.

Flatpak and snap are both just admissions of failure when it comes to this stuff. It’s been straightforward to build platforms this way for multiple decades now, just do it already.

> Sadly I have to agree with this. How many "package maintiners" are just wannabe developers that are just doing a bullshit job.

I'd be a little more charitable.

"Package maintainers are overworked, thus Flatpak."

Flatpak is not an improvement on any technical axis. It's going to bloat your disk usage. Your apps are going to have slight inconsistencies as app developers are going to lock to a specific version of Gtk/Qt/etc. and never move. I can go on and on.

However, that's not the point. The point is that package maintenance is work that nobody is willing to do or to pay for. At the end of the day, there simply is no choice other than shoving this back at the app developers.

> The point is that package maintenance is work that nobody is willing to do or to pay for.

It's also work that shouldn't have to exist in the first place. Same application being packaged in different formats - rpms, debs, tarballs and what not -, linked against different set of libraries - so that end users can unpack and run the application developers develop.

I know I'm simplifying the issue, but when you step back and look at the issue of how much time, energy and money goes into maintaining packages of the same software for different versions of different distributions, makes you wonder how we got into such a situation.

I remember having to update whole Ubuntu version to get a newer version of an application I wanted to use.

I take issue with calling them wannabe developers. Especially as the number one way to tank a project at a job is to make yet another way to distribute it. Many companies would do well to have a package maintainer position.

>> I take issue with calling them wannabe developers.

I did say "how many... ?" Certainly not all, but I once did a fresh Fedora install once, and the latest version of something didn't work. Not at all. I managed to do some searching, tracked down the root problem (in a dependency) and found a workaround, posted that to the IRC, and a while later the package was updated. The workaround was something like passing an option in the launcher - no "code" or rebuilding.

> If you're changing a minor version number you should not break any apps using you lib

That has never been a thing. There are plenty of software where even fixing a bug is compatibility breaking.

Just make the package manager in a way that it can handle any number/kind of different versions.

>> That has never been a thing.

See Windows. See MacOS.

>I’m not really sure who denies that Flatpak is a distribution, but I’m certainly not one of them. If anything, this seems to be a really good thing to me, because we’re bundling a distribution and deploying it to users’ systems

One difference between the "Flatpak distro" and traditional distros is that the latter's modularity improves accountability. For instance, if I encounter a bug with a Fedora or Red Hat RPM, I can file an issue in Red Hat Bugzilla for that component, each package has an owner whose job includes handle those bug reports just for that package and forward them upstream if necessary. If I wish, I can even install the corresponding debuginfo packages and step through a debugger myself.

Since Flatpak runtimes are monoliths, every bug is a problem with the entire runtime. It's not clear who is responsible for what part. Is there a centralized bugtracker for each runtime?

Also, compared to the "Flatpak distro" traditional distros have more clearly articulated maintenance policies. I know for how long a Fedora RPM or Ubuntu deb will get updates, and I trust the Ubuntu and Fedora maintainers to keep on top of the latest security patches. What level of maintenance does a Flatpak runtime receive?

Meanwhile, you can have the best of both worlds using Nix. Tons of things are packaged already, and for the most part dependences are shared across many different packages. But if a package needs a special version of a dependency, thats no big deal.

Does nix have any version of XDG portals for allowing programs to open file pickers without seeing the contents?

This seems like the killer feature of flatpak.

Why should sandboxing be part of package management? We should absolutely need sandboxes as non-android linux’s security is criminal, but that’s a separate issue in my opinion.

That’s how every other OS does it so it doesn’t seem like such a wild idea to me. Where else should it go?

No, the actual sandboxing is not part of the package managers

XDG portals are just APIs that applications can implement and use.

Regardless, do you not trust the applications that you run natively?

I don't assume that applications are inherently hostile, but I do not trust that the developer of every application I use to open untrusted input is sufficiently security conscious to prevent those applications from being subverted.

I mean I trust Firefox to not steal my data, or maybe $APP_NAME, but do I trust the C++ code? Or maybe it's an app that's been pwned a lot.

Sandboxing has uses other than running actively hostile apps (for which I'd argue this kind of sandboxing isn't enough).

No, I absolutely do not trust the applications I run natively. I trust the hardware, the OS, and the sandboxing layer. Mostly because I have to. I absolutely do not trust Spotify or Steam with my personal documents

I generally trust the applications that I run natively to not be malicious, but I don't always trust them to not step on each other's toes, or make a well-intentioned mess of things.

A “good” pdf reader only needs a bug and a bad pdf file.

https://github.com/nixpak/nixpak

The readme isn’t super clear how you use this. Is there some way I can for example use this to install Spotify with no file system, microphone, and camera access?

nix doesn't help you with containing each program last I heard. I've been waiting to hear about any work on one. It'd be really cool if nix package definitions also let you define defaults for containment per program.

No, it doesn't. I meant the best of both worlds w.r.t. packaging and distribution (which seemed to be the focus of the article), not sandboxing.

Yeah, until you're trying to install something that uses OpenGL. :)

Flatpaks also run fine on NixOS! So you don't even miss out.

If your entire system uses Flatpak it can probably reuse a lot of stuff. Flatpak-as-a-distro is bound to work well, just like any normal distro does.

However, I only run Flatpak applications when there are no better ways to run software.

$ ./flatpak-dedup-checker Directories: /var/lib/flatpak/{runtime,app} Size without deduplication: 13.82 GB Size with deduplication: 9.74 GB (70% of 13.82 GB)

$ flatpak list --app | wc -l 16

10GB for 16 applications is a lot. Electron applications seem to be the worst offenders here, I'm not seeing any runtime sharing between them and they're all hundreds of megabytes in size.

If flatpak is acceptable, then distributing statically linked binaries should be acceptable, too.

As ever, I wish I lived in the world the distro packagers are packaging software for, but in practice, I frequently do want to use the apps that make the distro packagers throw up their hands and go "we can't ship it like that".

Recent and related:

Developers are lazy, thus Flatpak - https://news.ycombinator.com/item?id=36185498 - June 2023 (18 comments)

Flatpak is OK until you realize that you’re installing multiple copies of pretty fat dependencies with each app. That is a huge problem (never mind that storage is cheap, it’s not _that_ cheap) when your apps take up twice as much as your OS, and the reason why I still prefer RPMs or .debs for most installs.

My main laptop uses Linux Mint. I've had to install flatpaks instead of the shipped .deb versions twice: once for imagemagick because the distros version is older and doesnt support some specific flag/function and the other LibreOffice for a similar reason.

I do software dev for a living. But as a desktop user, nowadays I couldn't care less for the circus and crazy things my OS does in the background. I just want functionality and things to work. I've also got terabytes of disk, MBps of bandwidth and 32GB of ram, so I dont really care if a library is repeated 50 times in my OS. I just want shit to work.

Flatpak, AppImage or .deb, I dont really care as long as I can achieve what I need to do.

And yes, I'm a developer and am generally lazy. That's why I love doing automation

Packaging for rpm or deb based distributions is a hassle. Arch’s makepkg especially and to some degree nix in comparison are incredibly easy most of the time.

I still can never remember all the idiotic debhelper commands and the linter has strong ideas on how to do something.

I can’t by any means point at a url or git repo, specify a hash, and add some minimal steps and dependencies followed by a single command. That just doesn’t exist for rpm or deb, or if it does it’s very difficult to find good information on it.

Nix goes even a step further and ensures the packaging works in a nice clean environment ensuring you didn’t mistakenly use something else installed but unlisted.

Frankly I’d be surprised if flatpak or anything else is ever as easy as arch’s makepkg .

makepkg is simple, but at a cost of not being nearly comparable to rpms or debs which handle a lot of stuff makepkg simply does not. With a proper deb you can do partial updates and won't end up in a state where you can't run an application because it's trying to use older ABI-incompatible versions of libraries than the ones you have presently installed. On Arch, it's very common - you're always expected to update the whole system in sync, and if you install a thing without updating the whole system first things will often go wrong. debs are complex because they're solving complex issues which makepkg does not even try to solve, otherwise it wouldn't be as easy.

That is the main reason why I only package my app for Arch and nothing else. I tried for ever to create deb packages until I just gave up and package for Arch + do a AppImage (which I also dislike a lot).

I'll be the first to say I prefer distribution packages to flatpaks in most cases but I understand why an author would choose to pick that as the distribution method (or docker or snap). I think it's great to have options for users and authors, but users can't expect authors to bow down every time they have a request. Let your voice be heard but be respectful rather than being toddler angry like so many blogs these days seem to be.

Flatpak bit me with how support for canon raw files requires special tricks. I never really figured them out, either. :(

Frankly, I just don't think Flatpak (and its ilk) is worth it for getting exact dependency versions. If you're stuck using any dependencies that suck at following semver, and change API/ABI/behavior in breaking ways, you should probably just vendor it with your app and link statically. This can be a part of your normal build process, so users building from source can get a working build, and you can also reasonably easily distribute binaries if you want to (though you'll probably want to use one of those glibc header tricks so you don't require a brand-new glibc version).

I could see some app developers liking Flatpak as a way to self-publish a new app (in order to gain some users) before distro packagers pick it up. I don't think I'd ever do that; I'd just wait for distros if they think it's worthwhile, but I can understand why some developers could find it useful.

The thing is, after reading this article, as well as the article it's responding to, I find that I largely agree with both of them. Software distribution and packaging on Linux is a huge mess, especially if you want to distribute binaries that make it easy for users to simply download your app from your website and run it. Flatpak does seem to do a decent job of solving that problem, though it creates other problems, and tries to do other things (like sandboxing) that it doesn't do particularly well. But at the same time, if you end up with a reasonably successful open source project (ignoring the chicken-and-egg problem there), you can rely on popular distros to package your app for you, and you just don't have to worry about it.

I think Flatpak could provide two main (potential) benefits:

1. Sandboxing and isolation. I agree that even distro packagers mostly don't do any kind of security auditing. They get an app building, running, and maybe do a few basic things with it to ensure that it at least vaguely works. Of course, as the author points out, many Flatpak apps are intentionally allowed to break out of the sandbox, and this fact is very poorly communicated to users.

2. Proprietary software distribution. Vendors won't package for 20 different distros; on average you get an RPM, a DEB, and maybe a tarball with an install script that does who knows what to your system. And hopefully they built it on an old-enough distro so it doesn't unintentionally depend on this month's release of glibc. And then hopefully it doesn't depend on libraries that are so old and obsolete that most distros don't ship them anymore. Flatpak gives vendors one thing to target that will run anywhere, and while I avoid proprietary software as much as possible, there's value there.

For my part, I keep Flatpak and Snap off my system; if an app is only available that way, I'll find a different app.

Reply on news.ycombinator.com