5 ms·

1. /bin (and /sbin) were intended for programs that needed to be on a small / partition before the larger /usr, etc. partitions were mounted. These days, it

1. /bin (and /sbin) were intended for programs that needed to be on a small / partition before the larger /usr, etc. partitions were mounted. These days, it mostly serves as a standard location for key programs like /bin/sh, although the original intent may still be relevant for e.g. installations on small embedded devices. 2. /sbin, as distinct from /bin, is for system management programs (not normally used by ordinary users) needed before /usr is mounted. 3. /usr/bin is for distribution-managed normal user programs. 4. There is a /usr/sbin with the same relationship to /usr/bin as /sbin has to /bin. 5. /usr/local/bin is for normal user programs not managed by the distribution package manager, e.g. locally compiled packages. You should not install them into /usr/bin because future distribution upgrades may modify or delete them without warning. 6. /usr/local/sbin, as you can probably guess at this point, is to /usr/local/bin as /usr/sbin to /usr/bin. source: https://unix.stackexchange.com/a/8658 https://unix.stackexchange.com/a/8658

gertop 3y ago
You said Program Files was a security nightmare compared to the Linux mess, that is what he was asking about. How is /bin safer than Program Files? None of the things you listed have any relevance to that question.
spoiler 3y ago
I'm familiar with the intent behind the structure. I am mostly asking about the security implications you mentioned. One downside to Program Files type structure is that there's probably going to be some duplicate libraries lying around. However, as someone who's battled version skews due to clashing maintainer mindsets: that's been a much bigger pain in my ass than a few wasted kbs!
- soraminazuki 3y ago
  Just to be clear, GoboLinux works nothing like Program Files. Packages still depend on each other and aren't self contained.
em500 3y ago
The main historical reason why some root level directories were moved to /usr (which was originally the user directory like today's /home) is that Thompson and Ritchie's first hard disk for the operating system was full. The rest seems to be mostly retcons and backronyms. source: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074...
- bbanyc 3y ago
  At one point I stumbled onto a document from circa 1990 laying out a fairly coherent rationale - / was always a filesystem on the local machine while /usr could be a site-wide NFS share across many machines. Thus you got things like splitting off architecture-independent /usr/share from binary /usr/lib (because if you have a few different kinds of workstations, you'd want one /usr per architecture but /usr/share could be site-wide) and creating /sbin from binaries that had been in /etc from day one. Oh and they came up with /var (also possibly a network share) so /usr could be mounted read-only. An interesting idea, but I have to figure the majority of Unix sites kept /usr on the local machine like always.
hnlmorg 3y ago
Those distinctions are more of a relic these days. If you take a look at a look at the inodes themselves you’ll see that they’re just symlinked back to /bin in a lot of Linux distros. BSDs still make the distinction but Linux moved on a while ago.
- lproven 3y ago
  This is a relatively recent thing, called the Usr Merge. https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
  - hnlmorg 3y ago
    It’s a lot older than the edit date of that document. ArchLinux, for example, made the change somewhere in the region of 10 years ago. I can’t find an exact date but here’s a stack overflow discussion about the topic from 2016: https://unix.stackexchange.com/questions/266517/why-is-bin-a-symbolic-link-to-usr-bin https://unix.stackexchange.com/questions/266517/why-is-bin-a...
- michaelmrose 3y ago
  More precisely /bin /sbin /usr/sbin all links pointing to /usr/bin yes but /usr/local is still of relevance and /opt although it really feels like opt (which doesn't have a great semantic meaning and would be better suited for something under /usr/local similarly /lib and /lib64 are pointers to /usr/lib It might be interesting in a vm to remove those symlinks and see what breaks. Presumably a lot.

gertop 3y ago

You said Program Files was a security nightmare compared to the Linux mess, that is what he was asking about. How is /bin safer than Program Files? None of the things you listed have any relevance to that question.

spoiler 3y ago

I'm familiar with the intent behind the structure. I am mostly asking about the security implications you mentioned. One downside to Program Files type structure is that there's probably going to be some duplicate libraries lying around. However, as someone who's battled version skews due to clashing maintainer mindsets: that's been a much bigger pain in my ass than a few wasted kbs!

soraminazuki 3y ago
Just to be clear, GoboLinux works nothing like Program Files. Packages still depend on each other and aren't self contained.

em500 3y ago

The main historical reason why some root level directories were moved to /usr (which was originally the user directory like today's /home) is that Thompson and Ritchie's first hard disk for the operating system was full. The rest seems to be mostly retcons and backronyms. source: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html http://lists.busybox.net/pipermail/busybox/2010-December/074...

bbanyc 3y ago
At one point I stumbled onto a document from circa 1990 laying out a fairly coherent rationale - / was always a filesystem on the local machine while /usr could be a site-wide NFS share across many machines. Thus you got things like splitting off architecture-independent /usr/share from binary /usr/lib (because if you have a few different kinds of workstations, you'd want one /usr per architecture but /usr/share could be site-wide) and creating /sbin from binaries that had been in /etc from day one. Oh and they came up with /var (also possibly a network share) so /usr could be mounted read-only. An interesting idea, but I have to figure the majority of Unix sites kept /usr on the local machine like always.

hnlmorg 3y ago

Those distinctions are more of a relic these days. If you take a look at a look at the inodes themselves you’ll see that they’re just symlinked back to /bin in a lot of Linux distros. BSDs still make the distinction but Linux moved on a while ago.

lproven 3y ago
This is a relatively recent thing, called the Usr Merge. https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
- hnlmorg 3y ago
  It’s a lot older than the edit date of that document. ArchLinux, for example, made the change somewhere in the region of 10 years ago. I can’t find an exact date but here’s a stack overflow discussion about the topic from 2016: https://unix.stackexchange.com/questions/266517/why-is-bin-a-symbolic-link-to-usr-bin https://unix.stackexchange.com/questions/266517/why-is-bin-a...
michaelmrose 3y ago
More precisely /bin /sbin /usr/sbin all links pointing to /usr/bin yes but /usr/local is still of relevance and /opt although it really feels like opt (which doesn't have a great semantic meaning and would be better suited for something under /usr/local similarly /lib and /lib64 are pointers to /usr/lib It might be interesting in a vm to remove those symlinks and see what breaks. Presumably a lot.