История создания ядра Linux и его уникальные решения #

Главный итог истории ядра Linux: из студенческого хобби‑проекта 1991 года ядро превратилось в одну из ключевых инфраструктур человечества — с уникальной комбинацией технических решений (монолит + модульность, cgroups/namespaces, eBPF, нестабильный внутренний API при жёстко стабильном ABI) и организационной модели (базарная разработка, «benevolent dictator», почтовые патчи, Git, мощная роль корпораций при сохранении community‑контроля).¹²³⁴

Ниже — по этапам и с акцентом на ключевые вехи и необычные решения.

1. Зарождение (1991–1992): от MINIX к GPL‑ядру #

Исходная точка — осень 1991 года. Студент Хельсинкского университета Линус Торвальдс пишет свой учебный «UNIX‑подобный» ядро‑клон для i386, изначально под MINIX как платформу разработки.⁵¹

Ключевые события этого периода:

0.01 (17 сентября 1991) — первая опубликованная версия на FTP‑сервере FUNET. Она даже не могла собираться сама по себе и требовала MINIX для компиляции и тестирования.⁶⁷¹
0.02 (5 октября 1991) — первая «официальная» версия, о которой Линус объявляет в Usenet (comp.os.minix); уже пригодна к использованию энтузиастами.⁷¹
0.11 (декабрь 1991) — ядро становится self‑hosting: его можно скомпилировать на системе, работающей под самим Linux. Это важный психологический и технический рубеж.⁶⁷
0.12 и 0.95 (начало 1992) — внедряются виртуальная память, job control, виртуальные консоли; в этот период Linux официально переходит под GPLv2, отказавшись от первоначальной лицензии, запрещавшей коммерческое распространение.⁵⁷⁶

Критически важное решение — выбор GPLv2 и сочетание с компонентами GNU. Это превращает ядро из «учебной игрушки» в проект, который легально можно встраивать в коммерческие дистрибутивы и продукты, при этом заставляя всех распространяющих модификации открывать исходники ядра.⁸⁵

2. Ранние стабильные ветки 1.x (1993–1996) #

К 1993–1994 году ядро уже перестаёт быть игрушкой и становится основой полноценных UNIX‑подобных систем.

Основные вехи:

0.99 (1992–1993) — появление ext2, NFS, TCP/IP, kmalloc; ядро быстро растёт по функциональности и размеру архива.⁷
1.0.0 (14 марта 1994) — первая «стабильная» версия, с сетевым стеком и более чем 170 000 строк исходного кода.¹⁷
1.2 (1995) — улучшенный планировщик (round‑robin), многие расширения по устройствам и файловым системам.⁷

Именно в этот период:

ядро перестаёт зависеть от MINIX и полностью переезжает на GNU‑пользовательское окружение;⁵
начинает расти число поддерживаемых архитектур (помимо x86);¹
формируется базовая культура разработки через Интернет и рассылку LKML, с частыми тестовыми релизами.³⁹

3. Linux 2.x: SMP, современные ФС и выход в enterprise (1996–2003) #

Версия 2.x делает из Linux полноценную многопроцессорную серверную ОС.

2.0 (июнь 1996): SMP и многоплатформенность #

Поддержка symmetric multiprocessing (SMP) — многопроцессорные системы становятся «гражданами первого сорта».¹⁰⁷¹
Расширяется спектр поддерживаемых архитектур и аппаратуры; это закладывает традицию сильной портируемости ядра.

2.2 (1999): современный стек устройств и сети #

Ветвь 2.2 добавляет:⁷

поддержку USB‑устройств, FAT32, NTFS (read‑only);
начальную поддержку IPv6, новый планировщик со SLAB‑аллокатором;
Video4Linux и расширения сетевого стека.

2.4 (2001): новые файловые системы и фильтрация пакетов #

Ветвь 2.4 приносит целый «зоопарк» современных файловых систем и сетевой фильтрации:¹¹⁷

ext3 (журналируемая evolution ext2), ReiserFS, JFS, XFS;
netfilter/iptables как гибкую подсистему фильтрации и NAT;
tmpfs, GFS, улучшения по масштабируемости;
крупный рефакторинг подсистемы виртуальной памяти в 2.4.10.⁷

На этом фоне код ядра вырос с примерно 10 000 строк в 0.01 до миллионов строк коду в ветви 2.4.x.¹¹⁶

4. 2.6 и новая модель разработки (2003–2011) #

Технические вехи 2.6.0 #

2.6.0 (декабрь 2003) вводит:¹²¹¹⁷

O(1)‑планировщик — планирование процессов за постоянное время независимо от числа задач;
preemptible kernel — управляемая вытесняемость ядра, улучшая латентность на десктопах и в real‑time сценариях;
ALSA как основную звуковую подсистему;
SELinux как модуль безопасности (LSM), реализующий мандатную модель контроля доступа.

Новая модель версий: от «2.4/2.5» к непрерывным релизам #

До 2.6 использовалась схема: чётная средняя цифра — стабильная ветка (2.0, 2.2, 2.4), нечётная — экспериментальная (2.1, 2.3, 2.5). С выходом 2.6:¹²

отказываются от отдельной «девелоперской» ветки: новая функциональность интегрируется в основной ряд;
вводится модель с merge window ~2 недели сразу после релиза (принимаются крупные изменения), затем 6–10 недель только bugfix и выпуск rc‑версий; после стабилизации выходит следующий релиз.¹²

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

Ключевые «строительные блоки» современных Linux‑систем #

На базе 2.6 появляются или дозревают технологии, которые позже станут основой контейнеризации и облаков:

cgroups (control groups) — начаты в Google как «process containers» в 2006, слиты в 2.6.24 (январь 2008). Они позволяют ограничивать и учитывать ресурсы (CPU, память, I/O, сеть) для групп процессов.¹³¹⁴
namespaces — постепенно добавляются с начала 2000‑х (PID, mount, UTS, затем network namespaces в 2008), обеспечивая изоляцию видов ресурсов.¹⁴¹⁵
Комбинация cgroups+namespaces приводит к LXC и затем к современным контейнерам (Docker, Kubernetes).¹⁵¹⁴
CFS (Completely Fair Scheduler) — новый планировщик, слит в 2.6.23 (2007); он использует красно‑чёрное дерево и концепцию «виртуального времени» для равномерного распределения CPU и поддерживает group scheduling.¹⁶¹⁷¹⁸¹⁹

5. Линейки 3.x, 4.x, 5.x, 6.x: зрелость ядра #

Смена схемы нумерации #

С 2003 по 2011 официальная ветка оставалась 2.6.x; в какой‑то момент номер стал неудобно длинным (2.6.39 и далее). Тогда:

3.0 (июль 2011) и 4.0 (апрель 2015) были по сути косметическими сменами номера без крупных ломаюших изменений; фактически просто «обрезали одну цифру» в версии.¹²¹
В 2019 Linus переименовал планировавшийся 4.22 в 5.0; сам он подчеркнул, что это чисто нумерологическое решение: «4.x стал слишком большим, закончились пальцы на руках и ногах».¹¹²

С тех пор схема x.y (и x.y.z для стабилизированных веток) остаётся в силе.¹²

LTS/SLTS и роль стабильных веток #

Современная практика:

Ряд релизов помечается как LTS (long-term support) — поддерживаются несколько лет (особенно важны для embedded и enterprise).
Некоторые релизы получают статус SLTS (super-long-term support), поддерживаются более 10 лет в рамках инициативы Civil Infrastructure Platform.²⁰

Например, ядро 6.12 (2024) — 25‑й LTS и пятый SLTS с поддержкой примерно до середины 2030‑х; оно уже выбрано как основа для будущих долгоживущих дистрибутивов Debian 13 и RHEL 10.²⁰

Рост масштаба #

Пара показательных цифр:

0.01 (1991) — 88 файлов и ~10 239 строк кода.²¹⁶
3.2 (2012) — уже более 15 млн строк и 37 000 файлов.²²
5.x–6.x — десятки миллионов строк, десятки тысяч файлов; каждый релиз включает тысячи коммитов от сотен разработчиков.²¹²²²⁰

Ядро сегодня работает:

на серверах и суперкомпьютерах,
в Android‑смартфонах,
в сетевом и встраиваемом оборудовании,
в машине IoT и промышленных системах.¹⁰⁶¹

6. Уникальные технические решения #

6.1. Монолитное ядро с модульной архитектурой #

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

Компромисс достигается через:

активное использование загружаемых модулей (LKM): драйверы и части подсистем могут подгружаться и выгружаться без перезагрузки системы;
систему декларирования лицензии модуля (MODULE_LICENSE), где «GPL», «Dual BSD/GPL», «Proprietary» и т. д. управляют тем, как ядро воспринимает модуль;²³
механизм tainting: загрузка проприетарного или «подозрительного» модуля «загрязняет» ядро, что явно фиксируется и учитывается при отладке и поддержке.²³⁸

Такой дизайн уникален тем, что сочетает:

производительность монолитного ядра;
возможность динамического расширения почти как у микроядра;
и встроенную позицию по отношению к закрытым модулям (через taint‑флаги).

6.2. Жёсткая стабильность пользовательского ABI и сознательная нестабильность внутреннего API #

Два ключевых архитектурно‑организационных принципа:

«Не ломать user space»: системный вызовной интерфейс, /proc, /sys (за разумными исключениями) считаются частью стабильного ABI. Старые программы, собранные под очень ранние ядра, как правило продолжают работать и под новыми релизами.²⁴²⁵⁴
НЕТ стабильного бинарного интерфейса для драйверов и внутриядерного API. Официальный документ Linux Kernel (stable-api-nonsense.rst) прямо заявляет: ядро умышленно не имеет стабильного in‑kernel API или бинарного интерфейса для модулей. Причины:⁴
- возможность без оглядки рефакторить внутренние структуры и интерфейсы ради производительности, безопасности, поддержки нового железа;
- мотивация держать драйверы в дереве ядра (in‑tree), а не как закрытые внешние модули;
- упрощение поддержки: основная цель — «стабильно работающий драйвер», а не стабильность ABI как самоцель.²⁶⁴

Эта комбинация (стабильный пользовательский ABI + нестабильный внутриядерный API) — одно из самых отличительных техническо‑политических решений Linux, отличающее его от многих коммерческих ОС.²⁵²⁴⁴

6.3. Планировщик, cgroups/namespaces и контейнеры #

Linux многократно переизобретал свои механизмы управления ресурсами:

O(1)‑планировщик (2.6.0) дал предсказуемое время выбора следующей задачи независимо от их числа.¹¹⁷
CFS (2.6.23) ввёл:
- использование красно‑чёрного дерева runqueue, упорядоченного по «виртуальному времени» выполнения;
- отказ от жёстких тайм‑слайсов в пользу «справедливого» распределения;
- group scheduling — справедливость не только между задачами, но и между группами задач (например, пользователями).¹⁷¹⁸¹⁹¹⁶

Параллельно:

cgroups (2.6.24) дают контроль за ресурсами CPU, памяти, I/O на уровне групп процессов; в cgroups v2 (ядро 4.5+) введена единая иерархия и улучшенные интерфейсы.¹³
namespaces обеспечивают изоляцию пространств имён для PID, mount, сети, IPC и т. д.; с появлением network namespaces (2008) стало возможно создавать полностью изолированные сетевые стеки для процессов.¹⁴¹⁵

Комбинация этих механизмов (cgroups+nspace) является базой:

LXC;
современных контейнеров (Docker, containerd);
оркестраторов (Kubernetes).¹⁵¹⁴

То есть многие «новые» облачные технологии на самом деле — прямое следствие эволюции ядра.

6.4. eBPF: программируемость ядра без модулей #

eBPF (Extended BPF) — одна из самых новаторских возможностей новых ядер:

введён в ядре 3.18 (2014) как расширение классического BPF; получил полноценную поддержку в ветвях 4.x;²⁷²⁸²⁹
представляет собой безопасную виртуальную машину в ядре:
- код eBPF загружается из user space,
- статически проверяется (верификатор отсеивает потенциально опасные программы),
- затем JIT‑компилируется в нативные инструкции;²⁸²⁹
позволяет «подписываться» на события в ядре (сетевые пакеты, системные вызовы, tracepoints) и исполнять мини‑программы почти без накладных расходов, не изменяя исходный код ядра и не загружая новые LKM.²⁹²⁸

Практический результат: eBPF даёт возможность динамически расширять поведение ядра (трассировка, безопасность, фильтрация, observability) без классического риска «упасть вместе с драйвером».

7. Уникальные организационные и социальные решения #

7.1. Базарная модель разработки: «release early, release often» #

Наблюдатели (прежде всего Эрик Рэймонд) описывают модель разработки ядра как «базар» в противоположность «собору» — централизованной разработке закрытым ядром.²³⁰⁹³

Основные принципы, сформулированные по мотивам Linux:

Релизовать рано и часто: в ранние годы Linus публиковал новые ядра чуть ли не ежедневно, постоянно подпитывая интерес и обратную связь.⁹³
Максимально открытая разработка через Интернет: всё идёт в открытых почтовых рассылках; любой может читать обсуждения и присылать патчи.²³
Самоотбор контрибьюторов: люди выбирают те части, которые им интересны; чем больше «глаз» смотрит на код, тем быстрее находятся ошибки — «закон Линуса» («given enough eyeballs, all bugs are shallow»).³⁰⁹²

Важно, что Linux не просто использовал эти идеи, а стал эталоном, через который мир ФОСС принял «базарную» модель как норму.

7.2. «Benevolent dictator» и иерархия мейнтейнеров #

Управление ядром строится по модели benevolent dictator:

Линус Торвальдс — конечный арбитр, принимающий решение о включении изменений в mainline, но работающий через систему доверенных лейтенантов и мейнтейнеров подсистем.³¹³²³³
Под Линусом — иерархия мейнтейнеров (сетевой стек, файловые системы, архитектуры и т. д.), каждый из которых владеет своей областью, собирает патчи и отправляет «pull‑requests» вверх по цепочке.³³

Исследования организационной структуры ядра описывают это как chain-of-trust: доверие распространяется по иерархии; Torvalds не ревьюит каждый патч, а полагается на своих «лейтенантов».³³

При этом:

возможность форка (юридически заложенная в GPL) служит сдерживающим фактором — если лидер перестанет быть «benevolent», сообщество в принципе может пойти своим путём;³²³¹
на практике успех Linux показывает, что такая централизованная, но «мягкая» модель способна масштабироваться до десятков тысяч коммитов за релиз.

7.3. Почтовые патчи, LKML и MAINTAINERS вместо «централизованного GitHub» #

Несмотря на популярность Git‑хостингов, разработка ядра по сей день построена вокруг:

Linux Kernel Mailing List (LKML) и множества специализированных списков (memory, networking, filesystems и т. д.);
патчей в формате git send-email, отправляемых на релевантные списки и в копию соответствующим мейнтейнерам;
текстового файла MAINTAINERS в дереве исходников, который описывает, какие файлы кода кому принадлежат и какие списки использовать.³⁴³⁵³⁶

Это необычное решения по сравнению с большинством современных проектов (GitHub/GitLab merge requests):

осознанный выбор в пользу e-mail workflow, хорошо масштабируемого и независимого от конкретной фордж‑платформы;
сохранение всей истории обсуждений в открытых архивов рассылок.

7.4. BitKeeper → Git: рождение нового стандарта VCS из кризиса ядра #

До 2002 года Линус вообще не использовал полноценную систему контроля версий: патчи рассылались по Usenet и почте, применялись «вручную»; позже появились различные самодельные скрипты.³⁷

Дальнейшая эволюция:

В 2002 году для разработки ядра выбирается BitKeeper — проприетарная распределённая VCS компании BitMover. Это вызывает бурные споры: закрытый инструмент для открытого проекта.³⁸³⁷
Условия «бесплатного» использования для ядра включали ограничения (нельзя работать над конкурентными VCS, BitMover сохранял контроль над частью метаданных).³⁸³⁷
В 2005 разработчик Andrew Tridgell реверс‑инжинирует протокол BitKeeper, чтобы создать свободную альтернативу; BitMover в ответ отзывает бесплатную лицензию у сообщества ядра.³⁹³⁷³⁸

Реакция Торвальдса:

он временно останавливает работу над самим ядром и за считанные недели пишет новую систему контроля версий — Git, заточенную под:
- распределённость,
- высокую производительность на огромном репозитории с большим числом веток и мержей,
- надёжность и защиту истории от подделки.³⁷³⁸
уже через пару недель происходит первое «настоящее» слияние ветки ядра через Git.³⁸

Это один из самых ярких примеров того, как организационный кризис (утрата VCS) привёл к созданию инструмента, который позже станет де‑факто мировым стандартом управления исходниками.

7.5. Роль корпораций и Linux Foundation #

Со временем развитие ядра стало в основном корпоративно финансируемым:

По отчётам Linux Foundation и независимым обзорам, большинство коммитов приходят от разработчиков, нанятых компаниями (Intel, Red Hat, IBM, Google, Huawei, Oracle, SUSE, Meta и др.).⁴⁰⁴¹⁴²²²²¹
При этом нет единственного доминирующего игрока: топ‑10 компаний дают порядка 50–70 % изменений, остальное — «длинный хвост» компаний и независимых разработчиков.⁴¹⁴²²²²¹
Доля независимых разработчиков стабильно держится на уровне около 10–12 % коммитов.²²²¹

Linux Foundation:

публикует регулярные отчёты о развитии ядра («Who Writes Linux?»), отслеживая динамику вклада;²¹²²
формирует практики взаимодействия бизнеса с ядром, включая Linux Kernel Contribution Maturity Model — модель зрелости компаний в плане upstream‑вклада и времени, через которое их внутреннее ядро догоняет mainline.³⁶

Таким образом ядро Linux — пример того, как корпоративное финансирование и community‑управление могут сосуществовать в крупном критичном проекте.

7.6. Лицензирование: GPLv2‑only, исключение для системных вызовов и отношение к проприетарным компонентам #

Несколько важных решений по лицензированию:

Переход на GPLv2 (1992) снял запрет на коммерческое распространение, что сделало легальными дистрибутивы вроде Slackware, Debian, Red Hat и др., и заложило основу для коммерческого успеха Linux.⁸⁶⁵
Ядро остаётся под GPLv2‑only: Линус неоднократно высказывался против перехода на GPLv3 (прежде всего из‑за формулировок про DRM); практический барьер — необходимость согласия тысяч контрибьюторов.⁵¹
В лицензировании ядра есть исключение для системных вызовов: программы user space, которые просто вызывают ядро через syscalls, не обязаны быть GPL; это позволило существование проприетарных приложений и middleware поверх Linux.⁵¹
Модули драйверов могут иметь более свободную или даже проприетарную лицензию, но ядро:
- помечает такие модули как tainted,
- не гарантирует им стабильность внутриядерного интерфейса.⁴²³⁸

Совокупно это создало баланс: ядро и большинство низкоуровневых компонентов остаются строго свободными, при этом экосистема допускает existence бизнеса с закрытым ПО поверх Linux.

8. Краткая хронология основных вех #

Для наглядности — компактный перечень ключевых точек:

1991
- 0.01 (сентябрь) — первая опубликованная версия под MINIX, ~10 239 строк кода.⁶¹
- 0.02 (октябрь) — первый «официальный» релиз для широкой публики.¹⁷
- 0.11 (декабрь) — ядро становится self‑hosting.⁷
1992
- Переход на GPLv2, выход 0.12, затем 0.95 с серьёзными улучшениями.⁶⁵⁷
1994
- 1.0.0 — первая стабильная версия, >170 000 строк кода, сформированный сетевой стек.¹⁷
1996
- 2.0 — SMP, поддержка нескольких архитектур; Linux становится серьёзной серверной ОС.¹⁰⁷¹
1999–2001
- 2.2 — USB, IPv6, SLAB, множество файловых систем.⁷
- 2.4 — ext3, ReiserFS, JFS, XFS, netfilter, крупная переработка VMM.¹¹⁷
2003
- 2.6.0 — O(1)‑планировщик, preemption, ALSA, SELinux; начало новой модели релизов без отдельной dev‑ветки.¹¹¹²⁷
2006–2008
- Введение cgroups (2.6.24) и постепенное развитие namespaces; первые полноценные контейнерные технологии (LXC).¹³¹⁴¹⁵
2007
- CFS становится основным планировщиком задач (2.6.23).¹⁸¹⁹¹⁶¹⁷
2005
- Конфликт с BitKeeper → рождение Git как новой распределённой VCS, заточенной под нагрузку ядра.³⁹³⁷³⁸
2011
- 3.0 — смена схемы нумерации без серьёзной архитектурной ломки.¹²¹
2014–2016
- eBPF (3.18) и затем XDP, BTF и пр. → программируемое ядро без модулей.²⁷²⁸²⁹
- cgroups v2 (4.5) с единой иерархией.¹³
2020‑е
- Линейки 5.x и 6.x с продолжением развития BPF, контейнерных и облачных сценариев, аппаратных оптимизаций.
- Появляются SLTS‑ядра вроде 6.12 с поддержкой более 10 лет.²⁰

Итог #

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

монолитное ядро с жёсткой нестабильностью внутриядерного API, но с практически непрерываемым пользовательским ABI;
сверхоткрытый «базарный» процесс разработки с центральным лидером‑арбитром;
тяжёлая ставка на рассылки и текстовый патч‑воркфлоу вместо модных фордж‑сервисов;
готовность переписывать критические подсистемы (планировщик, VMM, сетевой стек), не боясь поломать внешний ABI;
интеграция корпоративных интересов в community‑управление без захвата проекта одной компанией.

Совокупность этих технических и организационных решений сделала ядро Linux тем, чем оно является сегодня: сердцем подавляющего большинства серверов, смартфонов и облачных вычислительных платформ в мире. ⁴³⁴⁴⁴⁵⁴⁶⁴⁷⁴⁸⁴⁹⁵⁰