История развития ядра Linux: ключевые решения

Краткая история ядра Linux

История ядра Linux охватывает период от версии 0.01 в сентябре 1991 года до серии 7.x, которая сегодня загружается на серверах. Список релизов — наименее интересная часть этой истории. Несколько ключевых решений определили архитектуру системы, и каждое из них до сих пор влияет на работу арендуемого вами сервера.

Даты и номера версий приведены на основе данных kernel.org и опубликованной там истории релизов. Текущее состояние на август 2026 года: версия 7.0 вышла 12 апреля 2026 года, 7.1 — 14 июня 2026 года, а 7.2 находится на стадии release candidates.

Почему выбор GPL в 1992 году до сих пор важен

Версия 0.01 была опубликована 17 сентября 1991 года под лицензией, которую Торвальдс написал самостоятельно. Она требовала распространения исходного кода и содержала строку, которая имела большее значение: «Вы не можете распространять это за плату, даже за расходы на "обработку"». В 1991 году программное обеспечение поставлялось на дискетах, а копирование и пересылка дискет стоят денег. Это условие делало коммерческий дистрибутив Linux невозможным.

Он изменил это. Переход на GNU General Public License (GPL) был анонсирован в примечаниях к релизу 0.12 в январе 1992 года и вступил в силу 1 февраля 1992 года. Версия 0.95, вышедшая в марте 1992 года, стала первым релизом, опубликованным под этой лицензией. Весь бизнес, построенный впоследствии на Linux, опирается на это изменение.

Ядро лицензируется только версией GPL 2 и никогда не переходило на версию 3. Торвальдс отказался от этого в 2007 году, в основном из-за правила против «тивоизации» (anti-tivoisation) в GPLv3, которое требует, чтобы устройство, поставляемое с кодом GPL, также принимало модифицированную копию этого кода. Он считал заблокированное оборудование личным делом производителя. В 2017 году разработчики ядра опубликовали Kernel Enforcement Statement, который всё же заимствует один элемент из GPLv3: тот, кто устраняет нарушение после уведомления, сохраняет свою лицензию, вместо того чтобы лишиться её навсегда при первом же нарушении.

Для сервера это влечет два последствия. Бинарный файл ядра, который вы загружаете, дает право на получение соответствующего исходного кода, поэтому никто не может предоставить вам ядро Linux, которое вы не можете изучить или пересобрать. Кроме того, уведомление об авторских правах на ядро гласит, что лицензия не распространяется на пользовательские программы, которые используют службы ядра через обычные системные вызовы, поэтому проприетарные базы данных и агенты мониторинга поставляются для Linux без каких-либо нарушений. Разрешительная лицензия создает противоположное давление, и эту разницу стоит понимать перед выбором платформы: см. Linux и FreeBSD как серверные платформы.

Почему монолитное ядро победило на практике

29 января 1992 года Эндрю Таненбаум опубликовал в группе новостей comp.os.minix сообщение под заголовком "LINUX is obsolete". Он выдвинул два тезиса. Монолитные ядра, в которых драйверы и файловые системы работают в одном привилегированном адресном пространстве, — это архитектура 1970-х годов, тогда как микроядра, где эти компоненты исполняются как обычные процессы, являются будущим. И Linux жестко привязан к архитектуре Intel 386, поэтому он никогда не станет переносимым.

На утверждение о переносимости ответили самой переносимостью. В версии 1.2, вышедшей в марте 1995 года, была добавлена поддержка Alpha, SPARC и MIPS. В версии 2.0 в июне 1996 года появился 64-битный порт для Alpha.

На утверждение об архитектуре ответили компромиссом. Linux не стал микроядром. В нем появились загружаемые модули ядра: объектные файлы, которые можно вставить в работающее ядро и извлечь обратно, поэтому драйвер поставляется отдельно от бинарного файла ядра.

lsmod | head
modinfo virtio_net | head -5

Команда lsmod выводит список того, что загружено в данный момент. modinfo выводит путь к файлу, из которого был загружен модуль, и параметры, которые он принимает. На виртуальном сервере большая часть дискового и сетевого стека реализована в виде модулей, именно поэтому один и тот же образ ядра загружается на оборудовании, которое он ранее не встречал.

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

Цена, которую сохранил Linux, — это то, что необходимо учитывать при планировании: модуль работает с полными привилегиями ядра, поэтому сбойный модуль приводит к краху всей системы, а не одного процесса. Проблемы чаще всего возникают с модулями, не входящими в основное дерево ядра (out-of-tree). Драйвер от поставщика, отсутствующий в основной ветке, необходимо пересобирать для каждого нового ядра — именно это делает DKMS во время обновления. Если сборка завершается неудачей, устройство просто перестает работать после перезагрузки.

Почему на реализацию SMP ушло пятнадцать лет

Ядро Linux 2.0, выпущенное в июне 1996 года, стало первой версией с поддержкой симметричной многопроцессорной обработки (SMP). Это означает, что одно ядро могло работать на нескольких процессорах одновременно. Первая реализация использовала единую блокировку — big kernel lock (BKL), поэтому в коде ядра в каждый момент времени мог находиться только один процессор. В результате второй процессор помогал при выполнении вычислений в пространстве пользователя, но почти не ускорял работу системных вызовов, так как они выстраивались в очередь за одной и той же блокировкой.

Устранение этой блокировки заняло пятнадцать лет. Оставшиеся участки кода были переведены на гранулярные блокировки, в основном усилиями Arnd Bergmann, и BKL была окончательно удалена в версии 2.6.39, выпущенной 18 мая 2011 года. Планировщик развивался в таком же медленном темпе: планировщик O(1) появился в 2.6.0, Completely Fair Scheduler (CFS) — в 2.6.23 в 2007 году, а EEVDF заменил CFS в версии 6.6 в октябре 2023 года.

Благодаря этой работе конфигурация с 4 vCPU сегодня является обычным делом. Однако это также определяет предел, о котором стоит знать. На общем виртуальном сервере ваше ядро планирует потоки, а гипервизор планирует ваше ядро. Запустите top и изучите поле %st. Steal time — это время процессора, которое ваше ядро было готово использовать, но хост отдал его другой гостевой системе, поэтому никакая настройка внутри вашего ядра не поможет его вернуть.

Почему в серии 2.6 изменился порядок сборки ядра

До версии 2.6 номера версий шли парами. Четная вторая цифра означала стабильную серию (2.4), нечетная — разработку (2.5). Версия 2.4 вышла 4 января 2001 года, а 2.6 — 17 декабря 2003 года, поэтому пользователям пришлось ждать следующую стабильную серию почти три года. Дистрибутивы не могли ждать, поэтому они занимались бэкпортом. Два поставщика, выпускавшие «2.4», поставляли ядра, различающиеся тысячами патчей.

Разделение было отменено после 2.6. Сейчас в основной ветке (mainline) открывается окно слияния (merge window) примерно на две недели, принимаются новые изменения, затем выпускаются релиз-кандидаты до тех пор, пока разработка не затихает, и релиз выходит каждые 9–10 недель — этот цикл до сих пор документирован на kernel.org. Вторая часть модели появилась 4 марта 2005 года с первым релизом стабильной ветки (stable tree) — обновлением с исправлениями для 2.6.11, которое поддерживали Greg Kroah-Hartman и Chris Wright. Стабильная ветка принимает только исправления и отклоняет новые функции.

Побочный эффект: номер версии перестал быть обещанием. 3.0, 4.0, 5.0 и 7.0 не являются переписанными версиями. Torvalds увеличивает первую цифру, когда вторая становится достаточно большой, чтобы его беспокоить, поэтому 7.0 последовала за 6.19 в апреле 2026 года. Для сервера важно то, какую ветку отслеживает ваш дистрибутив и получает ли эта ветка исправления.

Как конфликт вокруг BitKeeper привел к созданию git в апреле 2005 года

Начиная с февраля 2002 года, разработка ядра велась в BitKeeper — проприетарной распределенной системе контроля версий от компании BitMover Ларри Маквоя (Larry McVoy), начиная с серии 2.5. Компания BitMover предоставила разработчикам ядра бесплатную лицензию с рядом условий: запрещалось работать над конкурирующими инструментами контроля версий и выполнять обратную разработку (reverse engineering) BitKeeper. Многим разработчикам не нравилось создавать свободное ядро с помощью инструмента, код которого им запрещено изучать.

Ситуация обострилась в апреле 2005 года, после того как Эндрю Триджелл (Andrew Tridgell) продемонстрировал программу, взаимодействующую с репозиториями BitKeeper. В BitMover назвали это обратной разработкой и отозвали бесплатную лицензию. Ядро осталось без системы контроля версий в середине цикла разработки.

Работа над git началась 3 апреля 2005 года. Торвальдс анонсировал его 6 апреля. Уже 7 апреля git стал самодостаточным (self-hosting), что означает, что история самого git уже хранилась в git. Первое слияние нескольких веток было выполнено 18 апреля. В июне 2005 года git обеспечил выпуск версии 2.6.12. Вскоре после этого Торвальдс передал сопровождение проекта Джунио Хамано (Junio Hamano) и вернулся к работе над ядром.

Архитектура системы напрямую вытекала из решаемой задачи: тысячи участников и сопровождающие, которые получают изменения друг от друга через сеть, которой никто не доверяет. Каждый объект именуется на основе хеша своего содержимого, поэтому изменение хотя бы одного байта в старой истории меняет имя каждого последующего коммита. Именно поэтому клон репозитория является доказательством, а не просто утверждением. Каждый конвейер развертывания (deploy pipeline), каждый репозиторий конфигураций, хостинг кода, куда отправляют изменения большинство команд и git-сервер, который можно запустить самостоятельно — всё это выросло из лицензионного спора вокруг одного ядра.

Что обещает модель LTS и чего она не обещает

Mainline — это не то, что следует использовать в продакшене. Релиз mainline сменяется новым через 9–10 недель. Ветка stable получает исправления в течение нескольких недель после каждого релиза. Ветки Longterm, обычно называемые LTS, получают их годами, и именно на них опираются дистрибутивы.

Версия 2.6.32, выпущенная в декабре 2009 года, стала доказательством эффективности этой модели. RHEL 6, Debian 6, SUSE Linux Enterprise 11 SP1 и Ubuntu 10.04 LTS использовали именно её, а поддержка ветки продолжалась до февраля 2016 года — более шести лет с момента появления.

Обещания по срокам менялись не раз. Сначала это было два года, затем для некоторых веток — шесть лет. В 2023 году мейнтейнеры stable сократили срок по умолчанию до двух лет, так как бэкпортирование исправлений в старые ветки требует много времени, а сами старые ветки проходят недостаточно реального тестирования. 25 февраля 2026 года Greg Kroah-Hartman снова опубликовал более длительные прогнозы после обсуждения с компаниями, зависящими от этих веток, и текущая схема предполагает поддержку от трёх до шести лет.

[
  {
    "kernel": "5.10",
    "released": "2020-12-13",
    "eol_projected": "Dec 2026",
    "maintained_for": 6.0
  },
  {
    "kernel": "5.15",
    "released": "2021-10-31",
    "eol_projected": "Dec 2026",
    "maintained_for": 5.1
  },
  {
    "kernel": "6.1",
    "released": "2022-12-11",
    "eol_projected": "Dec 2027",
    "maintained_for": 5.0
  },
  {
    "kernel": "6.6",
    "released": "2023-10-29",
    "eol_projected": "Dec 2027",
    "maintained_for": 4.2
  },
  {
    "kernel": "6.12",
    "released": "2024-11-17",
    "eol_projected": "Dec 2028",
    "maintained_for": 4.1
  },
  {
    "kernel": "6.18",
    "released": "2025-11-30",
    "eol_projected": "Dec 2028",
    "maintained_for": 3.1
  }
]

На сайте kernel.org по состоянию на август 2026 года указано 6 веток longterm. Самая старая из них, 5.10, получит исправления в течение 6.0 лет, когда её поддержка завершится в Dec 2026. Самая новая, 6.18, по прогнозам, будет поддерживаться до Dec 2028, что составляет 3.1 лет исправлений.

Воспринимайте эти даты как минимальный срок, а не как контракт. Прогнозы для 6.6 и 6.12 были сдвинуты в феврале 2026 года, но ветка, которой никто не пользуется, может быть закрыта раньше. Ваш дистрибутив обычно делает выбор за вас: Debian 13 поставляется с 6.12, а Ubuntu 26.04 LTS — с 7.0. Этот разрыв и есть практическая суть вопроса о выборе между LTS и промежуточными релизами на сервере, и именно это по-настоящему меняется «под капотом», когда вы обновляете Ubuntu 24.04 до 26.04.

Из этого вытекает одна ловушка. Команда uname -r в Ubuntu 24.04 выводит что-то вроде 6.8.0-51-generic. Это базовая версия от upstream плюс собственные бэкпорты дистрибутива, поэтому номер версии указывает лишь на то, с чего ветка началась, а не на то, какие именно исправления в неё включены. Сканеры, которые оценивают ядро только по строке версии, по этой самой причине выдают ложные срабатывания для ядер дистрибутивов.

Текущие дискуссии в ядре

В настоящее время ведутся два спора, и оба касаются распределения обязанностей.

Язык Rust стал частью инфраструктуры ядра в версии 6.1 в декабре 2022 года. В версии 7.0 с него был снят статус экспериментального, поэтому основными языками ядра теперь являются C, ассемблер и Rust, а для сборки больше не требуется nightly-компилятор. Спор касается сопровождения кода. Мейнтейнер C-кода, изменяющий интерфейс, может нарушить работу привязок Rust, которые он не изучает, и дискуссия ведётся о том, кто именно должен исправлять эти поломки.

Второй спор касается вклада ИИ. Саша Левин предложил политику в июле 2025 года, после того как объём патчей, созданных с помощью машинного обучения, в списках рассылки начал расти. Документ был принят 23 декабря 2025 года и теперь находится в официальной документации процесса разработки ядра по адресу docs.kernel.org/process/coding-assistants.html. ИИ-агент не должен добавлять тег Signed-off-by, так как эта строка подтверждает Developer Certificate of Origin (DCO), а подтвердить его может только человек. Использование помощников декларируется тегом Assisted-by:, который был изменён с Co-developed-by: в ходе рецензирования, поскольку инструмент не является автором. Сгенерированный код должен быть совместим с лицензией GPL-2.0-only. Человек, отправляющий патч, проводит его проверку и несёт за него ответственность.

Причиной введения этой политики стало время, затрачиваемое на рецензирование. Генерация патча занимает секунды, а его проверка отнимает у мейнтейнера полдня. Тег не решает этот дисбаланс. Однако он сохраняет происхождение кода: история изменений продолжает фиксировать, кто подписался под каждым изменением, — именно это свойство DCO был призван защитить в 2004 году.

Что эта история означает для арендуемого вами сервера

• Лицензия — это причина, по которой вы можете читать и пересобирать ядро, которое загружает ваш провайдер, и по которой на нем работает проприетарное программное обеспечение.
• Монолитная архитектура — это причина, по которой одна ошибка в драйвере приводит к перезагрузке всей машины, и по которой внешний модуль (out-of-tree) приходится пересобирать при каждом обновлении ядра.
• Модель релизов — это причина, по которой номер версии дает мало информации, в то время как ветка и дата окончания ее поддержки говорят почти обо всем.
• Тип виртуализации определяет, что именно вам разрешено делать: в KVM вы загружаете собственное ядро и загружаете модули, тогда как при контейнерной виртуализации, использующей общее ядро хоста, uname -r показывает версию хоста, modprobe завершается с ошибкой, а некоторые параметры sysctl доступны только для чтения.

FAQ

Почему ядро Linux до сих пор распространяется под лицензией GPLv2, а не GPLv3?

Линус Торвальдс отказался от перехода на GPLv3 в 2007 году, в основном из-за требования о запрете «тивоизации» (anti-tivoisation). Это требование обязывает производителя устройства, поставляющего код под GPL, обеспечить возможность запуска на этом устройстве модифицированной версии кода. Торвальдс считает, что блокировка аппаратного обеспечения — это личное дело производителя. Смена лицензии на практике практически невозможна, так как авторские права на код ядра принадлежат тысячам контрибьюторов, и не существует соглашения о передаче прав, на которое можно было бы опереться. Ядро лицензировано исключительно как GPL-2.0-only, поэтому код, предлагаемый только под GPLv3, не может быть включен в состав ядра.

Ядро Linux — это монолитное ядро или микроядро?

Монолитное, с поддержкой загружаемых модулей. Драйверы и файловые системы работают в адресном пространстве ядра, а команда lsmod позволяет увидеть те из них, что загружены в данный момент. Это дает преимущество в скорости, но увеличивает радиус поражения: неисправный модуль может вызвать kernel panic всей системы, тогда как в микроядерной архитектуре это привело бы лишь к завершению одного процесса. С 1992 года ситуация изменилась: появились файловые системы FUSE, работающие в пространстве пользователя, и программы eBPF, которые ядро проверяет перед выполнением.

В чем разница между mainline, stable и longterm ядрами?

Mainline — это основная ветка разработки Торвальдса, новые версии которой выходят каждые 9–10 недель; именно здесь в первую очередь появляются новые функции. Ветка stable берет за основу последний релиз mainline и получает исправления ошибок в течение нескольких недель. Ветки longterm получают обновления в течение нескольких лет, и именно на них дистрибутивы основывают свои ядра. На сайте kernel.org приведен список текущих веток longterm с указанием прогнозируемой даты окончания поддержки для каждой из них.

Принимает ли ядро Linux код, написанный ИИ?

Да, в соответствии с политикой, принятой в декабре 2025 года. Инструмент должен быть указан в теге Assisted-by:, ИИ-агент не должен добавлять строку Signed-off-by, а сгенерированный код должен быть совместим с лицензией GPL-2.0-only. Человек, отправляющий патч, подписывает его (sign-off), что означает проведение проверки и принятие ответственности за код в рамках Developer Certificate of Origin.

Какую версию ядра следует использовать на сервере?

Почти во всех случаях — ту, которую поддерживает ваш дистрибутив. Ядро дистрибутива — это ветка longterm с бэкпортированными исправлениями и результатами тестирования от вендора; именно на него ориентируются образы вашего провайдера и условия технической поддержки. Собирайте более новое ядро из mainline только в том случае, если вам нужен специфический драйвер или функция, и обязательно проверяйте дату окончания поддержки ветки, на которую вы переходите, прежде чем принимать решение.