Ядро, userspace и дистрибутивы: что выбирать и почему

Lesson from the course “Курс подготовки DevOps-инженеров”

Хронометраж: занятие 60 минут — теория 30 минут, практика 30 минут. Домашняя работа: 1–2 часа.

Кратко о чём урок: Из чего состоит система, чем отличаются семейства дистрибутивов (Debian/Ubuntu, RHEL/Rocky/Alma, Alpine), политика версий и поддержки, что берут в продакшен.

1. Что изучаем

После урока вы сможете:

объяснить, где заканчивается ядро и начинается userspace, и почему это разделение важно на практике;
назвать, из чего состоит дистрибутив, и сказать, чем два дистрибутива с одним ядром отличаются друг от друга;
определить по системе, что за дистрибутив перед вами, какая версия и до какого срока она поддерживается;
выбрать дистрибутив под задачу, опираясь на срок поддержки и пакетную базу, а не на привычку;
объяснить, чем musl в Alpine отличается от glibc и когда это выстреливает.

2. Зачем это нужно и где применяется

Кажется, что это теория ради теории: «работает же». Разница проявляется в конкретных ситуациях, и все они дорогие.

Вам достался сервер, и надо понять, что на нём. Первое, что вы делаете на незнакомой машине, — выясняете дистрибутив и версию. От этого зависит буквально всё дальнейшее: какой пакетный менеджер, где лежат конфигурации, как называется служба SSH, есть ли ещё обновления безопасности.

Вы выбираете основу для продакшена. Выбор «Ubuntu 26.04 LTS» и «Ubuntu 25.10» выглядит как выбор между «постарее» и «поновее». На самом деле это выбор между пятью годами обновлений безопасности и девятью месяцами. Через год после установки второй вариант превращается в задачу «срочно обновить всё», которую никто не планировал.

Приложение не запускается на другом дистрибутиве. Собрали бинарник на Ubuntu, положили в образ на Alpine — и получили not found при запуске существующего файла. Причина не в файле, а в другой реализации стандартной библиотеки C. Не понимая, из чего состоит система, такую ошибку можно отлаживать часами.

Вас спрашивают, почему выбрали это. На собеседовании и на ревью архитектуры ответ «мне так привычнее» слабый. Ответ «RHEL-семейство, потому что у заказчика требования по сертификации и десятилетний цикл поддержки» — рабочий.

3. Теория (30 минут)

3.1. Что такое Linux на самом деле

Строго говоря, Linux — это только ядро. Первый выпуск сделал Линус Торвальдс в 1991 году, и с тех пор это отдельный проект со своим циклом разработки, который живёт на kernel.org. Всё остальное, что вы видите, работая в системе, — не Linux, а программы вокруг него.

Ядро занимается тем, к чему прикладные программы прямого доступа не имеют:

процессы и планирование — кто и когда получает процессорное время;
память — виртуальная память, страницы, отображение файлов;
файловые системы — как байты на диске превращаются в файлы и каталоги;
сеть — стек TCP/IP, маршрутизация, фильтрация пакетов;
устройства — драйверы, доступ к железу;
изоляция — namespaces и cgroups, на которых потом стоят контейнеры (урок 02.13).

Ядро Linux — монолитное с загружаемыми модулями: основная функциональность работает в одном адресном пространстве, а драйверы и часть подсистем подгружаются во время работы. Практическое следствие, с которым вы столкнётесь: обновление ядра требует перезагрузки, а вот модуль можно загрузить и выгрузить на живой системе.

Пара слов о версии ядра, потому что её вы будете видеть постоянно в выводе uname -r. Формат — мажор.минор.патч (например, 6.12.9): мажор и минор задают поколение с его возможностями, патч — накопленные исправления. Здесь важно не спутать два числа, которые часто путают: версию ядра и версию дистрибутива. Ядро развивается своим темпом на kernel.org, а дистрибутив берёт какую-то его версию, фиксирует её и годами возит по ней только исправления безопасности — поэтому на свежеустановленном «стабильном» сервере ядро обычно заметно старее, чем последнее на kernel.org, и это нормально. Часть веток ядра помечены LTS (long-term support) и получают исправления годами — именно их берут дистрибутивы с длинным циклом. Практический смысл номера ядра появляется в двух ситуациях: новое железо и новые возможности (например, свежие механизмы изоляции для контейнеров) требуют достаточно нового ядра, а слишком старое ядро — признак системы, которую давно не обновляли.

Программа не обращается к железу напрямую — она просит ядро через системные вызовы (system calls): открыть файл, отправить пакет, создать процесс. Это и есть граница между двумя пространствами:

kernel space — код ядра, полный доступ к железу, падение здесь означает падение системы;
user space — все остальные программы, доступ только через системные вызовы, падение убивает только саму программу.

Это разделение — причина, по которой Linux в принципе устойчив: неверно работающая программа не может испортить систему, потому что физически не имеет доступа мимо ядра. Оно же объясняет, почему администрирование состоит в основном из работы с userspace: ядро вы трогаете редко и осторожно.

3.2. Из чего состоит дистрибутив

Одно ядро — сотни дистрибутивов. Дистрибутив — это готовый набор, собранный вокруг ядра:

Составная часть	Что это	Примеры различий
Ядро	версия и набор включённых опций	свежее ядро или проверенное годами
Стандартная библиотека C	прослойка между программами и системными вызовами	`glibc` почти везде, `musl` в Alpine
Базовые утилиты	`ls`, `cp`, `grep`, `sed`	GNU coreutils или BusyBox
Система инициализации	что запускается первым и управляет службами	`systemd` в большинстве, другие варианты реже
Пакетный менеджер и формат	как ставится и обновляется софт	`apt` и `.deb`, `dnf` и `.rpm`, `apk`
Политика версий и поддержки	как часто выходят версии и сколько живут	от девяти месяцев до десяти лет
Значения по умолчанию	что включено, где лежат конфигурации	пути, имена служб, права

Именно последние четыре строки создают основную разницу в работе. Команды ls и cd одинаковы везде; а вот то, что служба SSH называется ssh в Debian и sshd в RHEL-семействе, вы будете вспоминать каждый раз.

Про стандартную библиотеку стоит сказать отдельно, потому что это самая непонятная из ошибок новичка. Скомпилированная программа обращается к системным вызовам не напрямую, а через библиотеку C. В большинстве дистрибутивов это glibc, в Alpine — musl: он гораздо меньше, но не полностью совместим. Бинарник, собранный против glibc, в Alpine может не запуститься, причём сообщение будет обманчивым: оболочка скажет not found про файл, который существует, потому что не найден не файл, а нужный ему загрузчик библиотек. Знание этого экономит вечер отладки; подробнее вернёмся в блоке 08, когда будем уменьшать образы.

3.3. Три семейства, которые встречаются в работе

Debian и производные (Ubuntu). Пакеты .deb, менеджер apt. Самое распространённое семейство на серверах и в облаках, поэтому примеры этого курса даются для него.

Debian — политика поддержки: пять лет на выпуск, из них первые три года полная поддержка и ещё два года LTS. Текущий стабильный выпуск — Debian 13 «trixie», вышел 9 августа 2025 года, LTS-поддержка до 30 июня 2030-го. Предыдущий (oldstable) — Debian 12 «bookworm». В разработке — «forky» (14). Характер дистрибутива — консервативный: пакеты старее, зато меняются редко.
Ubuntu — выпуски каждые полгода, а LTS — раз в два года, в апреле. У LTS пять лет стандартных обновлений безопасности; подписка Ubuntu Pro расширяет это до десяти лет, а дополнительный вариант — до пятнадцати. Актуальные LTS: 26.04 (апрель 2026, поддержка до мая 2031), 24.04 (до мая 2029), 22.04 (до мая 2027).

Практический вывод: для сервера берут LTS. Промежуточный выпуск Ubuntu живёт девять месяцев — это нормально для рабочего ноутбука и плохо для сервера, который вы не собираетесь переставлять трижды в год.

RHEL и производные. Пакеты .rpm, менеджер dnf. Корпоративный мир, особенно там, где нужна коммерческая поддержка и сертификация.

RHEL (Red Hat Enterprise Linux) — платный, с десятилетним циклом поддержки; новая мажорная версия примерно раз в три года, RHEL 10 стала общедоступной в середине 2025 года.
CentOS раньше был бесплатной пересборкой RHEL, но проект превратился в CentOS Stream — теперь это поток, идущий впереди RHEL, а не его копия. У CentOS Stream 10 цикл около пяти лет, примерно до 2030 года. Из-за этого изменения появились Rocky Linux и AlmaLinux — бесплатные пересборки RHEL, которые заняли освободившееся место.

Alpine. Пакеты .apk, менеджер apk, библиотека musl, утилиты BusyBox. Отдельная история: это не «дистрибутив для серверов», а очень маленькая основа, которая стала популярной из-за контейнеров — базовый образ занимает единицы мегабайт против десятков у остальных. Плата за это — та самая несовместимость musl и урезанные утилиты, у которых нет части привычных флагов.

Отдельно про российские дистрибутивы. На рынке РФ вы встретите Astra Linux, РЕД ОС и семейство «Альт» — они входят в реестр отечественного ПО, и в госсекторе или в компаниях с требованиями по импортозамещению работа идёт именно с ними. Что полезно знать заранее: это Linux с привычными механизмами, отличается пакетная база и требования по сертификации. Astra Linux использует формат .deb и apt с репозиториями в /etc/apt/sources.list — то есть навык работы с Debian переносится напрямую. РЕД ОС построена на RPM-пакетах, что ближе к RHEL-семейству. «Альт» использует RPM-пакеты, но управляет ими менеджером на основе apt. В курсе мы на них не практикуемся, но понимать, куда вы попадёте с навыком Debian, а куда с навыком RHEL, стоит.

Arch, Gentoo и роллинг-релизы упомянем ради полноты: они хороши для изучения устройства системы и для рабочей машины, но на серверах встречаются редко, потому что «постоянно свежие пакеты» плохо сочетаются с «ничего не должно измениться без моего решения».

3.4. Как выбирать: критерии по порядку

Порядок здесь не случайный — он отражает, что дороже исправлять.

Что уже используется в компании. Второе семейство в инфраструктуре означает двойные плейбуки, двойные образы и двойные проверки. Веский повод отступить от этого критерия — только серьёзное техническое ограничение.
Срок поддержки против срока жизни системы. Простое правило: поддержка дистрибутива должна заканчиваться позже, чем вы планируете вывести систему из эксплуатации. Иначе обновление придётся делать в неудобный момент и под давлением.
Наличие нужного софта в пакетах. Если нужной версии нет в репозитории, вы будете собирать её сами или подключать сторонние репозитории — и то и другое становится вашей ответственностью навсегда.
Требования извне. Сертификация, требования заказчика, наличие коммерческой поддержки. Это критерий не технический, но обычно нерушимый.
Опыт команды. Дистрибутив, который никто не умеет отлаживать в три часа ночи, — плохой выбор, даже если он технически лучше.

Что не является критерием: свежесть версий сама по себе, размер сообщества, личные предпочтения и результаты синтетических тестов производительности. Разница в производительности между семействами на типовых задачах несопоставима с разницей в стоимости эксплуатации.

3.5. Как определить систему, на которую вас пустили

Пять команд, которые стоит выполнять на любой незнакомой машине. Порядок — от «что за система» к «в каком она состоянии».

cat /etc/os-release     # дистрибутив и версия — стандартный файл, есть везде
uname -r                # версия ядра
uname -m                # архитектура: x86_64, aarch64
hostnamectl             # сводка: ОС, ядро, архитектура, тип виртуализации (где есть systemd)
ls /etc/apt /etc/yum.repos.d 2>/dev/null   # какое семейство по наличию каталогов

Главный из них — /etc/os-release: это стандартный файл, а не особенность дистрибутива, и в нём есть машиночитаемые поля ID, VERSION_ID, PRETTY_NAME. Именно на них опираются скрипты, когда надо понять, где они запущены:

. /etc/os-release && echo "$ID $VERSION_ID"

Дальше стоит проверить то, о чём обычно забывают, — до какого срока эта версия поддерживается. Информации об этом в системе может не быть, поэтому смотрят на страницу жизненного цикла дистрибутива. Практическая ценность у этой проверки прямая: если поддержка закончилась, обновления безопасности не приходят, и это уже не вопрос удобства, а вопрос уязвимостей, которые никто не закроет.

3.6. Примеры и варианты реализации

Задача одна: выбрать и получить систему для работы. Отличается то, кто её вам даёт и что вы можете изменить.

Среда	Как решается	Что нужно иметь
Локальный стенд (Docker / VM)	Любой дистрибутив: контейнер запускается за секунды, ВМ ставится с ISO. Полная свобода выбора	Docker или гипервизор
VPS / bare-metal	Выбор из списка образов провайдера при создании; на своём железе — установка с ISO	Аккаунт у провайдера
Yandex Cloud	Выбор из каталога образов; часть образов подготовлена провайдером	Облачный аккаунт

Локальный стенд. Самый удобный способ посмотреть на несколько дистрибутивов сразу — контейнеры: docker run --rm -it debian:13 bash даёт систему за секунды и не оставляет следов. Образ с оснасткой блока (там уже есть ps, lsblk, strace и man-страницы) описан в examples/docker/. Ограничение важное: контейнер — это не полноценная система. В нём нет systemd, своего ядра и часто нет man; ядро используется общее с хозяином, поэтому uname -r в контейнере покажет ядро вашей машины, а не дистрибутива. Для сравнения пакетных менеджеров и библиотек этого достаточно, для изучения службы инициализации — нет, там нужна ВМ (урок 02.02).

VPS / bare-metal. Выбор ограничен списком образов провайдера, зато система полноценная. Тонкость, о которой стоит знать: образы провайдеров обычно уже изменены — предустановлен агент провайдера, настроен cloud-init, иногда открыт вход по паролю. Поэтому первое, что делается на новой машине, — проверка, что там уже есть и что оттуда стоит убрать.

Yandex Cloud. То же самое, плюс образы из каталога и возможность делать свои. В облаке заметнее ещё одно свойство выбора: чем более распространённый дистрибутив вы взяли, тем больше готового вокруг него — образы, инструкции провайдера, ответы в поддержке.

Что выбрать для курса. Практика идёт на Ubuntu LTS (24.04 или 26.04) — это то, что чаще всего встречается на серверах и в облаках; там, где поведение различается, в уроках будет отдельная пометка про RHEL-семейство. Alpine появится в блоке 08 как база для образов. Отступать от этого выбора можно, но тогда часть команд придётся переводить самостоятельно, и на это уйдёт время.

4. Практика на занятии (30 минут)

Курс проходят самостоятельно, поэтому шаги ниже — пошаговая инструкция: что сделать, зачем, что должно получиться и что делать, если вышло не так. Разберём свою систему и сравним три семейства в контейнерах. Docker установлен в уроке 01.06.

Шаг 1 (7 минут). Опишите свою систему.

Что ввести:

cat /etc/os-release
uname -r; uname -m

Зачем: это тот же набор полей, который вы будете читать первым делом на любой незнакомой машине — дистрибутив, версия, ядро, архитектура.
Ожидаемый результат: из /etc/os-release — строки PRETTY_NAME, ID, VERSION_ID; из uname — версия ядра вида мажор.минор.патч и архитектура (x86_64 или aarch64). Запишите все четыре значения в конспект.
Если не так: файла /etc/os-release нет вовсе — вы работаете в macOS или Windows, это и есть ответ на вопрос, почему практика курса идёт на стендах. Выполните команды внутри WSL2 или в контейнере Linux.

Шаг 2 (13 минут). Сравните три семейства.

Что ввести: запустите по очереди три контейнера и в каждом выполните один и тот же набор команд.

docker run --rm -it debian:13    bash
docker run --rm -it almalinux:10 bash
docker run --rm -it alpine:3     sh

Внутри каждого:

head -3 /etc/os-release
ls -d /etc/apt /etc/yum.repos.d /etc/apk 2>/dev/null    # какое семейство
for p in apt dnf apk; do command -v "$p"; done          # какой пакетный менеджер есть
ls /lib/ld-* /lib64/ld-* 2>/dev/null                    # загрузчик: glibc или musl
ls -l /bin/ls                                            # чем оказалась обычная утилита
exit

Зачем: одно и то же ядро под тремя разными наборами утилит, менеджеров пакетов и стандартных библиотек — увидеть своими глазами, из чего реально складывается разница между дистрибутивами.
Ожидаемый результат: (проверено на этих трёх образах)

	`debian:13`	`almalinux:10`	`alpine:3`
`PRETTY_NAME` / `NAME`	Debian GNU/Linux 13 (trixie)	AlmaLinux 10.2	Alpine Linux 3.24
каталог репозиториев	`/etc/apt`	`/etc/yum.repos.d`	`/etc/apk`
пакетный менеджер	`/usr/bin/apt`	`/usr/bin/dnf`	`/sbin/apk`
загрузчик библиотек	`/lib64/ld-linux-x86-64.so.2`	`/lib64/ld-linux-x86-64.so.2`	`/lib/ld-musl-x86_64.so.1`
`/bin/ls`	отдельный бинарник ~150 КБ	файл на 49 байт с shebang на `/usr/bin/coreutils`	ссылка на `/bin/busybox`

Две строки здесь стоят внимания. Загрузчик в Alpine называется ld-musl-* вместо ld-linux-* — это и есть musl вместо glibc, из-за чего чужие бинарники в Alpine не запускаются. И /bin/ls устроен во всех трёх по-разному: в Debian это обычная программа, в Alpine — ссылка на единый BusyBox, а в AlmaLinux 10 — крохотная обёртка, вызывающая один общий бинарник coreutils. Из этого следует практическая вещь: «утилита ls» — не универсальная сущность, и набор её флагов зависит от того, чья это реализация.

Заполняйте таблицу в examples/02.01-distros-and-kernel/distro-compare.md по ходу.

Если не так: третья команда (for p in apt dnf apk; do command -v "$p"; done) написана циклом не для красоты. Запись command -v apt dnf apk в одну строку работает в bash, но в Alpine оболочка — BusyBox ash, и там command -v принимает только один аргумент; вывод окажется пустым, и легко сделать неверный вывод, что пакетного менеджера нет. Это ровно тот класс различий, из-за которого скрипты, написанные «под bash», ломаются в контейнерах на Alpine. Вернёмся к этому в блоке 04.

Шаг 3 (5 минут). Проверьте, что ядро не от дистрибутива.

Что ввести:

uname -r

— выполните во всех трёх контейнерах из шага 2 (запустите каждый ещё раз, если уже вышли).

Зачем: убедиться на практике, а не только в теории, что у контейнера нет своего ядра — оно общее с хозяином и от выбранного дистрибутива не зависит.
Ожидаемый результат: значение uname -r одинаковое во всех трёх контейнерах. Чьё именно это ядро — зависит от вашей системы: на Linux это ядро вашей машины, значения совпадут с uname -r вне контейнера; на macOS и Windows контейнеры Linux работают внутри виртуальной машины, которую поднимает Docker Desktop, поэтому вы увидите ядро этой ВМ (у Docker Desktop оно с суффиксом linuxkit) — с uname вашей macOS оно не совпадёт, потому что там вообще не Linux.
Если не так: значения разошлись между контейнерами — вы, скорее всего, сравниваете вывод из разных сессий или разных машин; в пределах одного запуска Docker на одном хозяине расхождений быть не может.
Ответьте: что из этого следует про то, чему нельзя учиться в контейнере?

Шаг 4 (5 минут). Найдите срок поддержки.

Что сделать: откройте официальную страницу жизненного цикла вашего дистрибутива (ссылки — в разделе 8) и найдите дату окончания поддержки версии, которую вы записали в шаге 1.
Зачем: дистрибутив без обновлений безопасности — не вопрос удобства, а открытая дыра, про которую никто не сообщит, пока её не найдут раньше вас.
Ожидаемый результат: в конспекте записана дата окончания поддержки и ссылка на страницу, откуда она взята.
Если не так: своей версии на странице жизненного цикла не нашли — проверьте, не вышла ли она уже из поддержки и не убрана ли со страницы актуальных версий; это тоже результат, и его стоит записать явно, а не пропустить шаг.
Ответьте: сколько месяцев осталось и что вы будете делать, когда они закончатся?

Проверка результата. Таблица сравнения заполнена по трём дистрибутивам, вы можете назвать пакетный менеджер и стандартную библиотеку каждого, объяснить, почему uname -r в контейнере показывает не то, что ожидалось, и назвать дату окончания поддержки своей системы.

5. Домашняя работа (1–2 часа)

Задание. Обоснуйте выбор дистрибутива и проверьте, что понимаете последствия.

Сравнение версий пакетов. Возьмите один и тот же популярный пакет (например nginx или postgresql) и выясните, какая его версия доступна в репозиториях debian:13, ubuntu:24.04, ubuntu:26.04 и almalinux:10. Внутри контейнера:
```
# Debian/Ubuntu
apt update -qq && apt-cache policy nginx | head -5
# AlmaLinux
dnf -q info nginx | head -10
```
Сведите результат в таблицу и объясните разброс.
Карточка выбора по шаблону examples/02.01-distros-and-kernel/distro-choice.md для трёх разных задач: (а) веб-сервис, который проживёт пять лет; (б) базовый образ для контейнера приложения; (в) сервер в организации с требованием отечественного ПО. Для каждой — выбор и обоснование по критериям из раздела 3.4, включая срок поддержки с датой.

Эксперимент про musl. Проверьте гипотезу: программа, собранная под glibc, не запустится в Alpine — и доведите разбор до причины, а не до факта. Компилятор не нужен: возьмите готовый бинарник из образа Debian.

mkdir -p ~/lab/02.01 && cd ~/lab/02.01
# взять из Debian обычную программу и посмотреть, что ей нужно
docker run --rm -v "$PWD:/out" debian:13 sh -c 'cp /bin/ls /out/ls-from-debian && ldd /bin/ls'
# запустить её в Alpine
docker run --rm -v "$PWD:/work" -w /work alpine:3 sh -c './ls-from-debian; echo "код возврата: $?"'

Дальше в Alpine выясните, почему сообщение говорит not found про существующий файл:

docker run --rm -v "$PWD:/work" -w /work alpine:3 sh -c '
  ls -l ls-from-debian                        # файл на месте
  od -c ls-from-debian | head -1              # и это ELF
  strings ls-from-debian | grep ld-           # какой загрузчик он просит
  ls -l /lib64/ld-linux-x86-64.so.2           # есть ли он здесь
  ls /lib/ld-*'                               # а что есть вместо него

Оформите по карточке эксперимента из урока 01.07. В выводе объясните, что именно не найдено.

Срок поддержки на практике. Для трёх дистрибутивов (Debian 13, Ubuntu 24.04, ваш собственный) найдите на официальных страницах даты окончания поддержки и посчитайте, сколько месяцев осталось. Ссылки на страницы приложите.

Критерии приёмки.

Таблица версий пакета заполнена по четырём дистрибутивам, у каждой версии указано, чем получено.
Разброс версий объяснён через политику выпусков, а не через «там новее».
Три карточки выбора заполнены; в каждой указан срок поддержки с датой и источник.
Для задачи (в) выбор сделан среди дистрибутивов из реестра отечественного ПО и сказано, какой навык — Debian или RHEL — там пригодится.
Карточка эксперимента с musl заполнена, вывод команд приложен целиком.
В карточке эксперимента объяснено, почему сообщение об ошибке говорит not found про существующий файл.
Даты окончания поддержки трёх дистрибутивов найдены на официальных страницах, ссылки приложены.

Файлы для работы: blocks/02-linux/examples/02.01-distros-and-kernel/ — примеры к этому уроку в репозитории курса.

6. Частые ошибки и подводные камни

Ставить на сервер не-LTS выпуск. Симптом: через девять месяцев обновления безопасности перестают приходить. Причина: взяли самую свежую версию из списка, не посмотрев политику поддержки. Что делать: для серверов — только выпуски с длительной поддержкой; проверять дату окончания до установки.

Считать, что контейнер — это дистрибутив целиком. Симптом: в контейнере нет systemctl, man и служб, и делается вывод, что «в Alpine нет systemd, поэтому он плохой». Причина: контейнер — это файловая система с процессом, а не система с ядром и инициализацией. Что делать: для изучения служб — виртуальная машина; контейнер — для пакетов, библиотек и приложений.

Собирать в одном дистрибутиве, запускать в другом. Симптом: not found при запуске файла, который на месте. Причина: бинарник собран против glibc, а в системе musl — не найден загрузчик библиотек. Что делать: собирать и запускать в одном семействе либо собирать статически; в блоке 08 разберём multi-stage сборку, где это решается аккуратно.

Подключать сторонние репозитории, не подумав. Симптом: обновление системы ломает пакет или, наоборот, не даёт обновиться. Причина: пакет из сторонних репозиториев конфликтует с системным. Что делать: сначала искать нужную версию в официальных репозиториях и backports; сторонний источник подключать осознанно и записывать в конспект, что подключено и зачем.

Путать uname -r и версию дистрибутива. Симптом: на вопрос «какая версия системы» отвечают версией ядра. Причина: и то и другое «версия Linux». Что делать: дистрибутив и его версия — /etc/os-release, ядро — uname -r; это независимые числа.

Выбирать дистрибутив по производительности из статей. Симптом: в инфраструктуре второе семейство, потому что «оно быстрее на 3 %». Причина: синтетические тесты. Что делать: считать стоимость эксплуатации двух семейств вместо процентов; она всегда больше этих процентов.

7. Проверка усвоения

Что такое Linux в строгом смысле и что тогда такое дистрибутив?
Где проходит граница между kernel space и user space и через что программы её пересекают?
Почему падение программы не роняет систему, а падение в ядре — роняет?
Назовите четыре составные части дистрибутива, которые реально создают разницу в работе.
Чем musl отличается от glibc и как выглядит ошибка, когда их путают?
Ubuntu 26.04 LTS против Ubuntu 26.10: в чём практическая разница для сервера?
Что случилось с CentOS и откуда взялись Rocky Linux и AlmaLinux?
Почему uname -r внутри контейнера показывает ядро хозяина и чему из-за этого нельзя учиться в контейнере?
Вам дали незнакомый сервер. Какие команды выполните первыми, чтобы понять, что это за система?
Перечислите критерии выбора дистрибутива по порядку и назовите один, который критерием не является.

8. Материалы

Первоисточники:

The Linux Kernel Archives — сайт ядра: актуальные ветки, в том числе LTS, и сроки их поддержки. Полезно понимать, что версии ядра и версии дистрибутива живут отдельно.
Документация ядра Linux — официальная документация. Сейчас пригодится как ориентир, к разделам про cgroups и namespaces вернёмся в уроке 02.13.
man 5 os-release — стандарт на файл, по которому определяют дистрибутив. Короткая страница, стоит прочитать целиком.

Политики поддержки — то, по чему принимают решение:

Debian: релизы — текущий стабильный выпуск, oldstable, testing и сроки поддержки.
Ubuntu: цикл выпусков — даты выпуска и окончания поддержки всех LTS, что добавляет Ubuntu Pro.
Red Hat Enterprise Linux Life Cycle — десятилетний цикл и фазы поддержки RHEL.
CentOS Stream 10 — чем Stream отличается от прежнего CentOS Linux.
Alpine Linux: о проекте — заявленные свойства: размер, musl, BusyBox.

Для контекста по рынку РФ:

Справочный центр Astra Linux: репозитории и установка пакетов — видно, что работа с пакетами устроена как в Debian: apt и /etc/apt/sources.list.

← Предыдущий: 01.07. Как учиться в этой профессии: документация, man, RFC, эксперимент · Блок 02 · Следующий: 02.02. Установка и первичная настройка сервера →

Practice materials

Scripts, cheat sheets and starter files for the lesson tasks. The lesson text is on this page.