Ключевые векторы изменений в Linux-стеке
В 2025-м сложилась картина, где разработка ядра и поддерживающие проекты ускорились не просто из-за технологического прогресса, а из-за реальных нагрузок — геймеры, облака, гиперскейлеры и встраиваемые платформы требуют разных, порой конфликтующих, компромиссов. Несколько заметных трендов задают тон:
- Rust в ядре: от эксперимента к практике — появление первой CVE по коду на Rust и решение "Rust оставаться" означают не возврат к прежнему статус-кво, а новую страницу в разработке ядра;
- Консолидация драйверов: перевод старых AMD GCN GPU на amdgpu по умолчанию, параллельно с уходом AMDVLK и ростом RADV;
- Влияние игрового стека: Valve и Proton продолжают влиять на аппаратные и программные решения — Steam Deck стал не только устройством, но и трендовым форсмакером;
- Wayland и десктоп: GNOME и KDE ужесточают правила (вплоть до запрета AI-сгенерированного кода для расширений) и готовят полное прощание с X11;
- Открытые драйверы vs проприетарные: Nouveau/NVK, Mesa, RADV показывают всё большую зрелость, но регрессии по RDNA3/RDNA4 напомнили о хрупкости.
Почему Rust в ядре — больше, чем модное слово
Появление Rust-кода в ядре — это не только про память и безопасность от классов багов, связанных с UAF/буферными переполнениями. Это и про инструменты разработки, строгую типизацию и иной психотип ревьювера. Первая CVE в коде на Rust — ожидаемая, а не катастрофическая новость: любая новая подсистема проходит через уязвимости на ранних стадиях. Важнее то, как организуется процесс ревью, CI и поддержка языковых зависимостей.
Плюсы: лучшее выражение намерений кода, возможность писать безопасные абстракции для новых подсистем (например, сложные парсеры форматов или сетевые стеки). Минусы: увеличение барьера входа для поддерживающих разработчиков, необходимость добавления rust-toolchain в цепочки сборки, новые угрозы supply-chain для cargo-контента.
Кто выигрывает от консолидации драйверов?
Перевод старых GCN 1.0/1.1 на amdgpu — это долгожданное упрощение. Одно драйверное дерево означает единый набор инструментов тестирования, исправлений и трассировки. Практический эффект — RADV и RadeonSI получают лучше интегрированные пайплайны, Vulkan включается "из коробки" и старые карты получают поддержку современных возможностей.
Однако это не волшебство: массовые тесты показали, что на новых RDNA3/4 появились регрессии после перехода на Linux 6.19. Причина обычно кроется в сочетании изменений в драйвере, kernel API и тестового охвата. Такие ситуации подчеркивают важность regressions testing и vendor collaboration — у open-source проекта нет магического рычага, чтобы мгновенно исправить скрытые аппаратные баги.
Драйверы: открытый код против проприетарного
Откат AMD от AMDVLK и уклон в сторону Mesa (RADV) — ближайшее время станет интересным для инженеров, тестировщиков и энтузиастов. RADV быстро догнал и во многих сценариях превзошёл проприетарный стек, особенно в трассировке лучей. Для разработчиков это значит меньше закрытых blackbox-сценариев и больше контроля, но и большую ответственность: общество требует стабильности, а пользователи — производительности.
NVIDIA продолжает политику постепенного перевода старого HW в legacy-ветки драйверов, что вынуждает сообщество тестировать Nouveau/NVK против последних релизов. Это стратегия с очевидными рисками: поддержка старого HW может быть отложена, и для компаний с большим парком устаревших карт это удар по TCO.
Игровая экосистема — драйвер и middleware
Proton, Steam Play, VKD3D-Proton, D7VK (Direct3D 7 на Vulkan) — все эти проекты демонстрируют, что переход игрового стека на Linux идёт не по модулю, а по всей вертикали. Результат: лучший опыт на Linux для игр, больше интереса к ARM- и RISC-V-платформам, и коммерческие игроки начинают смотреть на Linux как на жизнеспособную платформу.
Пример: Valve scheduler, изначально оптимизированный под Steam Deck, оказался полезен и для серверных нагрузок и оказался адаптируемым для Meta. Это хороший случай технологии, которая выросла из натурных испытаний и перекочевала в гиперскейл.
Wayland, десктоп и сообщество
Wayland выходит на финишную прямую: KDE планирует стать Wayland-only к 2027, GNOME улучшает поддержку, а приложения постепенно мигрируют. Ограничение приёма AI-сгенерированного кода для GNOME-расширений — симптом зрелости: контроль качества становится важнее скорости поступления патчей.
Практические последствия для администраторов: планирование перехода, проверка совместимости Conky/tiling managers/remote desktop решений и тестирование приложений, которые раньше полагались на FBDEV/X11-консоли.
Виртуализация, облака и GPU-акселерация
Смешанные рабочие нагрузки — виртуальные машины для legacy-стеков и контейнеры для современных приложений — остаются нормой. Для тех, кто строит приватные облака или лаборатории, появляются интересные варианты: Proxmox и Proxmox-based сборки становятся платформой выбора для лёгкой интеграции KVM, LXC и passthrough GPU. Для прикладного примера есть подписная сборка — НАЙС.ОС Виртуализация на базе Proxmox (https://niceos.ru/v), которая упрощает развёртывание виртуальной инфраструктуры с поддержкой контейнеров и GPU-пропуска.
Проблемы остаются: GPU-пассстру (VFIO), миграция live VMs с ускорением и поддержка Vulkan/OpenCL внутри контейнеров всё ещё требуют аккуратной настройки. При этом растёт спрос на CI для графических драйверов и систем тестирования, которые умеют прогонять реальный игровой и compute-воркфлоу при каждом апстриме ядра.
Безопасность и governence: LSM, ревью и социальный контракт
Отсроченные предложения по LSM, обращения к Linus и TAB, вопросы терминологии в кодовой базе — всё это напоминает, что код ядра — это не только техническая арена, но и социотехническая система. Вопросы приёма новых LSM показывают, что нужен прозрачный путь для инноваций, иначе полезные проекты могут застрять в бюрократии.
Растущая доля кода на Rust также требует переосмысления процессов ревью: кто проверяет пэч, какие требования к зависимостям, как обновлять toolchain без разрушения CI? Это организационная нагрузка, которую придётся решать в ближайшие годы.
Практические рекомендации для инженера и архитектора
- Внедрять тесты производительности и регрессии при каждом обновлении ядра/драйверов.
- Выстраивать CI с прогоном графических и AI-воркфлоу (если используются GPUs).
- Планировать миграцию на Wayland заранее, тестируя реальные сценарии пользователей и RDP/VDI-инструменты.
- Оценивать риски от зависимости проприетарных драйверов и иметь план fallback (open-source драйверы или облачные экземляры).
- Следить за supply-chain Rust/Cargo и внедрять политику pin-версий и сканирования ЦСС/OSS-библиотек.
К чему готовиться в ближайшие 3 года
- Больше Rust-кода в ядре и подсистемах, особенно в тех, где нужны безопасные абстракции.
- Продолжение консолидации драйверов, но с периодическими регрессиями — тестирование важнее маркетинга.
- Wayland как де-факто стандарт для рабочих станций и ноутбуков к 2027.
- Игровая экосистема Linux будет развиваться дальше: Proton, VKD3D, D7VK и аппаратная поддержка вендоров.
- Усиление требований к CI и тестированию со стороны предприятий и разработчиков драйверов.
Заключение
2025-й продемонстрировал: Linux — это не статичный продукт, это живой организм, который адаптируется под реальные нагрузки и задачи. Технологические решения, родившиеся в геймерской среде, успешно переходят в дата-центры; новые языки дают много преимуществ, но меняют процессы; а драйверная экосистема — игра на опережение, где ставка делается на качество тестирования.
Интересно обсудить:
- Какие практики CI/QA вы считаете критичными при апдейте ядра и драйверов в продакшене?
- Готовы ли ваши рабочие станции и серверы к повсеместному внедрению Wayland и Rust-кода в ядре?
- Какой сценарий для вас важнее — поддержка legacy GPU или быстрая интеграция новых возможностей RADV/Vulkan?
Комментарии