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

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

История Linux kernel начинается с версии 0.01, выпущенной в September 1991, и продолжается серией 7.x, которая сегодня загружается на серверах. Список релизов — наименее интересная часть этой истории. Несколько решений определили устройство системы, и каждое из них до сих пор влияет на сервер, который вы арендуете сегодня. Причина, по которой в 1991 году вообще потребовалось новое ядро, изложена в более подробной истории Unix, лицензирования AT&T и судебного иска, из-за которого разработка BSD остановилась.

Даты и номера версий приведены на основе данных 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 выводит файл, из которого был загружен модуль, и параметры, которые он принимает. На виртуальном сервере большая часть путей к дискам и сети реализована через модули, поэтому один и тот же образ ядра загружается на оборудовании, которое он «не видел» ранее. Ядро лишь сообщает о новом оборудовании, а демон в пространстве пользователя решает, какой модуль загрузить и как назвать устройство. Именно поэтому управление устройствами перешло в систему инициализации, что отчасти объясняет, почему systemd стало сложно избежать.

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

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

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

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

На устранение этой блокировки ушло пятнадцать лет. Оставшиеся участки кода были переведены на гранулярные блокировки, в основном усилиями 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 — это время CPU, которое ваше ядро было готово использовать, но хост отдал его другой гостевой системе, поэтому никакая настройка внутри вашего ядра не поможет его вернуть.

Почему в серии 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, поддерживаемое Грегом Кроа-Хартманом и Крисом Райтом. Стабильная ветка принимает только исправления и отклоняет новые функции.

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

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

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

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

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

Архитектура системы стала прямым ответом на возникшую проблему: тысячи участников и сопровождающие, которые принимают изменения друг от друга через сеть, которой никто не доверяет. Каждый объект именуется на основе хеша своего содержимого, поэтому изменение хотя бы одного байта в старой истории меняет имя каждого последующего коммита. Именно поэтому клон репозитория является доказательством, а не просто заявлением. Каждый конвейер развертывания, каждый репозиторий конфигураций, хостинг кода, куда отправляют изменения большинство команд и 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 года — более шести лет после появления. Red Hat пошла ещё дальше и самостоятельно сопровождала ядро на базе 2.6.32 с помощью бэкпортов вплоть до окончания жизненного цикла RHEL 6 в 2020 году. Возможность бесплатно получить десятилетие такой поддержки — это главная причина, по которой существовал CentOS, а Rocky Linux и AlmaLinux пришли ему на смену.

Обещания по срокам менялись не раз. Сначала это было два года, затем для некоторых веток — шесть лет. В 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. Это базовая версия от апстрима плюс собственные бэкпорты дистрибутива, поэтому число указывает лишь на то, откуда ветка началась, а не на то, какие именно исправления в неё включены. Сканеры, которые оценивают ядро по строке версии, по этой самой причине выдают ложные срабатывания для ядер дистрибутивов.

О чем сейчас спорят в ядре

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

Поддержка 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) приходится пересобирать при каждом обновлении ядра.
• Модель релизов — это причина, по которой номер версии дает мало информации, тогда как ветка и дата окончания ее поддержки (end-of-life) говорят почти обо всем.
• Тип виртуализации определяет, что именно вам разрешено делать: в KVM вы загружаете собственное ядро и загружаете модули, тогда как при контейнерной виртуализации, использующей общее ядро хоста, uname -r показывает версию хоста, modprobe завершается с ошибкой, а некоторые параметры sysctl доступны только для чтения.

FAQ

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

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