Давайте разберемся со всеми папками bin и sbin (из стандарта иерархии файловой системы):

• /bin для бинарных файлов системного уровня
• /sbin для других бинарных файлов системного уровня, в основном для загрузчика и системных администраторов
• /usr/bin для несущественных двоичных файлов
• /usr/sbin- это где начинается беспорядок - не необходимые инструменты для системных администраторов? Что это означает? Для экспериментов?
• /usr/local/bin - ни слова об этой папке
• /usr/local/sbin- локально установленные программы системного администрирования. Опять таки? Как насчет /usr/sbin?

Таким образом, вопрос: Почему существует так много каталогов и каковы значения /usr/sbin, /usr/local/sbinа /usr/local/bin?

Многие программы распространяются через архивы, и мы должны создавать их из исходного кода. Обычно у них есть make-файл, так что это довольно просто. Этот процесс включает в себя создание файлов в каталогах usr / local / lib, usr / local / bin ... usr / local / независимо от создания определенных папок для данной программы.

Почему это так?

Я думаю, что это неправильно, потому что если нам нужно удалить программу, мы должны вручную удалить все ее файлы, если создатель программы не позаботился об этом.

1. Структура каталогов

Это должно быть отражено в стандарте иерархии файловой системы ( 2.3 PDF )

/ bin / Основные команды, которые должны быть доступны в однопользовательском режиме;
            для всех пользователей, например, cat, ls, cp

/ sbin / Основные системные файлы, например, init, ip, mount.

/ usr / bin / Несущественные двоичные файлы команд (не требуется в однопользовательском режиме); 
            для всех пользователей

/ usr / sbin / Несущественные системные двоичные файлы, например, демоны для различных сетевых сервисов.

/ usr / local / Третичная иерархия для локальных данных, специфичных для этого хоста. 
            Обычно имеет дополнительные подкаталоги, например, bin /, lib /, share /

2. Установка

Я использую менеджер пакетов везде, где это возможно (например, yum или apt-get). Это возможно для очень большого числа приложений, в некоторых случаях вам может понадобиться добавить репозиторий. Моим вторым выбором были бы пакеты более низкого уровня, такие как RPM, и компиляция из исходного кода была бы моим последним средством (но некоторые люди предпочитают это)

Некоторые менеджеры пакетов могут устанавливать из RPM (например yum install oddity.rpm)

Если вы компилируете из исходного кода, вероятно, это не большой шаг для создания собственного пакета, чтобы системный установщик знал, что вы сделали.

Тогда ваша проблема сводится, например, к yum remove packagename

Альтернатива - хранить хорошую документацию обо всех предпринятых действиях сисадмина (в любом случае я веду журнал в текстовом файле).

Материал во всех каталогах * / sbin полезен только системным администраторам. Вы можете держать их вне своего PATH, если вы обычный пользователь.

Разные каталоги не имеют большого смысла, если у вас есть один компьютер с Unix на одном диске, но имеют больше смысла, если у вас большая система и разные разделы. Помните, что многие из этих привычек были созданы в 80-х и 90-х годах, когда системы были немного другими.

/sbinимеет тенденцию быть очень маленьким. Это утилиты, которые вам нужны, когда вы на самом деле находитесь в безопасности. Вы поместите это в минимальный корневой раздел с / root и / lib. Вещи в / sbin раньше были статически связаны, так как если ваш раздел / usr скрыт, любые динамически связанные приложения бесполезны. fsck здесь и статически связан. Если у вас есть зависимость от / usr, очевидно, вы не можете fsck / usr /. Конечно, если корневой раздел скрыт, вы очень испорчены. Вот почему это такой маленький раздел - уменьшите шансы плохого дискового блока, используя здесь очень мало блоков.

/usr/sbinДвоичные файлы - это общие инструменты системного администратора, где вы можете по крайней мере перейти в однопользовательский режим и смонтировать все свои тома. Они могут быть динамически связаны.

Отдельные разделы для / sbin (ну, / sbin on / partition) и / usr также имеют больше смысла, если вспомнить, что резервное копирование было очень дорогим как по времени, так и для ленты. Если бы они были на отдельных разделах, вы могли бы запланировать их по-другому.

/usr/localможет быть сетевой файловой системой. Поэтому локально написанные инструменты sysadmin, которые могут использоваться многими компьютерами, иногда попадают в / usr / local / sbin. Очевидно, что никакие утилиты исправления сети не могут пойти туда.

Опять же, многое стало более понятным на больших машинах в сетевой среде на управляемых машинах с несколькими томами, в меньшей степени - на одной машине Linux в одном корневом разделе.

Тебе действительно нужно, чтобы твой второй вопрос был отдельным вопросом на Superuser. Это не связано с первым.

Да, иметь файлы повсюду - отстой. Вот почему существует множество упаковочных решений. RedHat создал RPM, который используется везде. У Соляриса был свой формат пакета. У HP / UX были свои, и есть много других форматов пакетов. Храните вещи в нужных местах (/ usr / bin, / usr / lib) по мере необходимости, но допускайте легкое добавление и удаление.

Для источника раньше были инструменты, которые позволяли бы вам настраивать и устанавливать в подкаталоге / usr / local, и он обрабатывал бы символические ссылки на / usr / local / bin для вас. Поскольку широкое распространение получили пакетные инструменты, в этом нет необходимости, и я забыл их названия.

Некоторые люди любят устанавливать в / opt / packagename и хранить там все вместе. Хорошо: все в одном каталоге и удаление rm -rf /opt/packagename. Недостатками этого являются добавление / opt / packagename / bin к каждому PATH и тот факт, что люди обычно не помещают / opt в отдельный раздел, а вы заполняете корневой раздел.

Мое понимание значений каталогов (из опыта работы с Debian GNU Linux) таково:

Первое различие: sдля суперпользователя

s перед bin каталогом указывает, что он содержит инструменты, которые обычно полезны только для администраторов. Обратите внимание, что, например, ifconfigтакже относится к этой категории, и я хотел бы вызвать ifconfigкак обычный пользователь (чтобы проверить, получил ли я IP-адрес / подключение к сети), что делает это различие не так сложно, как может показаться.

Второе отличие: local для «Локальные данные»

На практике самое важное различие заключается в том, что менеджеры пакетов ОС (например, APT) устанавливают пакеты в обычную /usrструктуру и оставляют/usr/local без изменений. Это позволяет размещать локально скомпилированные пакеты или внутренние сценарии, предоставляемые системным администратором, /usr/localгде они никогда не будут мешать правильно упакованным файлам.

Это спорно ли /usr/localследует переопределить существующие файлы с нормальной /usrструктурой, см Опасно иметь / USR / местные / бен впереди / USR / бен в своем пути? для некоторых деталей об этом.

Третье различие: верхний уровень /binи /sbinкаталоги.

На самом деле в Debian существует так называемый UsrMerge . Там раньше разница , что /binи /sbinбыли доступны в процессе загрузки ранее (думаю /usrнаходиться на сетевом устройстве или другой раздел, RAID и т.д.), но Nowdays несколько систем Linux загружается и без /usr, поэтому я хотел бы рассмотреть различие между ТОП - уровень и /usrкаталоги должны представлять большой интерес для Linux.

Напоследок: достоинства и проблемы «разбрасывания» файлов.

На самом деле нет «одного истинного» ответа на это. Преимущества разбросанной файловой системы Linux таковы:

• Все двоичные файлы находятся в нескольких каталогах. Это означает, что вы можете вызывать каждую программу из оболочки. Сравните Windows, где всегда нужно редактировать %PATH%переменную окружения, чтобы добавить любую интересующую программу. Я видел очень длинный путь в Windows.

• Все библиотеки находятся в центральном месте. Это означает, что их не нужно устанавливать дважды, когда они используются несколькими приложениями.

• Поскольку Linux спроектирован так, что большинство системных файлов в любом случае отслеживаются менеджером пакетов , нет необходимости хранить обзор файлов с точки зрения пользователя.

• Благодаря стандартизации FHS документация также находится в центральных местах, что позволяет системным системам man, infoа также файлам README работать должным образом.

• Проще полагаться на программу, устанавливаемую в фиксированном месте. Каждый пишет #!/bin/sh -eили похожий в начале сценариев, и это просто работает . Рассмотрим систему, в которой оболочка будет перемещаться в другой каталог: как узнать, какое имя она примет? Если интересно, проверьте различные способы установки Perl или LaTeX на Windows, чтобы увидеть, насколько это может быть сложно ...

Недостатки, которые я обнаружил, таковы:

• Обычно труднее заставить приложения запускаться «переносимо» в смысле «переносимых приложений для Windows». В Linux не так просто скопировать программу на другой компьютер ... нужно иметь пакет (для которого требуются права суперпользователя) или иметь дело с LD_LIBRARY_PATHуказанием приложениям на разных путях поиска для требуемых библиотек.

• Установка нескольких версий одной и той же программы должна поддерживаться в явном виде, тогда как в системах с «одним каталогом на программу» это часто не проблема.

• Управление файлами без менеджера пакетов подвержено ошибкам (как уже упоминалось).

Чтобы ответить на ваш второй вопрос:
Обычно программы распространяются с помощью так называемого менеджера пакетов . Диспетчер пакетов обычно выбирает двоичные пакеты (программное обеспечение, скомпилированное для определенной платформы) и разбрасывает их по каталогам (есть некоторые, кто загружает исходный код, компилирует его на вашем компьютере и устанавливает его). Таким образом, менеджер пакетов знает, где находятся файлы, принадлежащие определенной «программе» (пакету), и когда вы хотите удалить пакет, менеджер пакетов позаботится об очистке всего.
Даже когда вы компилируете исходный код самостоятельно

make

и установить его с

make install

вы обычно можете сделать

make uninstall

который удаляет файлы из файловой системы.