Почему в Linux /bin, /usr/bin, /usr/local/bin…

Одна из вещей, которые бросаются в глаза людям, переходящим в мир линукс-систем из мира windows — это «странная» организация файловой системы.
Почему вместо того чтобы выделить программе каталог, например /myprog, ее размазывают по /etc, /usr/bin, /usr/lib и тому подобное, «это же неудобно!» ?

Мало того, нередко после этого человек берется сделать удобнее, как в Windows: эту программу мы положим в /opt/prog1, вон ту — в /usr/lib/prog2, третью в /prog3, четвертую в /home/user/prog4 — а потом думают, как сделать миграцию с диска на диск и ничего при этом не потерять.

На самом деле, в именно такой структуре есть практический смысл, вернее — он был когда-то, пока его не забыли за давностью лет, и не разбавили опытом DOS.
Хотя конкретно Линукс просто скопировал ее из UNIX, по образу и подобию, но когда-то это работало примерно так:

Компьютеры (PDP11) уже научились работать с сетью, но дисковые накопители для них были дорогим удовольствием.
Держать несколько рабочих станций с полноценными дисковыми системами было довольно дорого, особенно если на них на всех использовалась одна и та же версия ОС, которая занимала драгоценное место на дисках.

Но можно было сделать по-другому: запустить сначала минимальный компактный образ ОС, единственной задачей которого было поднять сеть, а потом по NFS смонтировать всё остальное с сервера.
Необходимые для этого файлы были распределены по своему функциональному назначению:
/bin — выполняемые бинарники
/sbin — привелигированные бинарники, для рута
/lib — разделяемые библиотеки
/etc — настройки
/var — место «для того что изменяется» — данные электронной почты, логи и подобное.

Всё остальное, все системные программы ОС — можно смонтировать с сервера.
Чтобы оно не мешало работе — в отдельный каталог /usr: так появлялись /usr/bin, /usr/lib, /usr/share для всяких разных файлов, которые не бинарники и не библиотеки.
Оно вообще могло быть read only, потому что незачем локальным машинам что-то менять в системе, это забота системного администратора и вендора ОС.

Отдельная тема — пользовательские каталоги /usr/home, которые также могли лежать на сервере. Это позволяло любому пользователю, имеющему доступ к какой-то из рабочих станций, при логине в систему получать сразу свой рабочий каталог, на любой машине.
По этой причине домашний каталог рута — /root, в корне, локальный, а пользовательские могли быть за симлинком /home = /usr/home

То есть на локальных машинах из всего доступного места на дисках использовался только самый минимум, всё остальное можно было отдать под рабочие программы, размещенные на этих машинах. Предполагалось, что основная ОС уже смонтирована.
Так появился каталог /usr/local: /usr/local/bin, /usr/local/lib, /usr/local/etc — с настройками только для этих программ, чтобы логически отделить их от системных настроек, необходимых для загрузки.

Получилась стройная система костылей и подпорок: минимальный локальный системный, загрузочный софт — отдельно, программы ОС — отдельно, локально установленное ПО — отдельно.
Всё на своих местах, всё легко переносится/заменяется/мигрирует.

А потом пришла эпоха ПК, дешевых дисков, DOS-Windows.
Логика разделения программы на bin, lib, etc, var вместо C:\MYPROG была пользователям (точнее, уже разработчикам) непонятна — и тут программы начали компоновать по такому же принципу, в один каталог — а потом засунуть его куда-нибудь, в /opt, или в /usr/lib, или в /usr/share — кто на что горазд.

Персональный компьютер не обязан зависить от сети, и диски подешевели — поэтому никаких NFS mount, всё локально. И данные дистрибутива туда, и стороннее ПО туда же.
Зачем какой-то /usr/local/XXX — и так всё работает.
Зачем париться с разбиением диска — один плоский раздел на всё и готово.
Вся эта иерархия стала восприниматься как анахронизм.

Но иногда она может оказаться полезной. Хотя сейчас есть docker, который решает ту же задачу: отделить загрузку (хост) от дистрибутива ОС (образ) и прикладного софта (устанавливаемого в контейнер поверх образа).