Both flatpaks and snaps have been reasonably successful in distributing software in a cross distro way. Once apps reach any of these technologies they don't need to be in any specific distro repo. Snaps, for example, can update automatically silently in the background and it has been used at least by VSCode to bring updates to users.
Also consider that "stores" like ms/windows store, apple's app store, steam, google play store... are all mere glorified package managers which can update packages. Most used operating systems' these days offer such functionality. And yes, time has proven they are practical.
Package managers aren't designed with this in mind. They're from an old-school development/operations model which doesn't necessarily fit with modern best practices (where app devs are expected to own more of the product lifecycle).
For example, say Firefox is the only package you want to automatically update itself (because I do want those updates), via the package manager. AFAIK, there is no simple generic UI to configure this. You have to be a computer nerd that's familiar with shell scripting and consoles to configure such functionality, or hope that your one package manager has a UI that's both friendly and functional enough to easily configure this. Versus Firefox doing it itself, which is more user-friendly.
On top of that, if you have to wait for a package update, this means new security fixes + functionality have to wait for all distributions to update their packages and push updates, and then for users to adopt the updates. If you need to patch a 0day, it's much faster to simply push the update to the users. And new functionality can be tested and rolled out much faster if you don't have to wait for all systems to get an updated package. One of the most annoying things about Debian is how old their software is, unless you're on -testing, where you basically expect your system to break often.
> Package managers aren't designed with this in mind. They're from an old-school development/operations model which doesn't necessarily fit with modern best practices (where app devs are expected to own more of the product lifecycle).
Package managers were designed with update in mind. Which apt version has no "apt update"?
>For example, say Firefox is the only package you want to automatically update itself (because I do want those updates), via the package manager. AFAIK, there is no simple generic UI to configure this. You have to be a computer nerd that's familiar with shell scripting and consoles to configure such functionality, or hope that your one package manager has a UI that's both friendly and functional enough to easily configure this. Versus Firefox doing it itself, which is more user-friendly.
Gnome software allows me to update a single package. It comes installed by default on most current major linux distros. It has a very simple and intuitive UI.
>On top of that, if you have to wait for a package update, this means new security fixes + functionality have to wait for all distributions to update their packages and push updates, and then for users to adopt the updates. If you need to patch a 0day, it's much faster to simply push the update to the users. And new functionality can be tested and rolled out much faster if you don't have to wait for all systems to get an updated package. One of the most annoying things about Debian is how old their software is, unless you're on -testing, where you basically expect your system to break often.
Not if you're using flatpaks or snaps. Even if you are only using your distros' repos, Ubuntu is now maintained for a reasonably long time, 0days on a browser will reach you very soon. It is nowhere near as long as microsoft does with windows support, but long enough that at least 2 other LTS releases are available before support is dropped.
It seems, from your comment, that you have not used any linux desktop distro for a long time.