Как сделать хороший дистрибутив, чтобы не получился «BolgenOS» (Аркадий Шейн, OSSDEVCONF-2024)

Ссылки сюда (1) →

Короткая ссылка: 20241005G

Докладчик

Аркадий Шейн

Докладчик поделится личным опытом создания различных дистрибутивов Linux в России и рассмотрит проблему дистрибутивов, основанных на Red Hat Enterprise Linux.

Презентация

Thesis

В 2011 году на просторах российского сегмента сети Интернет появилась новость о выходе «Принципиально новой революционной операционной системы», которая получила название BolgenOS. Главным и единственным разработчиком дистрибутива был школьник из Нижнего Тагила. Новость облетела различные новостные ленты, включая Linux.org.ru и Хабр, а на местном ТВ даже появился репортаж.

Однако при ближайшем рассмотрении BolgenOS оказалась всего лишь немного изменённым дистрибутивом Ubuntu с удалёнными копирайтами и «нескучными обоями».

С тех пор название BolgenOS стало нарицательным, а любой новой ОС, основанной на пакетной базе другого дистрибутива Linux, злыми языками неизменно навешивается ярлык BolgenOS.

Автор, основываясь на личном опыте, проанализирует создание различных дистрибутивов, основанных на пакетной базе Red Hat, начиная с 90-х годов, и попытается ответить на вопрос, чем же самостоятельный дистрибутив отличается от «BolgenOS».

Первые дистрибутивы Linux не имели не только никакой русификации, но и никакой локализации. Если вам удалось поставить условный Red Hat Linux 5.0, то после установки вы понимаете, что не можете ни писать, ни читать на русском языке.

Проблемы была намного глубже, чем кажется на первый взгляд. В документе The Linux Cyrrilic HOWTO от 1998 года насчитывается двенадцать глав. Это и проблема со шрифтами, и с раскладками клавиатуры, с TeX’ом и т. п.

На этой почве стали появляться первые исправленные версии Red Hat Linux. Сначала это был Urban Soft, потом появились Красная Шапочка и Red Hat MSIU, затем Black Cat Linux, который превратился в ASPLinux.

В Московском государственном индустриальном университете был создан респин MSIU ASPLinux который содержал большое количество обновлений и изменений под учебный процесс.

Постепенно изменения попадали в upstream, и острая нужда в подобных дистрибутивах отпала. Однако в 2008 году появился ещё один респин — Russian Fedora. Сперва дистрибутив возник как ответ на проблему с установкой Fedora 9 на русском языке, а затем как позыв к образованию сообщества в рамках инициативы Red Hat по созданию сертифицированного центра в России. В итоге дистрибутив выдержал 30 релизов.

На сегодняшний день за границей существует большое количество дистрибутивов как платных, так и бесплатных, основанных на пакетной базе Red Hat Enterprise Linux. Это Oracle Linux, AlmaLinux, Rocky Linux, EuroLinux, MiracleLinux, CloudLinux. В России же до недавнего времени не существовало ни одного дистрибутива основанного на 8 или 9 версии RHEL, хотя спрос на подобные дистрибутивы существует, например, на рынке хостинга.

С чем это было связано? В основном с тем, что в отличии от принципиально лёгкой пересборки RHEL 6/7 (обычно это делали основываясь на пакетной базе CentOS), собрать 8 или 9 версию совсем не так просто. На сборку «МСВСфера» 8 мы потратили четыре месяца. Это связано и с модульными пакетами и с тем, что в актуальном окружении старые пакеты уже не собираются.

ОС «МСВСфера» на данный момент полностью повторяет пакетную базу RHEL, а также содержит различные дополнения и улучшения, например, возвращена поддержка технологии SPICE, обновлён LibreOffice, добавлена возможность прослушивать музыку и смотреть фильмы и т. д.

Так что же нужно, чтобы у вас получился хороший самостоятельный дистрибутив?

• Система контроля версий для хранения исходных текстов доступная всему сообществу. Это важный шаг в открытой разработке.
• Система сборки (Koji) + Modular Build System (для сборки модульных пакетов).
• Багтрекер для регистрации ошибок от сообщества.
• Репозиторий (в том числе для исходников и debug-пакетов).
• Errata/OVAL (для сканеров уязвимостей).
• Документация.
• Система тестирования дистрибутива.
• Запись в реестре и сертификация ФСТЭК.
• «Нескучные обои», куда без них.

Но главное нужна команда, которая понимает, что нужно делать.

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

Вы можете делать респины (без пересборки всех пакетов) какого-либо дистрибутива (будь то Fedora или ALT Linux) для удобства использования скажем в образовательной среде или под конкретные внутренние задачи, главное не забывать указывать источник пакетов.

И главное нужно стараться всегда отправлять важные изменения в upstream.