Компания Google сообщила, что с учётом пожеланий сообщества реализовала новый процесс установки сторонних неверифицированных приложений в Android, который будет действовать после внедрения обязательной регистрации разработчиков и приложений в сертифицированных сборках Android. Метод вводит 24-часовой период ожидания после включения опции для разработчиков, допускающей установку приложений из вручную загруженных apk-пакетов, созданных разработчиками, не зарегистрировавшими пакеты в Google и не подтвердившими свои персональные данные.
Алгоритм установки вручную загруженных пакетов сведётся к следующим действиям:
Включение в настройках режима для разработчика - необходимо коснуться 7 раз области с номером сборки на странице About Phone, после чего в настройках появится секция с опциями для разработчиков, в которой нужно выбрать "Allow Unverified Packages". Данный шаг позволит исключить случайную установку и усложнит практикуемые мошенниками методы быстрой установки отправленных пользователю вредоносных пакетов.
Подтверждение, что пользователь осознаёт риски и действует по своей инициативе, а не следует советам и уговорам посторонних.
Перезагрузка смартфона и введение своего кода разблокировки экрана. Данный шаг помешает удалённо управлять процессом установки и не позволит неразрывно контролировать действия пользователя по телефону.
Возможность установки вручную загруженного пакета будет активирована через 24 часа, что даст пользователю время на осознание ситуации, если он находится по влиянием мошенников. Через 24 часа пользователь должен повторно зайти в настройки и подтвердить, что он сознательно активировал режим для установки сторонний пакетов, используя PIN-код или биометрическую аутентификацию.
После подтверждения на выбор предлагается две опции: бессрочная возможность установки приложений от неподтверждённых разработчиков или разрешение, действующее только 7 дней (после истечения 7 дней процесс подтверждения потребуется повторить).
При каждой установке неверифицированного приложения пользователю будет показано предупреждение об имеющихся рисках, с которым нужно согласится, нажав кнопку "Install Anyway".
Помимо нового метода сохранится и ранее доступная возможность установки приложений при помощи утилиты "adb" (Android Debug Bridge), требующая подключения устройства к внешнему компьютеру и включения режима разработчика. Также будет предоставлена возможность регистрации бесплатного типа учётных записей для энтузиастов и студентов, работающая без подтверждения личности, но требующая регистрации в Android Developer Console каждого устройства, на которое приложение может быть установлено, и ограниченная 20 устройствами.
Напомним, что Google переходит к использованию на сертифицированных Android-устройствах зарегистрированных приложений от верифицированных разработчиков. Для верификации разработчик должен платно (25 долларов) зарегистрироваться в сервисе Android Developer Console, если он до этого не зарегистрирован в Google Play, и предоставить такие данные, как ФИО, адрес проживания, email, телефонный номер и фото документа, удостоверяющего личность. Для организаций потребуется подтверждение сайта и предоставление международного идентификатора юридических лиц (DUNS). После регистрации разработчик должен добавить свои приложения и подтвердить, что он является их автором, предоставив полные имена пакетов и ключи для цифровых подписей. Верификация станет обязательной в Бразилии, Индонезии, Сингапуре и Таиланде в сентябре 2026 года и будет распространена на остальные страны в 2027 году.
Роман Гущин (Roman Gushchin) из команды разработчиков ядра Linux, работающий в Google, объявил о создании новой системы проверки кода с использованием больших языковых моделей. Разработка велась последние несколько месяцев и получила название Sashiko, в честь традиционного японского плетения, состоящее из небольших прямых стежков, образующих разные узоры.
Sashiko уже некоторое время используется в компании Google для выявления проблем, а теперь стал доступен для всех и запущен для автоматического рецензирования всех патчей, отправляемых в список рассылки разработчиков ядра Linux.
Код Sashiko написан на языке Rust и открыт под лицензией Apache 2.0. Система самодостаточна и может использоваться на собственном оборудовании.
Sashiko был разработан для работы с моделью Google Gemini Pro 3.1, но частично протестирован с Claude и, вероятно, будет работать с другими современными большими языковыми моделями. Использованные для рецензнирования промпты основаны на наборе review-prompts, подготовленном Крисом Мейсоном (Chris Mason), создателем файловой системы Btrfs. Бюджет токенов и инфраструктуру Sashiko финансирует Google. Права на проект переданы организации Linux Foundation.
Судя по проведённым тестам, при использовании модели Gemini 3.1 Pro инструментарий Sashiko смог обнаружить 53.6% ошибок из неотфильтрованного набора, включающего 1000 недавних проблем в ядре, отмеченных тегами "Fixes:". На первый взгляд 53.6% выглядит не слишком впечатляющим, но следует иметь в виду, что все из выявленных проблем вначале не были замечены при рецензировании людьми и оказались включены в основную ветку ядра. Уровень ложных срабатываний, оценённый на основе выборочной ручной проверки, составил не более 20%.
Рецензирование разделено на 9 стадий, в ходе которых выявляются архитектурные проблемы, нарушения UAPI, расхождения с заявленной функциональностью, некорректное использование API, наличие недокументированных функций, логические ошибки, отсутствия проверки возвращаемых значений и кодов ошибок, утечки памяти, обращения к памяти после освобождения, двойное освобождение памяти, некорректная работа с очередями и таймерами, возникновение взаимных блокировок, ошибки при работе с потоками, переполнения буферов, утечки информации из неинициализированной памяти, а также специфичные для драйверов проблемы, связанные с использованием регистров, маппингом DMA и доступом к памяти.
После восьми месяцев разработки представлен стабильный релиз протокола, механизма межпроцессного взаимодействия и библиотек Wayland 1.25. Ветка 1.25 обратно совместима на уровне API и ABI с выпусками 1.x и содержит в основном исправления ошибок и незначительные обновления протокола. Наработки проекта распространяются под лицензией MIT. Эталонный композитный сервер Weston, предоставляющий код и рабочие примеры для использования Wayland в десктоп-окружениях и встраиваемых решениях, развивается в рамках отдельного цикла разработки.
Добавлен новый атрибут "frozen" для интерфейсов с несколькими родительскими интерфейсами.
Добавлен новый запрос wl_surface.get_release для получения уведомления о высвобождении буфера, прикреплённого клиентом через wl_surface.attach. В отличие от wl_buffer.release в wl_surface.get_release уведомление привязано к конкретному моменту отрисовки.
Добавлена функция wl_display_dispatch_pending_single(), позволяющая достать из очереди событий и обработать только одно событие, а не все накопившиеся события, как это делает wl_display_dispatch_pending().
Добавленные c момента выпуска Wayland 1.25 расширения протоколов, дополняющих базовый протокол Wayland и поставляемых в отдельном наборе Wayland-Protocols:
xx-input-method - позволяет приложениям реализовывать методы ввода текста для композитных серверов и формировать введённый текст, что может применяться, например, для создания виртуальных клавиатур и IME-прослоек (Input Method Editor) для обработки ввода.
xx-text-input - позволяет композитным серверам реализовывать методы ввода и отправлять текст в приложения. Протокол стандартизирует взаимодействие между композитным сервером и приложениями, и позволяет управлять такими возможностями, как передача вводимого текста, обработка событий об изменении фокуса ввода и учёт специфики полей ввода (язык, выделение текста, тип контента).
Доработаны протоколы color-management-v1 и color-representation-v1, предоставляющие возможности для управления цветом, поддержки HDR и
определения цветового представления Wayland-поверхности.
Наиболее заметные события, связанные с Wayland и произошедшие с момента публикации прошлого выпуска:
В GNOME 50 удалена поддержка X11. В KDE Plasma 6.8 решено прекратить поддержку X11.
JetBrains переводит IDE IntelliJ на использование Wayland по умолчанию.
Выпуск Wayback, прослойки для запуска рабочих столов X11, используя компоненты Wayland.
В Cinnamon добавлена опциональная возможность установки сессионных файлов для Wayland и реализована возможность переключения раскладки клавиатуры при использовании Wayland.
В драйвере wine при работе в окружениях на базе Wayland реализована поддержка буфера обмена, методов ввода, непрямоугольных окон и прозрачности.
Напомним, что Wayland представляет собой протокол взаимодействия композитного сервера и работающих с ним приложений. Клиенты самостоятельно выполняют отрисовку своих окон в отдельном буфере, передавая информацию об обновлениях композитному серверу, который комбинирует содержимое буферов отдельных приложений для формирования итогового вывода с учётом возможных нюансов, таких как перекрытие окон и прозрачность. Иными словами, композитный сервер не предоставляет API для отрисовки отдельных элементов, а оперирует только с уже сформированными окнами, что позволяет избавиться от двойной буферизации при использовании высокоуровневых библиотек, таких как GTK и Qt, берущих на себя работу по компоновке содержимого окон.
Wayland решает многие проблемы с безопасностью X11, так как в отличие от последнего изолирует ввод и вывод для каждого окна, не позволяет клиенту получить доступ к содержимому окон других клиентов, а также не допускает перехват связанных с другими окнами событий ввода. Поддержка прямой работы c Wayland реализована для большинства применяемых в Linux графических библиотек, включая GTK, Qt, SDL, FLTK, wxWidgets, Clutter и EFL (Enlightenment Foundation Library).
Взаимодействие с аппаратным обеспечением в Wayland/Weston, например, проведение инициализации, переключение видеорежимов (drm modesetting) и управление памятью (GEM для i915 и TTM для radeon и nouveau) графических карт, может производиться напрямую через модуль, работающий на уровне ядра, что позволяет обойтись без привилегий суперпользователя. Для обеспечения выполнения обычных X11-приложений в окружении на базе Wayland используется DDX-компонент XWayland (Device-Dependent X), похожий по организации работы на Xwin и Xquartz для платформ Win32 и macOS.
После трёх месяцев разработки доступен релиз системного менеджера systemd 260. Ключевые изменения: прекращение поддержки скриптов сервисов в формате System V, механизм "mstack" для компоновки многослойных иерархий монтирования, утилита systemd-report, поддержка интеграции systemd-networkd с ModemManager, поддержка пользовательских переносимых сервисов, концепция "xaccess" в systemd-logind и systemd-udevd.
Прекращена поддержка скриптов сервисов в формате System V и прекращена поставка компонентов rc-local.service, systemd-sysv-install, systemd-rc-local-generator и systemd-sysv-generator.
Реализован механизм "mstack" (Mount Stack), позволяющий использовать каталоги с суффиксом ".mstack/" для формирования составной иерархии каталогов, образуемой через последовательное монтирование и наложение дисковых образов и частей ФС при помощи OverlayFS и "mount --bind". Добавлены команда systemd-mstack, опция "--mstack" в systemd-nspawn и параметр RootMStack в unit-ы, которые могут использоваться для монтирования и отмонтирования разом всех элементов, определённых в конфигурации ".mstack", например, для быстрого воссоздания образа контейнера или рабочего окружения сервиса. Каждый файл или подкаталог в ".mstack/" определяет один уровень монтирования или слой "overlayfs".
Например, следующая конфигурация "foobar.mstack/" определяет overlayfs с двумя слоями в режиме только для чтения из дисковых образов base.raw и app.raw (указаны как символические ссылки), и каталогом "rw" с возможностью записи поверх них:
Реализованы фреймворки "metrics" и "report", которые могут использоваться системными компонентами для вывода статистики через Varlink в каталоге /run/systemd/report/. Добавлена утилита systemd-report, формирующая сводный отчёт, объединяющий статистику от всех компонентов, и выводящая его в формате JSON. В настоящее время метрики предоставляют только сервисный менеджер и systemd-networkd.
В systemd-networkd обеспечена интеграция с ModemManager и добавлена секция "[MobileNetwork]" с настройками APN, AllowedAuthenticationMechanisms, User, Password, IPFamily, AllowRoaming, PIN, OperatorId, RouteMetric и UseGateway, позволяющими использовать systemd-networkd для подключения через модем к сотовым операторам.
Предоставлена возможность запуска systemd-portabled как пользовательского сервиса, запускаемого непривилегированным пользователем. Для выбора типа сервиса в утилиту portablectl добавлены флаги "--user" и "--system". Переносимые сервисы ("Portable Services") представляют собой системные сервисы, оформленные в виде самодостаточных контейнеров (поставляется в виде системного образа, но обрабатывается как обычный сервис).
В systemd-logind и systemd-udevd добавлена поддержка концепции "xaccess" (Extended Access), позволяющей в графическом сеансе предоставить доступ к GPU для пользователей с удалённым доступом, которые физически не пользуются монитором и устройствами ввода на локальной системе (по аналогии с доступом uaccess, охватывающим физически работающих с компьютером пользователей). Для настройки сеансов в этом случае предлагается через PAM выставлять переменную окружения XDG_SESSION_EXTRA_DEVICE_ACCESS.
Для автоматизации настройки DeviceTree в UKI-образах (Unified Kernel Image) предложен канонический набор файлов c идентификаторами оборудования /usr/lib/systemd/boot/hwids/, связывающими идентификаторы устройств с элементами DeviceTree. При помощи данного набора UKI-образ автоматически находит и загружает необходимый DTB (Device Tree Blob) во время загрузки без необходимости создания образов, специфичных для каждого устройства. В настоящее hwid-файлы сформированы для ARM64-устройств на базе чипов Snapdragon.
В /etc/os-release добавлено новое поле "FANCY_NAME", отличающиеся от "PRETTY_NAME" возможностью использования не-ASCII глифов Unicode. При наличии поля "FANCY_NAME" оно будет использоваться в выводе systemd, systemd-hostnamed и hostnamectl вместо "PRETTY_NAME".
Сервисы, предоставляющие публичные интерфейсы Varlink, при помощи символических ссылок сведены в одном каталоге /run/varlink/registry/. Для просмотра списка подобных сервисов реализована команда 'varlinkctl list-registry'.
В unit-ах реализована возможность указания в параметре PrivateUsers значения "managed" для автоматического назначения unit-у диапазонов идентификаторов пользователей и групп (UID/GID) через systemd-nsresourced.
В unit-ы добавлена настройка RefreshOnReload для обновления расширений и учётных данных при перезапуске unit-а.
В unit-ы добавлена настройка BindNetworkInterface для автоматической привязки всех создаваемых в unit-е сокетов к указанному сетевому интерфейсу.
В unit-ы добавлены настройки ConditionPathIsSocket и AssertPathIsSocket для изменения поведения или аварийного завершения unit-а, если указанные пути не являются сокетами.
В systemctl добавлена команда 'enqueue-marked', вызывающая метод D-Bus EnqueueMarkedJobs(). Ранее применяемый для этих целей параметр '--marked' объявлен устаревшим.
В сервисы добавлена настройка MemoryTHP для управления использованием в сервисах больших страниц памяти (THP - Transparent Huge Pages).
В .delegate-файлы systemd-resolved добавлена поддержка параметра FirewallMark для выставления в сетевом стеке метки межсетевого экрана
("firewall mark") для генерируемого DNS-трафика.
В systemd-sysupdate добавлена команда 'acquire' для разделения этапов загрузки и установки или обновления. Реализована поддержка пометки разделов как частично загруженных.
В systemd-vmspawn добавлена опция "--image-format" для выбора формата (qcow2 или raw) дискового образа.
В systemd-inhibit для опции "--list" реализована поддержка формата "JSON" c возможностью использования флагов "--what", "--who", "--why" и "--mode" для фильтрации вывода.
В systemd-repart добавлена базовая поддержка контроля целостности шифрованных разделов, используя dm-integrity.
В утилиту systemd-keyutil добавлена команда 'extract-certificate' для вывода содержимого сертификатов X.509.
В systemd-sysext и varlinkctl реализована поддержка интерактивного прохождения авторизации при помощи polkit.
В systemd-importd добавлена возможность загружать OCI-образы командой "importctl pull-oci", которые сохраняются в форме образов для монтирования через "mstack".
Добавлена поддержка цветов SYSTEMD_COLORS=auto-16, SYSTEMD_COLORS=auto-256, и
SYSTEMD_COLORS=auto-24bit.
В systemd-oomd добавлен "prekill hook", позволяющий подключать обработчики, срабатывающие перед принудительным завершением процесса из-за нехватки памяти в системе.
Возобновлена, но помечена устаревшей, возможность использование несистемных пользователей и групп в правилах udev (OWNER=/GROUP=) и настройках systemd-networkd (User=/Group=).
В systemd-repart задействована появившаяся в xfsprogs 6.17.0 функциональность утилиты mkfs.xfs для развёртывания начального содержимого ФС из указанной директории.
Повышены требования к минимальным версиям: ядро Linux 5.4 → 5.10 (рекомендовано 5.14, а для полной функциональности - 6.6), libidn → libidn2, Python 3.7.0 → 3.9.0, glibc 2.31 → 2.34, OpenSSL 1.1.0 → 3.0.0, cryptsetup 2.0.1/2.3.0 → 2.4.0, elfutils 158 → 177, libblkid 2.24 → 2.37, libseccomp 2.3.1 → 2.4.0.
Переработаны и упрощены правила обеспечения переносимости и стабильности, в которых усилены обязательства по недопущению видимых пользователям регрессий в публичных интерфейсах.
Дополнение: В кодову базу systemd, на основе которой будет сформирован следующий релиз, принято изменение, добавляющее в userdb поле birthDate с датой рождения пользователя. В качестве причины добавления отмечается подготовка к реализации требований законов об интеграции в ОС API для проверки возраста.
После 6 месяцев разработки представлен релиз Samba 4.24.0, продолживший развитие ветки Samba 4 с полноценной реализацией контроллера домена и сервиса Active Directory, совместимого с реализацией Windows Server и способного обслуживать все поддерживаемые Microsoft версии Windows-клиентов, в том числе Windows 11. Samba 4 является многофункциональным серверным продуктом, предоставляющим также реализацию файлового сервера, сервиса печати и сервера идентификации (winbind). Код проекта написан на языке Си и распространяется под лицензией GPLv3.
Добавлен новый VFS-модуль vfs_aio_ratelimit для ограничения интенсивности (rate-limit) операций асинхронного ввода/вывода (AIO). Ограничения могут задаваться в байтах в секунду или в операциях в секунду. При превышении заданного лимита модуль начинает подставлять искусственные задержки в асинхронные операции для поддержания заданного верхнего порога.
В VFS-модуль vfs_ceph_new добавлена поддержка RPC-протокола Keybridge и режима FSCrypt для шифрования данных и имён файлов в файловой системе CephFS. Возможно включение шифрования на уровне отдельных каталогов.
В VFS-модуль vfs_streams_xattr, позволяющий сохранять альтернативные наборы данных NTFS (NTFS alternate data stream) в расширенных атрибутах файлов (xattr) в Linux, добавлена настройка "streams_xattr:max xattrs per stream", определяющая допустимое число xattr, применяемых для хранения данных. В Linux размер xattr ограничен 65536 байтами, но ФС XFS даёт возможность привязывать к одному файлу более одного xattr, что позволяет использовать несколько xattr для хранения до 1 МБ альтернативных данных.
Реализована поддержка аудита информации, связанной с аутентификацией. Добавлены отладочные классы "dsdb_password_audit" и "dsdb_password_json_audit" для отражения в логе изменений атрибутов Active Directory: altSecurityIdentities, dNSHostName, msDS-AdditionalDnsHostName, msDS-KeyCredentialLink и servicePrincipalName.
Добавлена поддержка внешних систем управления паролями Microsoft Entra ID и Keycloak, использующих при изменении пароля операцию сброса пароля (SSPR, password reset) без передачи старого пароля в контроллер домена. Для соблюдения политик, контролирующих время действия паролей, при сбросе пароля передаются дополнительные параметры ("password policy hints"), позволяющие обрабатывать операцию как обычную смену пароля. Теперь Samba учитывает подобные параметры при применении связанных с паролями, локальных политик.
Добавлена поддержка механизма аутентификации Kerberos PKINIT KeyTrust, дающего возможность в контроллерах домена на базе Samba и Heimdal KDC, использовать метод "Windows Hello for Business Key-Trust logons" для применения механизма аутентификации PKINIT с самоподписанными ключами. Для добавления и просмотра открытого ключа в утилиту samba-tool добавлена команда "user|computer keytrust". Сведения об открытом ключе сохраняются в учётной записи при помощи атрибута msDS-KeyCredentialLink.
В контроллеры домена на базе Samba и Heimdal KDC добавлена поддержка расширения протокола Kerberos PKINIT для маппинга ключей ("Windows Strong and Flexible key mappings"), применяемого при аутентификации по открытым ключам. По умолчанию допускается только точное сопоставление сертификатов ("strong certificate binding enforcement = full"), но возможно и гибкое сопоставление ("strong certificate binding enforcement = compatibility"), допускающее сертификаты новее учётной записи пользователя. Данные о маппинге сертификатов для учётной записи сохраняются в атрибуте altSecurityIdentities
Добавлена поддержка расширения протокола "Kerberos PKINIT SID", позволяющего использовать при аутентификации сертификаты с идентификатором Object SID. Для подписи сертификатов в утилиту samba-tool добавлена команда "user|computer generate-csr".
В реализации KDC (Key Distribution Center) по умолчанию обеспечено возвращение
структуры PAC (Privilege Attribute Certificate), содержащей данные о полномочиях пользователя, независимо от того, указано ли поле PA-PAC-REQUEST в запросе клиента. Для возвращения старого поведения предусмотрена настройка "kdc always generate pac = no".
В KDC добавлена настройка "kdc require canonicalization", при выставлении которой в значение "yes" клиент обязан запрашивать выполнение канонизации имени пользователя при обращении к серверу аутентификации (AS_REQ). Если канонизация не запрошена, сервер вернёт ошибку "пользователь неизвестен". В сетях с пользователями, использующими ОС Windows, активация новой настройки не должно вызвать проблем, так как Windows-клиенты по умолчанию всегда запрашивают канонизацию.
Обязательная канонизация позволяет защититься от атак класса "dollar ticket", манипулирующих тем, что имена пользователей могут задаваться по разному ("user" и "user$") и по разному обрабатываться в канонизированном и обычном представлении. Суть атаки в том, что злоумышленник, например, мог создать в AD учётную запись компьютера с именем "root$" и использовать её для получения у KDC мандата (ticket), отравив в запросе имя пользователя "root" вместо "root$". KDC не найдя пользователя "root", обработал бы запрос в контексте пользователя "root$" и выдал мандат, который можно использовать для подключения под пользователем root через SSH или NFS к Linux-серверу с SSSD.
В KDC добавлен обходной вариант защиты от атак "dollar ticket" для конфигураций с отключёнными обязательными запросами канонизации имён ("kdc require canonicalization = no", применяется по умолчанию). По умолчанию, если клиент не запросил выполнение канонизации и проверяемое имя не найдено, сервер выполняет дополнительную проверку, прикрепив символ "$" к имени. При помощи новой настройки "kdc name match implicit dollar without canonicalization = no" можно отключит данное поведение и выполнять только точные проверки (в контексте вышеупомянутой атаки, сервер не станет проверять имя "root$" при запросе "root").
В Heimdal KDC по умолчанию включена отправка сервисам Kerberos только канонизированных имён (sAMAccountName из PAC) вместо исходного значения cname.
Для возвращения старого поведения предусмотрена настройка "krb5 acceptor report canonical client name = no".
Для полноценной защиты от атак "dollar ticket" рекомендуется выставить настройки:
strong certificate binding enforcement full
kdc always include pac yes
kdc require canonicalization yes
Для блокирования уязвимости CVE-2026-20833 метод шифрования домена в настройках KDC по умолчанию изменён на AES (настройка "kdc default domain supported enctypes" выставлена в "aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96").
После шести месяцев разработки опубликован выпуск среды рабочего стола GNOME 50. Для быстрой оценки возможностей GNOME 50 предложены специализированные Live-сборки на основе openSUSE и установочной образ, подготовленный в рамках инициативы GNOME OS. GNOME 50 также уже включён в состав экспериментальных сборок Ubuntu 26.04 и Fedora 44.
Из пользовательской оболочки GNOME Shell и композитного сервера Mutterудалёнкод для поддержки протокола X11. В дисплейном менеджере GDM
удалена поддержка X11 и прекращена возможность сборки GDM без Wayland, но сохранена поддержка запуска других сред рабочего стола, использующих X11. В gnome-session прекращена поддержка выполнения сеансов на базе X11, а из gnome-settings-daemon удалена опция "-Dx11" и возможность настройки параметров X11.
Отныне в GNOME возможно использование только сеанса на базе Wayland, а поддержка работы под управлением X-сервера полностью прекращена. Возможность запуска X11-приложений при помощи XWayland сохраняется. В дистрибутивах поддержка сеанса GNOME на базе X11 ранее была прекращена в Ubuntu 25.10, Fedora 43 и RHEL 10. В библиотеке GTK бэкенд для протокола X11 объявлен устаревшим и в GTK5 планируют оставить только поддержку Wayland. Сеанс на базе протокола Wayland применяется в GNOME по умолчанию с 2016 года.
Реализована новая система сохранения сеансов, основанная на использовании systemd, и добавлен объект GsmSessionSave, обеспечивающий сохранение состояния отдельных приложений. Помимо сохранения позиций окон после восстановления, приложениям GNOME предоставлена возможность восстановления состояния, например, GNOME Calculator может восстановить выбранный режим вычислений. В конфигуратор добавлен переключатель, позволяющий отключить режим сохранения списка запущенных приложений во время завершения сеанса и восстановления их окон в последующем сеансе.
На экране входа реализована группировка списка сеансов в привязке к имени дисплея. Некоторые собственные компоненты для запуска экрана входа в систему заменены на штатные возможности systemd, что усилило зависимость GNOME от данного системного менеджера и требует создания новых прослоек для поставки GNOME в дистрибутивах и операционных системах, не использующих systemd. В GDM задействована инфраструктура systemd-userdb, предоставляемая systemd. Удалён встроенный менеджер сервисов, который функционировал на уровне запуска desktop-файлов.
Переработан интерфейс родительского контроля. Добавлены новые возможности для отслеживания времени работы с экраном, фильтрации web-контента и задания времени для перехода ко сну. Например, родители теперь могут ограничить суточное время работы за компьютером и назначить вечернее время, после которого экран будет заблокирован и ребёнок не сможет разблокировать его. При этом доступна опция, позволяющая ребёнку запросить у родителя дополнительное время в случае истечения назначенного ему лимита. Добавлена возможность вызова интерфейса родительского контроля из конфигуратора. Реализован сервис для фильтрации web-контента при работе через детские учётные записи (интерфейс для настройки фильтров появится в следующем выпуске).
Мастер начальной настройки (gnome-initial-setup) переведён на использование по умолчанию run0 для запуска привилегированных действий вместо pkexec.
В файловом менеджере Nautilus переработан механизм переименования групп файлов, при поиске разрешено использование нескольких фильтров типов файлов, в контекстное меню корзины добавлена ссылка на настройки, реализован независимый всплывающий диалог со свойствами файла, в строке ввода файлового пути реализовано автодополнение ввода без учёта регистра символов.
В Nautilus также сокращено потребление памяти; ускорена загрузка пиктограмм и миниатюр; увеличено покрытие тестами; расширено использование языка Blueprint для формирования интерфейса; задействована библиотека Glycin для sandbox-изоляции декодирования изображений.
В просмотрщике документов реализована полноценная возможность прикрепления аннотаций к отрывкам текста в документе. Аннотации теперь можно добавить одним кликом в основном окне. Появилась возможность рисования линий и выделения блоков цветом поверх содержимого.
В календаре-планировщике реализован новый список участников, через который можно получить информацию о приглашённых на мероприятие и оценить обязательность их присутствия. В будущем планируется реализовать полноценную систему управления отправкой приглашений. Изменено оформление диалога для быстрого добавления новых событий. Добавлена поддержка экспорта в формате ICS. Улучшен интерфейс просмотра событий за месяц. Добавлена поддержка навигации по событиям, используя клавиши управления курсором.
Конфигуратор переведён на использование языка построения интерфейсов Blueprint. Удалён бэкенд настройки для X11.
В настройки даты и времени добавлена возможность выбора первого дня недели, влияющая на формирование списка дней недели в календаре-планировщике и почтовом клиенте Evolution. Интерфейс настройки модема переведён на виджеты libadwaita и унифицирован с остальными настройками. На странице управления цветом решены проблемы с калибровкой экрана. На странице настройки звука более явно разделены уровни громкости для звуковых входов и выходов.
В системе удалённой работы с рабочим столом значительно повышена производительность и задействовано аппаратное ускорение вывода видео при помощи API Vulkan и VA-API. Интегрирована поддержка механизма "explicit sync", позволяющего снизить задержки и избавиться от появления артефактов на системах с драйверами NVIDIA. Добавлена поддержка HiDPI с возможностью автоматически масштабировать
вывод для соответствия разрешению используемого экрана. Реализована возможность использования локальной web-камеры в сеансе с удалённой системой. Добавлена поддержка аутентификации через Kerberos.
В настройки для людей с ограниченными возможностями добавлена опция "Reduced Motion" для минимизации использования анимации в интерфейсе. Модернизирован экранный ридер Orca, в котором предложен новый интерфейс настойки, расширен режим навигации и обеспечено автоматическое переключение языка.
В дисплейный менеджер GDM добавлен сервис "gnome-headless-session@.service" для упрощения запуска сеансов без экрана (например, при удалённом доступе к рабочему столу через RDP).
Улучшена поддержка выставления нецелых уровней масштабирования и применения механизма VRR (Variable Refresh Rate), адаптивно меняющего частоту обновления монитора для плавности и отсутствия разрывов во время игр и показа видео. При включении VRR обеспечена обработка курсора, независящая от частоты кадров приложения, что позволило добиться плавного движения курсора при максимальной частоте обновления монитора (например, 144 Гц), даже если игра или приложение отображает информацию с более низкой частотой кадров.
Обходным путём решены проблемы на системах с драйверами NVIDIA, приводившие к рывкам и нарушениям синхронизации кадров. Повышена плавность анимации окон и улучшена общая отзывчивость интерфейса на системах с видеокартами NVIDIA.
Реализована поддержка Wayland-протокола color-management-v2, предоставляющего средства для управления цветом.
Реализована поддержка предоставления совместного доступа к экрану с сохранением метаданных HDR для исключения потери насыщенности цветов при трансляции или записи HDR-контента.
Библиотека GTK обновлена до ветки 4.22, в которой реализован встроенный движок отрисовки SVG.
Библиотека Libadwaita, включающая набор компонентов для стилевого оформления интерфейса пользователя, обновлена до версии 1.9, в которой
преложены новые виджеты с реализацией боковой панели: AdwSidebar с поддержкой секций, всплывающих подсказок и контекстных меню; AdwViewSwitcherSidebar для создания адаптивных панелей, способных управлять AdwViewStack.
Компания Qualys выявила уязвимость (CVE-2026-3888) в организации работы связки snap-confine и systemd-tmpfiles в Ubuntu, позволяющую непривилегированному пользователю получить root-доступ к системе. Проблема проявляется в Ubuntu в конфигурации по умолчанию начиная с выпуска 24.04. В Ubuntu 16.04-22.04 уязвимость может быть эксплуатирована в нестандартных конфигурациях, имитирующих поведение более новых версий дистрибутива. В Ubuntu исправление доступно во вчерашнем обновлении пакета snapd. В snapd проблема устранена в обновлении 2.75.
Уязвимость возникает из-за некорректного взаимодействия утилит snap-confine и systemd-tmpfiles, выполняемых с повышенными привилегиями. Утилита snap-confine формирует sandbox-окружение для выполнения snap-приложения, а systemd-tmpfiles осуществляет автоматическую очистку временных файлов и каталогов. По умолчанию утилита systemd-tmpfiles настроена на удаление всех старых файлов и каталогов в /tmp, что может использоваться атакующим для подмены каталога /tmp/.snap в момент после его удаления утилитой systemd-tmpfiles, но до пересоздания командой snap-confine.
Атака сводится к ожиданию запуска процесса очистки временных файлов, подмены каталога /tmp/.snap после его удаления и размещения модифицированной копии библиотек /tmp/.snap/usr/lib/x86_64-linux-gnu.exchange. Атакующему может потребоваться несколько дней ожидания запуска systemd-tmpfiles, так как в Ubuntu 24.04 процесс очистки запускается раз в 10 дней, а в более новых выпусках - раз в 30 дней.
После подмены каталога атакующий добивается инициализации нового sandbox-окружения при помощи snap-confine.
Во время формирования начинки sandbox-окружения во временном каталоге /tmp/.snap атакующий дожидается нужного момента и переименовывает /tmp/.snap/usr/lib/x86_64-linux-gnu.exchange в /tmp/.snap/usr/lib/x86_64-linux-gnu, подменяя таким образом библиотеки и обеспечивая их bind-монтирование с правами root. Таким образом атакующий получает контроль над разделяемыми библиотеками и загрузчиком ld.so, запускаемыми в sandbox-окружении snap, и может добиться выполнения произвольного кода с правами root через запуск любой suid-программы, в которой применяется динамическое связывание.
Имея root-доступ в sandbox-окружении, изолированном через AppArmor и фильтр системных вызовов на базе seccomp, атакующий может скопировать /bin/bash в каталог /var/snap/$SNAP/common/ и выставить ему права "04755" (suid root). Несмотря на то, что права изменены внутри sandbox-окружения, файл с изменёнными правами доступен и в основной системе, поэтому для получения полного root доступа достаточно запустить /var/snap/<имя_snap_пакета>/common/bash обычным непривилегированным пользователем из штатного системного окружения.
Попутно была выявлена уязвимость в инструментарии
uutils coreutils (Rust Coreutils), аналоге пакета GNU Coreutils, написанном на языке Rust. Уязвимость позволяет непривилегированному пользователю получить права root в системе. Проблема выявлена в процессе рецензирования изменений в Ubuntu 25.10 и устранена обходным путём до релиза Ubuntu 25.10 через поставку /usr/bin/gnurm вместо uutils rm. В пакете uutils проблема была устранена в выпуске uutils coreutils 0.3.0, без отметки в списке изменений об устранении уязвимости (было указано, что в rm, du, chmod и chgrp реализован безопасный метод обхода путей).
Проблема вызвана состоянием гонки в утилите "rm", позволяющем локальному пользователю подменить содержимое каталога на символическую ссылку во время удаления подконтрольного пользователю файла процессом "rm" с правами root. Среди прочего уязвимость может быть эксплуатирована при ежедневном запуске из cron скрипта /etc/cron.daily/apport, который запускается с правами root и рекурсивно удаляет содержимое каталога /var/crash, доступного на запись всем пользователям в системе.
При рекурсивном удалении каталогов утилита rm вначале проверяет все каталоги, а затем последовательно удаляет их в обратном порядке, вызывая функцию rmdir(). Если добиться подмены родительского каталога на символическую ссылку сразу после проверки этого каталога, но до проверки вложенных в него дочерних каталогов, операция приведёт к удалению каталога, на который указывает символическая ссылка. Таким образом можно добиться не только удаления любого файла в системе, но и повышения привилегий через удаление каталога /tmp/snap-private-tmp/$SNAP/tmp/.snap для подмены содержимого sandbox-окружения snap-пакета (метод получения root аналогичен первой уязвимости).
Разработчики проекта postmarketOS, развивающего дистрибутив Linux для мобильных устройств, объявили о создании атомарно обновляемого варианта дистрибутива. Новая редакция развивается под именем Duranium и примечательна поставкой системы как единого целого, без разделения на отдельные пакеты. Отмечается, что новый вариант соответствует идее, что устройство должно просто работать, без необходимости пользователю знать о существовании терминала и разбираться в особенностях системы.
Системное окружение в разделе /usr монтируется в режиме только для чтения с использованием ФС EROFS и верифицируется при каждой загрузке по цифровой подписи. Раздел /usr имеет размер 5GB. Для контроля целостности данных в разделе /usr применяется dm-verity, а при при выявлении модификации содержимого - загрузка блокируется. Проверочный хэш встраивается в унифицированный образ UKI (Unified Kernel Image), объединяющий обработчик для загрузки ядра из UEFI (UEFI boot stub), образ ядра Linux и загружаемое в память системное окружение initrd, применяемое для начальной инициализации на стадии до монтирования корневой ФС. UKI-образ оформляется в виде одного исполняемого файла в формате PE и вызывается загрузчиком UEFI.
Остальные каталоги, кроме /usr, входят в состав корневого раздела, доступного на запись и сохраняемого между перезапусками и обновлениями. Содержимое корневого раздела обязательно шифруется с использованием LUKS2, что обуславливает повышение требований к оборудованию. Шифрованная корневая ФС создаётся во время первой загрузки или после выполнения сброса к заводским настройкам. По умолчанию создаётся пустой ключ, допускающий автоматическую разблокировку шифрованного раздела. В мастере начальной настройки и в конфигураторе пользователю предлагается установить пароль для расшифровки.
Настройки по умолчанию хранятся в составе системного образа в каталоге /usr/share/factory/etc. Во время первой загрузки в каталоге /etc создаются символические ссылки на все файлы в /usr/share/factory/etc, за исключением файлов passwd, group, shadow, fstab, machine-id и hostname. При необходимости изменения настроек в процессе работы, символическая ссылка заменяется на копию файла.
Обновления устанавливаются через замену всего системного образа. На накопителе создаётся два идентичных корневых раздела - активный и пассивный. Новое обновление устанавливается в пассивный раздел, никак не влияя на работу активного. После верификации корректности установленного обновления и успешной перезагрузки разделы меняются местами - раздел с обновлением становится активным, а прошлый активный раздел переводится в пассивный режим и ожидает установки следующего обновления. Если после обновления возникли проблемы с загрузкой, осуществляется автоматический откат на прошлый вариант системы.
Подобный подход значительно упрощает отладку и диагностику проблем, так как разработчики могут точно воспроизвести состояние, при котором возник сбой, без необходимости воспроизводить состав системы пользователя на уровне отдельных пакетов и учитывать имеющиеся комбинации версий пакетов. Недостатком являются более высокие требования к аппаратному обеспечению, что не позволит использовать Duranium на всех устройствах, поддерживаемых в postmarketOS.
Начинка системного образа Duranium формируется из единой с postmarketOS пакетной базы, основанной на Alpine Linux, стандартной Си-библиотеке Musl и наборе утилит BusyBox. Релизы postmarketOS и Duranium получаются почти идентичны по составу, но отличаются разными методами поставки системы. Для формирования, установки и обновления системных образов задействованы компоненты
systemd-sysupdate, systemd-repart и systemd-verity-setup.
Дополнительные приложения устанавливаются в формате Flatpak или с использованием пакетного менеджера Coldbrew. Coldbrew позволяет установить пакеты из репозиториев Alpine Linux в домашний каталог пользователя. При запуске подобные пакеты изолируются при помощи инструментария bubblewrap.
Разработчики проекта Arch Linux 32, развивающего ответвление от Arch Linux с поддержкой 32-разрядных систем, заблокировали доступ из Бразилии из-за опасения получения штрафов за нарушение закона о проверке возраста. Отмечается, что у развиваемого энтузиастами проекта нет необходимой инфраструктуры и финансовых ресурсов для выполнения требований вступившего в силу закона, поэтому они решили применить блокировку бразильских подсетей, чтобы избежать риска закрытия проекта в случае получения штрафа.
При попытке обращения к сайту проекта, форумам, загрузкам и wiki из бразильских подсетей теперь выводится страница о блокировке доступа. Также упоминается о возможной недостижимости pacman-репозиториев проекта из бразильских подсетей. Проект Arch Linux 32 не связан с Arch Linux и развивается отдельным сообществом как независимый форк, основанный в 2017 году после прекращения поддержки 32-разрядных систем x86 в Arch Linux.
Примечание о запрете использования продукта на территории Бразилии также добавлено проектом MidnightBSD. На странице загрузки указано, что начиная с 17 марта 2026 года гражданам Бразилии не разрешается использовать MidnightBSD из-за вступления в силу закона о верификации возраста. Указано, что разработчики не станут пытаться соответствовать требованиям данного закона, так как MidnightBSD не является коммерческой компанией и не имеет средств для оплаты сервисов верификации.
17 марта в Бразилии вступил в силу закон 15.211/2025 "Digital ECA", вводящий систему контроля доступа несовершеннолетних к цифровому контенту. В отличие от похожего закона, принятого в Калифорнии, бразильский вариант отличается более значительными штрафами и жёсткими требованиями. Закон предусматривает штрафы в размере до 10 процентов от годовой выручки или от 10 до 1000 реалов (2-200 долларов) за каждого зарегистрированного пользователя при отсутствии выручки, но в сумме не больше 50 миллионов реалов (13 млн долларов).
Закон требует от производителей операционных систем и магазинов приложений строгой проверки возраста, не ограничивающейся голословным согласием пользователя, что ему больше 18 лет. Для подтверждения требуется внедрение "эффективных и надёжных" методов верификации, таких как проверка документов или прохождение аутентификации в уполномоченных сервисах. Операционная система должна предоставить приложениям API для получения данных о возрасте, а также поддерживать инструменты родительского контроля, позволяющие отслеживать экранное время и ограничивать доступ к контенту только для взрослых.
При этом из сферы действия закона выведена "базовая функциональность, необходимая для работы интернета, включая открытые и универсальные технические протоколы и стандарты". Также отмечается, что операционная система с точки зрения закона выполняет вспомогательную роль, а основная ответственность ложится на приложения, которые при необходимости должны внедрять собственные механизмы для предотвращения несанкционированного доступа несовершеннолетних.
После шести месяцев разработки компания Oracle опубликовала платформу Java SE 26 (Java Platform, Standard Edition 26), в качестве эталонной реализации которой используется открытый проект OpenJDK. За исключением удаления некоторых устаревших возможностей в Java SE 26 сохранена обратная совместимость с прошлыми выпусками платформы Java - большинство ранее написанных Java-проектов без изменений будут работоспособны при запуске под управлением новой версии. Готовые для установки сборки Java SE 26 (JDK, JRE и Server JRE) подготовлены для Linux (x86_64, AArch64), Windows (x86_64) и macOS (x86_64, AArch64). Разработанная в рамках проекта OpenJDK эталонная реализация Java SE 26 полностью открыта под лицензией GPLv2 с исключениями GNU ClassPath, разрешающими динамическое связывание с коммерческими продуктами.
Java SE 26 отнесён к категории выпусков с обычным сроком поддержки, обновления для которого будут выпускаться до следующего релиза. В качестве ветки с длительным сроком поддержки (LTS) следует использовать Java SE 25, Java SE 21 или Java SE 17, обновления для которых будут выпускаться до 2033, 2031 и 2029 годов соответственно (общедоступные - до сентября 2030, 2028 и 2026 годов). Расширенная поддержка LTS-ветки Java SE 8 продлится до 2030 года, а Java SE 11 - до 2032 года.
Реализован вывод предупреждения при использовании глубокой рефлексии для изменения полей, помеченных ключевым словом "final". В будущем планируется отключить по умолчанию небезопасные возможности языка и, среди прочего, сделать поля, помеченные как final, полностью не изменяемые, убрав обходной путь для их изменения через глубокую рефлексию (API Reflection).
Удалён API Applet (java.applet.Applet*, javax.swing.JApplet), применявшийся для запуска Java-приложений в браузере. Данный API потерял актуальность после прекращения поддержка Java-плагина для браузеров и был объявлен устаревшим в 2021 году.
Реализована возможность использования предварительно формируемого кэша (AOT - ahead-of-time) c любыми сборщиками мусора, включая ZGC (Z Garbage Collector). Изменение подразумевает поддержку последовательной загрузки прокэшированных Java-объектов в память, используя универсальный и не зависящий от сборщиков мусора формат вместо прямого маппинга в память специфичных представлений кэша. Использование AOT-кэша сокращает время запуска и ускоряет актуализацию (warmup) виртуальной машины HotSpot.
В API HTTP Client добавлена поддержка протокола HTTP/3, позволяющая приложениям и библиотекам обращаться к серверам по HTTP/3 после минимальных изменений кода.
Повышена производительность сборщика мусора G1, благодаря сокращению блокировок для синхронизации потоков приложения с потоками сборщика мусора.
Предложен второй предварительный вариант API для кодирования и декодирования объектов с криптографическими ключами, сертификатами и списками отозванных сертификатов, используя формат PEM (Pivacy-Enhanced Mail).
Предложен для тестирования шестой предварительный вариант API для cтруктурированного параллелизма (Structured Concurrency), упрощающего разработку многопоточных приложений за счёт обработки нескольких задач, выполняемых в разных потоках, как единого блока.
Добавлен вторая предварительная редакция API Lazy Constants для работы с объектами, содержащими неизменяемые данные и обрабатываемыми в JVM как константы. К подобным объектам применяются оптимизации производительности, аналогичные полям с ключевым словом "final". В отличие от "final" новый API разделяет создание постоянных значений и их инициализацию, гарантирует, что значение может быть инициализировано только один раз, сокращает время запуска программ и позволяет применять в пользовательском коде оптимизации сворачивания констант (constant-folding), ранее использовавшиеся только во внутреннем коде JDK.
class Application {
// Было:
// static final UserService USERS = new UserService();
// Теперь можно:
static final StableValue<UserService> USERS = StableValue.of();
public static UserService users() {
return USERS.orElseSet(UserService::new);
}
}
В механизме сопоставления с образцом предложен четвёртый предварительный вариант возможности использования примитивных типов (int, byte, char и другие базовые типы, не являющиеся объектами) во всех видах шаблонов, в операторе "instanceof" и в блоках "switch".
switch (x.getStatus()) {
case 0 -> "okay";
case 1 -> "warning";
case 2 -> "error";
case int i -> "unknown status: " + i;
}
if (i instanceof byte b) {
... b ...
}
Предложена одиннадцатая тестовая реализация API Vector, предоставляющего функции для векторных вычислений, которые выполняются с использованием векторных инструкций процессоров x86_64 и AArch64 и позволяют одновременно применить операции сразу к нескольким значениям (SIMD). В отличие от предоставляемых в JIT-компиляторе HotSpot возможностей по автовекторизации скалярных операций, новый API даёт возможность явно управлять векторизацией для параллельной обработки данных.
Кроме того, компания Oracle анонсировала проект Detroit, который будет развиваться в составе OpenJDK и нацелен на улучшение переносимости между Java, JavaScript и Python. В рамках проекта намерены предоставить возможность встраивания в процесс JVM runtime с JavaScript-движком V8 и интерпретатором CPython. Ранее компания Oracle уже развивала JavaScript-движок Nashorn, работающий поверх виртуальной машины JVM, но свернула проект из-за проблематичности разрабатывать отдельную реализацию JavaScript в условиях, когда основная экосистема завязана на движке V8.
Дополнительно можно отметить публикацию обновления платформы для создания приложений с графическим интерфейсом JavaFX 26. В ближайшие часы также ожидается выпуск универсальной виртуальной машины GraalVM 26, поддерживающей запуск приложений на JavaScript (Node.js), Python, Ruby, R, любых языках для JVM (Java, Scala, Clojure, Kotlin) и языках, для которых может формироваться биткод LLVM (C, C++, Rust).
Компания Meta*объявила о возобновлении разработки библиотеки управления памятью jemalloc, репозиторий которой в июне прошлого года был переведён в архивный режим. Библиотека jemalloc предлагает альтернативную реализацию функций malloc, оптимизированную для снижения фрагментации и работы на многопроцессорных системах.
Отмечается, что компания Meta осознала преимущества от применения jemalloc в своей инфраструктуре и решила возобновить работу над кодом данной библиотеки для снижения издержек на сопровождение, модернизации кодовой базы, избавления от технического долга и адаптации аллокатора для новых видов нагрузки и актуального оборудования. Разработка будет продолжена в форме открытого проекта, развиваемого совместно с сообществом и приветствующего подключение к работе сторонних участников.
Библиотека jemalloc была разработана Джейсоном Эвансом (Jason Evans) в 2005 году для FreeBSD 7.0, после чего была портирована в NetBSD и интегрирована в состав Firefox. В 2009 году автор jemalloc перешёл на работу в компанию Facebook, в которой данная библиотека использовалась во внутренних проектах. В 2017 году Джейсон уволился из Facebook, а разработка была продолжена оставшейся командой из Facebook. После переименования в Meta приоритеты компании изменились, развитие библиотеки застопорилось, разработка сосредоточилась только на внутренних потребностях, а общедоступная кодовая база со временем деградировала. Для поддержания общедоступной библиотеки на плаву требовался значительный рефакторинг, но Джейсон
не готов был тратить своё время на эту работу и поэтому 10 месяцев назад перевёл репозиторий в архивный режим.
Среди планов, которые компания Facebook наметила реализовать после возрождения проекта:
Снижение накопленного технического долга, проведение рефакторинга и чистки кодовой базы, усовершенствование библиотеки для сохранения эффективности, надёжности и простоты использования.
Продолжение развития аллокатора HPA (Huge-Page Allocator) для оптимизации потребления ресурсов CPU за счёт более оптимального использования больших страниц памяти (transparent hugepage).
Внесение изменений для повышения эффективности работы с памятью, связанных с улучшением упаковки структур, кэширования и очистки освобождённых блоков памяти.
Добавление оптимизаций для архитектуры AArch64 (ARM64).
Компания Mistral AI представила большую языковую модель Leanstral, нацеленную на использование для разработки приложений (вайб-кодинга) и оптимизированную для формальной верификации кода. Предполагается, что Leanstral может применяться для создания AI-ассистентов, позволяющих не просто генерировать код, но и гарантировать отсутствие в нём ошибок.
Leanstral стала первой открытой моделью, поддерживающей язык программирования Lean 4 и связанный с ним инструментарий для проверки математических доказательств. Lean 4 предоставляет возможности для математического доказательства корректности кода и его соответствия спецификации, что в контексте вайб-кодинга позволяет подтвердить, что сгенерированный AI-моделью код делает именно то, что задумано.
Модель охватывает 119 миллиардов параметров (6.5 млрд активируемых параметров на токен), учитывает контекст в 256 тысяч токенов и опубликована под лицензией Apache 2.0. Загружаемый архив с Leanstral занимает 121 ГБ и пригоден для использования на локальных системах. Для локального запуска могут применяться библиотеки vllm, transformers и SGLang.
Среди прочего модель может применяться для вайб-разработки в открытом агенте mistral-vibe, а также интегрироваться с инструментарием Aeneas для верификации кода на языке Rust. В качестве входных параметров принимается текст и изображения, на выходе выдаётся только текст. Поддерживается анализ содержимого изображений.
Для оценки возможностей AI-моделей с учётом качества проведения формальной верификации кода и написания математических доказательств разработан новый набор тестов FLTEval. В проведённых тестах модель Leanstral ощутимо обогнала существующие открытые модели Qwen3.5 397B-A17B, Kimi-K2.5 1T-A32B и GLM5 744B-A40B, показала сходные результаты с моделями Claude Haiku 4.5 и Claude Sonnet 4.6 от компании Anthropic, но отстала от модели Claude Opus 4.6. В частности, модель Opus набрала
39.6 баллов, а Leanstral - 21.9 при одном проходе и 31.9 при 16 проходах. При этом затраты при использовании Opus составили 1650 долларов, а Leanstral - $18 при одном проходе и $290 при 16 проходах. Модель Haiku набрала 23 балла при затратах $184, а модель Sonnet - 23.7 при затратах $549.
После семи месяцев разработки опубликован мультимедиа-пакет FFmpeg 8.1, включающий набор приложений и коллекцию библиотек для операций над различными мультимедиа-форматами (запись, преобразование и декодирование звуковых и видеоформатов). Пакет написан на языке Си и распространяется под лицензиями LGPL и GPL.
Добавлены парсер, кодировщик и декодировщик, а также упаковщик и распаковщик мультимедийных контейнеров (muxer/demuxer), для формата изображений JPEG XS, который позиционируется как легковесная система кодирования изображений, обеспечивающая минимальные задержки при кодировании и декодировании, и ориентированная на оптимизацию передачи последовательностей изображений очень высокого качества (до 8K). JPEG XS позволяет существенно снизить необходимую пропускную способность канала связи без заметных для человеческого глаза потерь качества. Реализация основана на библиотеке libsvtjpegxs.
Добавлен экспериментальный декодировщик для формата кодирования звука xHE-AAC (High-Efficiency Advanced Audio Coding) со схемой объёмного звука Mps212 (MPEG Surround с раскладкой каналов 212). xHE-AAC используется в потоковом вещании Netflix и задействован в технологиях цифрового радиовещания Digital Radio Mondiale. Кодек примечателен поддержкой широкого диапазона битрейта (от 12 до 300 kbit/s), высокой степенью сжатия, средствами воспроизведения с постоянной громкостью, обеспечением высокой чёткости при любых уровнях громкости, дополнительными профилями управления динамическим диапазоном при прослушивании в шумных местах и добавлением метаданных, позволяющих восстанавливать потери на принимающей стороне.
На базе библиотеки libmpeghdec реализован декодировщик для интерактивного и объёмного звука в формате NGA (Next Generation Audio), определённого в стандарте кодирования звука и видео MPEG-H.
Добавлена поддержка упаковки и распаковки пространственного звука в формате IAMF (Immersive Audio Model and Formats) с объёмным звучанием в режиме Ambisonics, учитывающем распространение звука не только в горизонтальной плоскости, но и в вертикальной (для определения сверху или снизу источник звука).
Добавлена поддержка разбора и перенаправления метаданных в формате LCEVC (Low Complexity Enhancement Video Coding), реализующем дополнительный слой с метаданными поверх штатных кодеков для улучшения качества видео. Добавлена поддержка экспорта слоёв улучшения качества LCEVC в мультимедийные контейнеры MPEG-TS (MPEG Transport Stream).
На базе графического API Vulkan реализованы кодировщик и декодировщик для кодека Apple ProRes, а также декодировщик для применяемого в кинопроизводстве формата раздельной передачи кадров DPX (Digital Picture Exchange). Реализации на базе API Vulkan примечательны значительным повышением производительности за счёт аппаратного ускорения, распараллеливания операций и задействования вычислительных шейдеров. Проведена оптимизация реализаций кодеков на основе API Vulkan. Для ускорения инициализации кодеков реализована возможность использование уже скомпилированных шейдеров GLSL, без необходимости их компиляции во время работы.
В библиотеке swscale (Software Scaler), применяемой в FFmpeg для программного масштабирования и преобразования цветов, реализован бэкенд, использующий для ускорения выполнения операций графический API Vulkan.
Добавлены варианты кодировщиков форматов H.264 и AV1, использующие
API D3D12 (Direct3D 12) для аппаратного ускорения кодирования.
Добавлен вариант кодировщика формата H.264/HEVC, использующий доступные в чипах Rockchip средства аппаратного кодирования видео.
Добавлены распаковщики (demuxer) мультимедийных контейнеров в форматах HXVS и HXVT, применяемых в IP-камерах.
Реализован парсер для метаданных в формате EXIF и сопутствующий API для разбора метаданных.
В утилиту ffprobe добавлена опция "-codec" ("-c") для выбора определённой реализации декодировщика.
В утилиту ffmpeg добавлена поддержка мозаичного режима (tiled) хранения изображений в формате HEIF (когда очень большое изображение сохраняется в форме набора из более мелких изображений).
Удалён старый обработчик протокола HLS.
Новые фильтры:
drawvg для вывода векторной графики поверх видеокадров, используя библиотеку libcairo.
vpp_amf для изменения размера видео и преобразования цветового пространства, используя AMD Advanced Media Framework для аппаратного ускорения.
vf_scale_d3d12, vf_deinterlace_d3d12, vf_mestimate_d3d12 для масштабирования, деинтерлейсинга и анализа движения на видео, используя для аппаратного ускорения графический API Direct3D 12.
gfxcapture для захвата содержимого окон и экрана на платформе Windows при помощи API Windows.Graphics.Capture.
Кент Оверстрит (Kent Overstreet) опубликовал выпуск файловой системы Bcachefs 1.37.0. Выпуск охватывает два пакета: bcachefs-kernel-dkms с модулем ядра, собираемым при помощи системы DKMS (Dynamic Kernel Module Support), и bcachefs-tools с запускаемой в пространстве пользователя утилитой bcachefs, реализующей команды для создания (mkfs), монтирования, восстановления и проверки ФС. Пакеты собраны для Arch Linux и ожидаются для Debian, Ubuntu, Fedora, openSUSE и NixOS. DKMS-модуль поддерживает работу с ядрами Linux, начиная с 6.16.
Стабилизирована и объявлена готовой к повсеместному использованию поддержка кодов коррекции ошибок, позволяющих восстанавливать повреждённые данные по аналогии с RAID 5/6. Реализация основана на кодировании
Рида-Соломона, способном исправить до N ошибок в страйпе (stripe) при наличии N избыточных блоков. Обеспечено автоматическое восстановление деградировавших страйпов. Добавлена возможность применения кодов восстановления в конфигурациях с накопителями разного размера.
Добавлена поддержка находящегося в разработке ядра Linux 7.0.
Реализованы новые команды "subvolume list" для вывода подразделов с фильтрацией и сортировкой; "subvolume list-snapshots" для показа снапшотов в древовидной форме'; "subvolume reflink-option-propagate" для применения параметров ввода-вывода файла, таких как сжатие, контрольная сумма, количество реплик и список целевых устройств, к экстентам файла.
Стабилизирована операция раскрутки (rewind) журнала.
Обеспечено автоматическое восстановление при использовании устройств с некорректной поддержкой команд для сброса прокэшированных операций записи на накопитель (flush и FUA).
Ускорено восстановление после некорректного завершения работы.
Повышена производительность ФС, охватывающих несколько устройств.
Запускаемые в пространстве пользователя утилиты bcachefs переписаны на языке Rust.
В будущем планируется переписать на Rust и компоненты ФС, работающие на уровне ядра.
Началась работа по использованию инструментария Verus для формальной верификации кода на Rust.
Проектом Bcachefs развивается файловая система, нацеленная на сочетание расширенной функциональности, свойственной Btrfs и ZFS, и уровня производительности, надёжности и масштабируемости, характерного для XFS. Bcachefs поддерживает такие возможности, как включение в раздел нескольких устройств, многослойные раскладки накопителей (нижний слой с часто используемыми данными на базе быстрых SSD, а верхний слой с менее востребованными данными из жестких дисков), репликация (RAID 1/10), кэширование, прозрачное сжатие данных (режимы LZ4, gzip и ZSTD), срезы состояния (снапшоты), верификация целостности по контрольным суммам, коды коррекции ошибок, хранение информации в зашифрованном виде (используются ChaCha20 и Poly1305).
Проект AERIS-10 разработал полностью открытую модульную радиолокационную станцию (радар), которую можно использовать в качестве платформы для проведения экспериментов c фазированными антенными решётками, сжатием импульсов, доплеровской обработкой сигналов и отслеживанием целей. Полные схемы, распайки печатных плат, списки комплектующих (BOM), Gerber-файлы для изготовления плат, макеты для 3D-печати и описания аппаратных блоков на языках Verilog/VHDL распространяются под лицензией CERN-OHL-P (CERN Open Hardware Licence). Код прошивки для микроконтроллера STM32, вспомогательные утилиты на Си и графический интерфейс на Python поставляются под лицензией MIT.
Подготовлено два варианта радиолокационной станции на фазированных антенных решётках - AERIS-10N (Nexus) и AERIS-10E (Extended). Оба варианта используют частоту 10.5 ГГц и используют импульсную линейную частотную модуляцию (LFM). Отличия сводятся к мощности излучения (1Wx16 и 10Wx16), а также использованию массива плоскостных антенн 8x16 и массива щелевых излучателей в диэлектрически заполненном волноводе 32x16, обеспечивающих дальность действия до 3 км и 20 км, соответственно.
Система модульная с раздельными платами управления питанием, генерации частот и RF-блоками. Для обработки сигналов, сжатия импульсов, вычисления скорости объекта при помощи доплеровского быстрого преобразования Фурье, исключения неподвижных объектов (MTI) и обеспечения постоянного уровня ложных тревог (CFAR) задействован FPGA XC7A100T. Управление работой и настройка периферийных устройств осуществляется при помощи микроконтроллера STM32F746xx.
Корректировка положения и ориентации в режиме реального времени обеспечивается при помощи GPS и инерциальных датчиков (акселерометр, гироскоп). Реализовано электронное управление сканирующим лучом в пределах ±45° по высоте и азимуту. Вращение антенны на 360° обеспечивает шаговый двигатель. Возможно одновременное отслеживание движения нескольких объектов. Для управления радаром, наглядного отслеживания движущихся объектов и их сопоставления с картой реализован графический интерфейс.
Сборка радара осуществляется из типовых элементов, имеющихся в широкой продаже. Затраты на чипы и компоненты для изготовления радара в простейшей конфигурации оцениваются приблизительно в 5000 долларов. Для сравнения: стоимость коммерческих радаров того же класса начинается с 250 тысяч долларов.
