Kiosk Gui, но не ограничиваясь WebBrowsing

Во-первых, сразу оговорка о конфликте интересов: я давно являюсь разработчиком 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 Australia); я также записал свои заметки в прозе. На сайте GoboLinux также есть несколько старых документов, включая знаменитое "I am not clueless", в котором рассматриваются некоторые возражения и вопросы. Я думаю, что в наши дни мы все уже не так горячи, и подозреваю, что в будущем выпуске будет принято /usr в качестве базового местоположения для симлинков.

NixOS

NixOS помещает каждую установленную программу в свой собственный каталог под /nix/store. Эти каталоги называются примерно /nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/ - там находится криптографический хэш, представляющий весь набор зависимостей и конфигураций, ведущих к этой программе. Внутри этого каталога находятся все связанные файлы с более или менее обычными локальными расположениями.

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

LFS

Довольно просто пройти через Linux From Scratch и установить именно ту иерархию, которую вы хотите: просто создайте каталоги и настройте всё так, чтобы оно устанавливалось в нужное место. Я делал это несколько раз при создании экспериментов с GoboLinux, и это не намного сложнее, чем обычная LFS. В этом случае вам нужно сделать совместимые симлинки; в остальном это значительно сложнее, но осторожное использование union mounts может избежать этого, если вы действительно этого хотите.

Мне кажется, что когда-то был LFS Hint именно об этом, но я не могу найти его сейчас.

О выполнимости

Дело в том, что FHS - это стандарт, он очень распространен, и в целом отражает существующее использование на момент его написания. Большинство пользователей никогда не будут работать в системе, которая по сути не соответствует этой схеме. В результате этого многие программы имеют скрытые зависимости, которые никто не осознает, часто совершенно непреднамеренно.

Все эти скрипты с #!/bin/bash? Ничего хорошего, если у вас там нет Bash. Вот почему в GoboLinux есть все эти симлинки совместимости; это просто практично. Многие программы не работают либо во время сборки, либо во время выполнения при нестандартной компоновке, и тогда для их исправления требуются исправления, часто довольно навязчивые.

Ваша базовая программа Autoconf обычно с радостью установит себя туда, куда вы ей скажете, и довольно легко автоматизировать процесс передачи правильного -префикса. Другие системы сборки не всегда так добры, либо намеренно нарушая иерархию, либо заставляя авторов писать непортируемую конфигурацию. CMake - главный нарушитель в последней категории. Это означает, что если вы хотите жить в этом мире, вы должны быть готовы к тому, что придется проделать много сложной работы в чужих системах сборки. Это очень неприятно, когда приходится динамически исправлять сгенерированные файлы во время компиляции.

Время выполнения - это опять же другой вопрос. Многие программы имеют предположения о том, где находятся их собственные или чужие файлы, относительно их или абсолютно. Когда вы начинаете использовать симлинки для представления последовательного представления, многие программы имеют ошибки в работе с ними (или иногда, возможно, правильное поведение, которое вам не поможет). Например, инструмент foobar может ожидать найти исполняемый файл baz рядом с ним или в ../sbin. В зависимости от того, читает ли он свою симлинку или нет, это могут быть два разных места, и ни одно из них не может быть правильным в любом случае.

Объединенная проблема - это каталог /usr/share. Конечно, он предназначен для общих файлов, но когда вы помещаете каждую программу в свой собственный префикс, они перестают быть общими. Это приводит к тому, что программы не могут найти стандартные иконки и тому подобное. GoboLinux решал эту проблему довольно уродливым способом: во время сборки $prefix/share был симлинком на $prefix/Shared, а после сборки ссылка указывала на глобальный каталог share. Теперь для работы с share (и другими каталогами) используется "песочница" времени компиляции и перемещение файлов, но ошибки времени выполнения при чтении ссылок все еще могут быть проблемой.

Пакеты из нескольких программ - еще одна проблема. GoboLinux так и не смог добиться полноценной работы GNOME, и я не верю, что NixOS тоже, потому что взаимозависимости в компоновке настолько сильны, что вылечить их все просто нереально.

Итак, да, это осуществимо, но:

• Существует довольно много работы, связанной с тем, чтобы просто заставить вещи функционировать.
• Некоторые программы могут просто никогда не работать.
• Люди будут смотреть на вас смешно.

Все это может быть или не быть проблемой для вас.

¹ Версия 14.01 использует /System/Index, который отображается непосредственно на /usr. Я подозреваю, что будущая версия может отказаться от иерархии Links/Index и использовать /usr повсеместно.

² По умолчанию требуется наличие /bin/sh.