Go on and keep using your distro another few years, and you’ll recognize the patterns of what keeps breaking. And then try some others for some years, and you’ll find that you can at most pick between smaller issues on a regular base on rolling ones, or larger batches of issues on release based ones. And some point you’ll find that every user creating a custom mix of packages that are all interdependent on another is quite the mess, and the number of package combinations times the number of configuration option combinations is so large that you can guarantee some of them will have issues. On top you have package managers rumaging around in the system while it is in use, and with a mix of old code that is still loaded in ram and new code on disk behaviour for these transients is basically undefinded. Ultimately you’ll grow tired of this scheme at some point, and then running a byte-to-byte copy of something that has been tested and doing atomic updates is quite attractive. And putting a stronger focus on containerized applications not only enables immutable distros for broad adoption in the first place, but also cuts down the combinatorial complexity of the OS. And lastly, to be honest, after so many years of the same kinds of issues over and over again, the advent of immutable+atomic distros + containerized desktop apps brought a couple of new challenges that are more interesting for the time being…

Nothing is bug free, but that doesn’t mean everything is sort of the same just different flavor.

The last couple days I dealt with Windows, which is out of the ordinary for me. I had to build a little thing and chose PowerShell and that is quirky but ok at a glance. Now we are in 2025 and PowerShell is a modern thing, and kid you not you install a thing using Module-Install and then you uninstall it using Module-Uninstall and what happens? The thing is only gone partially and some broken remains stay. And then another curiosity comes up where after long rummaging it turns out that one user (Admin) simply cannot see another user’s mounted share - has microsoft ever heard of the concept of “permission denied”?

That’s not a differently flavored bag of bugs, that is like decades of computing and software engineering hadn’t taken place

Only if the application source code fits the API of the library versions on your system. Otherwise you also need to port the application to your available library versions. Also using different dependency versions might surface bugs that you have to sort out yourself.

I only want to point this out because it often seems that the people that complain about flatpak do not grasp what maintaining a package entails, and your suggestion effectively puts you in the position of being a package maintaier for your specific distro. (But the upshot is that with open source software you are always free to do this, and also share it with other people through (community-) repositories)

I think you slipped in the discussion intendations somewhere, this branch of the discussion tree is about the implications of piping curl into bash vs. installing packages

By that logic you have to review the Zed source code as well. Either you trust Zed devs or you don’t - decide! If you suspect their install script does something fishy, they could do it just as well as part of the editor. If you run their editor you execute their code, if you run the install script you execute their code - it’s the same thing.

Aur is worse because there usually somebody else writes the PKGBUILD, and then you have to either decide whether to trust that person as well, or be confident enough for vetting their work yourself.

Security wise it doesn’t matter, you run the code they wrote in any case. So either trust them or don’t. Where it matters is making a mess on your computer and possibly leaving cruft behind when uninstalling. But packages are in the works, Arch even has it since before linux support was announced officially.