· | 23.07.2025 | В Fedora предложено задействовать FlatHub в атомарных редакциях дистрибутива (82 +7) |
Майкл Катандзаро (Michael Catanzaro), один из разработчиков web-браузера Epiphany (GNOME Web), принимающий участие в проектах GNOME и Fedora, предложил пересмотреть использование каталога FlatHub в Fedora Linux. В атомарно обновляемой редакции Fedora Workstation предложено задействовать по умолчанию каталог FlatHub для flatpak-пакетов, устанавливаемых пользователями, а собственный репозиторий flatpak-пакетов ограничить только применением для предустанавливаемых пакетов.
В настоящее время по умолчанию в Fedora предлагается собственный flatpak-репозиторий, содержимое которого формируется на основе пересборки rpm-пакетов. По умолчанию загрузку пакетов из FlatHub можно включить лишь после установки, активировав в менеджере приложений GNOME опцию "Enable Third-Party Repositories", но даже в этом случае пакеты из репозитория Fedora являются более приоритетными. По мнению Майкла большинство пользователей предпочло бы установку пакетов из каталога FlatHub, собираемых основными разработчиками приложений, а не сопровождающими Fedora (80% участников дискуссии высказались за использование FlatHub). Предполагается, что разработчики приложений лучше знают нюансы своих проектов и собирают более качественно работающие flatpak-пакеты, тщательнее протестированные сообществом. При этом сопровождающие rpm-пакеты в Fedora не проявляют ожидаемого интереса к поддержанию вариантов пакетов в формате flatpak и не уделяют должного внимания сообщениям об ошибках в таких пакетах, что приводит к тому, что качество flatpak-пакетов от Fedora ниже, чем размещённых во FlatHub пакетах от основных проектов. Многие пользователи не в курсе, что устанавливая flatpak-пакет через менеджер приложений Fedora, он устанавливается не из FlatHub, как в других дистрибутивах, а из репозитория Fedora, пакеты в котором отличаются от вариантов с FlatHub. Из-за этого проблемы, специфичные для пакетов из репозитория Fedora, воспринимаются как проблемы в официальных пакетах с FlatHub и претензии направляются основным разработчикам, а не сопровождающим Fedora. Например, поставка проблемного flatpak-пакета OBS Studio в Fedora, который являлся более приоритетным, чем пакет из FlatHub, в феврале привела к конфликту с проектом OBS Studio. Применение собственного Flatpak-репозитория обусловлено необходимостью сборки в заслуживающем доверия окружении. Для пакетов во FlatHub, даже если рассматривать только верифицированные пакеты, за публикацию которых отвечают основные проекты, сборка производится во внешних инфраструктурах, безопасность которых может вызывать сомнение. Из достоинств поддержания собственного репозитория в Fedora упоминаются гарантии, что пакет собран из заявленного исходного кода и содержит только компоненты под открытыми лицензиями, одобренными к использованию Fedora. Пакеты в Fedora-репозитории также могут включать патчи, доступные только для RPM-пакетов в Fedora и пока не принятые в основную кодовую базу проектов. Предложение Майкла сводится к включению по умолчанию в атомарной редакции Fedora Workstation поддержки установки пакетов из FlatHub, находящихся в категории "свободное ПО". Возможность установки из FlatHub коснётся только пакетов, устанавливаемых пользователями через менеджер приложений GNOME Software. Все предустанавливаемые по умолчанию flatpak-пакеты продолжат загружаться из собственного репозитория Fedora, но для не применяемых по умолчанию пакетов в качестве источника для загрузки предлагается задействовать FlatHub. Перед переходом на FlatHub предлагается совместно внедрить во FlatHub возможности для сборки пакетов в заслуживающей доверие инфраструктуре и задействовать проверки на базе воспроизводимых сборок. Кроме того, следует решить вопрос с применением в пакетах устаревших версий Flatpak Runtime, в которые уже прекращён перенос исправлений уязвимостей. В настоящее время 994 из 3438 (почти треть) проверенных пакетов из FlatHub используют Runtime, время поддержки которых истекло. Проблемы с безопасностью также возникают из-за устаревших внутренних зависимостей, включаемых в состав пакетов, и применения недостаточных мер sandbox-изоляции (разработчики некоторых пакетов отключают режимы защиты). Проблемы предлагается решить через реализацию автоматизированных проверок устаревших runtime и зависимостей, и форсирование применения полноценной sandbox-изоляции. Кроме Майкла, с похожим предложением также выступил Тимоти Равье (Timothée Ravier): в Fedora 43 предлагается продолжить поставку предустановленных flatpak-пакетов из репозитория Fedora, но добавить фильтр, допускающий установку из FlatHub избранных проверенных приложений. В качестве достоинств предложенного решения называется снижение путаницы у пользователей и разработчиков основных проектов (разработчикам приходится разбирать сообщения об ошибках, специфичных для Flatpak-пакетов Fedora, отправленных под видом, что они присутствуют в официальном flatpak-пакете). Изменение также снизит нагрузку на сопровождающих и позволит им сфокусироваться на передаче исправлений в основные проекты и тестировании предустанавливаемых по умолчанию Flatpak-пакетов.
| ||
Обсуждение (82 +7) |
Тип: К сведению |
| ||
· | 22.07.2025 | Релиз Firefox 141 (217 +22) |
Состоялся релиз web-браузера Firefox 141 и сформированы обновления прошлых веток с длительным сроком поддержки - 140.1.0, 115.26.0 и 128.13.0. На стадию бета-тестирования переведена ветка Firefox 142, релиз которой намечен на 19 августа.
Основные новшества в Firefox 141:
Кроме новшеств и исправления ошибок в Firefox 141 устранено 27 уязвимостей. 13 уязвимостей вызваны проблемами работы с памятью, такими как переполнения буферов и обращение к уже освобождённым областям памяти. Потенциально данные проблемы способны привести к выполнению кода злоумышленника при открытии специально оформленных страниц.
| ||
Обсуждение (217 +22) |
Тип: Программы |
| ||
· | 22.07.2025 | Google представил проект OSS Rebuild для выявления скрытых изменений в пакетах (43 +12) |
Компания Google представила проект OSS Rebuild, предназначенный для выявления скрытых изменений в готовых пакетах, публикуемых в репозиториях. Работа OSS Rebuild основана на концепции воспроизводимых сборок и сводится к проверке соответствия размещённого в репозитории пакета с пакетом полученным на основе пересборки из эталонного исходного кода, соответствующего заявленной версии пакета. Код инструментария написан на языке Go и распространяется под лицензией Apache 2.0.
В настоящее время в OSS Rebuild реализована поддержка верификации пакетов из репозиториев NPM (JavaScript/TypeScript), PyPI (Python) и Crates.io (Rust). В будущем число поддерживаемых репозиториев планируют расширить. На практике инструментарий позволяет выявлять варианты атаки класса "supply chain", в ходе которых после компрометации учётных записей сопровождающих или диверсии внутри проекта в репозитории публикуется вредоносное обновление. При этом код в исходном репозитории основного проекта остаётся корректным, а вредоносные изменения вносятся только в готовые пакеты. Система по возможности автоматически формирует сценарий для воспроизводимой сборки выбранного пакета, используя эвристику и подбирая параметры, позволяющие добиться идентичности артефактов, поставляемых в пакете. Если автоматически не удаётся воспроизвести размещённый в репозитории пакет, возможно ручное добавление сборочной спецификации. После того как удалось воспроизвести пакет, инструментарий OSS Rebuild сохраняет описание процесса сборки для последующей проверки новых версий пакета. Дополнительно публикуется информация для верификации с использованием фреймворка SLSA. После проведения проверки конкретной версии пакета формируются данные аттестации, которые могут использоваться другими для оценки уже верифицированных пакетов. Проверку можно осуществить через запуск утилиты командной строк или сверку хэша, сохранённого в отдельном облачном хранилище. Инфраструктуру для проверки пакетов можно развернуть на собственном сервере. Так же можно воспользоваться информацией о проверках, выполняемых в Google для нескольких тысяч пакетов. В качестве примеров разных методов атак, от которых мог бы защитить OSS Rebuild, приводится добавление бэкдора в XZ, внедрение вредоносного кода в официальный JavaScript-клиент для криптовалюты Solana и подстановка изменений через Actions-обработчик changed-files:
| ||
Обсуждение (43 +12) |
Тип: Программы |
| ||
· | 21.07.2025 | Доступна библиотека OpenAPV 0.2 с эталонной реализацией видеокодека APV (43 +23) |
Опубликован выпуск библиотеки OpenAPV, предоставляющей эталонную реализацию видеокодека APV (Advanced Professional Video), предназначенного для профессиональной записи и обработки видео без различимой потери качества. Код библиотеки написан на языке С и распространяется под лицензией BSD. Проект развивает организация Academy Software Foundation, учреждённая Академией кинематографических искусств (США) и организацией Linux Foundation с целью продвижения использования открытого ПО в процессе создания фильмов.
Формат APV обеспечивают высокую пропускную способность и низкую сложность внутрикадрового кодирования, необходимые монтажным кодекам (среди них Apple ProRes и Avid DNxHD), а также отсутствие видимого снижения качества при повторном кодировании. Поддерживаются разрешения 2K, 4K и 8K, стандарт HDR10/10+ для использования расширенного динамического диапазона в видео, разбивка кадров (tiling) для распараллеливания кодирования/декодирования, различные форматы дискретизации цвета, многоракурсное видео (multi-view), добавление метаданных (глубина, прозрачность, данные для предпросмотра). Для ускорения работы в библиотеке OpenAPV поддерживается многопоточное кодирование и декодирование, а также задействованы оптимизации с использованием расширенных наборов команд NEON (ARM) и SSE/AVX (x86). В новой версии добавлена поддержка семейств APV (APV family), определяющих типовые конфигурации кодека, отвечающие определённым требованиям к размеру и битрейту. Учтены последние доработки спецификации. Добавлена поддержка профилей 422-12, 444-10, 444-12, 4444-10, 4444-12 и 400-10. Внесены оптимизации для сокращения времени кодирования и декодирования. Реализованы защищённые методы доступа к буферу битового потока (bitstream) и управления метаданными. Расширен API.
| ||
Обсуждение (43 +23) |
Тип: Программы |
| ||
· | 21.07.2025 | Фишинг позволил получить контроль над несколькими популярными NPM-пакетами (73 +18) ↻ |
Зафиксирована фишинг-атака на сопровождающих JavaScript-библиотеки, в ходе которой от имени сервиса NPM было разослано сообщение, уведомляющее о необходимости подтвердить свой email. Проведённая атака позволила злоумышленникам
получить NPM-токены сопровождающего одного из крупных JavaScript-проектов и выпустить обновления с вредоносным кодом для пяти NPM-пакетов, в сумме насчитывающих около 100 млн загрузок в неделю.
Отправленное сопровождающим сообщение было стилизовано под типовые уведомления NPM, отправляемые с адреса "[email protected]", но в качестве ссылки для перехода был указан домен "npnjs.com" вместо "npmjs.com" (третья буква "n" вместо "m"). Атакующие воспользовались психологическим эффектом, из-за которого мозг, предвосхищая ожидаемый результат, не замечает незначительные искажения, такие как замена букв на похожие или изменение порядка следования букв в слове. При переходе по ссылке открывалась полная копия сайта npmjs.com (вероятно, был настроен прокси, перехватывающий токен доступа). ![]() В ходе атаки были сформированы новые версии пакетов:
В сформированные выпуски был добавлен вредоносный код для атаки на пользователей, использующих платформу Windows. Внесённые изменения загружали библиотеку node-gyp.dll, содержащую функциональность для удалённого выполнения команд в системе. Сопровождающий заметил, что стал жертвой фишинга примерно через час после поступления первой жалобы о публикации подозрительных релизов. Он сразу отозвал токен доступа, поменял пароли и пометил проблемные версии устаревшими для предотвращения загрузки автоматизированными сборочными системами и отправил запрос на удаление проблемных версий из репозитория в службу поддержки NPM. Не уточняется сколько пользователей успело загрузить вредоносные версии (например, вредоносная версия пакета eslint-plugin-prettier оставалась в репозитории около двух дней). За прошлую неделю пакет eslint-config-prettier насчитывал 30 млн загрузок и использовался в качестве зависимости у 11762 тысячи пакетов, пакет eslint-plugin-prettier - 21 млн загрузок (8468 зависимых пакетов), synckit - 18 млн, @pkgr/core - 16 млн и napi-postinstall - 10 млн. Дополнение: Выявившие фишинг-атаку исследователи несколько дней назад также обратили внимание на 28 NPM-пакетов, авторами которых было включено изменение категории Protestware. Изменение приводило к воспроизведению украинского гимна и отключению обработки событий от мыши на сайтах в доменных зонах "ru", "su", "by" и "рф", если пользователь ранее уже открывал сайт более трёх дней назад и в его браузере была включена поддержка русского языка. Изначально изменение было реализовано около трёх лет назад в пакете Sweetalert2, насчитывающем 700 тысяч загрузок в неделю и используемого в 2403 других пакетах как зависимость. Наличие протестной активности было отдельно упомянуто на странице проекта. Через какое-то время изменение стало заимствоваться авторами других пакетов, как правило насчитывающие несколько сотен загрузок в неделю.
| ||
Обсуждение (73 +18) ↻ |
Тип: Проблемы безопасности |
| ||
· | 19.07.2025 | Компания Intel прекратила разработку дистрибутива Clear Linux (164 +10) |
Компания Intel объявила о сворачивании проекта Clear Linux, развивающего дистрибутив со строгой изоляцией приложений, реализованной при помощи контейнеров, разделённых с использованием полноценной виртуализации. Начиная с сегодняшнего дня Intel прекращает сопровождение и больше не будет выпускать обновления и исправления с устранением уязвимостей. GitHub-репозитории, в которых велась разработка дистрибутива, в ближайшее время будут переведены в архивный режим.
Пользователям Clear Linux рекомендовано перевести свои системы на другие дистрибутивы. При этом отмечается, что Intel продолжит активно поддерживать экосистему Linux и участвовать в разработке различных открытых проектов и Linux-дистрибутивов для добавления поддержки своего оборудования и оптимизации работы с ним. Предполагается, что вовлечённые в разработку Clear Linux сотрудники Intel попадают под массовое сокращение, в ходе которого персонал компании будет уменьшен на 5 тысяч человек. Напомним, что базовая часть Clear Linux содержит только минимальный набор инструментов для запуска контейнеров и обновляется атомарно через замену рабочих снапшотов Btrfs. Все приложения оформлены в виде пакетов Flatpak или наборов (Bundle), запускаемых в отдельных контейнерах. Внутри контейнеров выполняется специально оптимизированная копия Clear Linux, содержащая необходимые для запуска целевого приложения наборы (bundle). Версия дистрибутива охватывает состояние версий всех входящих в него компонентов - изменение любой части системы всегда приводит к изменению общей версии всего дистрибутива. Система не сохраняет своё состояние (stateless) и после установки не содержит заранее добавленных настроек в каталоге /etc, а генерирует настройки на лету на основе указанных при запуске шаблонов. Для изоляции контейнеров задействован инструментарий Kata Containers, применяющий полноценную виртуализацию на базе гипервизора KVM. В Kata Containers удалось минимизировать время запуска изолированного окружения на базе KVM и снизить потребление памяти, приблизив эти показатели к характеристикам обычных контейнеров. Для уменьшения потребления памяти применяется механизм DAX (прямой доступ к ФС в обход страничного кэша без применения уровня блочных устройств), а для дедупликации одинаковых областей памяти применяется технология KSM (Kernel Shared Memory).
| ||
Обсуждение (164 +10) |
Тип: К сведению |
| ||
· | 19.07.2025 | В AUR-репозитории Arch Linux выявлены вредоносные пакеты (173 +38) |
В репозитории AUR (Arch User Repository), применяемом в Arch Linux для распространения пакетов от сторонних разработчиков, выявлены три вредоносных пакета firefox-patch-bin, librewolf-fix-bin и zen-browser-patched-bin, содержащие модифицированные сборки браузеров Firefox, Librewolf и Zen. Имена пакетов напоминали легитимные пакеты firefox-bin,
librewolf-bin и zen-browser-bin, поддерживаемые энтузиастами в AUR.
В пакетах в файле PKGBUILD присутствовала ссылка на патчи, загружаемые из внешних репозиториев на GitHub (zenbrowser-patch, youtube-viewbot). Патчи вносили изменение в установочный процесс, приводящее к запуску скрипта на языке Python для установки трояна Chaos. Троян позволял получить удалённый доступ к системе, отправлять на внешний сервер конфиденциальные файлы и выполнять команды, например, для майнинга криптовалюты. Вредоносный исполняемый файл размещался как /usr/local/share/systemd-initd и запускался при помощи сервиса custom-initd.service, копируемого в каталог с systemd. При отсутствии прав root во время установки троян помещался в домашний каталог пользователя (~/.local/share/systemd-initd). Вредоносные пакеты были размешены в репозитории AUR 16 июля примерно в 23 часа (MSK). Для продвижения вредоносных пакетов 18 июля в 15 часов (MSK) была развёрнута спамерская кампания. Например, для стимулирования установки в примечании к сборке с браузером Zen было отмечено решение критических проблем со стабильностью и отрисовкой, а также устранение утечек памяти. Пакеты были удалены администраторами репозитория 18 июля в 19 часов (MSK). Почти сразу пользователи репозитория обратили внимание на ещё четыре вредоносных пакета minecraft-cracked, ttf-all-ms-fonts, ttf-ms-fonts-all и vesktop-bin-patched, размещённых под другой учётной записью примерно в 21 час 18 июля (MSK). На момент написания новости данные пакеты уже удалены из репозитория.
| ||
Обсуждение (173 +38) |
Тип: Проблемы безопасности |
| ||
· | 18.07.2025 | Доступна платформа совместной разработки Forgejo 12.0 (76 +23) |
Опубликован выпуск платформы совместной разработки Forgejo 12.0, позволяющей развернуть на своих серверах систему для совместной работы с репозиториями Git, напоминающую по решаемым задачам GitHub, Bitbucket и Gitlab. Forgejo является форком проекта Gitea, который в свою очередь ответвился от платформы Gogs. Отделение Forgejo произошло в 2022 году после попыток коммерциализации Gitea и перехода управления в руки коммерческой компании. Проект Forgejo придерживается принципов независимого управления и подконтрольности сообществу. На использование Forgejo перешёл Git-хостинг Codeberg.org. Код проекта написан на языке Go и распространяется под лицензией GPLv3.
Ключевыми особенностями платформы является низкое потребление ресурсов (может использоваться на плате Raspberry Pi или в дешёвых VPS) и простой процесс установки. Предоставляются типовые возможности работы с проектами, такие как управление задачами, отслеживание проблем (issues), pull-запросы, wiki, средства для координации групп разработчиков, подготовка релизов, автоматизация размещения пакетов в репозиториях, управление правами доступа, сопряжение с платформами непрерывной интеграции, поиск кода, аутентификация через LDAP и OAuth, доступ к репозиторию по протоколам SSH и HTTP/HTTPS, подключение web-хуков для интеграции со Slack, Discord и другими сервисами, поддержка Git-хуков и Git LFS, инструменты для миграции и зеркалирования репозиториев. Отдельно выделяется возможность использования протокола ActivityPub для объединения в федеративную сеть отдельных серверов разработчиков. Основные изменения:
| ||
Обсуждение (76 +23) |
Тип: Программы |
| ||
· | 18.07.2025 | Домен putty.org начали использовать для распространения идей антипрививочников (163 +36) |
В январе 1999 года Саймон Тэтхем (Simon Tatham) выпустил первый публичный релиз SSH-клиента PuTTY, разместив сайт проекта на своей домашней странице www.chiark.greenend.org.uk/~sgtatham/putty/. В октябре 1999 года домен putty.org был зарегистрирован неизвестным перекупщиком, после чего в 2008 году его выкупил Денис Бидер (Denis Bider), сооснователь компании Bitvise. После покупки на сайте putty.org была размещена информация о SSH-клиенте PuTTY со скриншотом и ссылкой на страницу загрузки, ведущую на основной сайт проекта. Попутно на странице были размещены ссылки на проприетарный SSH-сервер и SSH-клиент от компании Bitvise.
В 2016 году, после замечаний о том, что сайт создаёт впечатление причастности Bitvise к разработке PuTTY, на страницу было добавлено примечание, что упомянутые продукты Bitvise никак не связаны с PuTTY и не должны восприниматься как рекомендуемые проектом PuTTY. В 2018 году на сайте появилась страница "FAQ", на которой было сказано, что компания Bitvise не имеет отношения к PuTTY, но развивает свой SSH-сервер, совместимый с PuTTY. В FAQ также было упомянуто, что многие клиенты Bitvise пользуются PuTTY и вынуждены искать страницу загрузки проекта, поэтому компания выкупила домен и создала отдельный сайт. Со временем сайт putty.org стал восприниматься некоторыми пользователями как основная точка входа для загрузки PuTTY, а при поиске в Google, Yandex, Duckduckgo и Bing по ключевому слову "putty" домен putty.org показывается выше, чем официальная страница проекта www.chiark.greenend.org.uk/~sgtatham/putty. Сайт putty.org также часто упоминают в обсуждениях и рекомендациях, связанных с PuTTY.
![]() 13 июля один из блоггеров опубликовал заметку с критикой использования домена putty.org для рекламы продуктов Bitvise и призывом вернуть домен разработчику PuTTY. Утверждается, что компания Bitvise вводит пользователей в заблуждение, извлекает выгоду из возникшей путаницы и злоупотребляет доверием к открытому ПО для рекламы собственного SSH-клиента, конкурирующего с PuTTY. Денис Бидер из компании Bitvise, владеющий доменом putty.org и никак не связанный с разработкой PuTTY, ответил, что проект PuTTY изначально не владел доменом и разговоры о возвращении домена, которого у проекта PuTTY никогда не было, беспочвенны и вводят окружающих в заблуждение. По словам Дениса, выкупив домен и использовав его для перенаправления на основную страницу загрузки он действовал без корыстных мотивов, а ссылки на своё ПО разместил для компенсации своих затрат. После переписки с автором заметки Денис Бидер оскорбился, назвал призывы освободить домен происками коммунистов и заменил содержимое сайта, начав использовать его для распространения конспирологических и антивакцинаторских теорий. Ссылка на загрузку PuTTY была оставлена, но перемещена в самый низ страницы. В качестве мотива изменения указано, что так как страница пользуется популярностью, решено использовать её для дела, которое, по мнению владельца домена, послужит общему благу.
| ||
Обсуждение (163 +36) |
Тип: К сведению |
| ||
· | 17.07.2025 | Выпуск свободной системы 3D-моделирования Blender 4.5 (106 +36) |
Организация Blender Foundation опубликовала выпуск свободного пакета 3D-моделирования Blender 4.5, подходящего для решения различных задач, связанных с 3D-моделированием, 3D-графикой, разработкой компьютерных игр, симуляцией, рендерингом, композитингом, трекингом движений, скульптурным моделированием, созданием анимации и монтажом видео. Код распространяется под лицензией GPL. Готовые сборки сформированы для Linux, Windows и macOS. Выпуск получил статус релиза с расширенным сроком поддержки (LTS) и будет поддерживаться до июля 2027 года. Также продолжает поддерживаться LTS-ветка Blender 4.2, обновления для которой будут формироваться до июля 2026 года. Поддержка LTS-ветки Blender 3.6 прекращена.
Среди добавленных улучшений:
| ||
Обсуждение (106 +36) |
Тип: Программы |
| ||
· | 16.07.2025 | В Firefox и Safari будет включена поддержка WebGPU (160 +25) |
Компания Mozilla приняла решение активировать в Firefox поддержку API WebGPU и языка шейдеров WGSL (WebGPU Shading Language). Для платформы Windows поддержка WebGPU будет включена по умолчанию в выпуске Firefox 141, намеченном на 22 июля. Затем в течение нескольких месяцев поддержку WebGPU планируют активировать в сборках для Linux и macOS, а через некоторое время и в версии для платформы Android. Для ручного включения WebGPU можно использовать параметры "dom.webgpu.enabled" и "gfx.webrender.all" на странице about:config.
В Chrome поддержка WebGPU была предложена по умолчанию в версии 113, сформированной в мае 2023 года. В Safari поддержку WebGPU планируют включить по умолчанию этой осенью (экспериментальная поддержка доступна с ноября 2021 года). В Firefox экспериментальная поддержка WebGPU присутствовала с 2020 года, но была включена по умолчанию только в ночных сборках Firefox. Реализация WebGPU в Firefox основана на коде проекта WGPU, написанного на языке Rust и способного работать поверх графических API Direct3D 12, Vulkan, OpenGL и Metal. WebGPU предоставляет схожий с Vulkan, Metal и Direct3D 12 программный интерфейс для выполнения операций на стороне GPU. Кроме 3D-графики WebGPU охватывает и возможности, связанные с выносом вычислений на сторону GPU и выполнением шейдеров. Концептуально WebGPU отличается от старой спецификации WebGL примерно так же, как графический API Vulkan отличается от OpenGL. При этом WebGPU не основывается на конкретном графическом API, а представляет собой универсальную прослойку, использующую те же низкоуровневые примитивы, что имеются в Vulkan, Metal и Direct3D. WebGPU даёт возможность приложениям на языке JavaScript контролировать организацию, обработку и передачу команд к GPU, управлять связанными ресурсами, памятью, буферами, объектами текстур и скомпилированными графическими шейдерами. Подобный подход позволяет добиться более высокой производительности графических приложений за счёт снижения накладных расходов и повышения эффективности работы с GPU. При помощи WebGPU можно создавать не привязанные к конкретным платформам сложные 3D-проекты, работающие не хуже, чем обособленные программы, напрямую использующие Vulkan, Metal или Direct3D. WebGPU также предоставляет дополнительные возможности для портирования нативных графических программ в форму, способную работать в браузерах, благодаря компиляции в WebAssembly. Ключевые особенности WebGPU и отличия от WebGL:
| ||
Обсуждение (160 +25) |
Тип: К сведению |
| ||
· | 16.07.2025 | Возобновлена разработка окружения KDE Plasma Bigscreen для телевизоров (76 +22) |
Девин Лин (Devin Lin) объявил о продолжении разработки проекта Plasma Bigscreen, развивающего пользовательский интерфейс на основе технологий KDE, рассчитанный на использование на мультимедийных устройствах, подключаемых к телевизорам и проекторам. Окружение оптимизировано для работы с большими экранами и управления без клавиатуры c использованием пультов дистанционного управления или голосового помощника.
Проект активно развивался в 2020 году, после чего впал в стагнацию и не вошёл в состав KDE Plasma 6, так как не был переведён на использование библиотек KDE 6 и Qt 6 и был привязан к прекратившему существование голосовому помощнику Mycroft. Вместе с Plasma Bigscreen почти остановилась и разработка сопутствующих проектов - web-браузера Aura и мультимедийного проигрывателя Plank, поддерживающих навигацию с использованием телевизионного пульта. В сентябре прошлого года Plasma Bigscreen был переведён на технологии KDE 6 и Qt 6, но публикация новых выпусков не была возобновлена и проект опять оказался заброшен. Пару месяцев назад несколько разработчиков решили возродить проект и провели работу по модернизации интерфейса и доработке конфигуратора. Интерфейс был переведён на плоский стиль, удалены тени и фоновая заливка панелей, добавлены подсказки для индикаторов. Реализованы крупные экранные часы. Для вывода списков задействован QML-тип ListView и обеспечено кэширование отрисовки элементов. Обеспечено размывание фоновых объектов, находящихся не в фокусе. Было: ![]() Стало: ![]() Реализована функция поиска, основанная на KRunner, позволяющая находить приложения без необходимости ручного пролистывания полного списка приложений. ![]() Переработано оформление конфигуратора, в который добавлена боковая панель со списков категорий. Подготовлена библиотека для унификации оформления модулей к конфигуратору и применения горизонтальной раскладки элементов на экране. На новую библиотеку переведены модули для настройки экрана, звуковой подсистемы, Wi-Fi, оформления Bigscreen и взаимодействия со смартфоном (KDE Connect). Добавлен сервис Envmanager, позволяющий управлять настройками, специфичными для различных режимов работы KDE Plasma, и переключаться между режимами (декстоп, мобильный интерфейс и TV).
Публикацию пакетов с Plasma Bigscreen планируют наладить начиная с выпуска Plasma 6.5. До этого можно использовать сценарий сборки Plasma Bigscreen для postmarketOS или пакет plasma-bigscreen для дистрибутива Arch Linux из репозиториев nightly и AUR. Для управления через игровые контроллеры и пульты ДУ может применяться фоновый процесс из репозитория plasma-remotecontrollers. Из приложений, помимо web-браузера Aura и мультимедийного проигрывателя Plank, для управления с пульта могут использоваться flatpak-пакеты с медиацентром Kodi и интерфейсом к YouTube VacuumTube. Поддержка виртуальной клавиатуры пока отсутствует (экранная клавиатура находится в процессе разработки)
| ||
Обсуждение (76 +22) |
Тип: К сведению |
| ||
· | 15.07.2025 | PHP переходит на лицензию BSD-3, совместимую с GPL (168 +25) |
Разработчики языка программирования PHP планируют перевести интерпретатор PHP и движок Zend Engine с лицензий PHP License и Zend Engine License на 3-пунктовую лицензию BSD (BSD-3). Переход на лицензию BSD-3 упростит условия лицензирования, унифицирует лицензии для PHP и Zend Engine, обеспечит совместимость с GPL и решит давние проблемы, сохранив при этом все права пользователей и разработчиков. Смену лицензии намерены произвести в выпуске PHP 9.0, который может быть сформирован в следующем году. Все члены PHP Group одобрили смену лицензии и в настоящее время данное предложение выставлено на общее обсуждение.
Лицензия BSD-3 совместима с GPL и широко признана в сообществе, в отличие от ранее применявшихся лицензий. Лицензия PHP License одобрена организацией Open Source Initiative (OSI), но признана несовместимой с GPL Фондом СПО из-за пункта, не позволяющего без получения письменного разрешения использовать слово PHP для продвижения производных продуктов. Разработчики Debian критиковали лицензию PHP из-за привязки к продуктам PHP Group. Изначально ветки PHP 1.x и 2.x поставлялись под лицензией GPLv2, но ветка PHP 3 была переведена на использование двух лицензий - PHP License и GPL. В PHP 4 лицензия была изменена ещё раз - основной код стал распространяться только под лицензией PHP License, а движок Zend Engine, являющийся основной интерпретатора PHP, был размещён в подкаталоге "Zend/" под отдельной лицензией Zend Engine License. Zend Engine License, как и PHP License, содержит ограничения в отношении использования слова Zend в производных продуктах, но дополнительно требует упоминания использования движка в рекламных материалах. После перехода на новую лицензию авторские права всех участников разработки сохранятся, а права пользователей останутся без изменений. Новая лицензия не налагает дополнительных ограничений и не ущемляет имеющихся прав по использованию, модификации и распространению продукта. Лицензии PHP и Zend основаны на тексте 4-пунктовой лицензии BSD и переход на лицензию BSD-3 лишь приведёт к удалению пунктов, определяющих требования в отношении использования бренда "PHP", а также к прекращению действия условия, предписывающего упоминать об использовании свободного проекта PHP в производных продуктах. Переход на лицензию BSD-3 нуждается в утверждении со стороны компании Perforce Software, которой принадлежит компания Zend Technologies. Отмечается, что вопрос смены лицензии уже неформально согласован с Perforce и осталось лишь получить официальное юридически значимое письменное подтверждение. При этом смена лицензии не потребует получения отдельного согласия от каждого разработчика, так как в тексте лицензий PHP и Zend определены полномочия, позволяющие PHP Group вносить изменения в лицензию и выпускать новые версии лицензии. Процесс перехода на новую лицензию будет оформлен как обновление кода до версий PHP License v4 и Zend Engine License v3, текст которых будет совпадать с текстом лицензии BSD-3.
| ||
Обсуждение (168 +25) |
Тип: К сведению |
Интересно
| ||
· | 15.07.2025 | Подтверждены планы по слиянию Chrome OS и Android в одну платформу (139 +18) |
Самир Самат (Sameer Samat), президент Google по развитию экосистемы, связанной с Android, в интервью изданию Techradar упомянул намерения объединить Chrome OS и Android в одну платформу. В ходе общения Самир заметил у журналиста MacBook и Apple Watch, и поинтересовался, какие приложения тот применяет на своём ноутбуке и как управляется со своими устройствами, пояснив, что он спрашивает, так как Google собирается объединить Chrome OS и Android, и ему интересно как люди используют свои ноутбуки.
Ранее официальные представители Google открыто не упоминали планы по объединению Chrome OS и Android, информация о котором в ноябре 2024 года была неофициально получена от некоторых сотрудников Google. В качестве причины объединения упоминалось желание усилить конкуренцию с iPad и более эффективно использовать инженерные ресурсы, чтобы не распылять усилия на две операционные системы. Косвенным подтверждением намерений Google стала начатая в прошлом году работа по переводу системного окружения ChromeOS на вариант ядра Linux, фреймворки и системные компоненты платформы Android. В то же время в последних выпусках платформы Android началось активное развитие режима рабочего стола и возможностей для работы на устройствах с большими экранами. Операционная система ChromeOS напоминает по своей архитектуре атомарно обновляемые дистрибутивы Linux, использует ядро Linux со специфичными патчами, системный менеджер upstart и сборочный инструментарий ebuild/portage из Gentoo Linux. Несмотря на то, что пользовательское окружение ChromeOS сосредоточено на использовании web-браузера, а вместо стандартных программ задействованы web-приложения, платформа включает в себя полноценный многооконный интерфейс, рабочий стол и панель задач. Для запуска приложений, созданных для Linux и Android, используются виртуальные машины, запускаемые при помощи гипервизора CrosVM, основанного на KVM. По умолчанию в Chrome OS применяется шифрование дисковых разделов c пользовательскими данными (при помощи fscrypt), а системные разделы монтируются в режиме только для чтения, верифицируются по цифровой подписи и обновляются атомарно (два корневых раздела, рабочий и для установки обновления, которые меняются местами). Вывод на экран осуществляется при помощи графического стека Freon и оконного менеджера Aura (проектом также развивается композитный сервер Exo на базе Wayland, работающий поверх Aura). Исходный код распространяются под свободной лицензией Apache 2.0.
| ||
Обсуждение (139 +18) |
Тип: К сведению |
| ||
· | 14.07.2025 | GPUHammer - вариант атаки Rowhammer на память GPU (52 +9) |
Исследователи из Университета Торонто представили первую атаку класса Rowhammer, применяемую для искажения содержимого видеопамяти. Возможность совершения атаки, приводящей к подстановке до 8 бит данных, продемонстрирована на дискретном GPU NVIDIA A6000 с видеопамятью GDDR6. В качестве практического примера показано как можно использовать подобное искажение для вмешательства в выполнение моделей машинного обучения и существенного (с 80% до 0.1%) снижения точности выдаваемых ими результатов при изменении значения всего одного бита.
![]() До сих пор создание атак класса Rowhammer для видеопамяти было затруднено из-за сложности определения физической раскладки памяти в чипах GDDR, больших задержек при доступе к памяти (в 4 раза медленнее) и более высокой частоты обновления памяти. Кроме того, проведению исследований мешало задействование в чипах GDDR проприетарных механизмов защиты от манипуляций, приводящих к преждевременной потере заряда, для анализа которых требовалось создание специальных аппаратных тестовых стендов на базе FPGA. Для изучения видеопамяти исследователями была создана новая техника обратного инжиниринга GDDR DRAM, а в самой атаке задействованы применяемые для организации параллельных вычислений оптимизации доступа к памяти, которые были использованы в качестве усилителей интенсивности доступа к отдельным ячейкам. Для проведения атаки на GPU NVIDIA использован низкоуровневый код CUDA. В пользовательском коде CUDA не выполняется обращение по физическим адресам памяти, но в драйвере NVIDIA производилось отражение виртуальной памяти в одну и ту же физическую память, чем и воспользовались исследователи для вычисления смещения виртуальной памяти и определения раскладки банков памяти. Распознание обращений к разным банкам памяти было произведено через анализ задержек, которые отличались при доступе к одному или разными банкам памяти. В системах, совместно использующих GPU, таких как серверы для выполнения моделей машинного обучения, атака позволяет одному пользователю изменить содержимое видеопамяти с данными другого пользователя. В качестве меры защиты компания NVIDIA рекомендует включить коды коррекции ошибок (ECC, Error Correction Codes) командой "nvidia-smi -e 1" или использовать серии видеокарт с поддержкой OD-ECC (On-Die ECC), такие как GeForce RTX 50, RTX PRO, GB200, B200, B100, H100, H200, H20 и GH200. По данным исследователей включение ECC на системах с GPU A6000 приводит к снижению производительности выполнения моделей машинного обучения примерно на 10% и уменьшению объёма памяти на 6.25%. Инструментарий для проведения атаки и выполнения обратного инжиниринга низкоуровневой раскладки видеопамяти на системах с GPU NVIDIA опубликован на GitHub. Атака RowHammer позволяет исказить содержимое отдельных битов памяти DRAM путём цикличного чтения данных из соседних ячеек памяти. Так как память DRAM представляет собой двухмерный массив ячеек, каждая из которых состоит из конденсатора и транзистора, выполнение непрерывного чтения одной и той же области памяти приводит к флуктуации напряжения и аномалиям, вызывающим небольшую потерю заряда соседних ячеек. Если интенсивность чтения большая, то соседняя ячейка может потерять достаточно большой объём заряда и очередной цикл регенерации не успеет восстановить её первоначальное состояние, что приведёт к изменению значения сохранённых в ячейке данных. Метод атаки Rowhammer был предложен в 2014 году, после чего между исследователями безопасности и производителями оборудования началась игра в "кошки-мышки" - производители чипов памяти пытались блокировать уязвимость, а исследователи находили новые способы её обхода. Например, для защиты от RowHammer производители чипов добавили механизм TRR (Target Row Refresh), но оказалось, что он блокирует искажение ячеек лишь в частных случаях, но не защищает от всех возможных вариантов атаки. Методы атаки были разработаны для чипов DDR3, DDR4 и DDR5 на системах с процессорами Intel, AMD и ARM. Также были найдены способы обхода коррекции ошибок ECC и предложены варианты совершения атаки по сети и через выполнение JavaScript-кода в браузере.
| ||
Обсуждение (52 +9) |
Тип: Проблемы безопасности |
| ||
Следующая страница (раньше) >> |
Закладки на сайте Проследить за страницей |
Created 1996-2025 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |