История дистрибутивов Linux: от Debian до Red Hat

Что на самом деле представляет собой дистрибутив Linux

История дистрибутивов Linux начинается с пробела: само по себе ядро Linux не выполняет функций, полезных для пользователя. Оно загружается и обнаруживает оборудование. Затем оно останавливается. Кто-то должен добавить пользовательское окружение (userland), выбрать способ установки и обновления программного обеспечения, а также взять на себя обязательство исправлять ошибки в течение многих лет. Дистрибутив — это набор таких решений плюс группа людей, которые продолжают поддерживать систему в дальнейшем.

Он состоит из пяти частей. Измените любую из них, и вы получите другой дистрибутив, даже если большинство бинарных файлов совпадут:

• Ядро версии, выбранной проектом, с добавленными патчами и драйверами.
• Пользовательское окружение: библиотека C, командная оболочка, система инициализации, стандартные команды.
• Формат пакетов и инструмент для их установки.
• Политика релизов: что может меняться, как часто и как долго поддерживается каждый релиз.
• Люди: мейнтейнеры пакетов, команда безопасности и те, кто отвечает на запросы, когда пакет перестает работать.

Ядро — это общая часть, поэтому два дистрибутива Linux гораздо ближе друг к другу, чем любой из них к другой Unix-системе. Это стоит учитывать при сравнении Linux и FreeBSD как серверных платформ, где ядро и базовое пользовательское окружение создаются одним проектом и выпускаются совместно. В Linux эти компоненты поступают из разных независимых источников (upstreams), а дистрибутив — это то, что заставляет их работать согласованно.

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

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

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

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

MCC Interim Linux появилась в феврале 1992 года. Её собрал Оуэн Ле Блан в Манчестерском вычислительном центре (Manchester Computing Centre). Дистрибутив объединял ядро и инструменты GNU (GNU's not Unix) на паре образов дискет с установщиком на основе меню. Он был создан, так как ручная установка занимала целый рабочий день.

SLS (Softlanding Linux System), выпущенная Питером Макдональдом в 1992 году, пошла дальше и добавила X (X Window System) и поддержку сетей TCP/IP. Именно благодаря SLS слово «дистрибутив» приобрело своё текущее значение. Система была нестабильной и редко обновлялась, поэтому в 1993 году два человека независимо друг от друга решили исправить ситуацию. Один из них пересобрал систему, а другой начал разработку заново, опираясь на чёткие правила.

Slackware, 1993: старейшее семейство, которое до сих пор выпускает релизы

Патрик Фолькердинг выпустил Slackware 1.00 16 июля 1993 года, собрав его на базе SLS и исправив ошибки. Дистрибутив поддерживается до сих пор, что делает его старейшим из существующих дистрибутивов Linux.

Пакет Slackware представляет собой сжатый tar-архив, внутри которого находится скрипт установки. В системе отсутствует разрешение зависимостей: ничто не проверяет, установлена ли в системе библиотека, необходимая для нового пакета. Это единственное решение определило всё остальное. Если инструмент не разрешает зависимости, поставляемый набор должен быть согласованным по своей структуре, поэтому релизы выходят редко и остаются консервативными. Slackware 15.0 вышла в феврале 2022 года, спустя шесть лет после версии 14.2.

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

Debian, 1993: общественный договор и конвейер из трех веток

Иэн Мердок анонсировал Debian 16 августа 1993 года, через три недели после Slackware и по той же причине. Название объединяет имена его партнерши Дебры и его собственное. Манифест Debian последовал в январе 1994 года и установил правила: дистрибутив должен поддерживаться открыто силами волонтеров, а не компанией.

Затем Debian зафиксировал эти условия письменно. Общественный договор Debian и DFSG (руководство Debian по свободному ПО) были приняты в июле 1997 года, а DFSG в 1998 году легли в основу определения Open Source. Документ, написанный для того, чтобы определить состав одного дистрибутива, в итоге задал категорию лицензий для всей индустрии. Именно поэтому ваш 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–10 дней, если он собрался под архитектуры релиза и не получил новых критических ошибок. Затем ветка testing замораживается, команда релиза устраняет оставшиеся проблемы, и stable выпускается, когда список ошибок становится достаточно коротким. Не по дате. Именно поэтому Debian stable выглядит старым и работает стабильно: номера версий фиксируются на момент заморозки, а исправления безопасности продолжают бэкпортироваться в них.

Управление также регламентировано: есть избираемый лидер проекта и обязательные к исполнению общие резолюции. В 2014 году этот механизм выбрал systemd в качестве системы инициализации по умолчанию, а несогласные создали форк Devuan, который выпустил свой первый релиз в 2017 году. Крупнейшие производные системы — это Ubuntu, Raspberry Pi OS, Proxmox VE, Kali и Linux Mint.

Red Hat, 1994: RPM, затем разделение на Fedora и RHEL

Марк Юинг выпустил первый Red Hat Linux примерно на Хэллоуин 1994 года. Компания Боба Янга приобрела его в 1995 году, и они вместе создали первый Linux-бизнес, который продавал поддержку, а не программное обеспечение. Red Hat вышла на биржу 11 августа 1999 года. IBM завершила сделку по поглощению компании в июле 2019 года примерно за 34 миллиарда долларов, поэтому дистрибутив, для которого сертифицировано большинство корпоративного ПО, с тех пор является собственностью IBM.

Долговечным техническим вкладом стал RPM (Red Hat package manager), написанный Эриком Троаном и Марком Юингом для Red Hat Linux 2.0 в 1995 году. Пакет RPM объявляет свои зависимости и создается из spec-файла — рецепта сборки, который может запустить любой желающий. Именно это второе свойство впоследствии сделало возможной независимую пересборку корпоративного продукта Red Hat.

Red Hat Linux 9, вышедший в 2003 году, стал последним в оригинальной линейке. Компания разделила его на две части: Fedora Core 1 в ноябре 2003 года как быстрый релиз для сообщества и RHEL (Red Hat Enterprise Linux), который начал свой путь как Advanced Server 2.1 в 2002 году, как медленный платный продукт. Причина очевидна. Один продукт не может одновременно быть площадкой для тестирования новых версий и платформой, на которой банк работает без изменений в течение десяти лет. Эти две половины связаны: мажорная версия 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 Stream. Stream не является клоном. Это ветка, из которой формируются минорные релизы RHEL, поэтому она опережает RHEL, а не следует за ним. Для сервера, который должен работать годами, такой подход не подходит, так как вы получаете изменения раньше, чем платные клиенты Red Hat.

В 2021 году появились два проекта по пересборке. Rocky Linux был запущен Грегори Курцером, одним из сооснователей CentOS. Финансирование AlmaLinux взяла на себя компания CloudLinux. В июне 2023 года Red Hat прекратила публикацию исходных кодов RHEL везде, кроме CentOS Stream и клиентского портала. Rocky Linux продолжил стремиться к созданию идентичных сборок. AlmaLinux изменила свою цель на обеспечение ABI-совместимости (application binary interface), что означает работоспособность ПО, собранного для RHEL, без гарантии полного совпадения списка ошибок. Позже в том же году Oracle, SUSE и CIQ создали OpenELA для публикации общих исходных кодов.

Если в списке образов вашего провайдера всё ещё указана CentOS, уточните, какая именно версия имеется в виду, прежде чем разворачивать на ней инфраструктуру.

cat /etc/os-release

NAME="CentOS Stream" — это ветка непрерывной разработки, предшествующая RHEL. NAME="AlmaLinux" или NAME="Rocky Linux" — это клон, который следует за RHEL и имеет десятилетний цикл поддержки.

Ubuntu 20.04: снимок Debian unstable по календарю

Ubuntu 4.10 вышла 20 октября 2004 года при финансовой поддержке Марка Шаттлворта. Её связь с Debian носит скорее технический, чем идеологический характер. Каждый цикл разработки начинается с импорта пакетов из Debian unstable в новый релиз Ubuntu. Этот импорт продолжается до момента Debian Import Freeze в середине цикла, после чего Ubuntu вносит собственные изменения. Многие пакеты Ubuntu представляют собой пакеты Debian с добавлением дельты, информация о которой содержится в changelog.

Вторая половина стратегии — календарь. Debian выпускает релизы по мере готовности. Ubuntu выпускает релизы в апреле и октябре, а номер версии соответствует дате: 24.04 вышла в апреле 2024 года. Каждый второй апрельский релиз является LTS (версией с долгосрочной поддержкой) — именно это подразумевает провайдер, когда предлагает Ubuntu без дополнительных уточнений. Выбор между ними для сервера — это отдельная тема выбора между Ubuntu LTS и промежуточными релизами, а переход с одного LTS на другой имеет свою процедуру, описанную в обновлении с 24.04 до 26.04.

Одна деталь ежегодно ставит в тупик системных администраторов. Архив Ubuntu разделен на компоненты. main поддерживается Canonical в течение всего срока сопровождения. universe поддерживается сообществом, и обязательства по безопасности для него иные. apt install не выводит никакой информации об этой разнице. Проверить её можно одной командой:

apt-cache policy nginx

Строка репозитория, заканчивающаяся на /main, означает, что за пакет отвечает команда безопасности Canonical. Строка, заканчивающаяся на /universe, означает поддержку сообществом. Проверяйте это для любого сервиса, доступного из Интернета.

Arch, 2002: rolling release и цена частичного обновления

Judd Vinet выпустил Arch 0.1 11 марта 2002 года, используя написанный им самим менеджер пакетов pacman и рецепты сборки в виде обычных shell-скриптов. В Arch отсутствуют версионные релизы как таковые. Установочные образы представляют собой датированные снимки одних и тех же rolling-репозиториев, поэтому система, установленная в 2019 году и обновляемая еженедельно, работает на той же версии Arch, что и установленная сегодня. AUR (Arch user repository) содержит рецепты сборки, созданные пользователями. Это именно рецепты, а не проверенные пакеты, поэтому изучение PKGBUILD перед запуском — часть работы администратора.

У модели rolling release есть один сценарий сбоя, и он всегда является следствием действий пользователя. Установка одного пакета через 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. Натанаэль Копа создал его для встраиваемых устройств, а не для настольных систем. Он заменяет большинство стандартных компонентов пользовательского пространства: musl вместо GNU C library, BusyBox вместо GNU core utilities, OpenRC вместо systemd, а apk используется в качестве пакетного менеджера. Релиз Alpine 3.0 в 2014 году стал переходом на musl.

Контейнеры сделали его популярным. Базовый слой Alpine занимает малую часть размера базового образа Debian или Ubuntu, поэтому с 2016 года он стал стандартным базовым образом. Множество людей, которые никогда не устанавливали Alpine на железо, ежедневно запускают его в контейнерах.

Цена этого — musl не является glibc, и разница проявляется в виде ошибок, которые кажутся несвязанными. Бинарный файл, скомпилированный для glibc, не запускается в Alpine с сообщением, которое заставляет искать файл, который уже присутствует в системе:

sh: ./myapp: not found

Программа существует. Но её ELF-интерпретатор отсутствует, так как загрузчик glibc не установлен. Python — еще один источник регулярных сюрпризов: готовые пакеты (wheels), собранные для manylinux, не устанавливаются в musl, поэтому pip пытается выполнить компиляцию из исходного кода и прерывается, если компилятор не установлен. Стандарт musllinux для wheels, появившийся в 2021 году, решил эту проблему для проектов, которые публикуют такие пакеты, но не для остальных.

В качестве хостовой ОС на 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 snapshots и transactional-update. В 2024 году Red Hat добавила в RHEL режим на основе образов, построенный на bootc, где операционная система поставляется как контейнерный образ, а обновление машины выполняется путем указания на новый тег. Talos Linux идет дальше всех и полностью удаляет оболочку и 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 лет, поэтому она лучше подходит для образа контейнера, который вы часто пересобираете, чем для хоста, который вы оставляете без изменений. Команда безопасности Debian сопровождает стабильный релиз около 3 лет, а затем команда LTS продлевает поддержку основных архитектур примерно до 5 лет в сумме. Ubuntu LTS предоставляет 5 года для пакетов в main, а подписка Ubuntu Pro продлевает этот срок до 10 лет (бесплатно для личного использования на небольшом количестве машин). RHEL 10 заявляет 10 лет, которые платное дополнение extended life cycle support увеличивает до 13. AlmaLinux 10 соответствует сроку RHEL в 10 года без какой-либо подписки, что является основной причиной существования подобных пересборок.

Arch не имеет здесь строки, так как rolling-дистрибутив не имеет релизов для поддержки. Число, которое важно для Arch, — это то, как долго вы можете оставлять машину без обслуживания, и оно измеряется неделями.

Почему список образов вашего VPS выглядит именно так

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

Этот выбор накладывает обязательства, выходящие за рамки выбора пакетного менеджера. Он определяет процедуру обновления, которую вы будете выполнять через 3 года, а они кардинально различаются в зависимости от семейства. Debian и Ubuntu поддерживают обновление мажорных версий «на месте». Семейство Red Hat выполняет их через leapp. У Arch нет обновлений версий, так как нет самих версий. В Alpine обновление сводится к редактированию /etc/apk/repositories и выполнению apk upgrade --available. Выбор также определяет, какое ПО можно установить без добавления сторонних репозиториев, кто выпустит патч при появлении записи CVE (common vulnerabilities and exposures) для используемых вами компонентов, а также какие init-система и C-библиотека будут ожидаться вашим будущим ПО.

Есть еще один эффект, который легко недооценить. Большинство ответов в интернете подразумевают путь семейства Debian или семейства Red Hat, поэтому выбор за пределами этих двух означает необходимость переводить инструкции на протяжении всего жизненного цикла машины. Выбирайте семейство, политика релизов которого соответствует тому, как часто вы готовы обслуживать сервер, и придерживайтесь его. Менять пакеты поверх системы легко. Смена дистрибутива под ними означает пересборку сервера с нуля.

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 декабря 2021 года, а жизненный цикл CentOS Linux 7 завершился 30 июня 2024 года. Существующий проект CentOS Stream является веткой, на основе которой создаются минорные релизы RHEL, поэтому изменения в нем появляются раньше, чем в RHEL, а не позже. Роль бесплатных сборок, повторяющих функционал RHEL, теперь выполняют AlmaLinux и Rocky Linux, каждая из которых имеет десятилетний цикл поддержки.

Почему в Debian stable такие старые номера версий?

Потому что номер версии фиксируется, а исправления продолжают выпускаться. Debian переносит патчи безопасности в уже выпущенную версию вместо обновления до новой версии от разработчика (upstream). Поэтому пакет с версией 2.4.57-2+deb13u1 может содержать исправление, выпущенное на прошлой неделе. Суффикс после версии от разработчика — это ревизия Debian, а apt changelog <package> содержит список внесенных в нее изменений. Оценка безопасности сервера Debian по номерам версий всегда дает неверный результат.

Стоит ли использовать rolling-релиз, например Arch, на VPS?

Только если вы готовы обновлять его по расписанию. Rolling-дистрибутив предполагает, что система всегда приводится к актуальному состоянию пакетов. Обновление одного пакета через pacman -Sy foo приведет к несоответствию библиотек и ошибкам вроде cannot open shared object file. Регулярно запускайте pacman -Syu и читайте новости проекта перед каждым обновлением — тогда система будет стабильной. Если оставить систему без обновлений на год, первое же обновление станет рискованным.

Что именно меняют неизменяемые (immutable) или атомарные дистрибутивы?

Они меняют способ применения обновлений и механизм отката. /usr монтируется в режиме только для чтения, обновление подготавливается как полное новое дерево, а переключение происходит при перезагрузке. Предыдущее дерево сохраняется как пункт меню загрузчика для отката. Вы получаете систему, которая либо полностью обновлена, либо не обновлена вовсе, без промежуточных состояний. Вы отказываетесь от установки ПО путем редактирования файлов на месте, поэтому приложения переносятся в контейнеры или устанавливаются как слоистые пакеты.