You can't take a "standard" .rpm from the Fedora repositories and install it on CentOS. You can't take a .deb from Debian 11 and install it on Debian 10.

I mean, you can, if you also install its dependencies. And you may end up with a weird franken-system, but you can. You can even automate it and set preferred distros with pinning, it's how people run things like hybrid testing-unstable distros.

If I install software on MacOS or Windows, I don't have to care if it was packaged for an older version etc, or that my distro may not package a dependency.

It seems very much intentional. You could just keep multiple different, vulnerable versions around and keep everything working. Instead distros say "Nope. We support exactly one version. Update or die."

That is also why you have runtimes, grafting, support sunset,... . I agree that a different trade off makes much more sense for desktops. For servers though...

> distros don't have every library packaged.

Exactly. And for those that are packaged they say "these are the versions we support. If you want to us to do the support work, use these". Again for stuff like windows ltsc that means I install version X now and want this to be supported for the next 5 years. If I instead install a consumer version of windows it means X will be out if support by then and I am expected to have upgraded to X+1, X+2, X+3 during these 5 years.

Case in point, Firefox has multiple current versions: 102 ESR and 111. Both get regular updates and neither is "out of date".

Oh, not all libraries support that. They need to...

You will very likely bump into conflicts. Or you you need to upgrade a lot of fundational libraries (like libc), at which point why stay on Debian 10?

Backports exist for a reason.

Backports do indeed exist for a reason, I just felt like challenging “can’t”

If you're using a "Debian based" distribution, the "standard" .deb is the one shipping with Debian. If it doesn't work on the derivative distro, they are doing something wrong. Or like I said, maybe the dependencies are doing something wrong.

This is the problem that Flapak, Snap etc try and solve. I won't put AppImage onto that list because it actually doesn't solve the problem it just makes it worse.

I was under the impression that Debian already solved that problem by allowing you to deploy an older Debian version in a chroot with debootstrap? As long as the Linux kernel is binary compatible, that should work fine. Although I have to admit I don't use stale software that often, so I have little experience in that area.

The irony here is that we’re discussing flatpak/snap, which take the idea of static linking to the absolute extreme by doing something closer to a container where every dependency is part of the package. Maybe static linking being “against distro policy” is tossing the baby with the bath water by causing maintainers to reach to a much worse packaging method (snap) because the distro policy is just too obnoxious.

There’s no good reason you couldn’t just statically link (or relocatably copy) your dependencies into your .deb except the distro maintainers being purists. It would make the process of building a deb (or RPM or whatever) trivial because you’re using it as a dumb archive format for your build artifacts, similar to how a container works.

https://refspecs.linuxfoundation.org/lsb.shtml

These are, of course, not distro packages, but ISV packages and most RPM features cannot be used.

What things are can change, sometimes for the better. Imagine if distros maintainers could spend their time doing something more productive than doing the same work as hundreds of others are doing.

If a distro wants to include their application they have every right in the world to do so. So its up to them to do what ever is necessary to enhance their product with the freely available product of the unpaid developer who created it.

You build one flatpak and it will work for all distributions.

Packaging is not required for testing individual applications. That happens at build time and the developer writes the tests. These ate not distribution specific.

The separation of concerns is very clear. If a distribution doesn’t package the code then the user is left to build the application themselves. It’s impractical that a developer would build and maintain their own packages for every flavor of every distribution.

Instead, I think distros have to provide the base packages like desktop environments and related software. All configured for compatibility and complying with the distro philosophy.

But third party desktop applications that are not directly related to the desktop environment are a different category. There is an endless amount of them with varying quality and resources. You cannot expect distro maintainers to spend time on all these random applications.

However, if a third party app is not included in a distro, it does not mean users have to build the software by themselves. That is the problem that Flatpak and Snap and others are trying to solve. They provide sets of distro-agnostic libraries that developers can target instead of having to target each distro separately.

This way a developer can only package the app once, distro maintainers don't have to do extra work, and users can install applications without having to manually configure and build them. Everyone is happy.

Flatpak and friends are a pain in the ass to use and offer a shitty UX. Having a single point of contact and well understood mechanism for software management is a feature for users.

I don’t expect my distribution to have every software package ever. I do expect it to fulfill my needs. As long as there are applications in the repository that do what I need I am happy.

They solve problems that arch/pacman didn't start even thinking about. Like reliably updating an installation, that wasn't kept in a tight loop with the upstream repo.

> false dichotomy to say snap or flatpak are the only alternative

we are slowly moving into the world of immutable base systems, like fedora silverlight for example. The last thing you want is for a random app package to modify your base system. Separating system and apps is a good thing.

So they've decided to degrade the baseline UX because they want to optimize for people who don't keep their system up to date? As someone who has no problem keeping my system fresh, this isn't a use-case I want prioritized in my package manager.

> we are slowly moving into the world of immutable base systems, like fedora silverblue for example. The last thing you want is for a random app package to modify your base system. Separating system and apps is a good thing.

The "last thing I want" is a package manager that's invasive to use, doesn't have the latest software and is slow. Immutable systems can be a nightmare to actually use. Wrote your own software? Copying to /usr/local/bin is no longer an option, hope you like packaging up your one-off tool!

So, they decided that the update path is always defined, from any state to the latest, without having to update the packages in specific order, where some steps needed may disappear. You know, being robust.

If the year of linux desktop has to happen, not borking the system during updates is a requirement. You don't have a problem with daily updates? Congratulation, but your grandma probably has.

> mmutable systems can be a nightmare to actually use. Wrote your own software? Copying to /usr/local/bin is no longer an option, hope you like packaging up your one-off tool!

Immutable system does not prevent writable /usr/local/bin. Your one-off tool has no business messing with /usr/bin or /usr/lib.

Immutable systems are also minimal; they don't care about your additional software, as it is separated from the base system. You can update your software at any pace you want; nightlies if you want. It just cannot touch anything in /usr (with /usr/local being exception).

> Immutable system does not prevent writable /usr/local/bin.

I can't speak to the others, but Nix most definitely does not make /usr/local/bin writable. You have to package up your tools to use them.

So you have particularly skewed perspective; you should try a bit of operations, or at least devops, to normalize it.

> Arch perfectly suits my needs

Good for you. You just need to realize that you are minority. Do you notice that Arch is not the dominant distro? There's a reason for that.

> where as Flatpak/Snap... cause excruciating pain every time I'm forced to interact with them

You are holding it wrong ;)

> but Nix

Nix is not exactly a typical immutable system; it has strong opinions about many things, that other systems don't. You can't evaluate other systems through assuming they are like nix.

Nowadays, even MacOS is immutable and people live with it just fine.

I didn't say that you should use Arch on the server, but it's great for the desktop.

You can refer to this entire thread to see how well Flatpak/Snap... are working out. Pretty much universally reviled by developers (people who actually use Linux on the desktop).

And I said that apt/dnf solve problems that pacman didn't start thinking about yet. So we are in agreement here.

Flatpak seems to be working out pretty fine.

> Pretty much universally reviled by developers (people who actually use Linux on the desktop).

Two things:

1) Reviled by some very conservative types, often not willing to consider things from different perspective than what they are used to. If they would build the desktop, it would end up like Homer's dream car.

2) Don't you think that it is a problem when only developers use the desktop as it is? (Not really true, but let's consider that for the sake of argument).

I would consider my self non-conservative to the extreme, which is exactly why I don't like Snap since it's built out of fear of problems that I simply don't have. I want the latest versions of any given piece of software and I want my package manager to be performant. I don't think those are conservative values.

> 2) Don't you think that it is a problem when only developers use the desktop as it is? (Not really true, but let's consider that for the sake of argument).

I don't think developers having a great computing environment is a problem at all, quite the opposite. I think it's very desirable and I think efforts that hamper that for the mythical "grandma" are indicative of the core UX problems that plauge the "desktop linux" community.

For the base system and libraries, yes. But why should the distro maintainers be burdened with additional work for every possible enduser application out there? If I write a GTK app and want to make it available for Ubuntu/Debian users through official repositories, I need to make sure it gets added to the official package list, and every time I make a new release, someone else somewhere else has to do additional work just to repackage the application so it is available in the repository.

Maybe a far-fetched analogy, but imagine if browser maintainers have to perform additional work every time a new website launches before it is available to its users.

Also, in this system, the application developer has a lot of extra work for making the application run and build against older versions of its dependencies. If I want to make my app available for Ubuntu 22.04 LTS which has libadwaita 1.1, I cannot use any of the new widgets in libadwaita 1.2 (released 6 months ago) or 1.3 (released earlier this month). I can use those widgets but I'll have to write ifdefs and provide fallback behavior/widgets when building/running against these older versions. I will also have to manually track the various distro versions to detect when I can remove the fallbacks from my codebase.

This is what Flatpak is for. Using Flatpak I can target a specific GNOME SDK version and make use of all the new code immediately, without having to write fallbacks. The downside is that when a user downloads my application through Flathub or another Flatpak repository, it might have to download the additional libraries as well, but they will be the correct versions and they won't be downloaded if that SDK is already available due to other Flatpak applications already installed.

Essentially, something like Flatpak is a middle-ground solution that trades of some disk space for the benefit of less work for distro maintainers (so they can focus on core packages) and less work for application developers (that can use more recent dependency versions and don't have to worry about the versions in other distro's)

Yes, and that's a good thing for a whole bunch of reasons.

If you don't want to leave it up to the distro maintainers, nothing's stopping you from standing up your own repo to distribute your software to a particular distro. It's a one-liner for users to add your repo to their list so they can use their package manager to install and update your software as usual.

> Essentially, something like Flatpak is a middle-ground solution

Yes, I get that it's convenient for maintainers. But it kinda sucks for users (at least for me), which is why I avoid using software packaged that way.

I'll give flatpack this much credit, though -- it's not a nightmare like snaps are.

My browser, mail client, rss reader, music player, video player, image viewer, steam, ... all have been working incredibly well as Flatpaks. I also get free sandboxing for all of them, so for example Steam and its games, don't have access to my ssh and gpg keys or documents.

The only applications which don't work that well with Flatpak are things like my IDE or file manager.

Yeah but that the worst part of what they ARE and if they didn't have to spend so much time doing that maybe they could do more innovative things.