Linux Filesystem Hierarchy (2004)

About 2009 or 2010 I recall nearly every major distro saying they were going to ignore it, yes. It primarily existed so that Linux could mimic System V and/or POSIX, and that stopped being relevant as soon as software written for Unix migrated into software written for Linux.

Do you mean in the FHS? /run is in there. It's runtime variable data, like /var but for data that doesn't need to persist between boots.

The long version is:

/usr/bin belongs to the package manager for your distro. Don't put anything there.

/usr/sbin is the same but house executables that should only be run by root.

/bin and /sbin are analogous but house the minimal set that needs to be present during early boot in case /usr is on a separate partition. In practice, distros have largely moved to making at least /bin and /sbin symlinks to /usr/bin and /usr/sbin, with some making everything else a symlink to /usr/bin.

/usr/libexec holds executables installed by the package manager but meant to be run only by other programs, not by interactive users.

/usr/local/bin and /usr/local/sbin hold executables installed manually rather than by the package manager. By convention, the package manager should never touch this and it will be left alone during system upgrades. In theory, it holds executables meant to be used by every user of a system, but if this is a desktop system with only one user, putting your personal stuff there is harmless.

Not part of the FHS, but according to cross-desktop group standards, ~/.local/bin is where you put executables meant to be used by a single user only. The package manager won't touch this directory, but third-party installers like pip and what not should theoretically be using it (not ~/.cargo/bin like cargo does).

/opt effectively serves a similar purpose to /usr/local, but for software that expects all of its dependencies to be hermetically contained within a single top-level directory rather than shared. This is often because /opt is mounted via NFS and shared across multiple hosts that might not all have the same common system-wide dependencies. I can't think of a whole lot of examples where this is still commonly used, except that Kubernetes puts the CNI plugins here.

Also, technically if you're booting via UEFI, then your bootloader or any other EFI executables should be at the root of your EFI system partition, which in Linux will usually be mounted at either /boot or /boot/efi depending on the distro, but users should rarely be messing with this unless you're doing Linux from Scratch or really know what you're doing. This also includes Linux itself in a Linux distro because the kernel is an EFI executable now thanks to EFISTUB and you don't actually need a separate bootloader if you really know what you're doing.

evolution.

/mnt came first. and distros started mounting stuff into it. but actually it was never meant to be used for that. it was supposed to be an always empty directory where a sysadmin could mount something temporarily if they needed it.

so distros moved away from /mnt and started using /media

then /run was invented as a place for all that semi-automatic temporary stuff that needs a place while the system is running.

by looking at where a distro mounts stuff, you can see how long they have not bothered to follow changing standards.

/mnt historically was used as a single mount point. This became problematic when it became common to have multiple temporary mounts, for example a CD-ROM and a USB stick. /media solved that by stating mountpoints are folders inside it, eg /media/cdrom.