Оглавление

Этот текст открывает рубрику «Linux под капотом». Моя цель простая. Показать, что происходит в Linux на самом деле и почему оно устроено именно так. Если ты админишь серверы, ковыряешь Docker или просто хочешь понимать систему глубже, это будет полезно.

Про Linux часто рассказывают как сказку: «один студент написал ОС, и она захватила мир». Сказка удобная, но в ней теряется самое полезное для практики: почему система устроена именно так, где у неё швы и какие решения тянутся с начала 90-х до сегодняшних контейнеров и продакшн-VPS.

Ещё одна путаница: Linux в бытовом смысле называют операционкой. Технически Linux это ядро. Вокруг него пользовательские утилиты, библиотеки, компиляторы, init-система, менеджер пакетов, графика и так далее. Если это держать в голове, многие странные баги становятся логичными: ломается не Linux вообще, а конкретная связка ядро плюс userland плюс init плюс настройки.

И третья причина знать историю: по ней видно, что Linux взлетел не потому, что был идеальным, а потому что оказался вовремя. Дешёвое PC-железо, уже готовые инструменты GNU, сеть людей через FTP и Usenet и правильная для роста лицензия.

Контекст и зачем это знать

История Linux полезна не ради ностальгии. Она объясняет, почему у системы такой скелет: почему ядро отдельно, почему вокруг него сборки-дистрибутивы, почему контейнеры это не мини-виртуалки, а другой класс изоляции.

Когда ты понимаешь, где заканчивается ядро и начинается пользовательское пространство, становится проще отлаживать проблемы: зависания на загрузке, сетевые чудеса, странности с правами, лимитами и процессами.

А ещё история отличный фильтр от мифов. Linux не внезапно победил, его собрали из кусочков, которые уже существовали: идеи Unix, инструменты GNU, учебный MINIX и ядро, которое стало совместимым с экосистемой свободного софта.

Как это устроено

До Linux был Unix-мир: идеи многозадачности, всё файл, права доступа, процессы и сигналы. К началу 80-х Unix был в университетах и индустрии, но свободным его не назовёшь: лицензирование и исходники были отдельной болью.

В 1983 Ричард Столлман объявляет проект GNU: цель собрать свободную Unix-подобную систему. Компилятор, утилиты, библиотеки, всё, что нужно для нормальной жизни.

Параллельно в учебном мире появляется MINIX: небольшой Unix-клон для изучения устройства ОС. MINIX вышел в 1987 и стал популярным в университетских курсах.

Линус Торвальдс в 1991 ковыряет MINIX и пишет в comp.os.minix про свои эксперименты: делает бесплатное ядро для 386/486, просит фидбек и честно говорит, что это пока хобби. Важно: он позиционировал проект как ядро, а не как готовую систему.

17 сентября 1991 Linux 0.01 выкладывают на FTP-сервер nic.funet.fi (CSC/FUNET). Это не релиз для пользователей: там были в основном исходники и очень ранняя сборка.

5 октября 1991 появляется публичное объявление про Linux 0.02. Это момент, когда проект начинает обсуждаться шире и к нему подключается больше людей.

Самое недооценённое событие ранней истории лицензия. Изначально условия распространения были неудачными для роста, а затем Linux быстро переехал на GPL-совместимую модель. Это сделало возможными дистрибутивы, поставки, сопровождение и нормальную экосистему вокруг ядра.

GPLv2 опубликована в июне 1991. То есть юридический инструмент роста уже существовал, и Linux довольно быстро на него лег. Плюс у GNU уже были GCC, shell, coreutils и куча базовых программ, фактически готовый userland. Linux-ядро, став GPL-совместимым, стыкуется с этим набором, и из ядра студента получается база для системы, которую можно собирать, распространять и развивать.

Как посмотреть это на живой системе

Задача: увидеть границу «ядро vs окружение» и понять, где искать правду, когда что-то ломается. Ниже пять быстрых проверок. Каждая занимает секунды, но вместе они дают нормальную картину.

  • Версия ядра и архитектура. Это первое, с чего стоит начинать, когда проблема похожа на ядро.

uname -a

  • Чем ядро собрано и кем подписано. Здесь видно строку сборки и компилятор, а иногда и подсказки про окружение сборки.

cat /proc/version

  • Ранние сообщения ядра. Часто именно тут всплывают драйверы, параметры загрузки, диски, сетевые карты и первые ошибки.

dmesg | head

  • Какая userland-сборка. Это уже не ядро, а дистрибутив и его окружение. Полезно, когда сломалось после обновления, но неясно чего именно.

cat /etc/os-release

  • Кто у тебя PID 1, то есть какая init-система реально стартует систему. От этого зависит половина поведения сервиса и логов.

ps -p 1 -o comm=
История Linux без легенд: GNU, MINIX и первые релизы ядра. Почему Linux — это ядро, как сложилась экосистема и что проверить на живой системе.

Полезный щёлк по практике: зайди в контейнер и посмотри версию ядра. В контейнере она будет такой же, как на хосте. Это нормально. Контейнер изолирует процессы и окружение, но ядро делит с хостом.

uname -r

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

Типовые проблемы и симптомы

  • После обновления Linux всё сломалось. Часто обновилось не ядро, а userland или init. Если версия ядра прежняя, а релиз дистрибутива изменился, ищи в пакетах, сервисах и конфигах.

  • В контейнере же своя ОС. Симптом попытки чинить iptables или nftables, модули ядра или cgroups внутри контейнера. Ключевые вещи решаются на хосте или через настройки runtime, потому что ядро общее.

  • Легенды про лицензии мешают инженерии. Когда модель стала совместимой с GPL-экосистемой, вокруг ядра стало возможно строить дистрибутивы и сопровождение без постоянного юридического дребезга. Это не романтика, это инфраструктура роста.

Мини-лабораторка

Цель: потрогать Linux 0.01 и увидеть, почему это было ядро для 386, а не универсальная ОС.

  • Скачай архив Linux 0.01 с kernel.org и проверь, что файл приехал без сюрпризов.

wget https://www.kernel.org/pub/linux/kernel/Historic/linux-0.01.tar.gz
ls -lh linux-0.01.tar.gz

  • Распакуй архив в текущую папку.

tar -xzf linux-0.01.tar.gz
ls -la

  • Пробеги глазами по структуре проекта. Это быстрый способ понять, что перед тобой очень раннее ядро, без всего на свете.

find linux -maxdepth 2 -type d | head -n 50

  • Найди в Makefile следы ориентации на i386. Это прямой маркер эпохи 386/486.

grep -nE "386|i386" linux/Makefile

  • Оцени масштаб исходников. Это не научный показатель, но хорошо передаёт ощущение размера проекта.

find linux -type f \( -name "*.c" -o -name "*.h" \) | wc -l

  • Сравни с текущей системой. Просто чтобы почувствовать разницу сложности мира и того, сколько всего сообщает современное ядро на старте.

uname -r
dmesg | head -n 60

Источники и куда копать дальше

Что попробовать руками

Если времени мало, вот короткий набор проверок, который почти всегда даёт быструю диагностику: какая система, какое ядро, кто PID 1, что ядро сказало на старте, и есть ли проблемы в логах текущей загрузки.

  • Проверь базовую информацию о системе и ядре.

cat /etc/os-release
uname -a

  • Убедись, какая init-система у тебя реально работает.

ps -p 1 -o comm=
systemctl --version

  • Посмотри, что ядро сообщило на старте, и есть ли там явные ошибки.

dmesg | head -n 120
dmesg -T | egrep -i "error|fail|warn" | head -n 80

  • Проверь предупреждения и ошибки в логах текущей загрузки.

journalctl -b -p warning..alert --no-pager | head -n 120