3 ms·

/bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin I never know where to put my own binaries so I just add my own at ~/bin. Some programs also add the

/bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin I never know where to put my own binaries so I just add my own at ~/bin. Some programs also add their own like ~/.cargo/bin what a mess

froh 3y ago
/usr/local is for all users of the multi-user server you're on, which you have installed locally. ~/... is for your personal user account /bin (and /usr/bin, /sbin, /usr/sbin ) is for system software (from your distro of choice) and /opt is for third party packages from third party providers we tend to forget the "Unix" precursor of Linux comes from the data centre server world. so "a mess" is relative
- theandrewbailey 3y ago
  > /bin (and /usr/bin, /sbin, /usr/sbin ) is for system software (from your distro of choice) Don't most/popular distros symlink many of those together?
  - NekkoDroid 3y ago
    Most distros use a mostly hermetic-usr, where a majority of "distro stuff" is shipped in /usr/{bin,sbin,lib,lib<bitness>,share}. The folders in root mostly symlink to these directories (/usr/sbin might also symlink to /usr/bin).
  - yjftsjthsd-h 3y ago
    Yes, ex. https://wiki.debian.org/UsrMerge https://wiki.debian.org/UsrMerge
  - HankB99 3y ago
    Yes https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor... (Not sure if popularity matters.)
  - froh 3y ago
    yes they do, because the original purpose and value of the separation has gone. "back in the days" before there was an initrd you needed a small disk. that was /bin and /sbin. into that disk some /etc/rc.d/ file would mount a separate /use partition (and /home and /opt), often from network. however with pivot_root and initrd we don't need that dance any more and do another one... likewise the distinction between sbin and bin is gone. that's why they today just symlink together.
- cbm-vic-20 3y ago
  > we tend to forget the "Unix" precursor of Linux comes from the data centre server world. Indeed. When I first encountered Unix back in the Dark Ages, not only was it common to be working on the same machine with a dozen other people simultaneously, we also had an environment where many programs were hosted on NFS filesystems, and we would have paths like /usr/nfs/alpha-dec-osf1 for Alpha binaries, /usr/nfs/decstation-ultrix for MIPS binaries, /usr/nfs/sparc-sun-solaris, etc. You would make sure your profile scripts included the right architecture path. Even modern UNIXes (like Darwin/MacOS) include write(1), if you want to start a chat with someone else logged into your MacBook, I suppose.
theandrewbailey 3y ago
I think the current standard for your own binaries is ~/.local/bin instead of ~/bin https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-...
- anononaut 3y ago
  I would probably end up symlinking ~/.local/bin to ~ anyway, at which point I wonder why bother?
nonameiguess 3y ago
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.

/bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin I never know where to put my own binaries so I just add my own at ~/bin. Some programs also add their own like ~/.cargo/bin what a mess

froh 3y ago

/usr/local is for all users of the multi-user server you're on, which you have installed locally. ~/... is for your personal user account /bin (and /usr/bin, /sbin, /usr/sbin ) is for system software (from your distro of choice) and /opt is for third party packages from third party providers we tend to forget the "Unix" precursor of Linux comes from the data centre server world. so "a mess" is relative

theandrewbailey 3y ago
> /bin (and /usr/bin, /sbin, /usr/sbin ) is for system software (from your distro of choice) Don't most/popular distros symlink many of those together?
- NekkoDroid 3y ago
  Most distros use a mostly hermetic-usr, where a majority of "distro stuff" is shipped in /usr/{bin,sbin,lib,lib<bitness>,share}. The folders in root mostly symlink to these directories (/usr/sbin might also symlink to /usr/bin).
- yjftsjthsd-h 3y ago
  Yes, ex. https://wiki.debian.org/UsrMerge https://wiki.debian.org/UsrMerge
- HankB99 3y ago
  Yes https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor... (Not sure if popularity matters.)
- froh 3y ago
  yes they do, because the original purpose and value of the separation has gone. "back in the days" before there was an initrd you needed a small disk. that was /bin and /sbin. into that disk some /etc/rc.d/ file would mount a separate /use partition (and /home and /opt), often from network. however with pivot_root and initrd we don't need that dance any more and do another one... likewise the distinction between sbin and bin is gone. that's why they today just symlink together.
cbm-vic-20 3y ago
> we tend to forget the "Unix" precursor of Linux comes from the data centre server world. Indeed. When I first encountered Unix back in the Dark Ages, not only was it common to be working on the same machine with a dozen other people simultaneously, we also had an environment where many programs were hosted on NFS filesystems, and we would have paths like /usr/nfs/alpha-dec-osf1 for Alpha binaries, /usr/nfs/decstation-ultrix for MIPS binaries, /usr/nfs/sparc-sun-solaris, etc. You would make sure your profile scripts included the right architecture path. Even modern UNIXes (like Darwin/MacOS) include write(1), if you want to start a chat with someone else logged into your MacBook, I suppose.

theandrewbailey 3y ago

I think the current standard for your own binaries is ~/.local/bin instead of ~/bin https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-...

anononaut 3y ago
I would probably end up symlinking ~/.local/bin to ~ anyway, at which point I wonder why bother?

nonameiguess 3y ago

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.