4 ms·

I wish we could just unify /usr/local/bin, /usr/bin, /usr/sbin, /bin, and /opt. I'm a Linux user for 15 years and I still don't know if there's a good modern re

by tdeck 4y ago

I wish we could just unify /usr/local/bin, /usr/bin, /usr/sbin, /bin, and /opt. I'm a Linux user for 15 years and I still don't know if there's a good modern reason to have so many different directory trees for binaries and what that reason is. It's all historical craft that makes it so hard to find things as far as I am concerned.

protomyth 4y ago
I'm more BSD, but I have come to like 'local' and wish it were further refined so we can mount usr & bin as read-only and be able to rebuild machines with a backup of local and I guess etc.
pabs3 4y ago
On Hurd you probably could, just mount a merge translator over /bin that merges all the directories you want. IIRC on Hurd translator namespaces are per-process in the libc and are inherited from parent to child process. So like containers/namespaces on Linux but implemented in the libc.
- account42 4y ago
  Well when it comes to bin, other operating systems have that to. It's called $PATH.
  - pabs3 4y ago
    $PATH isn't quote the same, for eg you can't easily remove individual binaries from $PATH.
jabl 4y ago
The somewhat old and AFAIU no longer maintained FHS contains explanations https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html tl;dr: /usr/local - Place for the system administrator to put local stuff. That is, the package manager (apt/dnf/yum/whatever) won't touch anything there. /usr/bin - "Normal" binaries /usr/sbin - System binaries, that is, binaries that don't do anything useful when run without superuser privileges /bin - Well, nowadays just a symlink to /usr/bin. Read the article to understand the historical background why they were split. /opt - For packages that install everything under one directory instead of being spread out into the standard locations.
- GoblinSlayer 4y ago
  /opt is still spread out: programs must be in /opt/package/bin, configuration must be in /etc/opt, variable files must be in /var/opt.
Gigachad 4y ago
The historical reason for /usr/bin and /bin was that they ran out of hard drive space and needed a second drive for binaries. These days people just invent some fiction about how it’s actually “Unix system resources” and not just a second user folder.
- WesolyKubeczek 4y ago
  Also, in those days /usr was kinda sorta like $HOME today for "user files", until one day someone replicated the / hierarchy into there to get more space.
bandrami 4y ago
The OS promises not to touch /usr/local other than to set it and its subdirectories up. This allows two things: 1. /usr/local is usually set up to take priority over /usr, so if you want a newer C compiler or whatever you put it in /usr/local but keep the system compiler in /usr because you might need it for an OS patch or something. 2. If you see an error from something in /usr/local you know not to bother your OS vendor about it because it came from an outside source. It's largely the same theory as /opt, except stuff in /opt shouldn't link to any libraries in /usr while stuff in /usr/local can (stuff in /opt should be self-contained).

by tdeck 4y ago

protomyth 4y ago

I'm more BSD, but I have come to like 'local' and wish it were further refined so we can mount usr & bin as read-only and be able to rebuild machines with a backup of local and I guess etc.

pabs3 4y ago

On Hurd you probably could, just mount a merge translator over /bin that merges all the directories you want. IIRC on Hurd translator namespaces are per-process in the libc and are inherited from parent to child process. So like containers/namespaces on Linux but implemented in the libc.

account42 4y ago
Well when it comes to bin, other operating systems have that to. It's called $PATH.
- pabs3 4y ago
  $PATH isn't quote the same, for eg you can't easily remove individual binaries from $PATH.

jabl 4y ago

The somewhat old and AFAIU no longer maintained FHS contains explanations https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html tl;dr: /usr/local - Place for the system administrator to put local stuff. That is, the package manager (apt/dnf/yum/whatever) won't touch anything there. /usr/bin - "Normal" binaries /usr/sbin - System binaries, that is, binaries that don't do anything useful when run without superuser privileges /bin - Well, nowadays just a symlink to /usr/bin. Read the article to understand the historical background why they were split. /opt - For packages that install everything under one directory instead of being spread out into the standard locations.

GoblinSlayer 4y ago
/opt is still spread out: programs must be in /opt/package/bin, configuration must be in /etc/opt, variable files must be in /var/opt.

Gigachad 4y ago

The historical reason for /usr/bin and /bin was that they ran out of hard drive space and needed a second drive for binaries. These days people just invent some fiction about how it’s actually “Unix system resources” and not just a second user folder.

WesolyKubeczek 4y ago
Also, in those days /usr was kinda sorta like $HOME today for "user files", until one day someone replicated the / hierarchy into there to get more space.

bandrami 4y ago

The OS promises not to touch /usr/local other than to set it and its subdirectories up. This allows two things: 1. /usr/local is usually set up to take priority over /usr, so if you want a newer C compiler or whatever you put it in /usr/local but keep the system compiler in /usr because you might need it for an OS patch or something. 2. If you see an error from something in /usr/local you know not to bother your OS vendor about it because it came from an outside source. It's largely the same theory as /opt, except stuff in /opt shouldn't link to any libraries in /usr while stuff in /usr/local can (stuff in /opt should be self-contained).