Gah, how I hate Flatpak.

It insists on downloading all the packages I already have installed on my base system anyway, plus insists on installing stuff into the root partition instead into my home diretory.

All sorts of utterly annoying and otherwise avoidable frustrations ensue.

Flatpak and Snap should both just DIAF.

@rysiek There's a flavour of argument over packaging systems and formats which runs:

X package format is difficult for software developers to use.
Y package format is easy for software developers to use.
Therefore Y package format is better than X.

What's not realised is that the fundamental value and benefit to package management is to systems administrators / owners / users, and integrated distributions of packages. And that the major costs of operation and maintenance are not installation, but *operations and maintenance.

"Easy for sofware developers" typically translates to "encourages sloppy and difficult-to-maintain processes and practices". Not only this, but by lowering up-front costs at the expense of long-term costs, the practice further encourages poor practices (from an O&M perspective), and puts well-behaved software at a disadvantage.

See the Debian Project's explicit focus on user benefit, a long-term value benefit.

This is a Jevons Paradox / Gresham's Law crowding out of well-behaved software and a race-to-the-bottom of poor long-term O&M behaviour.

#Linux #PackageManagement #OperationsAndMaintenance #JevonsParadox #GreshamsLaw #Flatpak #snap

@dredmorbius @rysiek Well behaved software is not at a disadvantage with Flatpak. If software is easy to package in conventional distro package managers, it is easy to package in Flatpak.

@be @dredmorbius If software is easy to package in conventional distro package managers, Flatpak is unnecessary.

@rysiek @dredmorbius It's still helpful for people who choose to run out of date operating systems for whatever reason.

@be, @rysiek and @dredmorbius, I'm pretty sure machines running Debian stable don't need new and shiny software at all. I don't use it for development, but it's installed on all the old stuff I throw around the house and the only thing I need them to do is not breaking every now and then. For software not available in Debian's repo I take full responsibility and install them from source. Even when I'm nowhere near being a professional sysadmin, I have standards and Flatpak and Snap are instantly disqualified for anything I need a mental model of.

@cnx @rysiek @dredmorbius Oh hey, here's a Ubuntu LTS user asking how to install experimental, undocumented new software:

@be @cnx @dredmorbius yes, getting packaging right is hard. Yes, the problem of balancing stability vs. freshness is hard.

But that user chose LTS for a reason. If that reason doesn't hold anymore, one can always move to a fresher version of Ubuntu, for example.

Flatpak and snap are not solutions here, they are hacky work-arounds. In the long run they will, IMVHO, cause more problems than they solve. For one, because they break basic assumptions about how software is installed and run on a given system.

@rysiek @cnx @dredmorbius @cnx @rysiek @dredmorbius People do this all the time. Sure maintainers could say, well, you're choosing to run an out of date OS -- with package maintainers that don't respond to us when we tell them about releases -- deal with it or build from source. The reality is then most of them would ask for support for old versions, resulting in annoying questions about bugs that have already been fixed, not change their distro.

@be @cnx @dredmorbius yeah, but that doesn't solve the problem, it makes it worse!

Now the user has multiple different versions of the same library installed, and debugging which one got loaded at any given time is going to be hell. Especially with a non-techie user, which seems to be *the* target group for flatpak/snap.

Basically, it means the few important assumptions one could make about a given system just fly out the window.

@rysiek @be @cnx @dredmorbius

Now the user has multiple different versions of the same library installed, and debugging which one got loaded at any given time is going to be hell.

You haven’t debugged with flatpak, I see. You just install the debug symbols for the SDK and the app with a simple flatpak install, run gdb within the app sandbox, and then remove the debug symbols when you’re done. The multiple versions of the libraries don’t conflict with each other at all. And you always know what library you’re using: either the version in the SDK you use, or the one the developer has explicitly in their flatpak manifest.

@rysiek @be @cnx @dredmorbius If anything, it’s more difficult as a developer when you don’t know what version of a library the user has on their distro. Their distro could be shipping a bugged version, a version with patches that are causing problems, or the library could have changed ABI and the distro didn’t (or couldn’t) rebuild your app to account for it - which has happened on an app I’ve contributed to.

@brainblasted @rysiek @cnx @dredmorbius IME the biggest issue with library versions is users who choose to use outdated operating systems continuing to be affected by bugs in libraries that have already been fixed and released.

@be, please see Debian wiki for the counter argument if you haven’t already. As a developer, you can simply urge whoever reached you upstream to not attempt to use your software with Debian stable, or wait until the next release when your software is packaged downstream.

It’s also worth mentioning that via Debian’s policy users are not supposed to file bugs to upstream but report to the distro’s mailing list instead. Don’t try to take too many responsibilities, it’s not your job to warrant the end-users’ experience.

Cc: @brainblasted, @rysiek and @dredmorbius

@cnx @rysiek @brainblasted @dredmorbius Debian can say that all they want, but it doesn't change that lots and lots of people want to run software on old OSes.


@be @cnx @brainblasted @dredmorbius I wonder if that's somehow related to the stability of those "old OSes", which in turn comes at a price of them moving slower than the break-neck pace of the "move fast and break things" tech industry? :thaenkin:

Anyway, that a fun discussion and you guys should continue having it, but please untag me. Thanks.

· · Web · 0 · 0 · 2
Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!