I recently came across this article: . I would like to share my view on the standard.
/ bin
Contains commands that can be used by both the system administrator and users, but are required when no other file systems are mounted (for example, in single user mode). It may also contain commands that are used indirectly by scripts.
The following commands are expected there:
cat, chgrp, chmod, chown, cp, data, dd, df, dmesg, threw out, false, hostname, kill, ln, login, ls, mkdir, mknod, more, mount, mv, ps, pwd, rm, rmdir, thirst, sh, stty, su, sync, true, umount, uname.
It is possible to symlink to /usr, but while /usr is not seen on a standalone device in systemd days, it can still be found on an embedded system, a traffic light, a coffee grinder, and a PDP-11 serving an important appliance in one of the Academy of Sciences laboratories.
/ sbin
Utilities used for system administration (and other root-only commands), /sbin contains the binaries needed to boot, restore, restore, and/or restore the system in addition to the binaries in /bin. Programs that run after /usr is mounted (when there are no problems) are usually placed in /usr/sbin. Locally installed system administration programs should be placed in /usr/local/sbin.
Expected:
fastboot, fasthalt, fdisk, fsck, getty, halt, ifconfig, init, mkfs, mkswap, reboot, route, swapon, swapoff, update.
One of the ways to protect the system from the playful hands of users is to prevent anyone from running these utilities by setting the x attribute.
In addition, replacing /bin and /sbin with copies from the archive (the same for all systems of the same type) is a quick way to fix systems without a package manager.
/ usr / bin
Everything is simple here. The same type of commands, the same for all servers / coffee grinders of the company. And /usr itself can be deployed the same for different operating systems (for /bin and /sbin this usually does not work), these are architecturally independent programs. It may contain links to perl or python interpreters, which are in /opt or somewhere else on the network.
/ usr / sbin
Same as /usr/bin, but for admin use only.
/usr/local/bin and /usr/local/sbin
One of the most important locations. Unlike everything else, /usr can't be the same for an entire organization. There are OS-dependent, hardware-dependent and just programs that are not needed on all devices. When synchronizing /usr on machines, /usr/local needs to be excluded.
/home/$USER/bin
Here the case is similar with /usr/local, only there are programs specific to a particular user. Can be transferred (or synchronized) to another machine when the user moves. What cannot be transferred is added to /home/$USER/.local/bin. You can use local without a dot. /home/$USER/sbin is missing for obvious reasons.
I will be glad to corrections and additions.
Source: habr.com