Проект Linux From Scratch отказывается от поддержки классического SysVinit и в дальнейшем будет развиваться только с использованием systemd. Об этом сообщил главный редактор LFS и BLFS Брюс Дуббс. Актуальная на сегодня версия руководств LFS/BLFS 12.4 в варианте с SysVinit останется доступной, однако следующий крупный релиз, запланированный как версия 13.0, будет опубликован исключительно в редакции, ориентированной на systemd.
Linux From Scratch — это подробное руководство по созданию собственной минимальной Linux-системы буквально «из исходников», без использования готовых бинарных дистрибутивов. Пользователь собирает ядро, базовые утилиты, компиляторы, библиотеки и получает рабочую, но ещё довольно «голую» систему. Книга Beyond Linux From Scratch продолжает эту работу: она описывает установку и настройку большого набора прикладного ПО — от серверных компонентов и СУБД до графических окружений рабочего стола, браузеров и медиаплееров.
Исторически LFS предлагала две базовые ветки: с инициализацией на базе SysVinit и с использованием systemd. Таким образом читатель мог как познакомиться с классической моделью запуска и управления сервисами в стиле System V, так и освоить более современный, но гораздо более сложный системный менеджер. Теперь же вариант с SysVinit перестаёт развиваться: он «замораживается» на уровне версии 12.4, а все будущие обновления будут касаться лишь ветки systemd.
Главная причина отказа от обновления SysVinit-редакции — нехватка человеческих ресурсов. Команда LFS и BLFS состоит из небольшой группы волонтёров. Им необходимо отслеживать изменения в 88 пакетах, входящих в базовую книгу LFS, и более чем в тысяче пакетов, описанных в BLFS. Каждое обновление требует сборки, проверки на совместимость, корректировки инструкций и зачастую переписывания разделов. Делать это параллельно для двух разных систем инициализации оказалось физически невозможно.
Дополнительным фактором стало изменение экосистемы Linux. Крупные проекты настольных окружений, такие как GNOME и KDE Plasma, фактически прекратили поддержку конфигураций без systemd. Новые версии этих окружений ожидают наличия функций, предоставляемых именно systemd: механизмов логирования, управления сессиями, udev-инфраструктуры, таймеров, обработчиков питания и так далее. Теоретически часть этих функций можно было бы попытаться воспроизвести в связке с альтернативными init-системами, например на базе OpenRC, но это потребовало бы серьёзной архитектурной работы и всё равно не решило бы главную проблему — нехватку редакторов и тестировщиков.
Брюс Дуббс подчёркивает, что решение отказаться от SysVinit далось ему нелегко и лично его не радует. Он указывает на разительное отличие в масштабе между двумя подходами: systemd включает в себя свыше полутора тысяч файлов на языке C и массу вспомогательных данных, в то время как традиционный SysVinit укладывается примерно в пару десятков C-файлов и около пятидесяти небольших bash-скриптов и конфигураций. SysVinit гораздо проще прочитать, понять и даже модифицировать. Именно поэтому его присутствие в книге долгое время считалось важным с педагогической точки зрения.
По мнению Дуббса, с уходом SysVinit книга действительно теряет значимую учебную составляющую: читателю будет сложнее проследить «от начала до конца», как именно система запускается, инициализирует службы, обрабатывает уровни загрузки. Однако реальность такова, что значительная часть современного пользовательского и настольного ПО ориентируется именно на systemd, а задача редакторов — предоставить работающие рецепты сборки актуальных пакетов, а не сохранять исторические артефакты любой ценой.
Это ставит в повестку принципиальный вопрос: какова главная цель LFS — дать человеку практический способ собрать современную систему или научить его максимально глубоко понимать внутреннее устройство Unix-подобной ОС? На практике книга всегда совмещала обе задачи. С одной стороны, она показывает, как из исходников собрать реальную, пригодную к использованию систему. С другой — каждая стадия сборки раскрывает устройство компиляторов, линкеров, библиотек, init-системы, подсистем пользователей и прав, сетевых инструментов и многого другого.
Отказ от SysVinit отчасти меняет баланс между «учебной» и «прагматичной» сторонами LFS. Классическая, минималистичная модель инициализации на базе System V — это почти учебник по тому, как устроен запуск процессов в Unix: простые сценарии, прозрачные точки входа, понятные runlevel’ы. Systemd, напротив, представляет собой огромный комплекс с собственной логикой, форматом юнитов, бинарными логами и плотной интеграцией с остальными компонентами системы. Разобраться в нём сложнее, и «с ходу» увидеть общую картину запуска системы уже не так просто.
Однако важно понимать: цели LFS не исчезают и не «предаются». Они трансформируются под текущие условия экосистемы. Если задача — научить пользователя понимать современные Linux-системы, то игнорировать systemd уже невозможно: в серверном и настольном сегменте он де-факто стал стандартом. С этой точки зрения переход на единую init-систему не противоречит духу проекта, а скорее признаёт изменение реальности. Человек, который сегодня выходит на работу администратором или инженером по инфраструктуре, с гораздо большей вероятностью столкнётся именно с systemd, а не с SysVinit.
Обвинять Дуббса в том, что он «разрушает» LFS, было бы поверхностно. Он откровенно говорит: если попытаться в одиночку тянуть и SysVinit, и systemd, при нынешнем объёме пакетов, качество и актуальность всей книги просто просядут. Альтернатива — распылить и без того ограниченные ресурсы, устать, выгореть и в итоге не поддерживать корректно ни один из вариантов. В таком контексте выбор одной опорной технологии — это, скорее, попытка сохранить жизнеспособность проекта, чем саботаж.
При этом никто не отнимает у читателей возможность использовать старые версии книги с SysVinit. Версия 12.4 останется доступной, и желающие по-прежнему смогут пройти путь сборки классической системы, понять устройство System V init и получить тот самый «просветляющий» опыт работы с простым init. Более того, накопленные знания никуда не исчезают: даже если новые релизы сосредоточены на systemd, старые материалы могут служить дополнительным учебником по архитектуре Linux.
Для тех, кто подходит к LFS как к учебному курсу, переход на systemd имеет и положительную сторону. Теперь есть повод глубже разобраться, почему крупные среды рабочего стола, сетевые менеджеры, политики безопасности и многие другие компоненты так сильно завязаны на systemd. Понимание связей между подсистемами, зависимостей юнитов, работы журнала и механизма сокет-активации — это уже уровень, который прямо соответствует реальной практике администрирования современных дистрибутивов.
Нельзя не отметить и более широкий контекст спора вокруг systemd. Исторически Linux и многие Unix-подобные системы строились по принципу «делай одну вещь и делай её хорошо», с упором на множество небольших утилит, связанных между собой простыми интерфейсами. Systemd, по мнению его критиков, нарушает этот принцип, беря на себя слишком много функций: от инициализации и управления службами до логирования, управления устройствами и пользовательскими сессиями. Сторонники же утверждают, что интеграция позволяет обеспечить более предсказуемое поведение, лучшее управление зависимостями, параллельный запуск служб и повышенную надёжность.
LFS оказывается в центре этой дискуссии не по своей воле, а как учебный проект, который вынужден выбирать: сохранять максимально чистую, классическую модель ради «идеологии» или следовать за мейнстримом ради прикладной полезности. Ставка сделана на второе. Но это не отменяет того, что понимание традиционного init по-прежнему важно для общего технического кругозора. Для желающих углубиться ничто не мешает дополнить чтение LFS другими материалами, освещающими историю и архитектуру SysVinit, OpenRC или runit.
Ещё один аспект — выбор окружений и наборов пакетов в BLFS. Многие задаются вопросом: если цель — обучение, то действительно ли нужно тянуть в книгу тяжёлые графические оболочки, которые завязаны на systemd? Почему бы не ограничиться консольным окружением и набором легковесных приложений, тем самым сохранив независимость от конкретного системного менеджера? Ответ здесь тоже упирается в баланс между «минимализмом ради чистоты» и «практической полезностью». Большая часть пользователей хочет в итоге получить систему, на которой можно запускать современные браузеры, мультимедиа, офисные пакеты и знакомое им графическое окружение. Без этого LFS для многих останется лишь академическим экспериментом.
В конечном счёте, решение отказаться от поддержки SysVinit в новых версиях LFS и BLFS показывает, в каком направлении развивается мир Linux. Он становится менее «мозаичным» на уровне базовой инфраструктуры и более унифицированным вокруг крупных проектов вроде systemd. Для одних это повод для критики и ностальгии по «старому доброму Unix», для других — шаг к предсказуемости и удобству. LFS как учебный проект вынужден учитывать этот тренд, если хочет оставаться актуальным.
Тем, кто подходит к LFS прежде всего как к школе системного мышления, можно рекомендовать использовать обе линии развития: изучить версию 12.4 с SysVinit, чтобы освоить классическую модель инициализации, а затем пройти по цепочке сборки версии 13.0 и выше с systemd, чтобы увидеть, как устроена сегодняшняя реальность. Контраст между этими подходами даёт куда более глубокое понимание принципов работы операционной системы, чем жёсткая привязка к одному «правильному» варианту. Именно это — умение сравнивать, анализировать и осмысленно выбирать — и остаётся настоящей целью Linux From Scratch, независимо от того, какая система инициализации стоит у него в оглавлении.
