Розберемося з усіма папками bin та sbin (із стандартної ієрархії файлової системи):

• /bin призначений для двійкових файлів на системному рівні
• /sbin є для інших бінарних системного рівня, здебільшого для завантажувача та системних адміністраторів
• /usr/bin - це не важливі бінарні файли
• /usr/sbin- саме тут починається безлад - не важливі інструменти для системних адміністраторів? Що це означає? Для експериментів?
• /usr/local/bin - жодного слова про цю папку
• /usr/local/sbin- локально встановлені програми системного адміністрування. Знову? Як щодо /usr/sbin?

Таким чином, питання: Чому існує так багато каталогів і які значення /usr/sbin, /usr/local/sbinа /usr/local/bin?

Багато програм поширюються через архіви, і ми повинні будувати їх з вихідного коду. Зазвичай вони мають makefile, тому це досить просто. Цей процес включає створення файлів у usr / local / lib, usr / local / bin ... usr / local / як завгодно, не створюючи конкретних папок для заданої програми.

Чому так?

Я думаю, що це неправильно, тому що якщо нам потрібно видалити програму, ми повинні видалити всі її файли вручну, якщо творець програми не подбав про це.

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

Це має бути охоплено стандартом ієрархії файлової системи ( 2.3 PDF )

/ bin / Essential бінарні команди, які повинні бути доступні в режимі одного користувача;
            для всіх користувачів, наприклад, 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, як правило, корисна лише для системних адміністраторів. Ви можете захистити їх від своєї ПАТХ, якщо ви звичайний користувач.

У різних каталогах немає особливого сенсу, якщо у вас є одна машина Unix на одному диску, але має більше сенсу, якщо у вас є велика система та різні розділи. Пам'ятайте, що багато з цих звичок були зроблені у 80-90-ті роки, коли системи були дещо іншими.

/sbinмає тенденцію бути дуже маленьким. Це комунальні послуги, які вам потрібні, коли вам дуже потрібні шланги. Ви розміщуєте це на мінімальному кореневому розділі за допомогою / root та / lib. Речі в / sbin раніше були статично пов’язані, оскільки якщо ваш / usr розділ розміщений, будь-які динамічно пов'язані програми марні. fsck тут і статично пов'язаний. Якщо у вас залежність від / usr, очевидно, ви не можете fsck / usr /. Звичайно, якщо корінний розділ шланг, ви сильно накрутили. Ось чому це такий невеликий розділ - зменшіть шанси поганого блоку диска, використовуючи тут дуже мало блоків.

/usr/sbinбінарні файли - це загальні інструменти системного адміністратора, де ви можете принаймні перейти в єдиний користувальницький режим і змонтувати всі свої томи. Їм дозволяється динамічно зв’язуватися.

Окремі розділи для / sbin (добре, / sbin на / розділ) та / usr також мають більше сенсу, коли ви пам’ятаєте, що резервне копіювання було дуже дорогим і за час, і для стрічки. Якби вони були на окремих розділах, ви могли запланувати їх по-різному.

/usr/localможе бути мережевою файловою системою. Тож локально написані засоби sysadmin, якими можна ділитися на багатьох машинах, іноді переходять у / usr / local / sbin. Очевидно, що ніякі утиліти для фіксації мережі не можуть зайти туди.

Знову ж таки, багато речей мали більше сенсу на великих машинах у мережевому середовищі на керованих машинах з декількома томами, меншою мірою - на одній машині Linux на одному кореневому розділі.

Вам справді слід, щоб ваше друге запитання було окремим питанням тут, на Суперусер. Це не пов'язано з першим.

Так, файли повсюдно смокчуть. Ось чому існує багато рішень для упаковки. RedHat створив RPM, який використовується скрізь. Solaris мав свій пакетний формат. HP / UX мали свій, і є влучний та багато інших форматів пакетів. Тримайте речі в потрібних місцях (/ usr / bin, / usr / lib) у відповідних випадках, але дозволяйте легко додавати та видаляти.

Для джерела раніше існували інструменти, які дозволяли вам налаштувати та встановити в піддіректорі / usr / local, і він обробляв би посилання на / usr / local / bin для вас. Зважаючи на широке розповсюдження пакетних інструментів, це менш потрібно, і я забув їх назви.

Деяким людям подобається встановлювати in / opt / packagename і зберігати все разом. Добре: все є в одному каталозі, а видалення є rm -rf /opt/packagename. Мінуси цього полягають у тому, щоб додати / opt / packagename / bin до PATH кожного, а також те, що люди зазвичай не ставлять / вибирають окремий розділ, і ви заповнюєте кореневий розділ.

Я вважаю, що значення каталогів (з досвіду роботи з Debian GNU Linux):

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

sперед binкаталогом вказує, що він містить інструменти, які зазвичай корисні лише адміністраторам. Зауважте, що, наприклад, ifconfigтакож належить до цієї категорії, і я хотів би посилатися ifconfigяк звичайний користувач (щоб перевірити, чи я отримав IP-адресу / підключення до мережі), що робить це розмежування не таким важким, як може здатися.

Друга відмінність: localпризначено для "Місцевих даних"

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

Дискусійно, чи /usr/localслід замінювати наявні файли з нормальної /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

який видаляє файли з файлової системи.