Навіщо я будую незалежний український дистрибутив Linux з нуля

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Мене звати Юрій. Я фул-стек розробник, більшу частину часу пишу на Python і вожусь з інфраструктурою на Linux. Кілька місяців у вільний час я будую власний дистрибутив Linux і дійшов до моменту, коли є що показати. Ця стаття для тих, кому цікаво, як влаштована операційна система нижче рівня звичного пакетного менеджера, і для тих, хто думає про технологічну незалежність не як про гасло, а як про практичне інженерне завдання.

Одразу чесно про головне. Це не готовий до продакшену продукт. Це рання версія. Але основа вже стоїть, і саме про основу я хочу розповісти, бо вона і є найскладнішою частиною.

Чому ще один дистрибутив, та ще й в Україні

Більшість дистрибутивів Linux це форки. Хтось бере Debian, хтось Arch чи Fedora, додає свою тему, набір програм, інсталятор, і виходить новий дистрибутив. Це нормальний підхід, він дає швидкий результат. Але в основі завжди лежить чужа пакетна база, чужі рішення про те, як зібрано систему, звідки беруться бінарники і кому ви довіряєте на найнижчому рівні.

Я хотів іншого. Систему, де кожен бінарник можна простежити до його вихідного коду, рецепта збірки і всіх залежностей, без непрозорого шару під ним. І хотів, щоб це був український проєкт, бо технологічна незалежність зараз для нас не абстракція.

Подібних українських проєктів я не зустрічав. Є локалізації, є збірки на базі чужих систем, і це гарні речі. Але незалежного дистрибутива, який збирається повністю з вихідного коду і не є форком, серед українських я не бачив. Можливо, десь такий є і я просто про нього не знаю, тому категорично казати не буду. Але ніша довго була порожньою, і це одна з причин, чому я взявся.

Що означає незалежний насправді

Це слово легко сказати і складно довести. У моєму випадку незалежність означає буквально таке. Уся система, від базового набору інструментів компіляції до робочого столу, збирається з вихідного коду єдиним механізмом. Під нею немає чужої пакетної бази. Немає кроку, де ми просто беремо готову чужу систему і ставимо поверх неї косметику.

Це найважча частина і найдовша. Починати доводиться з того, що в системі ще нічого немає, навіть нормального компілятора, і треба підняти ланцюжок інструментів, який збере сам себе, а потім уже все інше. У світі це відомий жанр, але одна справа прочитати, як це робиться, а інша зробити так, щоб воно ще й трималося купи на щодень.

Кілька разів я думав, що це авантюра. Найбільш виснажливе тут не складність окремого кроку, а те, що помилка на ранньому етапі валить усе, що йде далі. Збираєш десятки пакетів, на якомусь глибоко всередині спливає, що ще на самому початку щось зібралося трохи не так, і ти повертаєшся в початок. Це окремий жанр терпіння, і саме на цьому етапі відсіюється більшість подібних спроб.

Окремою пригодою стала інфраструктура збірки. Важкі збірки дають таку лавину навантаження на диск, що це одного разу почало ронити сусідній продакшен на тому ж сервері. Процеси висли в очікуванні диска, система вважала сервіси мертвими і перезапускала їх, перезапуск давав ще більше навантаження, і петля годувала сама себе. Довелося розбиратися, виносити збірку в оперативну памʼять і перебудовувати роботу з диском, щоб важка компіляція не вбивала все навколо. Це той випадок, коли проблема виглядала як завантаження процесора, а насправді все впиралося в один повільний диск. Урок дався дорого, але після нього я почав інакше дивитися на те, де насправді вузьке місце.

Свій пакетний менеджер, бо без нього незалежності немає

Тут я зробив принципову річ. У системи свій пакетний менеджер. Не обгортка над чужим, а окремий механізм. Я назвав його promin, від слова промінь, у тон назві самого дистрибутива, Svitlo, тобто світло.

Ідея в основі близька до підходу, який багато хто знає за NixOS. Кожен пакет ставиться в окремий шлях, який однозначно визначається тим, з чого його зібрано. Завдяки цьому кілька версій одного пакета спокійно живуть поруч і не конфліктують. А головне, відкат системи до попереднього робочого стану займає секунди, бо переключення між станами це проста і миттєва операція. Якщо оновлення щось зламало, ви повертаєтесь назад одразу, без танців з бубном.

Для користувача при цьому встановлення пакетів швидке, як у звичайному дистрибутиві. Збірка з вихідного коду це деталь, яка живе на стороні інфраструктури, а не біль кінцевого користувача.

Логічне питання, навіщо писати пакетний менеджер самому, коли є готові. Відповідь проста. Готовий менеджер тягне за собою готову екосистему і готові рішення, а я будував систему, де хочу контролювати весь ланцюжок від вихідного коду до встановленого бінарника. Якби я взяв чужий менеджер, незалежність закінчилася б рівно там, де починається його база. Свій менеджер це не про синдром велосипеда, а про те, що він і є тією точкою, де визначається довіра до системи. Написати його було довго, але без цього весь задум не мав би сенсу.

Сучасний робочий стіл, зібраний чесно

Робочий стіл у системі сучасний, на новій графічній архітектурі без старого спадку. Він теж зібраний з вихідного коду, без готових бінарних блобів, які зазвичай просто кладуть у систему як є. Це додало роботи, бо багато речей у світі Linux за замовчуванням постачаються вже готовими, і коли збираєш їх сам, спливає купа припущень про те, що зазвичай ніхто не перевіряє.

Найбільше здивувало, скільки всього в типовій системі тягнеться за компонентами без явного запиту. Збираючи стіл самотужки, я кожну таку залежність бачив у обличчя і кожного разу вирішував, чи вона тут справді потрібна. Частину речей, які зазвичай їдуть у систему за інерцією, я свідомо лишив за бортом. Це і є та різниця між зібрати з нуля і взяти готове, ти бачиш справжній склад системи, а не той, який тобі дістався у спадок.

Чесно про стан, бо інакше не можна

Я свідомо не хочу видавати бажане за дійсне, тому скажу прямо, що зроблено, а що ні.

Працює інфраструктура збірки. Працює пакетний менеджер. Система здатна керувати собою сама. Є завантажувальний образ із графічним робочим столом, який можна запустити і подивитись.

Чого ще немає. Частину речей, які я закладав в архітектуру з самого початку, як то шифрування збережених даних і повна відсутність телеметрії, поки що заявлено як ціль, а не як готовий стан. Я волію чесно називати це планом, ніж видавати за зроблене. Для щоденного використання на основній машині ще рано.

Це бета в прямому сенсі слова. Я показую її не тому, що вона готова, а тому, що основа достатньо міцна, щоб про неї говорити і збирати критику.

Навіщо я це розповідаю

Кілька причин. По-перше, мені потрібна критика підходу від людей, які розуміють, про що йдеться. Коли довго працюєш над чимось наодинці, око замилюється, і свіжий погляд збоку вартий багато. По-друге, я хочу, щоб про можливість незалежного українського дистрибутива просто знали, бо це довго було порожньою нішею. По-третє, якщо комусь із читачів близька тема відтворюваних збірок, прозорого ланцюга постачання чи просто цікаво, як влаштований Linux на найнижчому рівні, можливо, це підштовхне до власних експериментів або до участі.

Якщо чесно, я роблю це передусім тому, що мені це цікаво до тієї міри, що я витрачаю на це вечори і вихідні замість відпочинку. Є в цьому й спокійне відчуття, що робиш щось своє і українське в галузі, де ми звикли користуватися чужим. Не з гучних мотивів, а просто тому, що хочеться, щоб таке в нас було.

Що далі

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

Якщо вам цікаво подивитись або поставити технічні питання, я радо відповім у коментарях. Сам проєкт некомерційний і відкритий.

Сайт проєкту: svitlolinux.org

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