| Interesting. First there was /bin for the things that UNIX provided and /usr/bin for the things that users provided. Part of the system, it lived in /bin, optional? it lives in /usr/bin. In SunOS 4 (and BSD 4.2 as I recall) the introduction of shared libraries meant you needed a "core" set of binaries for bootstrap and recovery which were not dynamically linked, and so "static" bin or /sbin (and its user equivalent /usr/sbin) came into existence. Same rules for lib. /lib for the system tools, /usr/lib for the optional user supplied stuff. Then networking joined the mix and often you wanted to mount a common set of things from a network file server (saved on precious disk space) but there were things you wanted locally, that gave use /usr/local/bin and /usr/local/lib. Then in the great BSD <==> SVR3.2 merge AT&T insisted on everything optional being in /opt which had a kind of logic to it. Mostly about making packages that could be installed without risking system permission escapes. When Linux started getting traction it was kind of silly that they copied the /bin, /sbin, /usr/bin, /usr/sbin stuff since your computer and you are the only "user" (usually) so why not put everything in the same place, (good enough for Windows right?) File system naming was made more important by the limited permission controls on files, user, group, and other is pretty simplistic. ACLs "fixed" that limitation but the naming conventions were baked into people fingers. The proliferation of places to keep your binaries lead to amazingly convoluted search paths. And with shared libraries and shared library search paths even more security vulnerabilities. |
Only in the minds of people who don't know much about Windows.
The Windows model is, after all, for globally installed individual packages to be largely rooted at "/Program Files/%COMPANY_OR_PERSON%/%PACKAGE%/" with "%USERPROFILE%/AppData/Local/%COMPANY_OR_PERSON%/%PACKAGE%/" as a root for per-user data. The former dates all of the way back to Windows NT 3.5, the latter "merely" dating back to Windows NT 4 (where it was "Application Data" rather than "AppData").
* https://blogs.msdn.microsoft.com/cjacks/2008/02/05/where-sho...
Unix and Linux people will recognize this as akin to NeXTSTEP's ~/Apps, /LocalLibrary, /LocalApps, and so forth from the early 1990s; and to Daniel J. Bernstein's /package hierarchy (for package management without the need for conflict resolution) from the turn of the century.
* http://cr.yp.to/slashpackage.html
* http://cr.yp.to/slashcommand.html
And a few years after NeXTSTEP introduced its directory hierarchy, SunOS 5 (a.k.a. Solaris 2) introduced the System 5 Release 4 /usr merge.