Яка користь у тому, як Linux упорядковує файли встановлених програм? [зачинено]


10

У Windows системний диск C:має каталог program_files, під яким у кожної програми є свій каталог.

У Linux, під /usr/і /usr/local/, є /bin, /etc, /share, /srcі т.д.

Так у Windows усі файли кожної програми згруповані в одному каталозі, тоді як в Linux файли одного типу з усіх програм є.

Я вважаю, що Windows організовує встановлені програми є більш логічним, ніж спосіб Linux, і таким чином встановленими програмами простіше керувати вручну.

Яка користь у тому, як Linux упорядковує файли встановлених програм? Дякую.

У мене це питання, коли виникає проблема Як організувати встановлені програми в $ HOME для оболонки для пошуку їх під час їх запуску? , де я намагаюся організувати свої програми $HOMEза допомогою Windows, але у мене є певна проблема із зазначенням шляхів пошуку для програм.


9
@RandallStewart ваше " непередбачуване та розсіяне " - це наше раціональне розміщення та не дублювання DLL.
RonJohn

1
Це ґрунтується на історичній основі - здебільшого для того, щоб мати змогу встановити кілька дискових розділів, в той час як можливість завантажувального пристрою мати лише необхідні речі. Аналогічна ситуація була в тому випадку, коли PC BIOS могли бачити лише першу частину дуже великих жорстких дисків, тому в цій першій частині був розміщений окремий розділ, що містить усе необхідне для завантаження. Зазвичай називається "/ boot". Сьогодні потреба у пісочницях та ненадійних додатках призвела до переосмислення - див., Наприклад, оснащення Ubuntu.
Thorbjørn Ravn Andersen

9
Дозвольте мені першим зазначити, що Windows зараз не розміщує всі файли кожної програми в директорії smae. Окрім «Файлів програми» та «Файлів програми (x86)», серед інших існують каталоги «Користувачі \ <ім'я користувача> \ Appdata» з «Місцевого», «Місцевого користування» та «Роумінгу». Також Windows завжди не використовувала папку "Файли програм" для програм або не використовувала її послідовно протягом своєї історії. * nix набагато послідовніше в обробці файлів у часі.
YLearn

5
@JAB, погодився і зрозумій це. Я вказував, що твердження ОП, а саме "Отже, у Windows усі файли кожної програми згруповані в одному каталозі" просто не відповідає дійсності. Я також не вніс в дискусію реєстр Windows, який також можна розглядати як зберігання конфігураційних та інших даних про програми Windows і не є частиною каталогу "Файли програм".
YLearn

2
Linux організовує файли встановлених програм? Відколи?
варення

Відповіді:


17

У Linux різні місця, як правило, добре підтримуються, відображають певну логіку. Напр .:

  • /bin містить найосновніші інструменти (програми)
  • /sbin містить найосновніші програми адміністрування

Вони містять елементарні команди, використовувані при завантаженні та фундаментальному усуненні несправностей. І тут ви бачите першу різницю. Деякі програми не призначені для використання звичайними користувачами.

Тоді загляньте /usr/bin. Тут ви повинні знайти більший вибір команд (програм), зазвичай їх більше 1000. Вони є стандартними інструментами, але не такі важливі, як ті, що знаходяться в /binта /sbin.

/usr/binмістить команди, тоді як файли конфігурації перебувають в іншому місці. Це і розділяє функціональні об'єкти (програми), і їх конфігурацію, і інші файли, але з точки зору функціональності користувача це стане в нагоді, оскільки використання команд, не змішаних ні з чим іншим, дозволяє просто використовувати PATHзмінну, що вказує на виконувані файли. Це також вносить ясність. Те, що є, має бути виконаним.

Поглянь на мою PATH,

$ echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/home/tomas/bin
/usr/local/bin
/usr/bin
/bin
/usr/local/games
/usr/games

Існує рівно шість місць, що містять команди, які я можу викликати безпосередньо (тобто не за їхніми шляхами, а за іменами їхніх виконавців).

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

Тепер до /usr/local/bin. Цей дещо слизький, і тут вже було пояснено: Що таке / usr / local / bin? . Щоб зрозуміти це, вам потрібно знати, що папка /usrможе бути спільною для багатьох машин і монтуватися з чистого місця. Команди там не потрібні під час завантаження, як зазначалося раніше, на відміну від тих, що в /bin, тому місце розташування можна монтувати на більш пізніх стадіях процесу завантаження. Він також може бути змонтований лише для читання. /usr/local/binз іншого боку, призначений для локально встановлених програм, і він повинен бути доступним для запису. Тож хоча багато мережевих машин можуть мати загальний /usrкаталог, кожен з них матиме власну /usr/localзмонтовану всередині загальної /usr.

Нарешті, подивіться на PATHмого кореневого користувача:

# echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

Він містить такі:

  • /usr/local/sbin, який містить команди адміністратора типу /usr/local
  • /usr/local/bin, які є тими самими, якими може користуватися звичайний користувач. Знову ж таки, їх тип можна описати як /usr/local.
  • /usr/sbin є несуттєвими утилітами управління.
  • /usr/bin - це неістотні адміністративні та регулярні утиліти користувачів.
  • /sbin є основними інструментами адміністратора.
  • /bin є основними інструментами адміністратора та звичайного користувача.

Дякую. Мене дуже цікавить, як ви організовуєте програми для встановлення /home/tomasz/bin/, дивіться unix.stackexchange.com/questions/431793/…
Тим,

Моє розуміння полягало в тому, що, хоча розділення /binі /usr/binнасправді було уникнення проблем із встановленими на мережу /usrкаталогами, розділення /usrі /usr/localпризначене для розмежування файлів, що постачаються постачальниками ( /usr), та файлів, встановлених вручну на самій машині ( /usr/local), і нічого спільного з цим не має. проблеми з монтажем у мережі. Це точно?
Кейдзі

4
@Keiji, розпорядження постачальника проти локального - це найпоширеніше (і звичайне) використання для цього розрізнення сьогодні, але якщо ви подивитесь на традиційні установки UNIX, /usr-of-a-network (по суті /usr/local, добре, локальний ) не є нечуваним з.
Чарльз Даффі

це все така погана ідея 2018 року
amara

7

В даний час я думаю, що це історична спадщина від класичного UNIX.

У перших версіях UNIX програми не були такими масштабними, як зараз. Програми часто складалися з одного виконуваного файлу, який використовує системні бібліотеки. Отже, ніхто не думав про програми, які будуть складатися з пари власних бібліотек. Головною бібліотекою була бібліотека С, і кожна програма знала про її місцезнаходження.

Також середовище UNIX розглядали як готовий продукт (для підготовки документації). Тому шлях до всіх інструментів був виправлений.

Сьогодні є деякі переваги від фіксованого проходження в жорсткому диску на жорсткому диску. Якщо FSH (ієрархія файлової системи) розділиться на окремі дискові розділи і розмістить розділи з бінарними файлами та бібліотеками біля первинних секторів жорсткого диска, то час запуску програми буде трохи швидшим.


6
Є вагомі переваги, які залишаються корисними і сьогодні. Зберігання бінарних файлів у /usr/binстатичних файлах даних /usr/shareта файлах, які можуть бути змінені, /varабо /usr/varозначає, що заходи безпеки можуть бути використані для забезпечення того, щоб нічого не було shareабо varвиконується (використовуючи noexecпрапорці для їх кріплення); що нічого зовнішнього не varможе бути змінено (у системі, що використовує dm_verityабо подібні заходи для генерації підписаних носіїв, доступних лише для читання); п.
Чарльз Даффі

3

Те, що ви бачите як сучасну систему, схожу на Unix, насправді не є традиційною.

Зазвичай, існують досить мінімальні /і /usrієрархії, що мають лише системні утиліти, а програми потім встановлюються окремо у підкаталог /usr/local, а потім стають доступними шляхом створення символічних посилань.

Дуже типовою установкою для програмного забезпечення GNU було складання та встановлення

./configure
make
make install prefix=/usr/local/DIR/program-1
cd /usr/local/DIR
stow program-1

Утиліта GNU stow створює символічні посилання, щоб забезпечити доступність програмного забезпечення на стандартному шляху, не потребуючи додавання каталогів до змінної PATH (як це робить Windows, і там же скупчується сурова).

Однак сучасні дистрибутиви Linux постачають все як готові пакети, тому програми стали частиною "системи". Оскільки менеджер пакунків піклується про встановлення, немає необхідності в символічних посиланнях, а розділення програм не виконує корисної мети (але це сповільнить запуск програми, оскільки потрібно буде сканувати багато невеликих каталогів).

Якщо ви хочете встановити програмне забезпечення у свій домашній каталог, я пропоную вам також використовувати GNU stow для цього - це дозволить вам тримати свої програми окремо, що розумно, якщо ви не використовуєте менеджера пакунків.

Моя традиційна установка для цього є один каталогом , ~/software/DIRякий я встановлюю програми в, а потім з допомогою Цих всередину , DIRщоб створити ~/software/bin, і ~/software/shareт.д. Це означає , що я повинен тільки додати ~/software/binв змінну PATH , щоб отримати все моє встановлене програмне забезпечення.

Використання:

./configure --prefix=~/software
make
make install prefix=~/software/DIR/program-1
cd ~/software/DIR
stow program-1

встановити, якщо програма дотримується конвенцій GNU.


2

Здається, ви говорите про стиль поділу окремих файлів за призначенням ( /usr/binдля виконуваних файлів, /usr/libдля бібліотек), а не про пакет програм (компілятор C ++ в одному dir, програми редагування зображень в іншому). Хоча в системах Unix велика причина цього історичного періоду, також існують сили сучасного часу, які, як правило, змушують Unix-подібні системи схилятися до цього: менеджери пакетів, які керують більшістю програм у системі.

У Windows, що склалося так, як і раніше, досить багато, додатки відповідали за надання власного інсталятора і, особливо, видалення, і навіть зараз часто не реєструються в будь-якому центральному списку програм. У такій ситуації, як правило, додатку краще мати "власну" каталог для якомога більшої кількості своїх файлів. Це допомагає уникнути конфліктів з іншими програмами, хоча це не завжди виходить (особливо у випадку з DLL ).

Системи Unix, з іншого боку, починаючи з 90-х, як правило, кожен мав єдиного прийнятого менеджера пакетів та групи, що надає велику кількість часто використовуваного програмного забезпечення через цей менеджер пакетів. (Офіційні менеджери пакетів для різних Unices включають yumі aptдля Linux систем, і pkgsrcдля NetBSD, і portsдля FreeBSD. Часто комерційні системи Unix також стикаються з неофіційним, але широко прийнятим менеджером пакетів, наприклад, brewдля MacOS.)

Ці менеджери пакунків мають перевагу в тому, що вони можуть і відслідковувати кожен файл у системі в різних підкаталогах, якими вони володіють. Оскільки одна група присвоює ім'я та місцезнаходження кожного файлу тут, вони можуть використовувати невеликий набір спільних між ними каталогів. Це пропонує різні переваги, особливо в областях обміну файлами між програмами та збереженням невеликої кількості шляхів, необхідних для пошуку бібліотек та виконуваних файлів.

Зважаючи на це, в Unix також існує давня традиція встановлення "окремого каталогу на додаток", як правило, під /optкаталогом.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.