commentarius

Курю документ по дизайну GoboLinux и почему-то кажется, что что-то тут не то. С одной стороны, поставлена цель запускать в полностью-run-time-конфигурабельной среде немодифицированные Unix-программы, а с другой — всё это должно работать на ванильном ядре. Понятно, что так просто не получится: нужно либо программы модифицировать с целью отвязать от compile-time привязки к путям в системе, либо на системном уровне обеспечивать виртуализацию привычного FHS. Может быть даже, ядро при этом удастся оставить вполне ванильным, но где-то на уровне загрузчика исполняемых модулей код виртуализации должен быть всё равно.

Другая проблема в том, что архитекторы GoboLinux всё еще остаются в рамках классического для Unix подхода к программам, в то время как реальность давно уже требует выйти на следующий уровень абстракции. На мой взгляд, современной ОС требуется:
а) уметь из модулей-кирпичиков составлять рабочую среду для приложения и
б) прозрачно отделять конфигурацию приложения от его бинарников.

GoboLinux пытается решать первую задачу, но оставляет за бортом вторую. Хотя если отстраниться от привычных понятий исполняемых файлов, библиотек, конфигураций и взглянуть на систему с точки зрения задач и служб, то мы увидим, что по отношению к задаче «Редактировать ~/todo.txt», исполняемый файл /usr/bin/kate является таким же служебным модулем, как какая-нибудь libqt-mt.so.3 — по отношению к самой kate. С точки зрения пользователя, мы «открываем документ ~/todo.txt в редакторе ~/.kde/share/apps/kate» (ну или где там у вас лежит его конфиг). Какие бинарники при этом грузятся, вообще никого не волнует. Да-да, тот самый документо-ориентированный интерфейс. Только его апологеты не понимают, что невозможно нарисовать в «Наутилусе» красивые иконки и добиться этим мировой гармонии, когда на уровне файловой системы царят бардак и кривые пакетные менеджеры. (Впрочем, они вообще ничего не понимают.)

Что касается практической стороны дела, то для реализации механизма виртуализации достаточно имеющихся средств. Как минимум, можно делать chroot в локальное рабочее окружение при запуске процесса. Другой вариант (требующий минимального вмешательства в ядро) — добавлять нужные симлинки в каталоги процессов в файловой системе proc, чтобы каждый процесс в /proc/self/something видел свой собственный вариант something. В общем, технически ничего сложного, если поставить задачу и всерьёз заняться её решением.

Я, впрочем, еще не дозрел до того, чтобы взяться переделывать GoboLinux на новый лад, с блекджеком и всем остальным, что полагается.