Перейти к содержанию

Дистрибутивы Linux


Корневые ветки

  • Debian - исходная gnu/linux ветка, основа Ubuntu, Mint, Proxmox VE, Raspberry Pi OS и десятков других.
  • Red Hat - RHEL как enterprise-ветка. Исторически «Red Hat Linux» эволюционировал в Fedora/RHEL-экосистему:
  • RHEL - флагман, платный enterprise.
  • Fedora - upstream, тестовый полигон для RHEL.
  • CentOS Stream - rolling между Fedora и RHEL.
  • Rocky Linux, AlmaLinux - RHEL-совместимые community enterprise (после смерти классического CentOS).
  • Oracle Linux - RHEL-совместимый, но vendor flavored.
  • Slackware - старейшая, минималистичная, без жёсткого dependency-менеджера.
  • Arch Linux - rolling release, KISS-философия, AUR как соц-надстройка.
  • Gentoo - source-based, всё собирается под себя через portage/emerge.
  • SUSE - openSUSE (Leap/Tumbleweed) и SLES (enterprise).
  • Alpine Linux - musl + busybox, любимец контейнеров и минимальных образов.
  • Void Linux - независимая, runit вместо systemd, пакеты xbps.
  • BSD-семейство - OpenBSD, FreeBSD, NetBSD. Не Linux, отдельный мир.
  • illumos / Solaris lineage - OpenIndiana и подобные. Отдельная UNIX-ветка, не Linux, но иногда мелькает в инфраструктурных разговорах (ZFS родом отсюда).

Отличия

База системы: glibc vs musl

  • glibc - у большинства классики (Debian, RHEL, SUSE, Arch, Gentoo, Void-glibc). Жирнее, совместимее с прекомпилированными бинарниками.
  • musl - у Alpine и нескольких нишевых. Меньше, проще, часто безопаснее по поверхности, но иногда ломает совместимость с бинарниками и некоторыми зависимостями (DNS-резолвер, thread-stack defaults, locale-handling).

Набор базовых утилит

  • Почти везде GNU coreutils.
  • В минималистичных/альтернативных (Alpine, embedded) - busybox или toybox. Команды те же, поведение слегка другое: иногда нет флагов, иногда другое поведение по умолчанию.

Формат пакетов и менеджер

Влияет на: как ставить, как обновляться, как решаются зависимости, как устроены репозитории.

  • Debian - .deb + apt/dpkg.
  • RHEL / Fedora / Rocky / Alma - .rpm + dnf (раньше yum) + rpm.
  • SUSE - .rpm + zypper.
  • Arch - .pkg.tar.zst + pacman. Плюс AUR как огромная пользовательская «соц-надстройка».
  • Gentoo - исходники/ebuild + portage (emerge). Ставишь, собирая под свой CPU/флаги.
  • Alpine - .apk + apk.
  • Void - .xbps + xbps.

Формат пакета - это не всё: важнее политика обновлений и контроль качества репозиториев.

Модель релизов и обновлений

Самое важное при выборе под сервер.

  • Stable / LTS (Debian stable, RHEL/Rocky/Alma, SLES) - медленные обновления, зато предсказуемо и долго поддерживается. Дефолт для прода.
  • Fixed releases (Fedora, openSUSE Leap) - относительно свежо, но с регулярными апгрейдами версии (каждые 6-12 месяцев).
  • Rolling release (Arch, openSUSE Tumbleweed, Void) - всегда свежее, но выше риск «сломалось после апдейта». Нужен режим «админ следит».
  • Source-based (Gentoo) - максимальный контроль, платишь временем сборки и сложностью.

Система инициализации и сервис-менеджмент

  • systemd - Debian, RHEL, Fedora, SUSE, Arch и т.д. Де-факто стандарт.
  • OpenRC - Alpine, Gentoo (опционально). Минимализм, скрипты ближе к классическому SysV.
  • runit - Void. Простые директории-сервисы, прозрачное логирование.

Это меняет: как пишутся юниты/скрипты, как дебажить сервисы, как настраивается логирование (journalctl vs /var/log/*).

Безопасность и патчи

Разница в:

  • скорости доставки security fix'ов
  • backport'ах - когда фикс тащат в старую версию пакета без обновления до «самого нового»
  • подходе к hardening и сборкам пакетов
  • SELinux/AppArmor по умолчанию и культуре использования.

Пример: RHEL/Fedora мир дружит с SELinux сильнее, Debian/Ubuntu - чаще AppArmor (хотя можно и так, и так).

Экосистема и «как принято» разворачивать софт

  • RHEL-семейство - сильнее enterprise-практики, совместимость, сертификации, SELinux.
  • Debian-семейство - огромная база пакетов и привычные гайды «для всех».
  • Arch - документация-энциклопедия (Arch Wiki), но rolling.
  • Alpine - любимец контейнеров и минимальных образов (Docker base images).

ABI-совместимость и «можно ли ставить чужие бинарники»

  • glibc-дистрибутивы обычно лучше для «скачал бинарник - запустил».
  • Alpine/musl иногда требует слоя совместимости (gcompat) или пересборки под musl.
  • RPM ≠ автоматически RHEL-совместимость: важны версии библиотек, политика, макросы сборки, ABI, репозитории. Rocky и Alma - именно про совместимость с RHEL на уровне бинарников.