Історія дистрибутивів Linux: Slackware, Debian і Red Hat

Що насправді таке дистрибутив Linux

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

Він складається з п’яти частин. Змініть будь-яку з них — і отримаєте інший дистрибутив, навіть якщо більшість бінарних файлів збігається:

• Ядро певної версії, вибраної проєктом, із доданими ним патчами та драйверами.
• Userland: бібліотека C, shell, система init, стандартні команди.
• Формат пакетів і інструмент для їх встановлення.
• Політика випусків: що може змінюватися, як часто це відбувається та як довго підтримується кожен випуск.
• Люди: мейнтейнери пакетів, команда безпеки та відповідальні фахівці, які реагують, коли пакет перестає працювати.

Ядро є спільною частиною, тому два дистрибутиви Linux набагато ближчі один до одного, ніж будь-який із них до іншої Unix-системи. Це важливо пам’ятати, коли ви порівнюєте Linux і FreeBSD як серверні платформи, де ядро та базовий userland створює один проєкт і випускає їх разом. У Linux ці компоненти надходять від окремих upstream-проєктів, а дистрибутив забезпечує їхню сумісну роботу.

Історія дистрибутивів Linux у трьох сімействах

Три проєкти, започатковані у 1993 і 1994 роках, стали основами сімейств: Slackware, Debian і Red Hat. Майже кожен образ у панелі керування VPS сьогодні є одним із них або похідним від нього. Похідний дистрибутив успадковує формат пакетів, структуру файлової системи та зазвичай підхід до випуску релізів. Саме тому похідний дистрибутив Debian усе ще поводиться як Debian, навіть якщо прибрати брендинг.

Незалежні дистрибутиви варто розглянути окремо, оскільки вони не були форками інших проєктів. Arch, Gentoo, Alpine, NixOS і Void створили власні менеджери пакетів і власні правила. Два з них, Arch і Alpine, зрештою все одно потрапили до списку образів вашого провайдера з причин, не пов’язаних із настільними системами.

1992: дистрибутиви до появи сімейств

MCC Interim Linux з’явився в лютому 1992 року. Його зібрав Owen Le Blanc у Manchester Computing Centre. Дистрибутив містив kernel і GNU (GNU's not Unix) tools у двох образах floppy-дискет та мав інсталятор із меню. Він був потрібен, бо ручне виконання цієї роботи займало цілий день.

SLS (Softlanding Linux System), випущений Peter MacDonald у 1992 році, пішов далі та додав X (the X Window System) і TCP/IP networking. Саме SLS сформував сучасне значення слова distribution. Водночас він містив багато помилок і повільно супроводжувався. У 1993 році двоє людей незалежно вирішили це виправити. Один перебудував його. Інший почав з нуля, спираючись на письмові правила.

Slackware, 1993: найстаріше сімейство, яке досі випускає релізи

Patrick Volkerding випустив Slackware 1.00 16 July 1993 року. Дистрибутив було створено на основі SLS з виправленими помилками. Slackware досі підтримується, тому це найстаріший Linux-дистрибутив, що зберігся.

Пакет Slackware — це стиснений tar-архів із інсталяційним скриптом усередині. Автоматичного розв’язання залежностей немає: ніщо не перевіряє, чи є на диску бібліотека, потрібна новому пакету. Це рішення визначило все інше. Якщо інструмент не розв’язує залежності, набір пакетів має бути узгодженим уже під час формування. Тому релізи виходять рідко й мають консервативний характер. Slackware 15.0 вийшов у February 2022 року, через шість років після 14.2.

Це невелике сімейство. Перші релізи SUSE у середині 1990-х були створені на основі Slackware, перш ніж проєкт пішов власним шляхом із YaST, а згодом і форматом пакетів RPM. Остання частина часто вводить в оману. SUSE та openSUSE використовують пакети RPM і не є похідними від Red Hat. Формат поширився. Спадкоємність — ні.

Debian, 1993: соціальний контракт і конвеєр із трьома гілками

Ian Murdock оголосив про Debian 16 August 1993, через три тижні після Slackware і з тієї самої причини. Назва поєднує ім’я його партнерки Debra з його власним. У січні 1994 року з’явився Debian Manifesto, який визначив основні умови: цей дистрибутив мали відкрито підтримувати волонтери, а не компанія.

Згодом Debian зафіксував ці умови письмово. Debian Social Contract і DFSG (Debian free software guidelines) ухвалили в липні 1997 року, а DFSG у 1998 році стали основою Open Source Definition. Документ, створений для визначення того, що може входити до одного дистрибутива, зрештою визначив категорію ліцензій для всієї індустрії. Саме тому ваш sources.list має компоненти: main містить програмне забезпечення, що відповідає цим настановам, contrib і non-free містять те, що їм не відповідає, а Debian 12 додав non-free-firmware, щоб ноутбук із бездротовою картою можна було встановити без тривалого пошуку необхідних драйверів.

Інша важлива спадщина — інструменти. dpkg встановлює один пакет і завершує роботу, якщо чогось бракує, виводячи dpkg: dependency problems prevent configuration of. APT (advanced package tool), який став типовим інструментом у Debian 2.1 у 1999 році, визначає, що ще потрібно завантажити і в якому порядку. Кожна команда apt у кожному похідному від Debian дистрибутиві походить від цієї роботи.

Механізм випуску має три гілки й одне правило. Супроводжувач завантажує пакет до unstable, яка постійно має кодову назву sid. Скрипт переносить пакет до testing приблизно через 5 to 10 днів, якщо пакет зібрався для архітектур випуску і не отримав нової критичної для випуску помилки. Потім testing заморожують, команда випуску усуває решту проблем, а stable випускають, коли список помилок стає достатньо коротким. Не за календарною датою. Тому Debian stable здається застарілим, але працює стабільно: номери версій перестають змінюватися після заморожування, а виправлення безпеки й надалі переносять до цих версій.

Система управління також формалізована: є обраний керівник проєкту та обов’язкові загальні резолюції. У 2014 році цей механізм обрав systemd типовою init-системою, а незгодні з цим рішенням розгалузили проєкт у Devuan, який випустив першу версію у 2017 році. Найбільші похідні дистрибутиви — Ubuntu, Raspberry Pi OS, Proxmox VE, Kali і Linux Mint.

Red Hat, 1994: RPM, а потім поділ на Fedora і RHEL

Marc Ewing випустив першу Red Hat Linux приблизно на Гелловін 1994 року. У 1995 році компанія Bob Young придбала цей продукт, і разом вони створили перший Linux-бізнес, який продавав не програмне забезпечення, а підтримку. Red Hat вийшла на біржу 11 August 1999 року. IBM завершила придбання компанії в July 2019 року приблизно за 34 billion dollars, тому дистрибутив, із яким сертифікують більшість корпоративного програмного забезпечення, відтоді належить IBM.

Головний довготривалий технічний внесок — RPM (Red Hat package manager), створений Erik Troan і Marc Ewing для Red Hat Linux 2.0 у 1995 році. Пакет RPM оголошує свої залежності та створюється з spec file — рецепта складання, який може виконати будь-хто. Саме друга властивість згодом зробила незалежне відтворення enterprise-продукту Red Hat взагалі можливим.

Red Hat Linux 9 у 2003 році стала останнім випуском початкової лінійки. Компанія розділила її на дві частини: Fedora Core 1 у November 2003 року як швидкий community-випуск і RHEL (Red Hat Enterprise Linux), що почалася як Advanced Server 2.1 у 2002 році, як повільний платний продукт. Причина очевидна. Один продукт не може одночасно бути місцем для випробування нових версій і платформою, яку банк використовує без змін протягом десяти років. Ці дві частини пов’язані: major-версія RHEL відгалужується від випуску Fedora, стабілізується, а потім заморожується. Пакетний інструмент розвивався за тим самим графіком: від yum у 2000-х роках до dnf як стандартного інструмента Fedora у 2015 році, а під обома працює rpm.

Чому CentOS перестав бути безкоштовною пересбіркою RHEL

CentOS розпочав роботу у 2004 році з простим завданням: брати вихідні пакети, які публікувала Red Hat, вилучати торговельні марки, перескладати їх і безкоштовно поширювати результат. Протягом десятиліття він був основним безкоштовним серверним дистрибутивом, а у 2014 році Red Hat взяла проєкт під свій контроль.

8 грудня 2020 року Red Hat оголосила, що CentOS Linux 8 припинить роботу 31 грудня 2021 року — на вісім років раніше за опубліковану дату, — а назва CentOS збережеться за CentOS Stream. Stream не є пересбіркою. Це гілка, з якої створюють мінорні випуски RHEL, тому вона випереджає RHEL, а не відстає від нього. Для машини, яку ви плануєте використовувати роками, випередження є неправильним напрямком, оскільки зміни надходять до вас раніше, ніж до клієнтів Red Hat, які платять за підтримку.

У 2021 році з’явилися дві пересбірки. Rocky Linux заснував Gregory Kurtzer, співзасновник CentOS. AlmaLinux фінансує CloudLinux. У червні 2023 року Red Hat припинила публікувати вихідні тексти RHEL будь-де, крім CentOS Stream і порталу для клієнтів. Rocky зберіг орієнтацію на ідентичні пересбірки. AlmaLinux змінив мету на сумісність на рівні ABI (application binary interface), тобто програмне забезпечення, зібране для RHEL, працює в цій системі, але без гарантії повної відповідності переліку помилок. Пізніше того ж року Oracle, SUSE і CIQ створили OpenELA для публікації спільних вихідних текстів.

Якщо у списку образів провайдера досі зазначено CentOS, з’ясуйте, який саме варіант мається на увазі, перш ніж розгортати на ньому систему.

cat /etc/os-release

NAME="CentOS Stream" — це rolling development branch, яка веде до RHEL. NAME="AlmaLinux" або NAME="Rocky Linux" — це пересбірка, яка слідує за ним і має десятирічний період підтримки.

Ubuntu, 2004: знімок Debian unstable за календарним графіком

Ubuntu 4.10 вийшла 20 October 2004 за фінансування Mark Shuttleworth. Її зв’язок із Debian є технічним, а не сентиментальним. Кожен цикл починається з імпорту пакетів із Debian unstable до нового випуску Ubuntu. Імпорт триває до Debian Import Freeze у середині циклу, після чого Ubuntu підтримує власні зміни. Багато пакетів Ubuntu є пакетами Debian із додатковими змінами, і changelog указує, якими саме.

Інша складова — календар. Debian випускає версії, коли вони готові. Ubuntu випускає версії у квітні та жовтні, а номер версії відповідає даті: 24.04 вийшла у квітні 2024 року. Кожен другий квітневий випуск є LTS (long term support), і саме це має на увазі провайдер, коли вказує Ubuntu без додаткового уточнення. Вибір між цими двома типами випусків для сервера є основною темою матеріалу як вибрати між Ubuntu LTS та проміжними випусками, а перехід з однієї LTS-версії на наступну має окрему процедуру, описану в матеріалі оновлення з 24.04 до 26.04.

Щороку адміністратори серверів стикаються з однією особливістю. Архів Ubuntu поділено на компоненти. main підтримує Canonical протягом усього періоду підтримки. universe підтримує спільнота, і умови security coverage для нього інші. apt install не показує цієї різниці. Її можна побачити однією командою:

apt-cache policy nginx

Рядок репозиторію, що закінчується на /main, означає, що за цей пакет відповідає security team Canonical. Рядок, що закінчується на /universe, означає, що за нього відповідає спільнота. Перевіряйте це для всіх компонентів, доступних з інтернету.

Arch, 2002: rolling releases і ціна часткового оновлення

Judd Vinet випустив Arch 0.1 11 March 2002 року разом із власним менеджером пакунків pacman і рецептами збирання у вигляді звичайних shell-скриптів. У Arch взагалі немає версійних релізів. Інсталяційні носії є датованими знімками тих самих rolling-репозиторіїв, тому система, встановлена у 2019 році й оновлювана щотижня, працює на тій самій версії Arch, що й система, встановлена сьогодні. AUR (Arch user repository) містить рецепти збирання, які додають користувачі. Це рецепти, а не перевірені пакунки, тому читання PKGBUILD перед запуском є обов’язковою частиною роботи.

Rolling-модель має один тип збою, і щоразу його спричиняє сам адміністратор. Встановлення одного пакунка за допомогою pacman -Sy foo оновлює базу даних пакунків, а потім встановлює один новий бінарний файл, скомпільований із бібліотеками, новішими за ті, що вже є на диску. Після цього програми завершуються з помилками такого типу:

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

Підтримувана операція — pacman -Syu, яка оновлює все разом. Проєкт також публікує новини, де зазначено, що перед певними оновленнями потрібне ручне втручання. Запуск оновлення без читання цих повідомлень може залишити систему, яка не завантажується.

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

Alpine: невеликий дистрибутив, популярність якому принесли контейнери

Alpine з’явився приблизно 2005 року як форк LEAF (Linux embedded appliance framework), що своєю чергою походив від Linux Router Project. Natanael Copa створив його для appliance-систем, а не для настільних комп’ютерів. У ньому замінено більшість стандартного userland: musl замість бібліотеки GNU C, BusyBox замість базових утиліт GNU, OpenRC замість systemd, а apk — як менеджер пакетів. Alpine 3.0 у 2014 році став першим релізом, що перейшов на musl.

Популярність йому принесли контейнери. Базовий шар Alpine у рази менший за базовий шар Debian або Ubuntu. Тому з 2016 року Alpine став поширеним базовим образом, і багато людей, які ніколи не встановлювали Alpine, щодня запускали його в контейнерах.

Недолік полягає в тому, що musl — це не glibc. Ця відмінність спричиняє помилки, які виглядають не пов’язаними з проблемою. Бінарний файл, скомпільований із прив’язкою до glibc, не запускається в Alpine. Повідомлення про помилку змушує шукати файл, який уже існує:

sh: ./myapp: not found

Програма існує. Але її ELF-інтерпретретатор відсутній, оскільки завантажувач glibc не встановлений. Python — ще одне типове джерело несподіваних проблем: готові wheel-пакети, зібрані для manylinux, не встановлюються в середовищі musl. Тому pip переходить до компіляції з вихідного коду й зупиняється, якщо компілятор не встановлений. Стандарт wheel-пакетів musllinux, представлений у 2021 році, розв’язав цю проблему для проєктів, які публікують такі wheel-пакети, і не розв’язав її для інших.

Як гостьова операційна система на VPS Alpine швидко встановлюється, швидко оновлюється й змушує відхилитися від підходів, які передбачає більшість документації. Кожну інструкцію, у якій сказано виконати systemctl enable, потрібно адаптувати до rc-update add.

Незмінне покоління: атомарні оновлення та сервери на основі образів

Найновіша гілка змінює модель оновлення, а не список пакетів. Система на основі ostree зберігає /usr лише для читання. Оновлення є повним новим деревом файлової системи, яке завантажується, готується та активується під час наступного перезавантаження. Попереднє дерево залишається доступним як запис у меню завантаження, тому невдале оновлення можна скасувати, перезавантаживши систему зі старого дерева.

Fedora Silverblue перенесла цей підхід на робочі станції у 2018 році, а Fedora CoreOS — на сервери у 2019 році, після придбання Red Hat компанії CoreOS у 2018 році. Flatcar Container Linux продовжила оригінальний Container Linux після його виведення з експлуатації у 2020 році. openSUSE MicroOS досягає такого самого результату за допомогою знімків btrfs і transactional-update. У 2024 році Red Hat додала до RHEL режим на основі образів, побудований на bootc, у якому операційна система постачається як образ контейнера, а система оновлюється прив’язуванням до нового tag. Talos Linux іде ще далі та повністю прибирає shell і SSH: систему налаштовують через API, тому входити до неї немає потреби. NixOS, уперше випущена у 2007 році, використовує інший підхід. Уся система збирається з однієї декларативної конфігурації, а попередні покоління залишаються доступними для завантаження.

Імовірно, ваш провайдер не пропонує жоден із цих варіантів як образ для встановлення в один клік, оскільки очікує, що під час першого запуску систему буде налаштовано через Ignition або cloud-init, а не адміністратором, який редагує файли через SSH. Переваги цього підходу особливо помітні на багатьох однакових машинах. Саме така ситуація виникає, коли ви одночасно керуєте кількома серверами Linux і кожен із них має бути гарантовано ідентичним іншим.

Скільки підтримується один реліз?

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

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 13
  }
]

Alpine підтримує кожну гілку 3.x протягом 2 років. Тому Alpine краще підходить для образу контейнера, який ви часто перебудовуєте, ніж для хоста, який залишаєте без змін. Команда безпеки Debian підтримує стабільний реліз приблизно 3 років. Після цього команда LTS підтримує поширені архітектури ще до загального періоду близько 5 років. Ubuntu LTS надає 5 років підтримки пакетів у main. Підписка Ubuntu Pro продовжує цей період до 10 років і є безкоштовною для особистого використання на невеликій кількості машин. RHEL 10 публікує період підтримки 10 років. Платне розширене обслуговування продовженого життєвого циклу збільшує його до 13 років. AlmaLinux 10 відповідає періоду RHEL у 10 років без будь-якої підписки. Саме для цього й існують ці перебудови.

Для Arch немає окремого рядка, оскільки rolling-дистрибутив не має релізу, який потрібно підтримувати. Для Arch важливо, як довго можна не змінювати машину. Цей період вимірюють у тижнях.

Чому список образів VPS має такий вигляд

Провайдер додає образи, які клієнти запитують за назвою та які можна встановити без участі користувача на його гіпервізорі. Тому майже кожен список починається з Ubuntu LTS і Debian stable, містить AlmaLinux або Rocky для користувачів, чиє програмне забезпечення сертифіковане для RHEL, а Alpine, Arch і Fedora розташовує нижче. Якщо ви вже знаєте що таке VPS і як образ потрапляє на диск, ця закономірність стає зрозумілою: провайдер обирає операційні системи, які успішно проходять автоматичне встановлення та довше підтримуються, ніж зазвичай використовується сервер клієнтом.

Вибір визначає більше, ніж менеджер пакетів. Він визначає оновлення, яке ви виконуватимете через три роки, а в різних сімейств дистрибутивів цей процес суттєво відрізняється. Debian і Ubuntu підтримують основні оновлення без перевстановлення. У сімействі Red Hat вони виконуються через leapp. В Arch оновлення версії не потрібне, оскільки окремих версій немає. В Alpine потрібно відредагувати /etc/apk/repositories і виконати apk upgrade --available. Вибір також визначає, яке програмне забезпечення можна встановити без додавання стороннього репозиторію, хто випустить виправлення, коли запис CVE (common vulnerabilities and exposures) стосуватиметься програмного забезпечення, яке ви використовуєте, а також який init system і C library передбачатиме майбутнє програмне забезпечення.

Є ще один наслідок, який легко недооцінити. Більшість відповідей в інтернеті передбачає роботу із сімейством Debian або Red Hat, тому вибір іншого сімейства означає перекладати інструкції протягом усього строку роботи сервера. Обирайте сімейство, чия release policy відповідає тому, як часто ви готові обслуговувати сервер, і дотримуйтеся цього вибору. Змінити пакети поверх системи легко. Змінити дистрибутив під ними означає перебудувати сервер.

FAQ

У якому сімействі дистрибутивів Linux працює мій сервер?

Виконайте cat /etc/os-release. Поле ID містить назву дистрибутива, а ID_LIKE — його сімейство, тому машина з Ubuntu повертає ID_LIKE=debian, а машина з AlmaLinux — ID_LIKE="rhel centos fedora". Іншою ознакою є менеджер пакетів. apt і dpkg означають сімейство Debian, dnf і rpm — сімейство Red Hat, apk — Alpine, а pacman — Arch.

CentOS досі є безкоштовною версією RHEL?

Ні. CentOS Linux 8, остання збірка з цією назвою, завершила життєвий цикл 31 December 2021, а CentOS Linux 7 — 30 June 2024. Проєкт CentOS Stream, який продовжує існувати, є гілкою, з якої збирають мінорні випуски RHEL, тому зміни з’являються в ньому раніше, а не пізніше, ніж у RHEL. Безкоштовні збірки, які перебрали на себе колишню роль CentOS, — AlmaLinux і Rocky Linux. Для обох передбачено десять років підтримки.

Чому stable-версія Debian містить такі старі номери версій?

Тому що номер версії заморожується, а виправлення продовжують надходити. Debian переносить security patches у вже випущену версію, а не імпортує новий upstream-випуск, тому пакет із номером 2.4.57-2+deb13u1 може містити виправлення, опубліковане минулого тижня. Суфікс після upstream-версії є ревізією Debian, а apt changelog <package> показує, що до неї ввійшло. Оцінювання безпеки сервера Debian за номерами версій щоразу дає неправильний результат.

Чи варто запускати rolling release, як-от Arch, на VPS?

Лише якщо ви оновлюватимете його за графіком. Rolling-дистрибутив передбачає, що кожна машина переходить до поточного набору пакетів, тому оновлення одного пакета за допомогою pacman -Sy foo залишає несумісні бібліотеки та спричиняє помилки на кшталт cannot open shared object file. Регулярно виконуйте pacman -Syu, перед кожним запуском читайте сторінку новин проєкту — і система буде стабільною. Якщо не оновлювати її протягом року, перше оновлення стане ризикованим.

Що насправді змінює immutable або atomic-дистрибутив?

Він змінює момент застосування оновлень і спосіб їх скасування. /usr монтується лише для читання, оновлення готується як повне нове дерево, а перемикання виконується під час перезавантаження; попереднє дерево зберігається як запис для завантаження та rollback. Машина буде або повністю оновленою, або повністю неоновленою, без частково застосованого стану. Водночас ви втрачаєте можливість встановлювати програмне забезпечення шляхом редагування файлів на місці, тому застосунки переміщуються в контейнери або layered packages.