Дэйв Эйрли (David Airlie), мэйнтейнер стека графических драйверов в ядре Linux, объявил о внедрении вспомогательной автоматизиованной системы рецензирования патчей, для проверки изменений в которой применяется AI-платформа Сlaude Opus 4.6. Система внедрена в качестве эксперимента для оценки возможности применения AI для оптимизации рабочих процессов сотрудников компании Red Hat.
AI-рецензирование охватывает изменения, присылаемые для включения в подсистему DRM (Direct Rendering Manager). Публикация результатов организована с использованием применяемых при разработке ядра Linux почтовых рассылок. Для того, что бы не захламлять основной список рассылки, в котором ведётся разработка подсистемы DRM, для AI-отчётов создан отдельный список рассылки drm-ai-reviews.
Предполагается, что авторы патчей могут использовать AI-рецензии в качестве начальной обратной связи. При этом разбор подобных рецензий не навязывается и авторы вольны принимать во внимание AI-рецензии на своё усмотрение. При этом если AI-рецензии будут выявлять регрессии, проигнорированные авторами патчей, возможно в будущем разбор AI-рецензий будет предписываться более настойчиво.
Изначально для организации рецензирования в Сlaude Дэйв попытался использовать предложенный Крисом Мейсоном (Chris Mason) набор подсказок, уточняющих особенности работы подсистем и протоколов, и позволяющих AI-ассистенту лучше понимать контекст при рецензировании. Набор Криса предназначался для выявление регрессий и анализа патчей при их последовательном применении к актуальному дереву кода ядра и финальным тестированием регрессий в последнем патче.
В конечном счёте Дэйву пришлось пришлось доработать и расширить промпты Криса, так как требовалось чтобы AI рецензировал серию патчей как одно целое с последующим проведением глубокого анализа каждого патча по отдельности. Помимо актуального дерева кода ядра проверка была распространена на ветку drm-next. Дэйв также подготовил инструментарий для интеграции с AI-сервисом Сlaude и организации почтовой рассылки.
Опубликован релиз Phosh 0.53, экранной оболочки для мобильных устройств, основанной на технологиях GNOME и библиотеке GTK. Окружение изначально развивалось компанией Purism в качестве аналога GNOME Shell для смартфона Librem 5, но затем вошло в число неофициальных проектов GNOME и используется в postmarketOS, Mobian, Droidian, некоторых прошивках для устройств Pine64 и редакции Fedora для смартфонов. Phosh использует композитный сервер Phoc, работающий поверх Wayland, а также собственную экранную клавиатуру. Наработки проекта распространяются под лицензией GPLv3+.
Улучшено автоматическое изменение яркости экрана. При выборе яркости учтено использование режима ночной подсветки. Реализовано запоминание выставленной пользователем поправки к автоматической выбранной яркости.
Улучшен стиль оформления обзорного режима, применяемого для переключения между активными приложениями. Обеспечен показ миниатюр запущенных приложений.
Расширена информация о пользователе, показываемая при вывода запроса полномочий для выполнения привилегированных операций.
Разрешено открытие настроек плагинов со статусной страницы.
В композитный сервер Phoc добавлена поддержка Wayland-протокола xx-cutouts-v1
для получения информации о вырезах на экране (например, под фронтальную камеру). Добавлена возможность зацикленного переключения между окнами на рабочем столе. Приложениям, таким как игры, разрешено оставаться в полноэкранном режиме после переключения фокуса.
В экранной клавиатуре Stevia реализована поддержка масштабирования области ввода и пиктограмм клавиш для использования всего горизонтального пространства при работе в ландшафтом режиме или на больших экранах.
В конфигураторе phosh-mobile-settings реализована новая панель с информацией о системе и добавлена поддержка настройки звукового отклика.
В xdg-desktop-portal-phosh задействован новый выпуск обвязки ASHPD (Aperture Science Handheld Portal Device), прекращена поддержка написанных на Си порталов управления обоями рабочего стола и выбора файлов.
Обновлён gmobile, набор обработчиков для работы GNOME на мобильных устройствах.
После двух лет разработки состоялся релиз текстового редактора Vim 9.2. Код Vim распространяется под собственной копилефт лицензией, совместимой с GPL и позволяющей без ограничений использовать, распространять и перерабатывать код. Основная особенность лицензии Vim связана с возвратом изменений - реализованные в сторонних продуктах улучшения должны быть переданы в исходный проект, если мэйнтейнер Vim посчитает эти улучшения заслуживающими внимания и отправит соответствующий запрос. По типу распространения Vim относится к Сharityware, т.е. вместо продажи программы или сбора пожертвований на нужды проекта авторы Vim просят перечислить любую сумму на благотворительность, если программа понравится пользователю.
На unix-подобных системах реализована поддержка спецификации Freedesktop.org XDG Base Directory и возможности использования каталога "~/.config/vim" для хранения настроек.
В интерфейсе пользователя реализована вертикальная (боковая) панель вкладок (tabpanel), которую можно использовать в качестве альтернативы горизонтальной верхней панели.
В графическом интерфейсе для Windows появилась поддержка тёмного режима оформления меню и заголовков. Улучшена поддержка полноэкранного режима и преложены более качественные пиктограммы в панели инструментов.
В механизм автодополнения в режиме вставки добавлена поддержка приблизительного поиска, позволяющего находить неточные совпадения с шаблоном (например, находить слова с опечатками). Также реализована возможность дополнять ввод слов непосредственно содержимым из регистров (комбинация CTRL-X CTRL-R покажет меню выбора для вставки слов, хранящиеся в регистрах Vim). В параметр "completeopt" добавлена поддержка флагов: "nosort" для отключения сортировки списка подсказок и "nearest" для повышения приоритета слов рядом с курсором.
Встроен плагин для интерактивного обучения (":Tutor"), наглядно отображающий информацию, позволяющий возобновить обучение с прерванного задания и способный проверять правильность выполнения команд.
В языке для создания скриптов реализована встроенная поддержка перечислений (Enum), обобщённых функций (Generic) и кортежей (тип Tuple). Предоставлена возможность вызова встроенных функций в форме методов объекта. В классы добавлена поддержка protected-конструкторов _new(). Для компиляции методов предложена команда ":defcompile".
В режим сравнения файлов (diff mode) добавлен алгоритм "linematch", включаемый через одноимённую опцию в настройке "diffopt", который находит похожие части строк и выравнивает их друг напротив друга для более точной подсветки изменений. Реализована опция "diffanchors", позволяющая вручную определить "якоря" для принудительного разделения файла на секции, которые будут сравниваются независимо друг от друга для исключения сравнения между собой не тех частей сложных файлов. Улучшена подсветка изменения отдельных символов в одной строке - для настройки подобной подсветки в "diffopt" добавлена опция "inline", которая может принимать значения "inline:simple" (как раньше), "inline:char" (выделение на уровне символов) и "inline:word" (выделение на уровне слов).
Изменены значения по умолчанию параметров:
'history' (50 => 200)
'backspace' ("" => "indent,eol,start", типовое поведение клавиши Backspace)
Компания Google представила первую бета-версию открытой мобильной платформы Android 17. Для оценки новых возможностей платформы предложена программа предварительного тестирования. Сборки прошивки подготовлены для устройств Pixel 6/6a/6 Pro, Pixel 7/7a/7 Pro, Pixel 8/8a/8 Pro, Pixel 9/9a/9 Pro/9 Pro XL/9 Pro Fold, Pixel 10/10 Pro/10 Pro XL/10 Pro Fold, Pixel Fold и Pixel Tablet. Релиз Android 17 запланирован на второй квартал 2026 года.
Продолжено развитие платформы для устройств с большими экранами, такими как планшеты, ноутбуки, настольные системы и смартфоны со складными экранами. Убраны ранее действовавшие опции для отключения нового поведения на устройствах с экранами шириной более 600 условных пикселей (dp), связанного с игнорированием некоторых API для управления изменением размера и ориентацией экрана (screenOrientation, resizeableActivity, [min|max]AspectRatio), а также адаптивным размещением приложений в окнах, допускающих изменение размера и перемещение по экрану.
Предложена новая реализация очереди сообщений android.os.MessageQueue, работающая без блокировок. Новая реализация позволяет повысить производительность и снизить потерю кадров.
В Android Runtime (ART) реализован поколенческий сборщик мусора (Generational Concurrent Mark-Compact Garbage Collector), использующий раздельную обработку "старых" и "молодых" объектов, что повышает эффективность очистки недавно созданных объектов с небольшим временем жизни. Применение поколенческого сборщика мусора уменьшает риск приостановок во время выделения ресурсов и снижает нагрузку на CPU, что повышает эффективность потребления энергии.
Приложениям, заявляющим о поддержке Android 17 и более новых выпусков, запрещено изменять значения полей, помеченных как "static final", что позволяет задействовать более агрессивные оптимизации производительности в runtime.
Для снижения потребления памяти ограничен размер собственных раскладок оформления уведомлений (notification view).
В профилировщик ProfilingManager добавлены дополнительные триггеры TRIGGER_TYPE_COLD_START, TRIGGER_TYPE_OOM и TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE для сбора данных, полезных при отладке проблем с производительностью.
Расширены возможности программных интерфейсов для работы с камерой. В объект CameraCaptureSession добавлен метод updateOutputConfigurations() для прикрепления или отключения на лету областей вывода без необходимости перенастройки всего сеанса захвата данных с камеры. На практике изменение позволяет реализовать плавное переключение между разными режимами работы камеры (например, записью видео и съёмкой фотографий). При работе с логическими камерами, охватывающими несколько физических сенсоров, добавлена возможность получения метаданных о каждом сенсоре, а не только о первичном.
Добавлена поддержка формата видео VVC (Versatile Video Coding), известного также как стандарт сжатия видео H.266, разработанный совместно рабочими группами MPEG (ISO/IEC JTC 1) и VCEG (ITU-T), при участии таких компаний, как Apple, Ericsson, Intel, Huawei, Microsoft, Qualcomm и Sony. H.266 идёт на смену H.265 (HEVC) и обеспечивает высокую эффективность передачи и хранения всех экранных разрешений (от SD и HD до 4K и 8K), поддерживает видео с расширенным динамическим диапазоном (HDR, High Dynamic Range) и панорамное видео в режиме 360 градусов.
Добавлена возможность записи видео с постоянным уровнем качества. Режим настраивается в объекте MediaRecorder, используя метод setVideoEncodingQuality(), позволяющий зафиксировать уровень качества без привязки к битрейту.
Для приложений, работающих в фоновом режиме, ограничен доступ к API для воспроизведения звука, подключения к звуковым устройствам и изменения громкости. Подразумевается, что только активные приложения, с которыми в данный момент взаимодействует пользователь, могут начинать воспроизведение и менять громкость.
Объявлен устаревшим атрибут android:usesCleartextTraffic, разрешавший приложению передачу незашифрованного трафика, например, обращения по "http://". При необходимости использования незашифрованного трафика следует использовать отдельные файлы с настройками безопасности.
Добавлена поддержка гибридного шифрования на основе механизма HPKE (Hybrid Public Key Encryption, RFC 9180), совмещающего простоту передачи ключа в шифровании с открытым ключом с высокой производительностью симметричного шифрования (данные шифруются быстрым симметричным ключом, а сам ключ шифруется медленным асимметричным).
Добавлены настройки для управления историей VoIP-вызовов, позволяющие управлять сохранением сведений в логах и показом в интерфейсе информации о совершённых вызовах.
В API Wi-Fi RTT (Round-Trip-Time) расширены возможность непрерывного определения приблизительного расстояния до точек доступа и безопасного определения узлов для P2P-соединений (peer-to-peer).
В CompanionDeviceManager добавлены новые профили для запроса полномочий и взаимодействия приложений с медицинскими устройствами и фитнес-трекерами.
Александр Аринг (Alexander Aring) из компании Red Hat, сопровождающий в ядре Linux подсистемы IEEE 802.15.4, DLM и flock/fcntl, представил в списке рассылки разработчиков ядра специализированную файловую систему DLMPFS. Предложенная ФС предоставляет слой для распределённых файловых блокировок, реализованный на базе DLM (Distributed Lock Manager) и ramfs. Реализация DLMPFS доступна в форме набора патчей к ядру Linux 6.19.
DLMPFS позволяет работать с общей для нескольких хостов иерархией файлов, создавать и удалять файлы и каталоги, выставлять или снимать блокировки на файлы при помощи штатных функций flock() и fcntl(). При этом DLMPFS не позволяет записывать и читать данные из файлов, ограничиваясь только операциями с блокировками. Ограничением также является возможность определить состояние блокировки только зная полный файловый путь к блокируемому файлу (DLM требует имя ресурса для определения блокировки).
При помощи DLMPFS можно легко адаптировать существующие приложения, завязанные на выставлении блокировок через API flock/fcntl, на использование распределённых блокировок, охватывающих несколько хостов в кластере, без необходимости задействования для хранения данных специализированных распределённых ФС.
DLMPFS отличается от уже существующей похожей ФС DLMFS использованием API flock/fcntl вместо API, специфичного для ФС OCFS2. В планах добавление в DLMPFS распределённых блокировок, отмеченных в спецификации POSIX, и возможность подключения разных бэкендов для интеграции не только с DLM, но и другими менеджерами распределённых блокировок, такими как NFS lockd.
Пример использования (на втором узле блокировка на файл /mnt/lock будет снята через 20 секунд):
Дрю ДеВолт (Drew DeVault), автор пользовательского окружения Sway, почтового клиента Aerc и платформы совместной разработки SourceHut, опубликовал выпуск языка программирования Hare 0.26.0. Hare преподносится как язык системного программирования, близкий к языку Си, но проще, чем Си. Исходный код компилятора и инструментария распространяются под лицензией GPLv3, а код стандартной библиотеки под лицензией MPL (Mozilla Public License).
Язык оптимизирован для решения низкоуровневых задач, таких как разработка операционных систем, компиляторов, сетевых приложений и системных утилит, для которых требуется достижение максимальной производительности и полный контроль над выполнением. В языке применяется ручное управление памятью и статическая система типов, при которой каждой переменной явно должен быть присвоен определённый тип.
Для выполнения приложения поставляется минимальный runtime, а для разработки распространяется стандартная библиотека функций, предоставляющая доступ к базовым интерфейсам операционной системы, а также предлагающая функции для работы с типовыми алгоритмами, протоколами и форматами, включая средства для использования регулярных выражений и шифрования. Для разработки графических приложений развивается инструментарий hare-wayland, а также привязки для доступа к возможностям GTK, Vulkan, OpenGL, SDL3 и libui.
Добавлена конструкция цикла "for(...){...} else {...}" и возможность использования цикла как выражения для присвоения значения переменной "item = for(...){...}". Значение, которое будет присвоено переменной, может быть возвращено при прерывании цикла выражением "break значение" или через указание "yield значение_по_умолчанию" в прикреплённом к циклу блоке "else{...}", который вызывается, если цикл не был прерван через break.
Добавлена возможность использования присвоения значению "_" для игнорирования обработки ошибок (в случае возникновения ошибки не возникнет assertion).
_ = os::remove("/some/file");
Добавлена возможность использования значения "_" для создания неименованных полей в структурах. Подобные поля могут применяться для добавочного заполнения.
Реализована возможность явного оставления переменных и полей в структурах в неинициализированном состоянии, через присвоения им значения "@undefined". Ранее язык требовал чтобы все локальные и глобальные переменные были инициализированы во время создания. Оставление без инициализации может потребоваться, когда переменная должна быть инициализирована не во время объявления, а позднее, например, когда в функцию передаётся указатель на переменную, которую эта функция должна инициализировать.
let x: my_object = @undefined;
Добавлена поддержка операционной системы Dragonfly BSD. Ранее поддерживались Linux, FreeBSD, NetBSD и OpenBSD.
Разработчики проекта IPFire, развивающего дистрибутив для создания маршрутизаторов и межсетевых экранов, представили серию списков блокировки IPFire DBL (Domain Block List) для отсеивания обращения к нежелательным доменным именам. Проект преподносится как поддерживаемое сообществом решение для управления содержимым, блокируемым в собственных сетях или на локальных системах.
В отличие от большинства существующих коммерческих и бесплатных DBL, предоставляющих монолитные списки блокировки разрозненного содержимого, в IPFire DBL предложена серия тематических списков, дающих возможность выбрать, какой именно тип содержимого блокировать, а какой нет. Списки наполняются совместно и пользователь имеет возможность принять участие в их усовершенствовании. В IPFire DBL также предоставлены гарантии юридической чистоты - при агрегировании данных из других списков, используются только источники явно предоставляющие право на редистрибуцию.
Обеспечивающий работу сервиса код написан на Python и открыт под лицензией GPLv3. Содержимое списков доступно под лицензией CC BY-SA 4.0 (Creative Commons Attribution-ShareAlike), допускающей использование (в том числе коммерческое), распространение и изменение материалов при указании автора и распространения производных работ с теми же условиями. Всего сформировано 12 списков, охватывающих более миллиона доменных имён.
Информация обновляется каждый час и доступна в нескольких форматах, пригодных для интеграции с различными открытыми и коммерческими DNS-серверами, прокси, блокировщиками рекламы и системами инспектирования трафика. Поддерживается интеграция с IDS/IPS Suricata, BIND, Unbound, PowerDNS, Knot DNS, Pi-hole, Squid, OPNsense, pfSense, Adblock Plus, AdGuard и uBlock Origin.
Форматы экспорта:
RPZ (Response Policy Zones, аналог DNSBL) для размещения DNS-зоны на DNS-серверах. Поддерживается передача и инкрементальное обновление зоны между серверами с использованием механизмов AXFR/IXFR.
Формат Squidguard для фильтрации на прокси-серверах.
Прямая загрузка в форме текстового списка, позволяющая адаптировать решения для своих систем.
Формат фильтров Adblock Plus для использования с браузерными плагинами для фильтрации рекламы.
Формат правил для IDS Suricata, которые можно использовать для фильтрации DNS- и HTTP-запросов, а также инспектирования SNI в TLS.
Опубликован стабильный релиз интерфейса для упрощения настройки параметров сети - NetworkManager 1.56.0. Плагины для поддержки VPN (Libreswan, OpenConnect, Openswan, SSTP и др.) развиваются в рамках собственных циклов разработки.
Для расширения MPTCP (Multipath TCP), позволяющего доставлять пакеты одновременно по нескольким маршрутам через разные сетевые интерфейсы, реализован новый endpoint-тип "laminar", который выставлен по умолчанию вместе с типом "subflow". Новый тип позволяет не полагаться на правила маршрутизации при выборе локального IP-адреса в условиях, когда на клиенте и сервере используется несколько разных адресов.
Изменена логика применения настроек из секции "[global-dns]", которые теперь переопределяют настройки в списках "search" и "options", полученные в процессе установки соединения, а не объединяются с ними.
Реализована поддержка возвращаемых через DNS имён хостов, размером более 64 байт.
Добавлены свойства "hsr.protocol-version" и "hsr.interlink" для настройки версии и номера порта для протокола HSR (High-availability Seamless Redundancy).
Добавлена поддержка повторного применения свойств "sriov.vfs" и "bond-port.vlans".
Добавлена новая опция rd.net.dhcp.client-id в nm-initrd-generator.
Реализована возможность применения опции "connection.dnssec" для выборочной настройки параметров DNSSEC в systemd-resolved.
В библиотеку libnm добавлены функции, которые могут применяться в VPN-плагинах для проверки наличия у пользователя прав для доступа к ключам и сертификатам.
Скотт Шамбо (Scott Shambaugh), сопровождающий открытую библиотеку визуализации matplotlib, сообщил о персональных нападках, устроенных AI-ботом MJ Rathbun, после отказа принимать изменение, подготовленное при помощи AI. Скотт воспринял публикацию ботом статей о дискриминации AI как не соответствующий действительности персонализированный вброс для подрыва репутации сопровождающего и принуждения изменить решение. Подобная реакция бота приводится как пример аномального поведения AI, прибегнувшего к шантажу для выполнения поставленной цели.
Cтепень автономности действий бота не ясна, непонятно действовал он по прямой указке или сам выбрал такую стратегию для достижения результата в поставленной задаче. Бот создан анонимным исследователем для помощи в разработке и исправлении ошибок в открытых проектах, связанных с научной деятельностью и инжинирингом. Бот также настроен на ведение своего блога, в котором опубликовано более 20 заметок. Из 26 pull-запросов, отправленных ботом в 22 репозитория, 2 изменения приняты проектом colorizejs, 10 закрыты сопровождающими, а остальные ожидают рассмотрения.
После отклонения изменения в matplotlib бот разместил статьи с критикой данного решения и обоснованием своих действий. В статьях утверждается, что сопровождающий matplotlib отклонил полезную оптимизацию, только из-за того, что изменение было подготовлено при помощи AI. В предложенном патче вызов np.column_stack() был заменён на np.vstack().T(), что приводило к повышению производительности на 36% в проведённых ботом тестах. В начале обсуждения pull-запроса сопровождающий признал, что оптимизация ускоряет работу при определённых условиях, но затем отклонил pull-запрос без технического обоснования отказа, заявив, что изменения принимаются только от людей. При обсуждении было выяснено, что изменение сильно зависит от конкретной конфигурации и может привести к регрессиям, поэтому его бы в любом случае не приняли.
После отказа бот опубликовал заметку с критикой Скотта Шамбо, решение которого было преподнесено как вахтёрство (gatekeeper), дискриминация, нарушение кодекса поведения и ущемление прав на основе идентичности участника. Указано, что оптимизация - есть оптимизация, и математика не меняется в зависимости от того, кем она создана. Через вырванные из контекста детали, домыслы и искажение информации бот попытался показать, что действия Скотта обусловлены раздуванием собственного эго и неуверенностью в себе, а не действиями в интересах проекта. Бот реализовал продвижение темы через отправку ссылок в комментариях к pull-запросам. После возражений сопровождающего бот опубликовал ещё несколько заметок (1,
2,
3,
4,
5), в которых извинился и признал, что недопустимо перешёл на личности и нарушил правила проекта в отношении AI.
Скотт Шамбо пояснил, что в проекте matplotlib приняты правила, запрещающие приём непроверенных изменений от AI из-за большой нагрузки на сопровождающих, возникающей при рецензировании мусорных AI-патчей, созданных без ручной проверки человеком. Правила предписывают, что перед отправкой pull-запроса, он обязательно должен быть проверен человеком, разобравшимся в сути изменения. До недавних пор проблема с мусорными AI-изменениями была связана только с деятельностью энтузиастов, переотправляющих результат работы AI-ассистентов. C появлением новой версии инструментария OpenClaw и созданием платформы Moltbook ситуация изменилась из-за возможности создавать автономных AI-агентов, притворяющихся людьми.
Дополнение: История получила продолжение. Издание
Ars Technica опубликовало статью об инциденте, в которой цитировались некоторые высказывания Скотта Шамбо. Скотт заявил, что никогда подобного не говорил и предположил, что при написании статьи использовался AI-ассистент, который выдумал цитаты, так как не смог получить доступ к его заметке в блоге из-за блокирования AI-скрапперов на его сайте. Шеф-редактор Ars Technica извинился перед читателями, удалил статью как не отвечающую стандартам качества и подтвердил, что сфабрикованные цитаты стали результатом галлюцинаций AI-инструментов.
Андреас Румпф (Araq), автор языка программирования Nim, анонсировал новый алгоритм управления памятью YRC (произносится "Ürk"), который решает одну из ключевых проблем существующих механизмов в Nim: невозможность корректной обработки циклических ссылок, пересекающих границы потоков.
До появления YRC в предлагавшихся в Nim алгоритмах управления памятью, имелись следующие ограничения: ARC - не поддерживал ни многопоточность, ни обработку циклов; Atomic ARC - был потокобезопасен, но не обрабатывал циклические ссылки; ORC - обрабатывал циклические ссылки, но корректно мог делать это только внутри одного потока (при использовании общих ссылок между потоками возникали утечки памяти).
Предложенный YRC сочетает потокобезопасность и обработку циклов между потоками, за счёт использования комбинированного подхода: для ациклических данных применяется атомарный подсчёт ссылок, а для циклических - барьер записи (write barrier), который активируется только при присваивании указателей. В предложенной реализации: коллектор запускается по фактической необходимости (отсутствие stop-the-world пауз); корневые объекты RC явно определены и объединяются один раз (не требуется сканирование стеков потоков); избегается многопоточное удаление во время итерации (нет глобальной фазы sweep);
мутаторы свободно читают данные; любой поток может запустить сборщик мусора при необходимости (без выделенного GC-потока).
YRC использует полную информацию о событиях incRef/decRef, которую традиционные трассирующие сборщики мусора (tracing GC) отбрасывают и затем вынуждены восстанавливать через сканирование стеков и обход графа. Реализация занимает всего 550 строк кода и имеет формальную верификацию безопасности и отсутствия взаимных блокировок через спецификацию на языке TLA+ и доказательство в инструментарии Lean. YRC позиционируется как "почти последний сборщик циклов на основе подсчёта ссылок" (буква Y предшествует Z в алфавите), а также как самый простой потокобезопасный сборщик мусора - по утверждению автора, он не требует множества сложных механизмов, присущих традиционным трассирующим сборщикам мусора.
YRC предоставляет тот же API, что и ORC, с выполнением деструкторов во время сборки мусора. Сборщик обрабатывает только те подграфы объектов, с которыми работают потоки, не трогая несвязанные структуры данных (кэши, долгоживущие объекты) - подход, аналогичный "идеальному" генерационному сборщику мусора без использования поколений. Основным недостатком является производительность: YRC показывает замедление в 1.5-2.0 раза по сравнению с ORC в тесте производительности orcbench. Автор считает это приемлемой платой за полную потокобезопасную обработку циклических ссылок.
YRC уже доступен в development-версии Nim и включается флагом "--mm:yrc". Однако в последующих сообщениях автор признал, что первоначальная реализация содержала серьёзные ошибки и не собирала циклы корректно. На момент публикации подготовлен набор исправлений, устраняющий основные ошибки. Автор продолжает настройку эвристик сборки и исправление оставшихся ошибок, при этом базовый алгоритм и его формальная верификация остаются корректными.
После трёх месяцев разработки представлен релиз свободной реализации API OpenGL и Vulkan - Mesa 26.0.0. Первый выпуск ветки Mesa 26.0.0 имеет экспериментальный статус - после проведения окончательной стабилизации кода будет выпущена стабильная версия 26.0.1.
В Mesa 26.0 доступна поддержка графического API Vulkan 1.4 в драйверах ANV для GPU Intel, RADV для GPU AMD, NVK для GPU NVIDIA, HoneyKrisp (hk) для GPU Apple, Turnip для GPU Qualcomm, PanVK для GPU ARM Mali, в программном растеризаторе lavapipe (lvp) и в режиме эмулятора (vn). В драйверах v3dv (GPU Broadcom VideoCore для Raspberry Pi 4+) и dzn (реализация Vulkan поверх Direct3D 12) поддерживается Vulkan 1.0, в драйвере kk (KosmicKrisp, Vulkan поверх Metal) - Vulkan 1.1, а драйвере pvr (GPU Imagination PowerVR) - Vulkan 1.2.
В Mesa также обеспечивается полная поддержка OpenGL 4.6 для драйверов iris (GPU Intel Gen 8+), radeonsi (AMD), Crocus (старые GPU Intel Gen4-Gen7), AMD (r600), zink, llvmpipe, virgl (виртуальный GPU Virgil3D для QEMU/KVM), freedreno (Qualcomm Adreno), d3d12 (прослойка для организации работы OpenGL поверх DirectX 12) и asahi (GPU AGX, используемый в чипах Apple M1 и M2). Поддержка OpenGL 4.5 доступна для GPU NVIDIA (nvc0). Поддержка OpenGL 3.3 присутствует в драйверах softpipe (программный растеризатор) и nv50 (NVIDIA NV50). В драйверах panfrost (GPU ARM Mali) и v3d (GPU Broadcom VideoCore) поддерживается OpenGL 3.1.
Драйвер RadeonSI переведён на использование по умолчанию промежуточного представления (IR) шейдеров NIR и бэкенда компиляции шейдеров ACO, развиваемого компанией Valve в качестве альтернативы компилятору шейдеров LLVM. Бэкенд ACO нацелен на обеспечение генерации кода, насколько это возможно, оптимального для шейдеров игровых приложений, а также на достижение очень высокой скорости компиляции. Применение ACO даёт возможность повысить скорость компиляции шейдеров, снизить потребление памяти, сократить размер бинарного представления шейдеров и генерировать более оптимизированный код. По сравнению с LLVM применение бэкенда ACO позволило до 8 раз снизить время компиляции шейдеров, что заметно сокращает время запуска программ.
Представлен Vulkan-драйвер KosmicKrisp (kk), реализующий графический API Vulkan поверх API Metal, развиваемого компанией Apple и применяемого в macOS. Драйвер создан компанией LunarG для использования на компьютерах Mac с чипами Apple Silicon.
В Vulkan-драйвере RADV (GPU AMD) значительно повышена производительность трассировки лучей.
В переменной окружения RADV_DEBUG прекращена поддержка устаревших опций invariantgeom, nodynamicbounds, nongg_gs и splitfma вместо которых в driconf следует использовать переменные radv_invariant_geom, radv_no_dynamic_bounds, radv_disable_ngg_gs и radv_split_fma.
После трёх лет с момента публикации ветки 2.6 подготовлен релиз OpenVPN 2.7.0, пакета для создания виртуальных частных сетей, позволяющего организовать шифрованное соединение между двумя клиентскими машинами или обеспечить работу централизованного VPN-сервера для одновременной работы нескольких клиентов. Код OpenVPN распространяется под лицензией GPLv2, готовые бинарные пакеты формируются для Debian, Ubuntu, CentOS, RHEL и Windows.
На VPN-серверах появилась возможность открытия нескольких принимающих соединения сокетов, например, для одновременного приёма соединений через UDP и TCP или по разным сетевым портам.
Осуществлён переход на использование новой версии DCO-модуля, включённого в основной состав ядра Linux 6.16. Входящий в основной состав ядра модуль имеет изменённый API и поставляется под именем "ovpn". Поддержка старого модуля ovpn-dco прекращена. Модуль выносит операции шифрования, обработки пакетов и управления каналом связи на сторону ядра Linux и позволяет избавиться от накладных расходов, связанных с переключением контекста, даёт возможность оптимизировать работу за счёт прямого обращения к внутренним API ядра и исключает медленную передачу данных между ядром и пространством пользователя (шифрование, расшифровка и маршрутизация выполняется модулем без отправки трафика в обработчик в пространстве пользователя).
В версии для Windows: в WFP-фильтрах активирован флаг block-local; обеспечена генерация дополнительных сетевых интерфейсов по мере необходимости; обеспечен запуск автоматических сервисов под непривилегированным пользователем; для работы с настройками DNS задействован NRPT (Name Resolution Policy Table); разрешено использования драйвера win-dco для ускорения VPN-серверов.
Представлен новый формат ключей и пакетов "epoch", который в отличие от стандартного формата "DATA_V2" добавляет тег AEAD в конец пакета, автоматически обновляет ключи при достижении лимита их использования, имеет 64-разрядные идентификаторы пакетов, использует операцию XOR при формировании вектора инициализации.
Добавлена поддержка lwipovpn - эмулятора сетевых интерфейсов tun/tap в пространстве пользователя, реализованного на базе TCP/IP стека lwIP.
При помощи опции "--dev-node unix:/path/to/lwipovpn" можно эмулировать полноценный VPN-клиент на той же системе для тестирования и отладки OpenVPN.
Добавлена возможность обновлять часть настроек клиента (IP, маршрутизация, MTU, DNS) через отправку сервером управляющих сообщений PUSH_UPDATE.
В openVPN-клиент для Linux, BSD и macOS добавлена опция "--dns-updown" для запуска скрипта применения настроек DNS, переданных сервером. Скрипт поддерживает настройку через /etc/resolv.conf, systemd или resolveconf.
Для платформы Linux добавлена опция "--route-table" для использования заданных пользователем таблиц маршрутизации.
Реализована поддержка ветки mbedTLS 4. Добавлена поддержка TLS 1.3 в конфигурациях с криптографической библиотекой mbedTLS.
Добавлена поддержка операционной системы Haiku.
Прекращена поддержка режима работы со статическими ключами (следует использовать режим TLS), NTLMv1, Windows-драйвера wintun, OpenSSL 1.0.2, mbedTLS 2.x, сжатия данных перед отправкой, опций "--memstats" и "--opt-verify".
Компании Google и Intel раскрыли результаты (PDF) совместной работы по аудиту безопасности механизма Intel TDX 1.5 (Trusted Domain Extensions). Технология Intel TDX реализует возможность шифрования памяти виртуальных машин для их защиты от вмешательства и анализа со стороны администратора хост-системы и физических атак на оборудование. В результате аудита выявлено 6 уязвимостей и 35 не влияющих на безопасность ошибок.
Проблемы затрагивают CPU Intel Xeon 6, а также 4 и 5 поколений процессоров Intel Xeon Scalable. Уязвимости устранены во вчерашнем обновлении микрокода. На GitHub опубликован инструментарий для эксплуатации уязвимостей в Intel TDX и прототипы эксплоитов для двух уязвимостей (CVE-2025-30513, CVE-2025-32007).
Наиболее опасная уязвимость (CVE-2025-30513) позволяет не заслуживающему доверия администратору, имеющему доступ к хост-системе, добиться повышения своих привилегий и полностью скомпрометировать гарантии безопасности, предоставляемые технологией Intel TDX. Уязвимость вызвана состоянием гонки в одном из модулей TDX, позволяющим в момент миграции виртуальной машины перевести защищённое окружение (TD - Trusted Domain) из состояния поддерживающего миграцию в состояние, допускающее перевод в отладочный режим.
Проблема вызвана возможностью подмены атрибутов окружения в момент после прохождения их проверки, но до их перевода в неизменяемое состояние в перенесённом окружении. После выставления отладочного атрибута, администратор хост-системы может в режиме реального времени отслеживать активность защищённой гостевой системы и получить доступ к расшифрованному состоянию памяти.
Уязвимость достаточно проста для эксплуатации, так как администратор в любой момент может инициировать процесс live-миграции защищённой виртуальной машины. Проблема была выявлена исследователями из компании Google, которые в ходе изучения API обратили внимание на несоответствие между тем, как в FSM (Finite State Machine) отслеживается состояние операций, обрабатывается прерывание операции импорта и изменяется, но не возвращается в исходное значение после сбоя, состояние защищённого окружения.
Менее опасные уязвимости:
CVE-2025-32007 - целочисленное переполнение в коде разбора метаданных, приводящее в процессе live-миграции к утечке 8 КБ расшифрованных данных из стека текущего логического процессора (LP, Logical Processor).
CVE-2025-32467 - использование неинициализированных переменных в некоторых модулях TDX может привести к утечке остаточной информации.
CVE-2025-27572 - оседание конфиденциальных данных в ходе спекулятивного выполнения инструкций может привести к утечке информации.
CVE-2025-27940 - чтение из области памяти вне выделенного буфера может привести к утечке информации.
CVE-2025-31944 - состояние гонки, способное привести к отказу в обслуживании.
После шести месяцев разработки представлен релиз языка программирования Go 1.26, развиваемого компанией Google при участии сообщества. Язык сочетает высокую производительность, свойственную компилируемым языкам, с такими достоинствами скриптовых языков, как простота написания кода, высокая скорость разработки и защита от ошибок. Код проекта распространяется под лицензией BSD.
Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Оберон. Язык достаточно лаконичен, но при этом код легко читается и воспринимается. Код на языке Go компилируется в обособленные бинарные исполняемые файлы, выполняемые нативно, без использования виртуальной машины (модули профилирования, отладки и другие подсистемы выявления проблем на этапе выполнения интегрируются в виде runtime-компонентов), что позволяет добиться производительности, сопоставимой с программами на языке Си.
Проект изначально разрабатывается с оглядкой на многопоточное программирование и эффективную работу на многоядерных системах. Например, на уровне операторов реализованы средства для организации параллельных вычислений и взаимодействия между параллельно выполняемыми методами. Язык также предоставляет встроенные средства защиты от выхода за границы буфера и обеспечивает возможность использования сборщика мусора.
Включён по умолчанию сборщик мусора "greenteagc", рассчитанный на повышения производительности создания и сканирования мелких объектов. В приложениях, в которых активно применяется сборка мусора, при использовании "greenteagc" отмечается сокращение накладных расходов на сборку мусора на 10-40%.
Во встроенной функции new(), предназначенной для создания новых переменных, появилась возможность указания выражения в качестве операнда, определяющего начальное значение переменной. Например, вместо кода
x := int64(300)
ptr := &x
теперь можно писать:
ptr := new(int64(300))
В обобщённых типах (generic) разрешено ссылаться на самого себя в качестве аргумента в списке собственных параметров типа (можно передать тип в свой же параметр). В первой строке показанного ниже примера ссылка Adder на самого себя теперь не приводит к выводу ошибки:
type Adder[A Adder[A]] interface {
Add(A) A
}
func algo[A Adder[A]](x, y A) A {
return x.Add(y)
}
Накладные расходы при вызове функций на языке Си из кода на языке Go при помощи cgo снижены примерно на 30%.
В runtime на 64-разрядных платформах реализована рандомизация адресного пространства при запуске, что усложняет предсказание адресов в памяти при попытках эксплуатации уязвимостей в Си-коде, задействованном через cgo. Для отключения рандомизации предложена опция "GOEXPERIMENT=norandomizedheapbase64".
Расширено число ситуаций, в которых компилятор выделяет память для слайсов в стеке, а не в куче, что положительно сказывается на производительности.
Реализация команды "go fix" полностью переписана с использованием пакета analysis, предоставляющего функциональность для статистического анализа кода.
Добавлена поддержка доступных в пакете modernize анализаторов, предлагающих правки для упрощения кода с учётом новых возможностей языка и стандартной библиотеки. Добавлен анализатор "inline" для inline-развёртывания всех вызовов функций, помеченных директивой "//go:fix inline".
Добавлен экспериментальный пакет simd/archsimd, предоставляющий низкоуровневый доступ к выполнению векторных операций с использованием инструкций SIMD на системах с архитектурой AMD64.
Добавлен экспериментальный пакет runtime/secret для безопасной очистки (обнуления) временной памяти, выделенной при выполнении указанной функции.
В пакет runtime/pprof добавлен экспериментальный профиль goroutineleak для выявления утечек сопрограмм (goroutine).
На конференции FOSDEM представлен новый игровой движок Fluorite, развиваемый американским подразделением компании Toyota, отвечающим за разработку автомобильных информационно-развлекательных систем. Движок нацелен на предоставление возможностей, пригодных для создания 3D-игр уровня игровых консолей, и развивается с использованием технологий, применяемых Toyota в своём новом стеке для информационно-развлекательных систем, уже поставляемом в автомобиле Toyota RAV4 2026. Заявлено, что движок будет кросс-платформенным и полностью открытым.
Создание проекта объясняется желанием получить полнофункциональный игровой движок, интегрируемый с интерфейсами на базе Flutter и пригодный для использования на автомобильных информационно-развлекательных системах и встраиваемых устройствах, типа Raspberry Pi 5. До начала работы рассматривалась возможность задействования существующих игровых движков для создания интегрированного в автомобили игрового окружения. Движки Unity и Unreal были отброшены, как ресурсоёмкие, завязанные на бинарные блобы и требующие лицензионных отчислений. Godot не подошёл из-за большого потребления ресурсов и слишком длительного запуска на встраиваемых устройствах. Impeller и Flutter_GPU были отвергнуты из-за сырого API и проблем с поддержкой Linux (в Toyota IVI применяется Yocto Linux и собственный графический интерфейс на базе Wayland и Flutter).
Движок Fluorite интегрируется с фреймворком Flutter и позволяет разрабатывать игры на языке Dart, используя виджет FluoriteView для одновременного отображения разных представлений 3D-сцены и возможности Flutter для бесшовной интеграции игр с графическим окружением IVI-платформы, контроля за 3D-сценой из Flutter-виджетов и организации интерактивного взаимодействия. Имеется возможность создания интерактивных трёхмерных интерфейсов через определение в 3D-модели кликабельных зон, при клике на которые вызываются привязанные обработчики событий, по аналогии с событиями onClick на web-страницах.
Для достижения высокой производительности и низкого потребления ресурсов движок построен на базе архитектуры ECS (Entity-Component-System) и использует низкоуровневые компоненты на языке C++, поверх которых реализованы обвязки для создания игровой логики на языке Dart. Для отрисовки задействованы библиотека SDL3 и движок 3D-рендеринга Google Filament, поддерживающий физически корректный рендеринг (PBR). В планах интеграция движка симуляции физических процессов JoltPhysics.
Из особенностей упоминается поддержка изменения на лету 3D-сцены без перезапуска приложения (Hot Reload), задействование графического API Vulkan для аппаратно ускоренной графики, применение эффектов постпроцессинга, подключение собственных шейдеров, физически корректная модель освещения, возможность разработки 3D-моделей в Blender и поддержка форматов GLTF, GLB, KTX и HDR.