Отчёт о состоянии работ FreeBSD за первый квартал 2026

Ссылки:
Фонд FreeBSD URL: https://freebsdfoundation.org/
Технологическая дорожная карта URL: https://freebsdfoundation.org/blog/technology-roadmap/
Пожертвовать URL: https://freebsdfoundation.org/donate/
Программа партнёрства Фонда URL: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/
Журнал FreeBSD URL: https://freebsdfoundation.org/journal/
Мероприятия Фонда URL: https://freebsdfoundation.org/our-work/events/

Контакт: Deb Goodkin <deb@FreeBSDFoundation.org>

Фонд FreeBSD — некоммерческая организация 501(c)(3), занимающаяся развитием FreeBSD как через техническую, так и через нетехническую поддержку. Финансируемый исключительно за счёт пожертвований, Фонд поддерживает разработку программного обеспечения, инфраструктуру, безопасность и совместную работу; организует мероприятия и саммиты разработчиков; предоставляет образовательные ресурсы; и представляет проект FreeBSD в юридических вопросах.

Ссылки:
Объявление о FreeBSD 14.4-RELEASE URL: https://www.freebsd.org/releases/14.4R/announce/
Расписание FreeBSD 15.1-RELEASE URL: https://www.freebsd.org/releases/15.1R/schedule/
Релизы FreeBSD URL: https://download.freebsd.org/releases/ISO-IMAGES/
Разработочные снимки FreeBSD URL: https://download.freebsd.org/snapshots/ISO-IMAGES/

Контакт: Команда подготовки релизов FreeBSD <re@FreeBSD.org>

Команда подготовки релизов FreeBSD отвечает за установление и публикацию графиков релизов официальных выпусков FreeBSD, объявление заморозок кода и поддержание соответствующих веток, среди прочего.

Команда выполняла работы по выпуску 14.4-RELEASE, что привело к официальной сборке RELEASE и объявлению в марте. Началось планирование предстоящего 15.1-RELEASE, который должен выйти в июне.

В команду вошли четыре новых участника: Серхио Карлавилья Дельгадо (Sergio Carlavilla Delgado), Крейг Лерес (Craig Leres), Владлен Пополитов и Александр Зияи (Alexander Ziaee), а двое участников покинули команду: Джейк Фриленд (Jake Freeland) и Махди Мохтари (Mahdi Mokhtari). Мы благодарим их за их вклад.

Команда подготовки релизов продолжила предоставлять еженедельные промежуточные сборки для веток main, stable/15, stable/14 и stable/13. Обратите внимание, что еженедельные промежуточные сборки для stable/13 прекратятся, когда эта ветка достигнет конца своего жизненного цикла в конце апреля.

Ссылки:
О портах FreeBSD URL:https://www.FreeBSD.org/ports/
Вклад в порты URL: https://docs.freebsd.org/en/articles/contributing/#ports-contributing
Команда управления портами URL: https://www.freebsd.org/portmgr/
Tar-архив портов URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/

Контакт: Команда управления портами FreeBSD <portmgr@FreeBSD.org>

Команда управления портами отвечает за общее направление развития дерева портов, сборку пакетов и кадровые вопросы. Ниже описано, что произошло в последнем квартале.

В течение последнего квартала мы приветствовали Юсуфа Ямана (Yusuf Yaman, nxjoseph), Косукэ Каннаги (Kousuke Kannagi, mce), Петра Смырака (Piotr Smyrak, smyru), Лорана Шардона (Laurent Chardon, laurent) и Кеннета Рэпли (Kenneth Raplee, kenrap) в качестве новых коммиттеров портов и попрощались с одним коммиттером.

Согласно INDEX, в настоящее время в Коллекции портов насчитывается 37 958 портов (выросло с 37 163). В настоящее время открыто около 2 710 PR по портам (снизилось с 3 428), из которых 798 (снизилось с 821) не назначены. За последний квартал было совершено 8 970 коммитов (выросло с 8 738) от 166 коммиттеров (выросло с 156) в основной ветке и 697 коммитов (снизилось с 898) от 59 коммиттеров (снизилось с 61) в ветке 2026Q1.

Наиболее активные коммиттеры в основной ветке: 2135 sunpoet@FreeBSD.org 800 yuri@FreeBSD.org 528 vvd@FreeBSD.org 312 bofh@FreeBSD.org 294 tagattie@FreeBSD.org 182 nivit@FreeBSD.org 177 arrowd@FreeBSD.org 175 eduardo@FreeBSD.org 153 fuz@FreeBSD.org 132 mfechner@FreeBSD.org

За последние три месяца в дереве портов произошло много событий, вот выдержка из основных обновлений программного обеспечения:

В течение последнего квартала pkgmgr@ провёл 29 экспериментальных сборок (exp-run) для тестирования различных изменений в базовой системе и обновлений портов.

Ссылки:
Члены команды Cluster Administration URL: https://www.freebsd.org/administration/#t-clusteradm

Контакт: Команда администраторов кластера <clusteradm@FreeBSD.org> Контакт: Philip Paeps <philip@FreeBSD.org>

Члены команды администраторов кластера FreeBSD отвечают за управление машинами, на которых проект FreeBSD обеспечивает синхронизацию своей распределённой работы и коммуникаций.

В этом квартале команда работала над следующим:

Ссылки:
FreeBSD Bugzilla URL: bugs.freebsd.org/

Контакт: Bugmeister <bugmeister@FreeBSD.org>

Команда Bugmeister отвечает за то, чтобы программное обеспечение для работы с отчётами о проблемах (Problem Report) функционировало корректно, записи были правильно классифицированы и не содержало недействительных записей.

Мы завершаем квартал с 9548 открытыми PR, что немного выше по каждой категории по сравнению с этим временем в прошлом году. БОльшую часть времени в этом квартале мы потратили на приветствие новых контрибьюторов перед предоставлением им учётной записи. Мы считаем, что это идёт очень хорошо и привело к повышению активности и качества заявок, но мы полагаем, что в команде могло бы быть ещё несколько человек.

Мы приветствовали нового члена команды Triage, Саймона Воллваге (Simon Wollwage), который с любовью просматривал базу данных, обновлял патчи и был добр к контрибьюторам. Благодаря его усилиям множество отчётов было закрыто или их основные проблемы были исправлены, и мы благодарим его.

Мы завершили обновление документации, в которой теперь требуется, чтобы предлагаемые изменения отправлялись в виде патчей в формате git. Это сэкономит время, повысит безопасность и позволит правильно передавать метаданные автора. Если мы где-то что-то упустили, пожалуйста, сообщите нам.

См. также: https://wiki.freebsd.org/Bugzilla/SearchQueries

Ссылки:
Готовность к Закону о киберустойчивости URL: https://github.com/FreeBSDFoundation/all-projects/tree/main/Cyber%20Resilience%20Act%20Readiness

Фонд реализует проект в течение 2026 года для активной подготовки Фонда FreeBSD, Проекта и сообщества к Закону о киберустойчивости (Cyber Resilience Act) ЕС. Выделено шесть основных направлений: Безопасность и обработка уязвимостей, Инструментарий SBOM, Публичная документация, Взаимодействие с законодателями в сообществе, Публичный репозиторий проекта и Коммуникации.

За февраль и март проект перешёл от планирования к активной реализации. Теперь проводятся внутренние еженедельные координационные встречи, и привлечённый Фондом руководитель по безопасности Пьер Проншери (Pierre Pronchery) присоединился к команде безопасности FreeBSD, чтобы более тесно согласовать работу проекта с существующими процессами безопасности Проекта FreeBSD.

Что касается взаимодействия с регулирующими органами, Фонд совместно подписал письмо Open Source Initiative Европейской комиссии в поддержку добровольной аттестации безопасности, внёс вклад в отзыв Eclipse Foundation о проекте рекомендаций CRA, а также посетил FOSDEM и FOSS Backstage для сотрудничества с другими сообществами открытого исходного кода, осваивающими CRA.

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

Ссылки:
pkgbasify URL: https://github.com/FreeBSDFoundation/pkgbasify

Контакт: Isaac Freund <ifreund@freebsdfoundation.org>

Скрипт pkgbasify используется для преобразования систем FreeBSD, не использующих pkgbase, в системы, использующие pkgbase.

В прошлом квартале я внёс несколько улучшений в вышестоящий пакет pkg, что позволило pkgbasify стать как проще, так и надёжнее. В то же время зависимость pkgbasify от базы данных etcupdate в /var/db/etcupdate/current теперь может быть устранена, что делает pkgbasify гораздо более гибким.

Эти улучшения станут доступны конечным пользователям после выпуска pkg 2.7.

Спонсор: Фонд FreeBSD

Ссылки:
Alpha-Omega — Проект Linux Foundation URL: https://alpha-omega.dev
Alpha-Omega на GitHub URL: https://github.com/ossf/alpha-omega
Фонд FreeBSD URL: https://freebsdfoundation.org
Репозиторий проекта от Фонда FreeBSD URL: https://github.com/FreeBSDFoundation/alpha-omega-beach-cleaning

Контакт: Pierre Pronchery <pierre@freebsdfoundation.org>

Миссия Alpha-Omega — стимулировать устойчивые улучшения безопасности критически важных проектов с открытым исходным кодом и экосистем. После успешного проекта с Фондом FreeBSD в 2024 году (аудит гипервизора bhyve и фреймворка изоляции Capsicum) Alpha-Omega снова выбрала FreeBSD — на этот раз для проекта Alpha Omega Beach Cleaning. Этот новый грант направлен на общее повышение безопасности и сопровождаемости стороннего программного обеспечения в базовой системе FreeBSD. Фонд FreeBSD получил грант, а также управлял и выполнял проект. Официально проект завершён 30 марта 2026 года.

После предыдущего отчёта за 2025Q4 были определены две основные цели:

Обе цели близки к завершению, и они были публично представлены на AsiaBSDCon 2026 на Тайване, как в ходе Саммита разработчиков FreeBSD, так и на сессии Work-in-Progress конференции.

Ежемесячные отчёты направлялись в alpha-omega и доступны, как и прежде, на GitHub: за 2025 год и за 2026 год.

Спонсоры: Alpha-Omega, Фонд FreeBSD

Ссылки:
spdxtool: Добавление параметра для использования URI в качестве идентификатора SPDX URL: https://github.com/pkgconf/pkgconf/pull/484
spdxtool: Добавление параметра командной строки для изменения идентификатора SPDX URL: https://github.com/pkgconf/pkgconf/pull/483
spdxtool: Добавление обработки домашней страницы URL: https://github.com/pkgconf/pkgconf/pull/475
spdxtool: Добавление обработки исходного кода в SBOM URL: https://github.com/pkgconf/pkgconf/pull/474
spdxtool: Добавление поддержки текста авторских прав URL: https://github.com/pkgconf/pkgconf/pull/473
spdxtool: Переработка вычисления выражений License-tag SDPX URL: https://github.com/pkgconf/pkgconf/pull/461
Добавление более строгих предупреждений компилятора и устранение новых предупреждений URL: https://github.com/pkgconf/pkgconf/pull/450
libpkgconf/libpkgconf.h: Добавление атрибутов, подобных printf, к функциям URL: https://github.com/pkgconf/pkgconf/pull/447
spdxtool: Обновление переменных, которые являются const, до const URL: https://github.com/pkgconf/pkgconf/pull/446
man/spdxtool.1: Добавление справочной страницы для spdxtool URL: https://github.com/pkgconf/pkgconf/pull/445
Добавлены идентификаторы SPDX-License-Identifier URL: https://cgit.freebsd.org/src/log/?qt=author&q=Tuukka+Pasanen
Идентификаторы SPDX-License-Identifier на рассмотрении и ожидают передачи в вышестоящий репозиторий URL: https://github.com/freebsd/freebsd-src/compare/main…​illuusio:freebsd-src:update-spdx-licenses
Открытая проблема для комментариев и рецензирования: caesar: Добавление тегов SPDX-License-Identifier URL: https://reviews.freebsd.org/D55461
Файл .pc для метаданных SBOM (разработка) URL: https://github.com/illuusio/freebsd-src/tree/sbom-pkgconfig/release/sbom

Контакт: Tuukka Pasanen <tuukka.pasanen@ilmi.fi>

Проект «Спецификация программных компонентов FreeBSD (SBOM)» начался в 2025 году и продолжился в 2026 году. Работа в 2026 году была больше сосредоточена на Законе о киберустойчивости (CRA) ЕС, и усилия сместились в сторону предоставления фреймворка для исходного кода FreeBSD.

В первом квартале 2026 года работа по SBOM была выполнена в трёх категориях:

Если вы хотите помочь в этих усилиях:

Спонсор: Фонд FreeBSD

Ссылки:
URL проекта URL: https://freebsdfoundation.github.io/freebsd-laptop-testing/
Репозиторий на GitHub URL: https://github.com/FreeBSDFoundation/freebsd-laptop-testing

Контакт: Shreeney Ajmeri <shreeney@freebsdfoundation.org>

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

В рамках проекта Фонда FreeBSD «Поддержка ноутбуков и удобство использования» этот рабочий процесс будет очень полезен для потенциальных пользователей FreeBSD, которые хотят протестировать свои ноутбуки, чтобы узнать, насколько хорошо они поддерживаются. Он также помогает покупателям, которые хотят приобрести ноутбук, заведомо хорошо поддерживаемый FreeBSD.

Основная цель — объединить всю информацию о совместимости FreeBSD с ноутбуками в одну центральную базу знаний, на которую сможет ссылаться сообщество.

В течение этого квартала были выполнены следующие пункты:

Кроме того, в течение этого квартала проводилось обширное тестирование:

Другие заметки:

Спонсор: Фонд FreeBSD

Ссылки:
Задача проекта «Поддержка ноутбуков и удобство использования» URL: https://github.com/FreeBSDFoundation/proj-laptop/issues/25
Репозиторий проекта URL: https://gitlab.com/alfix/kde-installer-dialogs

Контакт: Alfonso Sabato Siciliano <asiciliano@FreeBSD.org>

В прошлом я разработал несколько shell-скриптов с графическими интерфейсами для установки и настройки полноценного окружения рабочего стола на своём ноутбуке. Эти интерфейсы позволяли пользователям выбирать предпочитаемые ими опции. Один из скриптов, в частности, включал драйверы GPU, окружения рабочего стола и инструменты как для ноутбуков, так и для настольных систем. Эти проекты всё ещё доступны в публичных онлайн-репозиториях, но теперь они, вероятно, устарели, поскольку не использовались и не сопровождались в течение нескольких лет.

Недавно Фонд FreeBSD запустил проект «Поддержка ноутбуков и удобство использования» (Laptop Support and Usability Project). Одной из краткосрочных целей этого проекта является предоставление простой возможности в bsdinstall(8) (установщике системы FreeBSD) для установки и настройки графического окружения. Установщик должен спрашивать пользователей, хотят ли они установить окружение рабочего стола, и если да — автоматически устанавливать и настраивать всё необходимое с минимальным или нулевым вмешательством пользователя. После перезагрузки пользователям должен быть представлен графический экран входа в систему KDE Plasma.

Для реализации этой возможности я повторно использовал один из своих предыдущих скриптов в качестве подтверждения концепции. Он был обновлён, упрощён и переименован в desktop. Скрипт устанавливает и настраивает драйверы GPU, Xorg, KDE Plasma и SDDM. Основываясь на полученных отзывах, я внёс несколько улучшений по сравнению с оригинальной версией:

В будущем, в зависимости от интереса пользователей и отзывов, поддержка может быть расширена на другие окружения рабочего стола и инструменты.

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

Версия скрипта позже была адаптирована для интеграции в bsdinstall и в установочный ISO-образ. После успешного тестирования как на CURRENT, так и на STABLE была отправлена рецензия на добавление скрипта desktop в bsdinstall: D56167.

Спонсор: Фонд FreeBSD

Ссылки:
Bhyvemgr URL: https://github.com/alonsobsd/bhyvemgr/

Контакт: José Alonso Cárdenas Márquez <acm@FreeBSD.org>

Bhyvemgr — это графический интерфейс управления bhyve, написанный на Freepascal/Lazarus во FreeBSD. Для работы ему требуется набор инструментов, в основном установленных в базовой системе, а некоторые устанавливаются из портов/пакетов. Основная цель — создать настольное приложение, ориентированное на пользователей рабочих станций, позволяющее легко и быстро настраивать и запускать виртуальные машины на хостах FreeBSD.

В течение этого квартала в Bhyvemgr было сделано множество исправлений ошибок и улучшений.

Вот некоторые основные добавленные улучшения:

Bhyvemgr поддерживает aarch64 на версиях от 15.x до 16-CURRENT и amd64 на версиях FreeBSD от 14.x до 16-CURRENT. Его можно скомпилировать или установить из портов или пакетов с поддержкой интерфейса gtk2, qt5 или qt6.

Приветствуются люди, заинтересованные в помощи или поддержке проекта.

Текущая версия: 1.13.1

Спонсор: https://paypal.me/alonsocbsd

Контакт: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>

Ссылки:
Веб-сайт URL: https://sylve.io
GitHub URL: https://github.com/AlchemillaHQ/Sylve
CI URL: https://sylve-ci.alchemilla.io
Discord URL: https://discord.gg/bJB826JvXK

Контакт: Hayzam Sherif <hayzam@alchemilla.io>

Sylve — это современная унифицированная платформа управления системой для FreeBSD. Она предоставляет интегрированный веб-интерфейс для управления виртуальными машинами (через Bhyve), Jail, сетями вокруг них и хранилищами ZFS.

Бэкенд реализован на Go, а фронтенд построен на Svelte. Проект делает акцент на минимальном системном следе. По умолчанию он не требует никаких пакетов, кроме базовой системы.

В конце этого квартала мы выпустили наш первый релиз Sylve v0.1.0, и на момент написания этой статьи мы находимся на версии v0.2.3.

Опциональные зависимости времени выполнения, необходимые только при использовании соответствующих функций, включают:

Порт подтягивает эти зависимости для удобства пользователя, но сам по себе Sylve не требует никаких зависимостей для работы.

Ссылки:
AppJail на GitHub URL: https://github.com/DtxdF/AppJail
AppScript на GitHub URL: https://github.com/DtxdF/appscript
x11appjail на GitHub URL: https://github.com/DtxdF/x11appjail

Контакт: Jesús Daniel Colmenares Oviedo <dtxdf@FreeBSD.org>

AppJail — это open-source фреймворк под лицензией BSD-3, полностью написанный на POSIX-совместимом shell и C, предназначенный для создания изолированных, переносимых и простых в развёртывании окружений с использованием клеток (jail) во FreeBSD, которые ведут себя как приложения.

AppScript — это очень лёгкий и простой в использовании инструмент для создания самодостаточных исполняемых файлов.

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

Клетки — это реализация виртуализации на уровне ОС для FreeBSD. С помощью клетки можно легко ограничить множество аспектов: ограничение ресурсов, ограничение доступа к устройствам /dev, ограничение файловой системы, ограничение сети и многие другие. Всё это прозрачно для приложения, работающего внутри клетки. Однако одна проблема, особенно с X11-приложениями, — это отсутствие изоляции. Пользователи часто используют трюк с xhost +, чтобы запустить X11-приложение внутри клетки и отобразить его на X-сервере хоста. Это создаёт угрозу безопасности, поскольку, даже если X11-приложение работает внутри клетки и даже если оно работает как непривилегированный процесс, оно может получить большое количество информации с хоста. Поэтому скомпрометированное приложение, приложение с уязвимостью или просто собирающее много информации в «телеметрических целях» может стать кошмаром при такой настройке и в худшем случае скомпрометировать хост.

Недавно в AppJail была добавлена новая команда для решения этой проблемы: appjail-x11(1). Эта команда запускает приложение внутри клетки, но отображает его на новом X-сервере, созданном Xephyr, который уже аутентифицирован с помощью MIT-MAGIC-COOKIE-1. Это гораздо проще и легковеснее, чем настраивать SSH-сервер внутри клетки, создавать для этого ключевую пару, подключаться к клетке и так далее. Однако эта команда не ограничивается только этим: вы можете изменять размер окна Xephyr, и ваше DE/WM будет соответствующим образом обновляться, поскольку эта команда способна обнаруживать такие изменения.

Однако, хотя с помощью этой команды уже многое достигнуто, пользователь должен установить DE/WM и приложение внутри клетки, а возможно, установить и пользовательский .desktop-файл на хосте. Это можно автоматизировать с помощью Makejails, и продвинутые пользователи справятся с этим, поскольку они любят всё настраивать, но для обычного пользователя (или даже для меня) я хотел распространять приложения так, чтобы пользователям не нужно было делать ничего, кроме как просто запустить приложение, и именно эту задачу призван решать x11appjail.

x11appjail — это репозиторий, содержащий предварительно написанные скрипты для развёртывания некоторых X11-приложений с использованием appjail-x11, который автоматизирует установку .desktop-файла, иконки, создание jail через Makejails, а также устанавливает разумные переменные окружения по умолчанию, которые можно легко изменить во время выполнения. Однако на самом деле репозиторий усугубляет проблему удобства использования: теперь пользователь должен клонировать репозиторий и получать обновления, чего может быть достаточно для некоторых пользователей, но я хотел добиться достаточно хорошего удобства использования приложения и возможности легко изолировать его в клетке. Поэтому я написал appscript, который создаёт SFX-файлы в формате ELF, и они автоматически создаются с каждым новым релизом этого репозитория благодаря GitHub workflow.

Спонсор: https://www.patreon.com/appjail

Ссылки:
Daemonless URL: https://daemonless.io

Контакт: Michael Johnson <ahze@ahze.net> Контакт: Jesús Daniel Colmenares Oviedo <dtxdf@FreeBSD.org>

Daemonless — это коллекция нативных для FreeBSD OCI-образов, которые работают непосредственно на ядре FreeBSD. Он объединяет мощь и безопасность клеток (jail) с современной экосистемой контейнеров — совместим с Podman, AppJail или любой средой выполнения, соответствующей OCI. Без необходимости в виртуальных машинах Linux или дополнительных накладных расходах.

Особенности:

Наш парк образов насчитывает более 60 образов — от медиа-менеджеров, таких как Radarr, Sonarr, Prowlarr, Lidarr, Readarr, Bazarr и Jellyfin, до загрузчиков вроде SABnzbd и Transmission, а также инфраструктурного программного обеспечения, такого как nginx, Vaultwarden, Smokeping и OpenSpeedTest. У нас есть даже полный стек для Immich!

Все эти образы были созданы с помощью https://daemonless.io/guides/dbuild/ — основного движка сборки проекта Daemonless, который недавно был портирован. Он предоставляет унифицированный интерфейс для сборки, тестирования и публикации OCI-образов контейнеров FreeBSD, обеспечивая согласованность между локальной разработкой и CI/CD-средами.

В дополнение к развёртыванию OCI-контейнеров с использованием Podman и Podman-Compose, недавно стало возможным использовать https://github.com/DtxdF/AppJail и https://github.com/DtxdF/director в качестве альтернатив благодаря их совместимости с OCI.

Ссылки:

Статья о бенчмарке ядра URL: https://github.com/Humanoid-Human/fbsd-work/blob/main/kernel-benchmark.md
Обсуждение MAINTAINERS в srcmgr URL: https://github.com/freebsd/srcmgr/issues/21
Pull request для MAINTAINERS URL: https://github.com/freebsd/freebsd-src/pull/2107
Конвертер pkg в набор дистрибутива URL: https://github.com/Humanoid-Human/fbsd-work/pull/1

Контакт: Trevor Xu <trevorxu5@gmail.com>

Моя работа в этом квартале была разделена между тремя проектами.

Ссылки:
Мета-задача LLVM URL: https://github.com/llvm/llvm-project/issues/180061

Контакт: Minsoo Choo <minsoochoo0122@proton.me>

Из-за проблем с лицензированием GDB (GPLv3), FreeBSD использует LLVM, включая LLDB, в своей базовой системе начиная с FreeBSD 10.0. Однако большинство разработчиков ядра по-прежнему полагаются на KGDB (патченную версию последнего GDB) для отладки ядра. Это отчасти связано с личными предпочтениями (некоторые считают синтаксис команд GDB более удобным), но есть и практические причины: LLDB не хватает нескольких функций, которые предоставляет KGDB (подробности ниже), и даже в базовой системе поддержка LLDB недостаточна. Моя работа направлена на достижение паритета функций с KGDB к концу апреля.

Улучшения, которые я сделал на данный момент, перечислены по ссылке выше. Обратите внимание, что мелкие исправления ошибок не включены в этот список.

Следующее не поддерживается: i386, arm, powerpc32, powerpc64be и mips*. FreeBSD 13 и более ранние версии также не поддерживаются. Целевая версия LLVM — 23, хотя эта работа может быть перенесена обратно в LLVM в дереве FreeBSD и main в stable/14 и stable/15 после того, как Димитрий Андрик (Dimitry Andric) завершит свой MFV (перенос от вендора) LLVM 21.

Я начал эту работу в конце января, и она, по прогнозам, будет завершена к апрелю. Помимо паритета функций, возможны дальнейшие улучшения, такие как поддержка minidump2elf и добавление UUID в заголовки ELF ядра и дампа памяти (core dump).

Самым большим препятствием для этого проекта является нехватка рецензентов, хорошо знакомых как с внутренним устройством FreeBSD, так и с внутренним устройством KGDB. Если у вас есть время, пожалуйста, оставляйте отзывы на мои pull request. Тестировщики на машинах, отличных от x86 и arm64, также очень приветствуются. Если вы обнаружите какие-либо проблемы, пожалуйста, сообщите об ошибке и свяжитесь со мной в llvm/llvm-project.

Спонсор: Фонд FreeBSD

Контакт: Konstantin Belousov <kib@FreeBSD.org>

FreeBSD давно предлагает средство «дескрипторов процессов» (Process Descriptors). Основное его использование — в песочницах Capsicum, где для работы с объектом требуется дескриптор, и дескриптор процесса предоставляет такой дескриптор. Другие операционные системы предоставляют аналогичное средство под тем же именем. Предлагаемый API был неполным, основным недостающим элементом был системный вызов pdwait(2), аналог семейства wait(2), который работает с дескриптором процесса вместо идентификатора процесса.

Описываемый проект добавил вызов pdwait(2). Другим важным дополнением стал вызов pdrfork(2), который обеспечивает такую же детальную поддержку создания копий процессов, как и rfork(2), но также возвращает дескриптор процесса в качестве дескриптора, подобно pdfork(2).

После добавления pdwait и pdrfork стали возможны естественные расширения для средств posix_spawn(3). Теперь атрибут posix_spawnattr_setprocdescp_np(3) требует, чтобы posix_spawn(3) возвращал дескриптор процесса. Другим естественным дополнением стал posix_spawnattr_setexecfd_np(3), который указывает исполняемый образ через дескриптор файла вместо имени.

В совокупности новые добавленные функции делают дескриптор процесса полным и позволяют использовать posix_spawn в песочницах.

Спонсор: Фонд FreeBSD

Контакт: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>

Я работал над специализированным драйвером для ноутбуков System76, и теперь он доступен в CURRENT.

На данный момент добавлена поддержка:

Единственное, что осталось сделать — переключение между dGPU и iGPU силами драйвера. Однако переключение возможно и без помощи драйвера.

Ссылки:
Блог URL: https://obiw.ac/s0ix/
Доклад на BSDCan о s2idle/S0ix URL: https://youtu.be/RCjPc4X2Edc
Образ для тестирования сна URL: https://people.freebsd.org/~obiwac/s0ix/
Рабочая ветка URL: https://github.com/obiwac/freebsd-s0ix/pull/15

Контакт: obiwac <obiwac@FreeBSD.org>

Приостановка-до-бездействия (suspend-to-idle) и поддержка сна S0ix находятся в процессе добавления во FreeBSD.

Это позволит современным ноутбукам Intel и AMD, некоторые из которых не поддерживают сон ACPI S3, переходить в состояния с низким энергопотреблением для увеличения времени автономной работы.

На данный момент большинство ревизий уже зафиксированы, включая новый драйвер acpi_spmc и поддержку s2idle. Единственное, что осталось добавить, — это поддержку приостановки USB4 и цикл s2idle (но это требует дополнительного обсуждения и исследования). Смотрите ревизии D52861 и D54410 соответственно.

Многие ошибки были исправлены, но всё ещё есть проблема, когда система иногда зависает через несколько секунд после возобновления работы. Было установлено, что проблема связана с тем, что NVMe-накопитель неправильно просыпается после приостановки — требуется дальнейшее расследование.

Начата работа над драйвером Intel PMC: D54881 Это уже позволяет считывать время пребывания в самом глубоком возможном состоянии S0ix на процессорах Intel.

Начата работа над новым общим интерфейсом управления питанием: D55508 Это необходимо, поскольку s2idle не является состоянием питания ACPI, и единственным (современным) механизмом для запросов перехода питания является интерфейс ioctl ACPI. Он ещё не зафиксирован, потому что мы можем в итоге изменить или даже удалить различие между типами сна и переходами состояний сна.

Спонсор: Фонд FreeBSD

Ссылки:
Код начального прототипа для сохранения образа системы URL: https://github.com/OlCe2/freebsd-src/tree/oc-hibernate
Дизайн-документ о загрузочной части процесса восстановления URL: https://hackmd.io/50ygFG3qSmqMOKytJMuOGw?both=

Контакт: Olivier Certner <olce@FreeBSD.org>
Контакт: Konstantin Belousov <kib@FreeBSD.org>

Ведётся работа по обеспечению поддержки гибернации (приостановки с сохранением состояния на диск) во FreeBSD без помощи BIOS/прошивки для сохранения текущего состояния машины для amd64-машин, загружаемых через UEFI.

Первым этапом было создание прототипа, который сохраняет образ системы, пока откладывая вопросы согласованности, чтобы можно было начать параллельную работу над EFI-приложением, предназначенным для восстановления и загрузки сохранённого образа (Константин Белоусов работает над этой частью). Этот этап был завершён в марте. Прежде чем этот экспериментальный код может быть зафиксирован, необходимо провести значительный рефакторинг, в частности нижележащей инфраструктуры дампов.

Следующий основной этап — обеспечение согласованности сохранённого образа системы, чтобы система была работоспособна после восстановления. Если кратко, самое большое ограничение здесь заключается в том, что мы должны гарантировать отсутствие незавершённого ввода-вывода по нескольким причинам, что состоит в том, чтобы сначала гарантировать, что больше не могут создаваться запросы ввода-вывода, а затем опустошить существующие запросы. В частности, текущие DMA-доступы могут изменять память в то время, как она сохраняется, что приводит к устаревшему кэшированию в сохранённом образе. Кроме того, если восстановление не удаётся (например, из-за какой-либо проблемы согласованности оборудования), ввод-вывод, который не достиг устойчивого хранилища, будет потерян, в то время как прикладной код или код файловой системы ожидали бы его фиксации (потеря согласованности). Мы начали идентифицировать подсистемы, требующие внимания, и анализировать, какие изменения в них необходимы (например, шина, GEOM, драйверы дисков).

Следующий этап — определить, как окончательно сохранить образ системы, не нарушая согласованности, поскольку сама эта операция изменяет память ядра. Первая высокоуровневая возможность — сделать снимок (snapshot) памяти после обеспечения стабильности, а затем возобновить нормальную работу, чтобы сохранить страницы в том состоянии, в котором они были на момент создания снимка. Существует несколько возможных уточнений, таких как упреждающее или ленивое копирование, с разными стратегиями реализации, а следовательно, характеристиками и требованиями. Преимущества создания снимка включают возможность использования обычного кода ядра для сохранения образа со всей поддержкой доступных преобразований. Недостатки — более высокое потребление памяти, хотя это сильно зависит от выбранной стратегии реализации и, по-видимому, в значительной степени смягчается, а также возможные некоторые сложности на очень низких уровнях ядра. Альтернатива, которая изучается, — не делать снимок, а вместо этого гарантировать, что отправка образа на диск изменяет только то состояние, которое будет эффективно сброшено при восстановлении. Эта альтернатива требует реализации выборочной приостановки (selective suspend), но в остальном мы ожидаем, что большая часть существующего кода дампа при панике (dump-on-panic) будет пригодна для повторного использования. В настоящее время мы изучаем различные варианты, чтобы лучше понять их осуществимость и связанные с ними компромиссы.

Спонсор: Фонд FreeBSD

Контакт: ShengYi Hung <aokblast@FreeBSD.org>
Контакт: Olivier Certner <olce@FreeBSD.org>

Совместное управление производительностью процессоров (Collaborative Processor Performance Control, CPPC) — это стандарт, представленный ACPI, позволяющий операционной системе управлять производительностью и, соответственно, эффективностью процессоров благодаря абстрактной шкале производительности, в общем случае не коррелирующей с простыми уровнями частоты и обеспечивающей более тонкую настройку, чем они. Intel и AMD уже несколько лет предоставляют реализации процессоров с поддержкой ACPI CPPC.

FreeBSD поддерживала включение CPPC, но только для процессоров Intel и позволяла управлять полезным, но очень ограниченным подмножеством его функциональности благодаря драйверу hwpstate_intel(4), добавленному в 2020 году. Автономный выбор целевой производительности аппаратным обеспечением в зависимости от рабочей нагрузки принудительно включён, и только основной соответствующий аппаратный параметр, называемый Efficiency/Performance Preference (EPP), доступен администратору через параметр sysctl(8).

Мы добавили поддержку реализации CPPC от AMD в существующий драйвер hwpstate_amd(4), который, в отличие от hwpstate_intel(4), до сих пор управлял только «обычными» P-состояниями. Драйвер предоставляет 4 параметра sysctl(8): минимальная производительность, максимальная производительность, желаемая производительность и EPP. Минимальная, максимальная и желаемая производительность — это значения от 0 до 255, но в зависимости от аппаратного обеспечения эффект может иметь только поддиапазон. Начальные значения минимальной и максимальной производительности устанавливаются равными границам эффективного поддиапазона в соответствии с указаниями платформы (если они доступны). Управление EPP служит для выражения предпочтения в сторону эффективности или производительности и представляет собой значение от 0 (максимальное предпочтение производительности) до 255 (максимальное предпочтение эффективности). Желаемая производительность может быть установлена на любое значение между минимальной и максимальной производительностью или на специальное значение 0 для включения аппаратного автономного выбора целевой производительности в зависимости от текущей рабочей нагрузки. Управление минимальной производительностью, максимальной производительностью и EPP применяется независимо от того, включён ли автономный выбор или указана конкретная желаемая производительность. Обратите внимание, что эффект каждой комбинации этих значений зависит от модели процессора, и мы уже смогли наблюдать сильно различающееся поведение на нескольких из них. Поэтому ожидайте, что вам придётся экспериментировать, чтобы найти значения, подходящие для ваших сценариев использования на конкретной машине.

hwpstate_amd(4) включён в ядро GENERIC (через cpufreq(4)) и использует CPPC, если процессоры поддерживают его, если только явно не указано иное (через параметр machdep.hwpstate_amd_cppc_enable). Следовательно, чтобы избежать регрессии производительности, на данный момент мы решили установить вышеупомянутые параметры управления на максимальную производительность, так как это поведение по умолчанию для традиционной поддержки P-состояний, а также для любого другого драйвера cpufreq(4), за исключением hwpstate_intel(4) (который в настоящее время принудительно включает аппаратный автономный выбор и устанавливает EPP по умолчанию в 0x80 (50%)). Это может быть пересмотрено позже, в зависимости от того, сможем ли мы надёжно определить, является ли работающий компьютер ноутбуком.

Следующие шаги:

Спонсор: Фонд FreeBSD

Контакт: Christos Margiolis <christos@FreeBSD.org>

Я работаю над аудиостеком с 2024Q1. Ниже приведён список предыдущих отчётов о состоянии:

2024Q1 URL: https://www.freebsd.org/status/report-2024-01-2024-03/#_audio_stack_improvements
2024Q2 URL: https://www.freebsd.org/status/report-2024-04-2024-06/#_audio_stack_improvements
2024Q3 URL: https://www.freebsd.org/status/report-2024-07-2024-09/#_audio_stack_improvements
2024Q4 URL: https://www.freebsd.org/status/report-2024-10-2024-12/#_audio_stack_improvements
2025Q1 URL: https://www.freebsd.org/status/report-2025-01-2025-03/#_audio_stack_improvements
2025Q2 URL: https://www.freebsd.org/status/report-2025-04-2025-06/#_audio_stack_improvements
2025Q3 URL: https://www.freebsd.org/status/report-2025-07-2025-09/#_audio_stack_improvements
2025Q4 URL: https://www.freebsd.org/status/report-2025-10-2025-12/#_audio_stack_improvements

Важная работа после последнего отчёта:

Вы также можете следить за процессом разработки в репозитории status-updates Фонда FreeBSD, где я публикую еженедельные отчёты.

Спонсор: Фонд FreeBSD

Ссылки:
Поддержка беспроводных карт MediaTek URL: https://github.com/FreeBSDFoundation/proj-laptop/issues/66
Поддержка беспроводных карт Realtek URL: https://github.com/FreeBSDFoundation/proj-laptop/issues/99

Контакт: Bjoern A. Zeeb <bz@FreeBSD.org>
Контакт: Список рассылки беспроводных технологий FreeBSD <wireless@FreeBSD.org>

Этот отчёт посвящён усилиям по использованию драйверов беспроводных устройств Linux с пермиссивными лицензиями, в основном без изменений, во FreeBSD, а также подготовке нативного стека net80211 к поддержке более новых стандартов.

Контакт: Tom Jones <thj@FreeBSD.org>

Опция Jumbo Payload (гигантская полезная нагрузка) — это расширенный заголовок IPv6, предназначенный для поддержки размеров пакетов, превышающих 65 735 октетов. FreeBSD получила поддержку Jumbo Payload от проекта KAME, но ни в одной реальной сети эта поддержка никогда не использовалась.

В рамках модернизации стека IPv6 поддержка Jumbo Payload была удалена. Насколько нам известно, использовать эту поддержку с хостом FreeBSD никогда не было возможно.

Спонсор: Фонд FreeBSD

Ссылки:
Добавление поддержки Geneve (RFC8926) URL: https://reviews.freebsd.org/D54172

Контакт: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>

С момента последнего отчёта я разбил реализацию GENEVE на множество более мелких ревизий, чтобы упростить процесс рецензирования:

Вы можете помочь ускорить процесс, рецензируя и предоставляя отзывы на phabricator.

Ссылки:
drm-kmod: Сборка и запуск на ARM64 с 16.0-CURRENT URL: https://github.com/freebsd/drm-kmod/pull/402

Контакт: Dmitry Salychev <dsl@FreeBSD.org>

Я успешно собрал и запустил graphics/drm-66-kmod с этими патчами на моём Honeycomb LX2 с Radeon RX 460. С этими патчами версия 6.6-lts может стать заменой для всех, кто полагался на устаревший graphics/drm-510-kmod.

Ссылки:
Wiki URL: https://wiki.freebsd.org/arm/Bananapi

Контакт: Martin Filla <freebsd@sysctl.cz>

Ссылки:
Ошибка 292006 — dpni некорректно работает в мосте URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292006
dpaa2: Установка возможностей интерфейса при подключении URL: https://reviews.freebsd.org/D53436
dpnaa2: объявление поддержки контрольных сумм при передаче URL: https://reviews.freebsd.org/D54809
dpaa2: Выполнение bus_dma предварительной синхронизации записи перед операцией постановки в очередь URL: https://reviews.freebsd.org/D56144
dpaa2: dpaa2_ni_rx() информация о включении/ошибках контрольных сумм RX для L3/4 URL: https://reviews.freebsd.org/D55320
dpaa2: Вынос функций, специфичных для кадров, в dpaa2_frame.[h,c] URL: https://reviews.freebsd.org/D56315
dpaa2: Извлечение статусов контрольных сумм на входящем трафике URL: https://reviews.freebsd.org/D56383
dpaa2: ni: добавление дополнительной статистики и информации о канале связи URL: https://reviews.freebsd.org/D55321

Контакт: Michael Tuexen <tuexen@FreeBSD.org>
Контакт: Bjoern A. Zeeb <bz@FreeBSD.org>
Контакт: Dmitry Salychev <dsl@FreeBSD.org>

Ссылки:
Спецификация Intel FRED до SDM URL: https://www.intel.com/content/www/us/en/content-details/819481/flexible-return-and-event-delivery-fred-specification.html + D55829 amd64: поддержка FRED URL: https://reviews.freebsd.org/D55829

Контакт: Konstantin Belousov <kib@FreeBSD.org>

Реализована поддержка функции FRED (Flexible Return and Event Delivery — гибкое возвращение и доставка событий) для очень современных платформ amd64. FRED представляет собой полную переработку аппаратного интерфейса для сообщения операционной системе об исключениях, прерываниях и системных вызовах, а также способа, которым операционная система возвращает управление из обработчика прерванному коду. Целью разработки FRED было избавиться от слоёв функций совместимости и ошибок, накопившихся в существующем способе, назовём его доставкой событий на основе IDT.

Спецификация FRED теперь включена в Intel SDM редакции 90. Похоже, что AMD также планирует предоставить FRED в некоторых будущих реализациях.

Таким образом, поддержка FRED требует нового пути кода для обработчиков событий. Хорошая структурированность FRED позволяет использовать минимальные trampoline-части на ассемблере, перенося бОльшую часть диспетчеризации в код на C.

Реализация обработчика FRED была относительно простой и потребовала гораздо меньше времени, чем я изначально предполагал. Это показывает, насколько хорош и естественен предлагаемый интерфейс.

На данный момент тестирование проводилось только на эмуляторе Simics. FRED должен поддерживаться недавно выпущенными процессорами Intel Panther Lake, но у меня нет доступа к реальному оборудованию.

Спонсор: Фонд FreeBSD

Контакт: Tom Jones <thj@FreeBSD.org>

Семейство устройств Allwinner H616 (H616, H616 и H700) — это серия небольших, но мощных систем-на-кристалле (SoC) с мощной медиа-поддержкой. Они используются во многих телевизионных приставках, портативных устройствах и одноплатных компьютерах.

FreeBSD теперь поддерживает большинство периферийных устройств, и поддержка была протестирована с Orange Pi 2. Существует пока неизвестная проблема с контроллером Ethernet, но она находится в стадии исследования. Поддержка графики требует drm, и это ещё не было изучено. Видеоустройство не поддерживается в u-boot или Linux как консоль фреймбуфера.

Спонсор: Фонд FreeBSD

Ссылки:
AMI для FreeBSD 15.0-RELEASE URL: https://www.freebsd.org/releases/15.0R/ec2-ami-ids/release/

Контакт: Colin Percival <cperciva@FreeBSD.org>

FreeBSD доступна на EC2-инстансах как amd64 (Intel и AMD), так и arm64 (Graviton).

Список EC2 AMI для FreeBSD 15.0-RELEASE был добавлен на веб-сайт FreeBSD. Эта страница включает JavaScript, позволяющий фильтровать список по региону, архитектуре, типу (flavour) и корневой файловой системе.

Теперь действует процесс публикации обновлённых EC2 AMI в ответ на консультации по безопасности; в настоящее время у нас есть AMI для FreeBSD 15.0-RELEASE-p5, и мы ожидаем, что обновлённые AMI обычно будут доступны в течение нескольких часов после публикации консультаций. Идентификаторы этих AMI публикуются через SSM Parameter Store и веб-сайт FreeBSD. В настоящее время не существует механизма для создания обновлённых AMI для релизов 14.x.

Проблема, из-за которой прерывания ввода-вывода драйвера ena(4) все попадали на CPU 0 в системах arm64, была исправлена в main. Исправление должно присутствовать в 15.1-RELEASE (июнь) и 14.5-RELEASE (сентябрь).

Проблема, из-за которой драйвер ena(4) не подключался при загрузке FreeBSD на инстансах r8i.96xlarge, была исправлена в main. Ожидается, что исправление будет присутствовать в 15.1-RELEASE (июнь) и 14.5-RELEASE (сентябрь).

Спонсор: Amazon
Спонсор: https://www.patreon.com/cperciva

Ссылки:
STACKIT URL: https://stackit.com/
Интерфейс командной строки STACKIT URL: https://github.com/stackitcloud/stackit-cli

Контакт: Robert Gogolok <gogolok@gmail.com>

Я работаю над тем, чтобы FreeBSD стала платформой первого класса для управления ресурсами в STACKIT — европейском облаке с суверенитетом данных. Цель — предоставить сообществу BSD нативный и надёжный доступ к инструментам IaaS и PaaS STACKIT.

Нативные бинарные файлы: В дополнение к существующему порту sysutils/stackit, нативные бинарные файлы FreeBSD (amd64/arm64) теперь включены в каждый официальный вышестоящий релиз.

Вклад в вышестоящие проекты:

Будущая работа:

Ссылки:
Cloud Native Buildpacks (CNBs) URL: https://buildpacks.io/
Репозиторий Buildpacks на GitHub URL: https://github.com/buildpacks/pack

Контакт: Robert Gogolok <gogolok@gmail.com>

Cloud Native Buildpacks (CNBs) преобразуют исходный код приложения в образы контейнеров. Эти образы могут работать в любом облаке. С помощью buildpacks организации могут сконцентрировать знания о передовых практиках сборки контейнеров в специализированной команде, вместо того чтобы заставлять разработчиков приложений по всей организации индивидуально сопровождать свои собственные Dockerfile.

С момента последнего отчёта в 2025Q1 проект перешёл от экспериментальной поддержки к официальному предоставлению бинарных файлов:

Следующие шаги сосредоточены на снижении порога входа для разработчиков и улучшении автоматизации процесса сборки для FreeBSD:

Ссылки:
Официальный веб-сайт FreeBSD на русском языке URL: https://www.freebsd.org/ru/
FAQ URL: https://docs.freebsd.org/ru/books/faq/
Сайт проекта русской документации FreeBSD URL: https://github.com/freebsd-doc-ru/freebsd-doc/discussions

Контакт: Андрей Захватов (Andrey Zakhvatov) <andy@FreeBSD.org>
Контакт: Владлен Пополитов (Vladlen Popolitov) <vladlen@FreeBSD.org>

Текущая цель Проекта русскоязычной документации FreeBSD — предоставлять актуальные русские переводы наиболее важных частей документации FreeBSD (FAQ, Руководство, содержимое веб-сайта). Это необходимо для поддержки русскоязычных пользователей качественными официальными техническими материалами и для расширения распространённости операционной системы по всему миру. Мы надеемся, что эта инициатива получит поддержку в русскоязычном сообществе FreeBSD и приведёт к увеличению объёма переведённых материалов.

В течение последнего квартала:

План на следующий квартал:

Ознакомьтесь с официальным руководством по переводу, если вы хотите помочь.

Мы будем признательны за вашу помощь в переводе следующих материалов:

Ссылки:
Инициатива KDE/FreeBSD URL: https://freebsd.kde.org/
FreeBSD — KDE Community Wiki URL: https://community.kde.org/FreeBSD

Контакт: Список рассылки KDE во FreeBSD <kde@FreeBSD.org>

Проект KDE во FreeBSD упаковывает CMake, Qt и программное обеспечение из сообщества KDE для дерева портов FreeBSD. Программное обеспечение включает в себя полноценное окружение рабочего стола под названием KDE Plasma (как для X11, так и для Wayland) и сотни приложений, которые могут использоваться на любой машине FreeBSD. Команда KDE является частью команд desktop@ и multimedia@, создавая программный стек, чтобы сделать FreeBSD красивой и пригодной для использования в качестве повседневной графической рабочей станции.

Ссылки:
Проект GCC URL: https://gcc.gnu.org/
Серия релизов GCC 13 URL: https://gcc.gnu.org/gcc-13/
Серия релизов GCC 14 URL: https://gcc.gnu.org/gcc-14/
Серия релизов GCC 15 URL: https://gcc.gnu.org/gcc-15/
Серия релизов GCC 16 URL: https://gcc.gnu.org/gcc-16/

Контакт: Lorenzo Salvadore <salvadore@FreeBSD.org>

В этом квартале у нас три основные новости.

В январе мы исследовали, почему еженедельные снимки GCC 16 перестали компилироваться, начиная со снимка за ноябрь. Потребовалось много глаз, чтобы понять, что произошло, но в конечном счёте проблема была понята, и в феврале исправление было зафиксировано в вышестоящем репозитории. Подробности можно найти в сообщении об ошибке вышестоящего репозитория. Спасибо всем, кто помог, особенно Марку Милларду (Mark Millard) и Димитрию Андрику (Dimitry Andric).

На данный момент lang/gcc16-devel не собирается на arm64. К сожалению, я пока не нашёл времени, чтобы действительно заняться этим, но надеюсь сделать это в ближайшее время. PR 294062 — это отчёт об ошибке, отслеживающий эту проблему.

Процесс по установке GCC_DEFAULT=15 начался. Обновление до GCC_DEFAULT=14 всё ещё недавнее, и GCC 14 активно поддерживается, поэтому нет спешки с завершением этого обновления; но поскольку такие обновления обычно занимают много времени, я уже начал его. Таким образом, сейчас это не мой главный приоритет: пока это то, на что я трачу свои силы, когда у меня есть свободное время.

Ссылки:
Домашняя страница Valgrind URL: https://www.valgrind.org/
Новости Valgrind URL: https://www.valgrind.org/docs/manual/dist.news.html

Контакт: Paul Floyd <pjfloyd@wanadoo.fr>

Когда вышла FreeBSD 14.4-RELEASE и всё прошло гладко, я подумал, что для этого ежеквартального отчёта будет мало что сказать. Затем я начал использовать пару машин с 16.0-CURRENT, которые являются частью фермы серверов GCC. Там я увидел несколько проблем. Поначалу было гораздо больше сбоев, чем я обычно ожидал. Чуть позже серверы были обновлены, и Valgrind довольно сильно сломался, выдавая утверждение (assert) на раннем этапе запуска. Некоторые из этих проблем были обычным высоким уровнем обслуживания, ожидаемым от Valgrind. Потребовалось новое подавление Helgrind для внутренних блокировок, используемых pthread_create. Серверы были собраны и установлены из исходных кодов, что иногда влияет на стеки вызовов ошибок. Регрессионные тесты Valgrind довольно чувствительны к такого рода изменениям, и потребовалась дополнительная фильтрация. Утверждения были вызваны неверными предположениями в Valgrind, которые используются, когда инструмент читает свой собственный бинарный файл, в основном для того, чтобы иметь возможность напечатать свой собственный стек вызовов в случае сбоя. Последняя проблема была вызвана изменением способа создания разделяемых отладочных файлов (split debug files) библиотек.

В целом, это скорее стабилизационный релиз. Относительно мало новых функций.

Valgrind 3.27 должен выйти в конце апреля 2026 года, и devel/valgrind будет обновлён вскоре после этого.

Вот список исправлений ошибок с момента моего последнего отчёта (Q3 2025).

Ссылки:
Описание проекта URL: https://freebsdfoundation.org/project/improving-openjdk-on-freebsd/
Репозиторий проекта URL: https://github.com/freebsd/openjdk
Вышестоящий репозиторий BSD-порта URL: https://github.com/openjdk/bsd-port

Контакт:
Harald Eilertsen <haraldei@FreeBSD.org>
Список рассылки FreeBSD Java <freebsd-java@lists.freebsd.org>

Цель этого проекта — улучшить поддержку OpenJDK для FreeBSD/amd64 и FreeBSD/arm64.

Java является важной средой выполнения для многих высокопроизводительных критически важных корпоративных систем. Обеспечение правильной и эффективной работы приложений на основе Java во FreeBSD важно для того, чтобы FreeBSD оставалась жизнеспособной и привлекательной платформой для предприятий, а также для бизнеса и организаций любого размера.

В этом квартале были достигнуты следующие цели/вехи:

Другие заметки:

Спонсор: Фонд FreeBSD

Ссылки: Ошибка 272855 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272855 Таблица отслеживания незавершённой работы URL: https://docs.google.com/spreadsheets/d/17hmRQ0ShY4SHHVEkQBVxqK2G88fPZLriTzO26zXdjC4/edit?usp=sharing

Контакт: Ronald Klop <ronald@FreeBSD.org>

Наличие активной среды Java полезно для всех видов приложений FreeBSD.

Версия JAVA_VERSION по умолчанию в портах FreeBSD была изменена с 8 на 21 26 февраля. Это был серьёзный шаг в смене версий. Поэтому потребовалось довольно много работы. Теперь всё сделано.

Все известные порты, которые могли сломаться, были исправлены, и с тех пор не поступало сообщений о регрессиях. Ветка портов 2026Q2 будет первой стабильной веткой портов, в которой OpenJDK 21 будет версией Java по умолчанию.

Ссылка: Ошибка 293559 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293559

Контакт: Ronald Klop <ronald@FreeBSD.org>

Java — это важное окружение для запуска некоторых приложений на FreeBSD. Порты OpenJDK активно поддерживаются и находятся в актуальном состоянии. С октября 2025 года OpenJDK 25 LTS доступен в дереве портов.

Основываясь на фундаменте, заложенном при переводе портов на OpenJDK 21, переключение JAVA_DEFAULT на 25 является гораздо меньшим шагом. Большинство Java-портов компилируются и работают без изменений. Лишь горстка портов требует некоторых исправлений, которые сейчас в процессе.

Работа отслеживается в PR 293559.

Я считаю разумным привести порты в состояние, готовое для установки JAVA_VERSION=25, во втором квартале 2026 года.

План:

Ссылки:
Wazuh URL: https://wazuh.com

Контакт: José Alonso Cárdenas Márquez <acm@FreeBSD.org>
Контакт: Jesús Daniel Colmenares Oviedo <dtxdf@FreeBSD.org>

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

Решение Wazuh состоит из агента безопасности конечной точки, развёртываемого на отслеживаемых системах, и управляющего сервера (менеджера), который собирает и анализирует данные, собранные агентами. Кроме того, Wazuh полностью интегрирован с Elastic Stack или OpenSearch Stack, предоставляя поисковую систему и инструмент визуализации данных, который позволяет пользователям перемещаться по своим оповещениям безопасности.

В этом квартале произошло много событий. Многочисленные улучшения и исправления ошибок для улучшения поддержки FreeBSD этой превосходной платформой XDR/SIEM и безопасности.

Makejails для Wazuh были улучшены и теперь имитируют официальные Dockerfile, поэтому пользователи, знакомые с ними, могут легко развернуть все компоненты Wazuh с помощью AppJail и Director:

Это также добавляет инфраструктуру кластерного режима для Makejails.

Обнаружение уязвимостей (vulnerability detection) ещё не реализовано во FreeBSD, но для устранения этого недостатка был разработан Serpico. Serpico — это сканер безопасности для пакетов и релизов FreeBSD, который сравнивает версии со списком версий, помеченных как уязвимые, и отображает информацию об уязвимостях в компактном формате JSON для лёгкого анализа с помощью других инструментов безопасности. Пакет включает правила для Wazuh и панель управления, которую можно легко установить через веб-интерфейс или OpenSearch Dashboards API.

Текущая версия: 4.14.3

Ссылки:
sysutils/slurm-wlm URL: https://cgit.freebsd.org/ports/tree/sysutils/slurm-wlm/
net/pmix URL: https://cgit.freebsd.org/ports/tree/net/pmix/
net/prrte URL: https://cgit.freebsd.org/ports/tree/net/prrte/
net/openmpi URL: https://cgit.freebsd.org/ports/tree/net/openmpi/
net/ucx URL: https://cgit.freebsd.org/ports/tree/net/ucx/
benchmarks/py-reframe-hpc URL: https://cgit.freebsd.org/ports/tree/benchmarks/py-reframe-hpc/
sysutils/mpifileutils URL: https://cgit.freebsd.org/ports/tree/sysutils/mpifileutils/

Контакт: Generic Rikka <rikka.goering@outlook.de>

Этот отчёт продолжает текущую инициативу по модернизации HPC-портов FreeBSD, которая направлена на то, чтобы сделать FreeBSD практичной и поддерживаемой платформой для современных программных стеков высокопроизводительных вычислений (HPC).

Предыдущая работа была сосредоточена на обновлении основного планировщика и стека времени выполнения путём модернизации sysutils/slurm-wlm и введения отдельных портов для net/pmix и net/prrte. В течение этого квартала внимание сместилось на расширение окружающей экосистемы HPC, улучшение интеграции между компонентами и передачу исправлений переносимости, обнаруженных в процессе портирования, в вышестоящие проекты.

Долгосрочная цель — предоставить согласованную программную среду HPC в Коллекции портов FreeBSD, которая напоминает то, что пользователи ожидают от HPC-систем на базе Linux, оставаясь при этом поддерживаемой в экосистеме FreeBSD.

Ссылки:
libvirt: Драйвер bhyve URL: https://libvirt.org/drvbhyve.html

Контакт: Roman Bogorodskiy <novel@FreeBSD.org>