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

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

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

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

• Ядро версии, выбранной проектом, с добавленными патчами и драйверами.
• Пользовательское окружение (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 года, его собрал Оуэн Ле Блан в Манчестерском вычислительном центре. Он объединил ядро и инструменты 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 году. Debian был не первым дистрибутивом, совершившим этот переход, и не последним. Причины, по которым это происходило, наряду с возражениями, оказавшимися верными, описаны в истории о том, как systemd заменил SysV init. Крупнейшие производные дистрибутивы — это Ubuntu, Raspberry Pi OS, Proxmox VE, Kali и Linux Mint.

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

Marc Ewing выпустил первый Red Hat Linux примерно на Хэллоуин 1994 года. Компания Bob Young приобрела его в 1995 году, и они вместе создали первый Linux-бизнес, который продавал поддержку, а не программное обеспечение. Red Hat вышла на биржу 11 августа 1999 года. IBM завершила сделку по поглощению компании в июле 2019 года примерно за 34 миллиарда долларов, поэтому дистрибутив, для которого сертифицировано большинство корпоративного ПО, с тех пор является собственностью 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 в ноябре 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 для публикации общих исходных кодов. Вся эта последовательность событий, от разделения в 2003 году до изменения политики публикации исходников в 2023 году и текущих обязательств каждого из клонов, подробно описана в подробном обзоре истории Red Hat, CentOS, Rocky и AlmaLinux.

Если в списке образов вашего провайдера всё ещё указана 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 и как образ попадает на диск, закономерность станет очевидной: провайдер выбирает операционные системы, которые успешно проходят автоматическую установку и поддерживаются дольше, чем средний клиент использует сервер.

Этот выбор накладывает обязательства, выходящие за рамки выбора пакетного менеджера. Он определяет процедуру обновления, которую вы будете выполнять через три года, а они кардинально различаются в зависимости от семейства ОС. Debian и Ubuntu поддерживают обновление мажорных версий «на месте». В семействе Red Hat это выполняется через leapp. У Arch нет обновлений версий, так как нет самих версий. В Alpine обновление сводится к редактированию /etc/apk/repositories и выполнению apk upgrade --available. Выбор также определяет, какое ПО можно установить без добавления сторонних репозиториев, кто выпустит патч, когда появится запись CVE (common vulnerabilities and exposures) для используемого вами компонента, а также какие система инициализации и библиотека 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, а не позже. Роль бесплатных сборок, аналогичных старой CentOS, теперь выполняют AlmaLinux и Rocky Linux, каждая из которых имеет десятилетний цикл поддержки.

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

Потому что номера версий фиксируются, а исправления продолжают выпускаться. Debian переносит патчи безопасности в уже выпущенную версию вместо импорта новых апстрим-релизов. Поэтому пакет с версией 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 монтируется в режиме только для чтения, обновление подготавливается как полное новое дерево, а переключение происходит при перезагрузке. Предыдущее дерево сохраняется как пункт меню загрузчика для отката. Вы получаете систему, которая либо полностью обновлена, либо не обновлена вовсе, без промежуточных состояний. Вы отказываетесь от установки ПО путем редактирования файлов на месте, поэтому приложения переносятся в контейнеры или устанавливаются как наслоенные пакеты.