Pervin

What is safe, stated plainly:

Safe: the package cache, the journal beyond your retention, old kernels other than the running one and one fallback, container images and build caches you can rebuild, thumbnail and browser caches under home directories, files in temporary directories.

Safe with thought: old backups, log archives, anything under /var/lib belonging to software you no longer run.

Not safe: anything under the system binaries and libraries, configuration, or a running service's data directory. If you find yourself considering these, the disk is too small rather than too full, and the answer is more storage or moving the data.

The general rule: delete things that a program will recreate, and never things a program expects to find.

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.

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.

The middle path worth knowing about: enrol your own key.

You generate a key, enrol it in firmware, and sign your own bootloader and modules with it. Then Secure Boot is enabled and trusting you rather than a third party, which is arguably the correct arrangement for a machine you own.

There are tools that automate the signing on module rebuilds so it is not a manual step every kernel update. Setting it up is an afternoon, and after that it is invisible.

It is also the only option that gets you Secure Boot on a distribution with no signed loader, so for a rolling distribution it is the answer rather than a curiosity.