5 ms·

Why not move them all to /bin instead? /usr is a relic of the times when unix systems were big hulking monsters the side of fridges. and hard disks the size of

Why not move them all to /bin instead? /usr is a relic of the times when unix systems were big hulking monsters the side of fridges. and hard disks the size of washing machines. You kept a separate /, /var, /usr, /home, etc because you had a lack of space and because disks kept crashing. That's no longer the case. Even for the largest 4096cpu numa system you just throw the entire OS on one partition, with a separate home/data disk. I'm sure the developers have some neckbeard reason why it has to be /usr and not / but surely user friendliness is not it.

veneratio 15y ago
While I'm new to the discussion, I agree with you spitfire. But at least this is a step towards something simpler. The current file structure for most distributions is downright confusing to even moderately competent users.
- rhizome 15y ago
  What? It may take a minute to find where something actually is, but on all Unix-like OSes you can type `man hier` and have all the mystery swept away. Moving everything to /bin strikes me more of a marketing move than anything.
makecheck 15y ago
According to the Filesystem Hierarchy Standard [1], /bin was originally designed to hold programs that are "required when no other filesystems are mounted" or commands "used indirectly by scripts". Which is a fancy way of saying that you don't want basic functionality to break just because a mounted volume is unresponsive for some reason. The /bin versions of programs can also be less powerful (e.g. to keep them extremely small), although that's unlikely to be an issue these days. For example, when local disks were small it wasn't unusual to see a bare-bones /bin version of some program while also having a /usr/bin version that was capable of large file support and other niceties. [1] http://www.pathname.com/fhs/ http://www.pathname.com/fhs/
- spitfire 15y ago
  I know about all that. You're basically saying "lets stick with the past... just because. If you're going to simplify things, do so in a meaningful way and keep up with the times.
  - makecheck 15y ago
    No, that's not what I'm saying. If you don't separate /bin and /usr, and /usr is a mount and it becomes unresponsive, how do you log into the machine? Where are the login shells and basic file management tools to rescue the machine? That problem exists as soon as you collect tools into one place, whether you choose /bin or /usr/bin to be that place. But choosing (only) /bin has an additional problem, which is that you lose the ability to easily set up mounts. If you have many machines to keep in sync, they could each have a relatively simple /usr mount; while you could set up root paths equivalently, you would need more of them: either symlinks or mounts in several places on all machines that all have to be kept in sync. That is unnecessarily complicated. The /bin option is only equivalent if you are in fact dumping everything on the local disk and not using mounts. But "standard" hierarchy paths should not assume the architecture.

veneratio 15y ago

While I'm new to the discussion, I agree with you spitfire. But at least this is a step towards something simpler. The current file structure for most distributions is downright confusing to even moderately competent users.

rhizome 15y ago
What? It may take a minute to find where something actually is, but on all Unix-like OSes you can type `man hier` and have all the mystery swept away. Moving everything to /bin strikes me more of a marketing move than anything.

makecheck 15y ago

According to the Filesystem Hierarchy Standard [1], /bin was originally designed to hold programs that are "required when no other filesystems are mounted" or commands "used indirectly by scripts". Which is a fancy way of saying that you don't want basic functionality to break just because a mounted volume is unresponsive for some reason. The /bin versions of programs can also be less powerful (e.g. to keep them extremely small), although that's unlikely to be an issue these days. For example, when local disks were small it wasn't unusual to see a bare-bones /bin version of some program while also having a /usr/bin version that was capable of large file support and other niceties. [1] http://www.pathname.com/fhs/ http://www.pathname.com/fhs/

spitfire 15y ago
I know about all that. You're basically saying "lets stick with the past... just because. If you're going to simplify things, do so in a meaningful way and keep up with the times.
- makecheck 15y ago
  No, that's not what I'm saying. If you don't separate /bin and /usr, and /usr is a mount and it becomes unresponsive, how do you log into the machine? Where are the login shells and basic file management tools to rescue the machine? That problem exists as soon as you collect tools into one place, whether you choose /bin or /usr/bin to be that place. But choosing (only) /bin has an additional problem, which is that you lose the ability to easily set up mounts. If you have many machines to keep in sync, they could each have a relatively simple /usr mount; while you could set up root paths equivalently, you would need more of them: either symlinks or mounts in several places on all machines that all have to be kept in sync. That is unnecessarily complicated. The /bin option is only equivalent if you are in fact dumping everything on the local disk and not using mounts. But "standard" hierarchy paths should not assume the architecture.