When should I install software from the package manager and when from a downloaded package or vendor script?

On that last one, since it is the most common installation instruction on the web and the objection is often overstated in the wrong direction.

The usual complaint is that the server could serve something malicious. True, and if you do not trust the vendor you should not be installing their software at all — running their installer and running their program are the same trust decision.

The better objections are practical:

• You cannot see what it did. Files land in places your package manager does not know about, and removing it later means guessing.
• A partial download executes partially. A truncated script can run half of itself, which is a genuine failure mode rather than a theoretical one.
• It usually adds a repository or a scheduled task anyway, so you could have added those yourself and known what you had.

The compromise: download the script to a file, read it, then run it. Most are short and most just add a repository, which you can then do directly.

For the machine you already have, the way back is an inventory rather than a rebuild.

List what the package manager knows about, and then treat everything else as a manual item. On the systems I run I keep a plain text file recording anything installed outside the package manager, with where it came from and how to update it. It takes a minute per item and it is the difference between a machine you can hand over and one only you can maintain.

The test for whether you have a problem: could somebody else patch this machine after a vulnerability announcement, without asking you? If the answer is no, the inventory is what fixes that, not reinstalling.

The question that decides it: what updates this, and will I know when it needs updating? Everything else follows.

Distribution repository. Updated with the system, signed, dependencies resolved, removable cleanly, and somebody has checked it works on your distribution. Default choice. The cost is that versions lag, sometimes a lot.

Vendor repository. You add the vendor's repository and their key, and their packages then update with the system too. This is the right answer for software that must be current — browsers, developer tools — and it is much better than a downloaded file because updates keep flowing. The cost is that you have trusted that vendor to ship into your system.

A downloaded package file. Installs correctly and does not update. It sits at that version until you remember. This is the one that produces the machine you are describing.

Self-contained bundles. Update themselves, isolated, larger, sometimes awkward about touching your files.

A script piped into a shell. You are executing whatever the server returns, as root, unread.

One caution on mixing vendor repositories with a distribution: prefer the vendor's own repository over a package file, and prefer either over pulling in a repository intended for a different distribution.

Repositories from another distribution or another release will resolve, install, and then quietly replace shared libraries that everything else depends on. That is how a working machine becomes one that cannot be updated at all, and it is far harder to unwind than any of the failure modes above.