Релиз ядра Linux 7.0: что изменилось и к чему готовиться администраторам и пользователям
------------------------------------------------------------
После примерно двух месяцев активной разработки Линус Торвальдс объявил о выходе ядра Linux 7.0. Номер мажорной версии сменился не из‑за какого‑то "революционного" перелома, а по эстетическим причинам: ветка 6.x разрослась до большого числа выпусков, как в своё время 5.19 сменили на 6.0. По сути это логичное продолжение эволюции ядра, но с очень заметным набором новшеств.
В ветку 7.0 вошло 15 624 изменения от 2 477 разработчиков. Патч потянул примерно на 56 МБ: затронуто 18 053 файла, добавлено около 704 тысяч строк кода и удалено 278 тысяч. Для сравнения, в предыдущей версии было чуть больше изменений, но меньший общий объём патча. Структура вклада традиционно перекошена в сторону железа: около 51% всех правок касаются драйверов устройств, около 11% - архитектурно‑специфичного кода, примерно 14% - сетевого стека, 5% - файловых систем и около 3% - внутренних подсистем ядра.
Ниже - ключевые направления изменений и то, как они скажутся на реальных системах.
Новая политика по использованию AI‑ассистентов
В код ядра официально встроены правила, регулирующие применение AI‑ассистентов при разработке. Формально это оформление уже существующей практики: автоматически сгенерированный код без должного контроля, понятной лицензии и аудита считается неприемлемым.
Смысл нововведений:
- запрет "бездумного" копипаста фрагментов, выданных ИИ, без проверки лицензий и соответствия стилю ядра;
- подчёркивание ответственности автора патча: именно человек, а не ассистент, отвечает за качество, безопасность и юридическую чистоту кода;
- снижение риска утечки чувствительных фрагментов кода через внешние сервисы.
Для рядового пользователя это почти незаметно, но для корпоративных разработчиков и мейнтейнеров - формализация требований, которые и так фактически действовали.
Rust становится полноценной частью ядра
Rust‑подсистема, ранее считавшаяся экспериментальной, теперь фактически переведена в разряд обычных возможностей ядра. Это не значит, что ядро внезапно переписали на Rust, но:
- инфраструктура для написания драйверов и компонентов на Rust стала стабильнее и шире;
- повышается интерес к использованию Rust для разработки модулей, где критична безопасность памяти и устойчивость к целым классам уязвимостей;
- дистрибутивы будут всё активнее включать поддержку Rust‑модулей в свои сборки ядра.
Для системных администраторов это сигнал: в среднесрочной перспективе часть драйверов и подсистем может прийти на Rust, что потенциально уменьшит количество багов, связанных с обращением к памяти.
Оптимизации подкачки и включение PREEMPT_LAZY по умолчанию
В 7.0 продолжено улучшение подсистемы подкачки: переработаны алгоритмы работы с памятью, чтобы сократить задержки при активном использовании swap и уменьшить негативное влияние на интерактивность систем под нагрузкой. На серверах и рабочих станциях с интенсивной нагрузкой это может вылиться в чуть более предсказуемое поведение при дефиците RAM.
Одно из самых обсуждаемых изменений - активация режима PREEMPT_LAZY по умолчанию. Он меняет баланс между латентностью и пропускной способностью, откладывая вытеснение задач в некоторых ситуациях. На практике это оказалось не безболезненно: на ARM64 выявлена серьёзная регрессия - производительность PostgreSQL в отдельных сценариях падает примерно в два раза.
Разработчикам PostgreSQL предложено использовать опцию `PR_RSEQ_SLICE_EXTENSION`, которая уменьшает вероятность вытеснения потока, владеющего блокировкой, и частично сглаживает регрессию. Администраторам, которые плотно используют PostgreSQL на ARM64, стоит внимательно отнестись к обновлению и протестировать свои нагрузки до массового развёртывания ядра 7.0.
Развитие файловых систем: Nullfs, Btrfs, XFS, NFS
В файловой подсистеме тоже немало значимых изменений:
- Новая ФС Nullfs
В ядро введена новая файловая система Nullfs. Она используется, в первую очередь, как служебный инструмент - для тестирования, спецсценариев и отладки. Для конечного пользователя это не "очередная ФС для диска", а инфраструктурный кирпич, который может быть полезен разработчикам и создателям специализированных решений.
- Инфраструктура fserror
Добавлена унифицированная инфраструктура для обработки ошибок файловых систем. Это шаг к тому, чтобы ошибки в разных ФС обрабатывались более предсказуемо и единообразно, что упростит диагностику и повысит надёжность.
- Новые средства мониторинга XFS
В XFS расширены возможности наблюдения и отладки. Это особенно важно для крупных систем хранения и серверов, где XFS активно используется. Админы получат больше информации о состоянии ФС и смогут быстрее выявлять проблемы.
- Улучшения Btrfs: ремапинг
Btrfs получила поддержку дополнительных операций ремапинга. Это усиливает её позицию как продвинутой ФС с богатым функционалом для снапшотов, дедупликации и гибкого управления данными.
- NFS 4.1 включён по умолчанию
В новой версии по умолчанию активирован NFS 4.1. Это более современная и функциональная версия протокола сетевых файловых систем по сравнению с устаревшими вариантами. Администраторам, использующим NFS, стоит убедиться, что инфраструктура и клиенты корректно работают с 4.1 либо явно задать нужные версии.
io_uring: фильтры для операций
Подсистема io_uring, отвечающая за высокопроизводительный асинхронный ввод‑вывод, получила поддержку фильтров для операций. Это позволяет:
- гибко ограничивать или модифицировать исполняемые запросы;
- реализовывать более продвинутые модели безопасности и контроля;
- создавать оптимизации на уровне конкретных типов операций.
Для разработчиков высоконагруженных приложений это даёт дополнительные инструменты тонкой настройки I/O без отказа от преимуществ io_uring.
Криптография: интеграция пост‑квантового алгоритма ML‑DSA
В криптоподсистеме ядра появился пост‑квантовый алгоритм ML‑DSA. Его интеграция не означает мгновенного отказа от классических схем, но:
- ядро готовится к будущему, в котором квантовые вычисления могут сделать традиционную криптографию уязвимой;
- разработчики систем безопасности и коммуникационных решений могут начинать экспериментировать с пост‑квантовыми схемами на уровне ядра.
Это долгосрочное вложение в устойчивость инфраструктур к возможным угрозам "завтрашнего дня".
Сетевая подсистема: AccECN и подготовка к Wi‑Fi 8
В сетевом стеке активирован AccECN - расширенный Explicit Congestion Notification, позволяющий эффективнее сигнализировать о перегрузке в сети и оптимизировать управление трафиком. Это важно для высокоскоростных и нагруженных сетей, где каждая миллисекунда задержки и каждый процент пропускной способности на счету.
Дополнительно появилась начальная поддержка Wi‑Fi 8. Пока это фундамент для будущих драйверов и устройств, а не готовое решение "из коробки", но в перспективе это ускорит появление устойчивой поддержки новых стандартов беспроводной связи в Linux.
Linux‑libre 7.0‑gnu: полностью свободный вариант ядра
Параллельно с официальным релизом подготовлен полностью свободный вариант ядра 7.0 - Linux‑libre 7.0‑gnu. Из него удалены прошивки и драйверы, содержащие несвободные компоненты или код с ограничениями, навязанными производителями.
В рамках этой чистки:
- удалены бинарные блобы из драйвера iwlwifi;
- обновлён и расширен код "очистки" в драйверах amdgpu, adreno, TI PRUeth, air_en8811h, ath12k, TI VPE, rtw8852b, rt1320, rt5575 SPI, tas2783, Intel catpt;
- обработаны dts‑файлы (devicetree) для ARM‑чипов: удалены или переименованы упоминания бинарных blob'ов.
Этот вариант интересен тем, кто принципиально избегает несвободных компонентов, даже ценой некоторой потери функциональности или поддержки части железа.
Поддержка старого "железа" и спор вокруг i486
На фоне выхода 7.0 продолжаются дискуссии о судьбе очень старых архитектур. Поддержка i486 в ядре до сих пор существует, хотя на практике реальных рабочих систем на таком железе крайне мало. Параллельно вычищаются устаревшие механизмы, вроде отдельных режимов энергосбережения для давно неактуальных конфигураций.
Смысл тенденции понятен:
- чем больше "мертвого" кода поддерживает ядро, тем сложнее его сопровождать;
- старые архитектуры ограничивают возможность внедрения новых оптимизаций;
- при этом абсолютно все сценарии эксплуатации предсказать невозможно, поэтому часть пользователей неизбежно оказывается недовольна.
Для владельцев действительно древних машин это означает необходимость либо оставаться на старых версиях ядра, либо переходить на специализированные сборки, либо пересматривать железо. В корпоративном сегменте подобные системы и так нередко изолированы и работают "до физической смерти".
HDD против SSD и вопрос производительности
Обсуждения вокруг ядра традиционно выливаются и в споры о железе - особенно о том, насколько критично наличие SSD. В практической плоскости:
- SSD дают максимальный эффект при загрузке системы, запуске приложений, работе с большим числом мелких файлов и при активном случайном I/O.
- При уже прогретом кэше и достаточном объёме оперативной памяти разница между SSD и HDD в рамках одной сессии работы может быть не столь заметной: данные читаются из RAM.
- HDD остаются востребованными там, где важен объём за меньшие деньги и относительно простые сценарии доступа (архивы, бэкапы, медиа‑хранилища).
- Стоимость и SSD, и HDD растёт, поэтому абсолютный выбор не всегда очевиден: всё зависит от профиля нагрузки и бюджета.
Ядро 7.0, с учётом улучшений подкачки и оптимизаций I/O, в целом чуть лучше чувствует себя как на SSD, так и на HDD, но "чуда" для очень старых и медленных дисков ждать не стоит. Если ОС давно переехала на SSD, ускорение системы в новых версиях ядра будет сочетаться с преимуществами накопителя.
Энергоэффективность и "выпиленные" механизмы экономии
Отдельный пласт претензий связан с тем, что некоторые старые режимы энергосбережения и подсистемы, вроде устаревших вариантов laptop_mode, постепенно исчезают. Причины:
- современные ноутбуки и десктопы используют куда более продвинутые механизмы управления питанием (ACPI, современные драйверы питания, гибридные графические схемы и т.д.);
- старые пути оптимизации зачастую несут больше технического долга, чем реальной пользы;
- в ПК примерно десятилетней давности выигрыш от некоторых вычищенных механизмов весьма сомнителен, а вот накладные расходы на их поддержку для разработчиков очень реальны.
Для пользователей, у которых ноутбуки и десктопы моложе 10-12 лет, исчезновение древних режимов, как правило, не несёт заметных последствий. В более старых системах может потребоваться тонкая настройка современных механизмов питания, либо смириться с чуть меньшей автономностью, если железо совсем архаично.
Стоит ли обновляться на Linux 7.0?
Ответ зависит от сценария:
- Серверы с PostgreSQL на ARM64
Необходимо тщательное тестирование. Из‑за включённого по умолчанию PREEMPT_LAZY возможны серьёзные просадки производительности. Нужно либо адаптировать конфигурацию (включая использование `PR_RSEQ_SLICE_EXTENSION`), либо временно придерживаться более старой ветки ядра.
- Современные серверы и рабочие станции
Вы получите улучшенную работу подкачки, обновлённые драйверы, более свежий сетевой стек, начальную почву под пост‑квантовую криптографию и Rust‑модули. При наличии хорошего тестового контура обновление выглядит вполне оправданным.
- Старое железо (уровень i486 и древние ноутбуки с HDD)
Ядро постепенно движется прочь от очень старых платформ. Обновление может ничего не "сломать", но и не принесёт чудес. В некоторых случаях стабильнее остаться на "консервативной" ветке ядра, особенно если система выполняет критичные задачи и нет ресурсов на глубокое тестирование.
- Сторонники полностью свободного ПО
Для вас подготовлен Linux‑libre 7.0‑gnu. Он позволит использовать свежие возможности ядра, насколько это возможно без несвободных компонентов.
***
Linux 7.0 - не "революция ради семёрки в номере", а крупный, но логичный шаг эволюции. Он продолжает наращивать возможности ядра в области производительности, безопасности, работы с современным железом и готовит платформу к технологическим сдвигам - от пост‑квантовой криптографии до новых стандартов беспроводной связи. При этом, как всегда, обновление требует взвешенного подхода: особенно там, где на кону производительность баз данных, специфическое старое железо или критичные производственные системы.
