Історія дистрибутивів Linux: від Slackware до VPS

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

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

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

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

Ядро є спільною частиною, тому два дистрибутиви 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) у двох образах дискет та мав інсталятор із меню. Він з’явився тому, що ручне виконання цієї роботи займало цілий день.

SLS (Softlanding Linux System), випущений Peter MacDonald у 1992 році, пішов далі та додав X (the X Window System) і мережеву підтримку TCP/IP. Саме через SLS слово дистрибутив набуло сучасного значення. Водночас SLS містив помилки, а його супровід був повільним. У 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, щоб ноутбук із wireless card можна було встановити без пошуку потрібних пакетів по різних джерелах.

Інша важлива спадщина — інструменти. 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 виглядає застарілим, але працює надійно: номери версій припиняють змінюватися під час freeze, а виправлення безпеки й надалі переносять у ці версії.

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

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

Marc Ewing випустив першу версію Red Hat Linux приблизно на Halloween 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-файлу — рецепта складання, який може виконати будь-хто. Саме друга властивість згодом зробила незалежне повторне складання корпоративного продукту 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 December 2020 року Red Hat оголосила, що CentOS Linux 8 припинить роботу 31 December 2021 року — на вісім років раніше за опубліковану дату, — а назва продовжить існувати як CentOS Stream. Stream не є збіркою. Це гілка, з якої формуються мінорні випуски RHEL, тому вона випереджає RHEL, а не відстає від нього. Для машини, яку ви плануєте використовувати роками, випередження є неправильним напрямком, оскільки зміни надходитимуть до неї раніше, ніж до платних клієнтів Red Hat.

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

Якщо у списку образів провайдера досі вказано 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 жовтня 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 підтримує спільнота, і умови підтримки безпеки для нього інші. apt install не показує цієї різниці. Її можна побачити однією командою:

apt-cache policy nginx

Рядок репозиторію, що закінчується на /main, означає, що за цей пакет відповідає команда безпеки 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-систем, а не для настільних комп’ютерів. Alpine замінює більшість стандартного userland: musl замість GNU C library, BusyBox замість GNU core utilities, 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 — ще одне типове джерело несподіваних проблем: попередньо зібрані wheels для manylinux не встановлюються в середовищі з musl, тому pip переходить до компіляції з вихідного коду й зупиняється, якщо компілятор не встановлено. Стандарт wheels musllinux, запроваджений у 2021 році, вирішив цю проблему для проєктів, які публікують такі wheels, але не для інших проєктів.

Як хостова операційна система на 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, у якому операційна система постачається як образ контейнера, а оновлення машини виконується шляхом указання нового тегу. 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 family або Red Hat family, тому вибір іншого сімейства означає перекладати інструкції протягом усього строку експлуатації машини. Обирайте сімейство, чия 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. Обидві мають десятирічний період підтримки.

Чому стабільний Debian постачається з такими старими номерами версій?

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

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

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

Що на практиці змінює immutable або atomic distribution?

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