OSNews

Thats the problem though, they aren't. You have /sbin because you dont want super user apps in the normal users path variables. you have /bin which has the basic apps required to use bash, because years ago /bin and /usr were always on seperate partitions (if not drives), and people wanted the system to be usable even if /usr failed to load. /usr/bin is where things installed with the os go, and /usr/local/bin is where stuff compiled on that machine goes.

In reality, if /usr isn't loading properly, 99% of the time having access to sh and vi aren't going to do it for the person, and they are just going to end up rebuilding the machine. /usr/bin now has plenty of apps that require super user creds, so at this point its a pretty arbitrary line between what goes in sbin and what doesn't. Now that we have package managers, /usr/local/bin is also a pretty silly convention, since 95%+ of what is on your machine is going to come from the package manager, and if you dont package up the stuff you compile yourself, you are really asking for the pain you are going to be inflicting on yourself.

And that is just when it comes one thing getting spread all over the place for reasons that are now irrelevant, or at least irrelevant for most installations. I mean, with the advent of tab completion, is it really worth dropping the e in user? Most of the system folders are gibberish words, and there is no reason for that any more. Sure, you would still need to learn that /applications is where your executables live, but at least it is a proper word.



First of all, I would say it is alot closer to OSX then it is to windows. Secondly, /usr/bin has stopped being relevent to anyone for at least a decade. Being archaic for the sake of being archaic is only really helpful for the people who have been using it since the time there were reasons for these things.