Начало 2026 года для сообщества ядра Linux получилось насыщенным. В конце января в документацию добавили раздел Linux kernel project continuity. В нем описывается, что произойдет, если ключевые участники проекта внезапно не смогут выполнять свою работу. Обсуждения шли еще на Maintainers Summit в декабре 2025-го, и теперь этот вопрос зафиксирован в документации в явном виде.

Все вполне логично. Ядро Linux давно превратилось в часть огромной мировой инфраструктуры — с десятками миллионов строк кода, тысячами разработчиков из компаний по всему миру и постоянным давлением со стороны требований к производительности, безопасности и энергоэффективности. Поэтому сообщество вынуждено не только поддерживать текущий уровень стабильности, но и экспериментировать, стараться сделать систему гибче и надежнее. В 2026 году проявились несколько направлений такой работы — от Rust и планировщиков до поддержки новых архитектур. Давайте посмотрим, что тут и как.


Rust в ядре: от эксперимента к повседневности

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

Источник

Эволюция идет относительно гладко, хотя есть и небольшие проблемы. Часть старых мейнтейнеров все еще смотрит на Rust скептически, особенно когда речь заходит о сложных подсистемах вроде GPU-драйверов. Стоит понимать, что сейчас никто не собирается переписывать все ядро с нуля — миллионы строк на C продолжают жить своей жизнью. Тем не менее для новых драйверов и отдельных компонентов преимущества Rust очевидны: проще привлекать разработчиков, привыкших к современным инструментам, и снижать риск типичных ошибок еще на этапе написания кода. В этом году инфраструктуру вокруг Rust продолжают приводить в порядок: улучшают связку с существующим C-кодом, дорабатывают инструменты сборки и готовят основу для более крупных компонентов.

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

Планировщики и фокус на эффективности

Еще одна важная тема — планировщик задач. Пока он справляется с типичными сценариями, но в системах с разными типами ядер и ускорителей требуется больше гибкости. Эту проблему пытаются решить через sched_ext — способ пробовать новые подходы к планированию без изменений в самом ядре.

Ну и в этом году обсуждают добавление в sched_ext понимания GPU и механизмов для разумного распределения задач с учетом энергопотребления. Система сможет сама перекидывать нагрузку на более экономичные компоненты. Это важно и для серверов в дата-центрах, и для мобильных устройств, где каждый ватт на счету. Не все участники процесса уверены, что eBPF-подход идеален для таких критических вещей, но наработки уже показывают реальные улучшения.

Параллельно дорабатывают и основной планировщик. Как именно? Его поведение стараются сделать более плавным в интерактивных сценариях и стабильнее в виртуальных средах. В результате система ведет себя предсказуемее — и на серверах, и на обычных рабочих машинах.

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

Новые архитектуры и рост экосистемы

RISC-V продолжает набирать популярность. Открытая архитектура привлекает производителей встроенных систем, IoT-гаджетов и даже серверов. Поддержка в ядре развивается быстро: улучшают векторизацию, добавляют расширения для ускорения вычислений, включая задачи машинного обучения. К этому году RISC-V уже становится реальной альтернативой в ряде сегментов, особенно во встраиваемых устройствах и специализированном оборудовании.

Крупные компании активно занимаются развитием RISC-V и поддержкой его в Linux. Например, Google и Intel участвуют в международных инициативах по развитию экосистемы RISC-V и оптимизации ее программной части. Ну а Qualcomm регулярно отправляет патчи для улучшения поддержки RISC-V в ядре. Это помогает расширить рынок и ускорить внедрение архитектуры в разные устройства и системы.

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

Помимо RISC-V, сообщество активно работает и с другими перспективными архитектурами. LoongArch — китайский проект — к началу 2026 года получает все более зрелую поддержку: в ближайших релизах появился 32-битный вариант (LA32R и LA32S). Плюс на рынке уже есть реальные устройства — мини-ПК и ноутбуки на процессорах Loongson, где Linux работает стабильно и показывает неплохую производительность по сравнению с традиционными платформами.

Резервный сценарий для управления ядром Linux

Отдельного внимания заслуживает документ, который в начале года вызвал заметный резонанс. В медиа появились громкие заголовки вроде «Мир готовят к Linux без Торвальдса», но все не так мрачно. В документации ядра появился новый раздел, неформально называемый конклавом, где описан резервный сценарий на случай, если ключевые интеграторы проекта — прежде всего Линус Торвальдс и его ближайшие помощники — по каким-то причинам не смогут выполнять свои обязанности. Это маловероятно (пока, п�� крайней мере), но не невозможно.

Идея оформилась после обсуждения на Maintainers Summit в декабре 2025 года. Сессию о стабильности Линукса и снижении внешних рисков вел Дэн Уильямс из Intel. Он начал разговор о рисках для проекта в случае непредвиденных ситуаций. В итоге участники согласились, что такой план нужен, но без жесткой иерархии и заранее назначенного преемника.

Источник

Что решили? В экстренной ситуации организатор последнего саммита (или представитель Technical Advisory Board) быстро собирает встречу ключевых мейнтейнеров. Онлайн или офлайн — как удобнее, главное, чтобы пришло как можно больше людей. На этой встрече, которую прозвали конклав (с намеком на выбор папы римского и белый дым), решают, как дальше управлять главной веткой. Цель простая: выбрать вариант, который лучше всего сохранит здоровье проекта и сообщества в долгосрочной перспективе.

Решение может быть любым: один человек, группа или даже комитет. Через пару недель итоги публикуют открыто, а Linux Foundation помогает с технической стороной. Документ подчеркивает: это именно запасной сценарий. Если Торвальдс решит уйти по собственному желанию, он сам все организует, как любой другой мейнтейнер.

Кстати, неформально обсуждается, что в переходной ситуации эту роль мог бы взять Грег Кроа-Хартман. Дело в том, что он уже не раз временно заменял Торвальдса и отвечает за стабильные ветки ядра. При этом сам документ сознательно избегает конкретных имен: важны не должности, а реальный опыт и вклад в проект. Но пока что сам Торвальдс никуда не собирается. 

В итоге 2026 год для ядра Linux начался без резких изменений, но с заметными сдвигами внутри проекта. Объем кода ядра уже превысил 40 миллионов строк, число активных контрибьюторов продолжает расти. Rust постепенно занимает свое место, планировщики становятся гибче, поддержка архитектур расширяется, а формальные процессы снижают риски вокруг управления. Развитие продолжается.