Hacker News Reader

Comment by spoiler | Hacker News Reader

I'm curious how bin is different from Program Files?

Unless you mean stuff like configuration? I think user configuration would still reside somewhere under the user's home dir

View on HN

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

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.

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!

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

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/074...

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.

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.

This is a relatively recent thing, called the Usr Merge.

https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...

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...

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.

Reply on news.ycombinator.com