По-перше, попередня відмова від конфлікту інтересів: я давно розробник GoboLinux.
По-друге, напередодні вимоги доменної експертизи: я давно розробник GoboLinux.
У поточному використанні є кілька різних структур. GoboLinux має такий, і такі інструменти, як GNU Stow , Homebrew тощо, використовують щось досить схоже (в першу чергу для програм користувача). NixOS також використовує нестандартну ієрархію програм та філософії життя. Це також досить поширений експеримент LFS.
Я збираюся описати все це, а потім прокоментую досвід, як це відбувається на практиці ("здійсненність"). Коротка відповідь полягає в тому, що так, це можливо, але ви повинні дійсно цього бажати .
GoboLinux
GoboLinux має структуру, дуже схожу на описану вами. Програмне забезпечення встановлюється під /Programs: /Programs/ZSH/5.0.8містить всі файли , що належать ZSH 5.0.8, в звичайних bin/ lib/ ... каталогах. Системні інструменти створюють посилання на ті файли в /System/Linksієрархії, які відображаються на /usr¹. PATHМінлива містить тільки єдиний уніфікований виконуваний каталог, і LD_LIBRARY_PATHне використовується. Кілька версій програмного забезпечення можуть співіснувати одночасно, але тільки один файл із заданим іменем ( bin/zsh) буде зв’язаний активно відразу. Ви можете отримати доступ до інших по повному шляху.
Набір сімлінок сумісності також існує, так /binі /usr/binкарти до єдиної директорії виконуваних файлів, і так далі. Це полегшує життя програмного забезпечення під час роботи. Патч ядра, GoboHide, дозволяє приховувати ці посилання на сумісність від списків файлів (але все ще проходять).
На противагу іншій відповіді, вам не потрібно змінювати код ядра: GoboHide суто косметичний, і ядро взагалі не залежить від шляхів простір користувачів². GoboLinux має замовлену систему init, але цього також робити не потрібно.
Мітка завжди була "файлова система - менеджер пакунків", але в системі є досить звичайні засоби управління пакетами. Ви можете все робити cp, rmі ln, хоча.
Якщо ви хочете використовувати GoboLinux, ви дуже раді. Я зазначу, що це невелика команда розробників, і ви, ймовірно, виявите, що якесь програмне забезпечення, яке ви хочете, не упаковується, якщо ніхто раніше не хотів ним користуватися. Хороша новина полягає в тому, що побудувати програму для системи взагалі досить просто (стандартний "рецепт" триває близько трьох рядків); погана новина полягає в тому, що іноді це неприємно складно, про що я розповім докладніше нижче.
Публікації
Є кілька «публікацій». Я виступив з презентацією на linux.conf.au 2010 про систему в цілому, яка охоплює все в цілому, що доступне у відео: ogv mp4 (також у вашому локальному дзеркалі Linux в Австралії); Я також записував свої замітки до прози. На веб-сайті GoboLinux також є декілька старих документів, серед яких відомий " Я не знаю " , де розглядаються деякі заперечення та проблеми. Я думаю, що всі ми трохи менше гунг-хо в ці дні, і я підозрюю, що майбутній реліз буде прийнятий як базове місце для посилань./usr
NixOS
NixOS ставить кожну встановлену програму у свій каталог під /nix/store. Ці каталоги названі чимось на кшталт /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/- є криптографічний хеш, який представляє весь набір залежностей і конфігурації, що ведуть до цієї програми. Всередині цього каталогу знаходяться всі пов’язані файли з більш-менш нормальними локальними місцями.
Це також дозволяє мати декілька версій одночасно та використовувати будь-яку з них. NixOS має цілу філософію, пов’язану з нею відтворюваної конфігурації: вона по суті має систему управління конфігурацією, вкладену в неї з самого початку. Він покладається на деякі екологічні маніпуляції, щоб представити користувачеві правильний світ встановлених програм.
LFS
Досить просто перейти через Linux From Scratch і налаштувати саме ту ієрархію, яку ви хочете: просто створіть каталоги та налаштуйте все, щоб встановити в потрібному місці. Я робив це кілька разів, будуючи експерименти з GoboLinux, і це не суттєво складніше, ніж звичайний LFS. У цьому випадку вам потрібно зробити посилання на сумісність; в іншому випадку це набагато важче, але обережне використання кріпильних з'єднань, можливо, може цього уникнути, якщо ви дійсно цього хотіли.
Я відчуваю, що був підказка LFS про саме це в один момент, але я не можу зараз знайти його.
Про доцільність
Справа в FHS полягає в тому, що це стандарт, він дуже поширений, і він широко відображає існуюче використання на той час, коли він був написаний. Більшість користувачів ніколи не будуть мати систему, яка по суті не дотримується цієї верстки. Результатом цього є те, що багато програмного забезпечення мають приховану залежність від нього, яку ніхто не усвідомлює, часто зовсім ненавмисно.
Усі ці сценарії #!/bin/bash? Нічого добре, якщо у вас там немає Баша. Ось чому GoboLinux має всі ці посилання на сумісність; це просто практично. Багато програмного забезпечення не спрацьовує ні під час збирання, ні під час запуску за нестандартним макетом, і тоді воно потребує виправлення, щоб виправити, часто досить нав'язливо.
Ваша основна програма Autoconf зазвичай із задоволенням встановлює себе там, де ви це скажете, і досить легко автоматизувати процес передачі в правильному --prefix. Інші системи побудови не завжди такі приємні, чи навмисно випікання в ієрархії, або провідні автори для написання не портативної конфігурації. CMake є головним правопорушником в останній категорії. Це означає, що якщо ви хочете жити в цьому світі, ви повинні бути готові до того, щоб зробити багато завзято працюючих в інших системах нарощування. Справжнє клопотання потрібно динамічно виправляти створені файли під час компіляції.
Виконання - знову інша справа. Багато програм мають припущення щодо того, де їх власні файли чи чужі файли знаходяться або відносно них, або абсолютно. Коли ви починаєте використовувати символьні посилання для представлення послідовного перегляду, у багатьох програмах виникають помилки, що обробляють їх (або іноді, напевно, правильна поведінка, яка вам не корисна). Наприклад, інструмент foobarможе очікувати, що він знайде bazвиконуваний поруч або в ньому ../sbin. Залежно від того, читає воно симпосилання чи ні, це можуть бути два різних місця, і жодне з них не може бути правильним.
Поєднана проблема - це /usr/shareкаталог. Це, звичайно, для спільних файлів, але коли ви вставляєте кожну програму у свій префікс, вони фактично не поділяються. Це призводить до того, що програми не можуть знайти стандартні піктограми тощо. GoboLinux розібрався з цим досить потворно: під час збирання $prefix/shareбуло символьним посиланням на $prefix/Shared, а після побудови посилання було вказано на глобальний shareкаталог. Тепер для використання share(та інших каталогів) тепер використовується пісочниця компіляції та руху файлів , але помилки під час читання посилань все ще можуть бути проблемою.
Набори декількох програм - ще одна проблема. GoboLinux ніколи не змушував GNOME працювати повноцінно, і я не вірю, що в NixOS це також є, тому що взаємозалежності компонування настільки випікані, що вилікувати їх усіх просто неможливо.
Так, так, це можливо , але:
- В роботі над тим, щоб речі просто функціонували, досить багато.
- Деякі програми можуть просто ніколи не працювати.
- Люди будуть дивитись на вас смішно.
Все це може чи не може бути проблемою для вас.
Uses Використовується версія 14.01 /System/Index, яка відображається безпосередньо на /usr. Я підозрюю, що майбутня версія може відмовитись від ієрархії посилань / індексів та використовувати її на /usrвсій основі.
² Це вимагає /bin/shіснування за замовчуванням.