OpenNews.opennet.ru: Основная лента (RSS Feed)

OpenNews - Новости мира открытых систем (Основная лента)

https://www.opennet.me/opennews/

Last Notes

2026-05-25 08:44:29 UTC

В nginx выявлена вторая за 10 дней удалённо эксплуатируемая уязвимость
Сформированы (https://github.com/nginx/nginx/releases/tag/release-1.31.1) корректирующие выпуски nginx 1.31.1 (https://nginx.org/) и 1.30.2 (https://github.com/nginx/nginx/releases/tag/release-1.30.2), в которых устранена критическая уязвимость (https://my.f5.com/manage/s/article/K000161377) (CVE-2026-9256 (https://www.cve.org/CVERecord?id=CVE-2026-9256)), позволяющая удалённо добиться выполнения кода с правами рабочего процесса nginx через отправку специально оформленного HTTP-запроса. Выявившие проблему исследователи продемонстрировали (https://twitter.com/nebusecurity/status/2057071579876753643) рабочий эксплоит с обходом ASLR, который будет опубликован вместе с полным описанием спустя 30 дней после исправления. Уязвимость получила кодовое имя nginx-poolslip. Проблема проявляется начиная с версии nginx 0.1.17, выпущенной в феврале 2005 года. Для angie (https://github.com/webserver-llc/angie/tags) и freenginx (https://freenginx.org/) на момент написания новости исправления не опубликованы.
Как и устранённая (https://www.opennet.me/opennews/art.shtml?num=65442) на прошлой неделе похожая проблема, новая уязвимость вызвана переполнением буфера в модуле ngx_http_rewrite_module и проявляется в конфигурациях с определёнными регулярными выражениями в директиве "rewrite". В данном случае уязвимость затрагивает системы с перекрывающимися шаблонами для подстановки (скобки в скобках) в rewrite-выражении, например, "^/((.*))$" или "^/(test([123]))$", в сочетании с использованием нескольких неименованных подстановок в заменяющей строке (например, "$1$2").
Дополнительно можно отметить выпуск njs 0.9.9 (http://nginx.org/en/docs/njs/), модуля для интеграции интерпретаторов языка JavaScript в http-сервер nginx. В новой версии устранена уязвимость (https://my.f5.com/manage/s/article/K000161307) (CVE-2026-8711 (https://www.cve.org/CVERecord?id=CVE-2026-8711)), проявляющаяся (https://github.com/nginx/njs/commit/dea83189) начиная с версии njs 0.9.4. Проблема вызвана переполнением буфера и проявляется в конфигурациях с директивой js_fetch_proxy (https://nginx.org/en/docs/http/ngx_http_js_module.html#js_fetch_proxy), содержащей переменные nginx с данными из клиентского запроса (например, $http_*, $arg_* и $cookie_*), в сочетании с использованием location-обработчика, вызывающего функцию ngx.fetch(). Уязвимость можно эксплуатировать для выполнения кода с правами рабочего процесса nginx через отправку специально оформленного HTTP-запроса.
Источник: http://www.opennet.me/opennews/art.shtml?num=65505 (http://www.opennet.me/opennews/art.shtml?num=65505)
https://www.opennet.me/opennews/art.shtml?num=65505

2026-05-25 08:44:28 UTC

Релиз дистрибутива TileOS 2.0
Доступен (https://mastodon.social/@tile_os) выпуск дистрибутива TileOS 2.0 "Sauropod" (https://tile-os.com/), построенного на пакетной базе Debian и предлагающего рабочий стол, использующий мозаичные оконные менеджеры. TileOS преследует те же цели, что и дистрибутив Ubuntu Sway Remix (https://www.opennet.me/opennews/art.shtml?num=60017) (развивается тем же автором), предлагая готовый к использованию интерфейс, не требующий дополнительной настройки и ориентированный как на опытных пользователей Linux, так и на новичков, желающих попробовать окружение мозаичных оконных менеджеров, не тратя большое количество времени на их настройку.
В отличии от Ubuntu Sway Remix, TileOS гораздо более открыт для различных изменений и кастомизаций, а также избавлен от каких-либо потенциальных проблем с авторскими правами (Ubuntu Sway Remix использует зарегистрированные товарные знаки Canonical, но официального ответа по поводу включения дистрибутива в официальное семейство Ubuntu до сих пор не получено). Для загрузки подготовлены (https://downloads.tile-os.com/stable/) сборки для архитектуры amd64 (в будущем планируется обеспечить поддержку arm64, в частности плат Raspberry Pi). Исходный код компонентов TileOS распространяется (https://git.tile-os.com/TileOS) по лицензии GNU GPLv3.
Основное внимание в TileOS уделяется оконным менеджерам, использующим протокол Wayland. Официально представлены редакции с рабочими столами Sway (https://swaywm.org/), River (https://codeberg.org/river/river), Qtile (https://qtile.org/), MiracleWM (https://miracle-wm.org/) и Niri (https://niri-wm.github.io/niri/). Дистрибутив использует пакетную базу Debian Stable, однако из тестовой ветки переносятся различные улучшения, более свежие версии некоторого ПО и графических драйверов. Помимо этого, в состав включён ряд исправлений (https://git.tile-os.com/TileOS/tileos-system-adjustments), оптимизирующих работу дисковой подсистемы и памяти, а также перенесены некоторые улучшения из Ubuntu, например монтирование дисков в файловом менеджере без запроса пароля, и другие.
https://www.opennet.me/opennews/pics_base/CFD0C5CECEC5D4_1779515697.png
(https://files.mastodon.social/media_attachments/files/116/602/256/941/102/637/original/78012092bee337a3.png)
В новом выпуске:
- Пакетная база обновлена до Debian 13. По умолчанию задействовано штатное ядро Debian, с поддержкой Secure Boot. Опционально доступна установка ядра Liquorix (https://liquorix.net/), оптимизированного для десктопных задач;
- Для установки и обновления ядра Linux добавлена утилита tileos-kernel-manager (https://git.tile-os.com/TileOS/tileos-kernel-manager);
- По умолчанию задействована утилита sudo-rs (https://github.com/trifectatechfoundation/sudo-rs) - вариант sudo, переписанный на языке Rust;
- В качестве DNS-резолвера задействован systemd-resolved, а в качестве dhcp-клиента - dhcpcd5;
- Добавлена утилита TileOS Welcome (https://git.tile-os.com/TileOS/tileos-welcome), позволяющая произвести начальную настройку системы;
- При автоматической разметке диска, по умолчанию задействована файловая система Btrfs. Добавлена поддержка установки на раздел с файловой системой F2FS;
- Хранитель экрана swaylock заменен на gtklock (https://github.com/jovanlanik/gtklock);
- В состав системы включены программа резервного копирования Timeshift и инструменты для работы с Btrfs;
- В состав системы включён демон Kdeconnect, обеспечивающий синхронизацию с мобильными устройствами;
- Переписаны и оптимизированы пользовательские скрипты, для автозапуска большинства компонентов задействованы штатные возможности systemd;
- В панель Waybar добавлен модуль power-profiles-daemon, для быстрого переключения режимов энергосбережения;
- Добавлен компонент swaykbdd (https://github.com/artemsen/swaykbdd) для реализации раздельных раскладок клавиатуры для каждого окна;
- Добавлен компонент SwayOSD (https://github.com/ErikReider/SwayOSD), обеспечивающий вывод экранного индикатора при изменении уровня громкости или яркости экрана, а также состояния клавиши Caps Lock;
- Предустановлен и включён по умолчанию пакетный менеджер Flatpak;
- Мелкие улучшения в заставке Plymouth;
- Обновлена утилита Sway Input Configurator (https://github.com/Sunderland93/sway-input-config), в которой устранены мелкие ошибки и началась подготовка к обеспечению поддержки других Wayland-композиторов, таких как MiracleWM.
Добавлены две новые экспериментальные редакции:
- Niri Edition - использует рабочий стол Niri, написанный на языке Rust и реализующий метод мозаичной компоновки в стиле GNOME-расширения PaperWM, в котором окна группируются в бесконечно прокручиваемую на экране ленту. В Niri Edition задействованы все типовые компоненты TileOS, такие как панель Waybar. В будущем рассматривается задействование оболочки Dank Material Shell.
https://www.opennet.me/opennews/pics_base/CFD0C5CECEC5D4_1779515724.png
(https://files.mastodon.social/media_attachments/files/116/602/259/075/710/930/original/38fb0dc6c7819d62.png)
- Miracle Edition - использует рабочий стол MiracleWM, построенный на базе библиотеки Mir. MiracleWM предоставляет интерфейс в стиле Sway, при этом реализуя различные графические эффекты (анимации переключения окон, полупрозрачность и т.д). Конфигурация осуществляется в формате YAML. Поскольку MiracleWM все ещё в стадии активной разработки - очень многие возможности ещё не реализованы, а стабильная работа не гарантируется.
https://www.opennet.me/opennews/pics_base/CFD0C5CECEC5D4_1779515733.png
(https://files.mastodon.social/media_attachments/files/116/602/259/843/953/313/original/864759e35aedd624.png)
Помимо этого сформирован выпуск TileOS 1.4 "T-Rex", в который включены накопившиеся обновления, в том числе с устранением недавно обнаруженных уязвимостей в ядре Linux.
Источник: http://www.opennet.me/opennews/art.shtml?num=65507 (http://www.opennet.me/opennews/art.shtml?num=65507)
https://www.opennet.me/opennews/art.shtml?num=65507

2026-05-25 08:44:28 UTC

GRO Frag - седьмая уязвимость класса Copy Fail, предоставляющая права root в Linux
В открытом доступе размещён эксплоит (https://gist.github.com/lcfr-eth/2566a5cef312c94a5ff8d62fa417955f) для седьмой уязвимости (1 (https://www.opennet.me/opennews/art.shtml?num=65325), 2-3 (https://www.opennet.me/opennews/art.shtml?num=65395), 4 (https://www.opennet.me/opennews/art.shtml?num=65441), 5 (https://www.opennet.me/opennews/art.shtml?num=65473), 6 (https://www.opennet.me/opennews/art.shtml?num=65476)) в ядре Linux, позволяющей непривилегированному локальному пользователю получить права root, перезаписав данные в страничном кэше. CVE-идентификатор ещё не присвоен, кроме кода эксплоита информации о проблеме пока нет. Исправление доступно только в виде патча (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4db79a322db8), который опубликован 20 мая и 21 мая был принят в основную ветку ядра Linux (корректирующие выпуски (https://kernel.org) ядра ещё недоступны).
Уязвимость присутствует в реализации технологии GRO (https://docs.kernel.org/networking/segmentation-offloads.html) (Generic Receive Offload), применяемой для ускорения обработки сегментированных пакетов. Уязвимость вызвана ошибкой в реализации механизма zerocopy в функции skb_gro_receive(), осуществляющей прямое изменение данных в страничном кэше для исключения лишней буферизации. При установленном флаге SKBFL_MANAGED_FRAG_REFS пропускалось сохранение ссылки на освобождаемые страницы памяти в поле shinfo->frags, после чего данное поле присоединялось к другому skb без изменения счётчика ссылок, что приводило к обращению к памяти после её освобождения (use-after-free). Проблему удалось эксплуатировать для перезаписи данных в страничном кэше, благодаря манипуляции с указателем на буфер io_uring.
Атака возможна на системы с включённой подсистемой io_uring (io_uring_disabled=0). Для работы эксплоита в системе должен быть доступный на чтение исполняемый файл с флагом SUID-root. Механизм эксплуатации сводится к тому, что атакующий добивается оседания базы пользователей в страничном кэше, после чего подставляет в кэш строку "hax::0:0::/root:/bin/sh". Следом запускается команда "su hax", которая получает не оригинальную базу пользователей с накопителя, а изменённую копию с подставным логином "hax", которому выставлены права root и пустой пароль. Работа эксплоита протестирована в Ubuntu 24.04.
Источник: http://www.opennet.me/opennews/art.shtml?num=65504 (http://www.opennet.me/opennews/art.shtml?num=65504)
https://www.opennet.me/opennews/art.shtml?num=65504

2026-05-25 08:44:27 UTC

Доступен GNOME Commander 2.0, переписанный на Rust и сменивший лицензию на GPLv3
Состоялся (https://gitlab.gnome.org/GNOME/gnome-commander/-/releases/2.0.0) релиз двухпанельного файлового менеджера GNOME Commander 2.0 (http://gcmd.github.io/), оптимизированного для использования в пользовательском окружении GNOME. GNOME Commander представляет такие возможности как вкладки, доступ к командной строке, закладки, изменяемые цветовые схемы, режим пропуска каталогов при выделении файлов, доступ к внешним данным через SFTP и SAMBA, расширяемые контекстные меню, автоматическое монтирование внешних накопителей, доступ к истории навигации, поддержка плагинов, встроенный просмотрщик текста и изображений, функции поиска, переименования по маске и сравнения каталогов. Код распространяется (https://gitlab.gnome.org/GNOME/gnome-commander/) под лицензией GPLv3.
В новой версии:
- Кодовая база переписана c C++ на Rust.
- Осуществлён переход с библиотеки GTK3 на GTK4.
- Лицензия на код изменена с GPLv2 на GPLv3.
- 17 мая сопровождающим проект назначен (https://gitlab.gnome.org/GNOME/gnome-commander/-/commit/39ff8f38a668cddda1164beff48bf7dc0a6d9d5e) Владимир Палант (Wladimir Palant (https://palant.info/)), в своё время создавший блокировщик рекламы Adblock Plus (https://adblockplus.org/).
- В приложение встроен эмулятор терминала, отображающий вывод запускаемых команд. В меню View добавлена опция для автоматического скрытия терминала при его неактивности.
- Переделана панель быстрого поиска, которая может использоваться и для фильтрации списка показываемых файлов. Поисковый запрос применяется к любым частям имени файла, если явно не заданы маски "*" и "?". Добавлена кнопка для поиска с учётом регистра символов. По умолчанию поиск стартует не с начала списка, а с текущей позиции в нём.
- Повышена производительность и расширены возможности диалога поиска. Закрытие диалога не приводит к очистке результатов поиска. В процессе поиска индикатор прогресса показывает путь, в котором осуществляется поиск в данный момент.
- Во встроенном просмотрщике унифицирована обработка кодировок файлов, добавлена настройка для смены шрифта, диалог поиска заменён на панель поиска, реализован поиск шестнадцатеричных значений без учёта регистра символов, добавлена команда для выделения всего текста ("Select All"), реализовано контекстное меню для изображений.
Бинарный режим просмотра переименован в "Fixed Width" и поддерживает UTF-8.
- Для людей, имеющих проблемы со зрением, обеспечена полноценная поддержка работы с использованием экранного ридера, который распознаёт контекст разных функций приложения.
- При восстановлении сеанса реализовано восстановление состояния выделенных файлов, порядка сортировки, скрытия и изменения размера столбцов в панелях.
https://www.opennet.me/opennews/pics_base/CFD0C5CECEC5D4_1779518050.png
(https://gnome.pages.gitlab.gnome.org/gnome-commander/images/screenshot-740-light.png)
https://www.opennet.me/opennews/pics_base/CFD0C5CECEC5D4_1779517983.png
(https://thisweek.gnome.org/_astro/commander.DZi49Kc3_Z1cLSkU.webp)
Источник: http://www.opennet.me/opennews/art.shtml?num=65509 (http://www.opennet.me/opennews/art.shtml?num=65509)
https://www.opennet.me/opennews/art.shtml?num=65509

2026-05-25 08:44:26 UTC

При помощи AI-модели Mythos выявлены 23 тысячи уязвимостей в открытом ПО
Компания Anthropic подвела (https://www.anthropic.com/research/glasswing-initial-update) первые итоги тестирования предварительного варианта AI-модели Mythos, в которой были существенно (https://www.opennet.me/opennews/art.shtml?num=65165) расширены возможности по поиску ошибок, выявлению уязвимостей и написанию готовых эксплоитов. Компания Anthropic при помощи AI-модели Mythos провела сканирование более тысячи важных открытых проектов, в ходе которого было выявлено 23019 уязвимостей. 6202 уязвимостям был назначен высокий или критический уровень опасности.
1752 из 6202 уязвимостей, отнесённых AI-моделью Mythos к категории опасных, были проверены независимыми компаниями, специализирующимися на компьютерной безопасности. В 1587 случаях (90.6%) наличие уязвимости было подтверждено, а в 1094 (62.4%) - сохранился высокий или критический уровень опасности. При текущих показателях ложных срабатываний предполагается, что из 6202 заявленных AI-моделью опасных уязвимостей примерно 3900 (62.4%) сохранят выбранный моделью высокий уровень опасности, не считая опасных уязвимостей найденных отдельно при проверке 50 участниками проекта Glasswing.
Сведения об 467 верифицированных уязвимостях переданы сопровождающим открытые проекты представителями компаний, проводивших рецензирование. По отдельным запросам сотрудники Anthropic напрямую передали сопровождающим информацию о 1129 непроверенных проблемах. Всего сопровождающие 281 открытого проекта получили сведения (https://red.anthropic.com/2026/cvd/) о 1596 проблемах и подтвердили наличие 1451 уязвимостей. При этом в кодовых базах пока исправлено только 97 проблем и выпущено 88 публичных отчётов (https://red.anthropic.com/2026/cvd/#cves-section) об уязвимостях.
Кроме того, сообщается, что 50 участников проекта Glasswing, которым был предоставлен ранний доступ к модели Mythos, выявили в своих кодовых базах более 10 тысяч опасных уязвимостей. Например, компания Cloudflare нашла при помощи Mythos более 2000 ошибок, из которых 400 отмечены как уязвимости с высоким и критическим уровнем опасности. Уровень ложных срабатываний по оценке Cloudflare оказался ниже, чем при тестировании людьми. Компания Mozilla при проверке кода Firefox 150 нашла (https://www.opennet.me/opennews/art.shtml?num=65405) при помощи Mythos 271 уязвимость, что в 10 раз больше, чем было найдено при проверке Firefox 148 моделью Claude Opus 4.6.
В качестве примера уже исправленной критической проблемы приводится
уязвимость (https://www.wolfssl.com/how-claude-mythos-preview-helped-harden-wolfssl/) (CVE-2026-5194 (https://nvd.nist.gov/vuln/detail/CVE-2026-5194)) в криптографической библиотеке wolfSSL (https://www.wolfssl.com/). Mythos смог подготовить эксплоит, позволяющий атакующему сформировать поддельный ECDSA-сертификат для сайтов и почтовых серверов, который при проверке библиотекой wolfSSL обрабатывался как корректный. Проблема была вызвана отсутствием в коде проверки размера хэша и OID, что позволяло указать в сертификате хэш, размером меньше допустимого.
Источник: http://www.opennet.me/opennews/art.shtml?num=65515 (http://www.opennet.me/opennews/art.shtml?num=65515)
https://www.opennet.me/opennews/art.shtml?num=65515

2026-05-25 08:44:26 UTC

Введён в строй официальный каталог Godot Asset Store, интегрированный с движком Godot
После нескольких лет работы и нескольких месяцев бета-тестирования представлен (https://godotengine.org/article/introducing-the-godot-asset-store/) официальный магазин-каталог ассетов и плагинов для игрового движка Godot (https://www.opennet.me/opennews/art.shtml?num=64682) - Godot Asset Store (https://store.godotengine.org/), который пришёл на смену библиотеке ассетов (Asset Library). Новый каталог примечателен полной интеграцией с движком Godot и его поддержка уже добавлена в ветку Godot 4.7, находящуюся на стадии бета тестирования. В каталоге пока поддерживается размещение только бесплатных ассетов, поддержку размещения платных продуктов и систему донатов обещают добавить позднее.
Из новых возможностей, по сравнению с Asset Library, отмечается появление рейтинга и рецензирования ассетов, доступ к аналитике о загрузках, возможность предоставления нескольких версий для загрузки, добавление страницы со списком изменений и поддержка привязки тегов к ассетам, включая собственные теги. При доступе в Asset Store используется общая с инфраструктурой Godot система учётных записей, например, если у пользователя есть учётная запись в форуме, то ему не нужно создавать отдельный аккаунт в Asset Store.
Разработчикам рекомендуется начать переносить свои ассеты из
Asset Library в Asset Store. Автоматически такой перенос решили не производить из-за необходимости получения разрешения от каждого автора на миграцию, переноса на свой хостинг файлов со сторонних ресурсов и нежелании переносить давно не поддерживаемые устаревшие ассеты. В дальнейшем доступ к каталогу Asset Library будет сохранён для поддержки старых версий движка Godot, но будет переведён в режиме только для чтения.
Изначально организация Godot Foundation не хотела создавать собственный официальный каталог ассетов и полагалась на экосистему и существующие платформы, такие как itch.io (https://itch.io/), но в конечном счёте из-за ряда проблем изменила свои намерения. Запуск Asset Store избавит сообщество от путаницы с магазинами приложений (многие пользователи не понимали, какой из магазинов рекомендован Godot Foundation), решит проблемы с авторскими правами и злоупотреблениями (некоторые каталоги размещали платные версии бесплатных ассетов без информации об авторстве) и позволит избавиться от технического долга (в Asset Library использовалась своя система учётных записей, не интегрированная с остальными сервисами Godot).
Исходный код игрового движка Godot был открыт (https://www.opennet.me/opennews/art.shtml?num=39053) в 2014 году студией OKAM (https://web.archive.org/web/20171003053858/https://okamgames.com/), после десяти лет развития проприетарного продукта профессионального уровня, который использовался для создания и публикации многих игр (https://web.archive.org/web/20181017194214/http://okamgames.com/portfolio) для PC, игровых консолей и мобильных устройств. Движок подходит для создания 2D- и 3D-игр, предоставляет простой для изучения язык задания игровой логики, графическую среду для проектирования игр, систему развёртывания игр в один клик, возможности анимации и симуляции физических процессов, встроенный отладчик и систему выявления узких мест в производительности. Код игрового движка, среды проектирования игр и сопутствующих средств разработки (физический движок, звуковой сервер, бэкенды 2D/3D рендеринга и т.п.) распространяется (https://github.com/okamstudio/godot/) под лицензией MIT.
Источник: http://www.opennet.me/opennews/art.shtml?num=65506 (http://www.opennet.me/opennews/art.shtml?num=65506)
https://www.opennet.me/opennews/art.shtml?num=65506

2026-05-25 08:44:25 UTC

Выполнено дизассемблирование микрокода i386 и создан открытый CPU z386
Энтузиасты смогли (https://www.reenigne.org/blog/80386-microcode-disassembled/) успешно извлечь и дизассемблировать микрокод процессора Intel 80386, который из-за отсутствия документации считался "чёрным ящиком". Бинарный образ микрокода был воссоздан с привлечением AI по фотографиям кристалла в высоком разрешении, а логика работы разобрана через трассировку соединений на кристалле. Постепенно были определены структура микрокоманд (μ-ops), поля, порядок исполнения и маркеры конца инструкций. Наработки проекта опубликованы (https://github.com/reenigne/x86_microcode/tree/main/80386) на GitHub как общественное достояние.
https://www.opennet.me/opennews/pics_base/CFD0C5CECEC5D4_1779562758.jpg
(https://nand2mario.github.io/posts/2026/z386/80386-die-labeled-units.jpg)
Выявлено, что в CPU 80386 каждая инструкция полностью исполняется через микрокод, в то время как в 8086 и современных процессорах часть инструкций обрабатывается напрямую. Кроме того, в отличие от процессоров 8086, в 80386 микрокод не реализует алгоритмы напрямую, а в основном настраивает аппаратные ускорители (умножитель, делитель, быстрый сдвиг (https://ru.wikipedia.org/wiki/Barrel_shifter), PTU (Protection Test Unit)).
В ходе исследования также была обнаружена возможная проблема с безопасностью при обработке битовой карты прав доступа к вводу/выводу (IO permission bitmap): при 4-байтовом обращении к портам проверялись биты прав доступа только для первых 3 байтов, а доступ к 4-му байту не проверялся, что теоретически допускало обращение к аппаратным регистрам, доступ к которым должен был быть запрещён.
На основе опубликованного микрокода разработан (https://nand2mario.github.io/posts/2026/z386/) открытый CPU z386 (https://github.com/nand2mario/z386), реализованный на языке SystemVerilog и работающий с использованием FPGA. Вместо реализации каждой инструкции в форме отдельного RTL (https://ru.wikipedia.org/wiki/%D0%A3%D1%80%D0%BE%D0%B2%D0%B5%D0%BD%D1%8C_%D1%80%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80%D0%BE%D0%B2%D1%8B%D1%85_%D0%BF%D0%B5%D1%80%D0%B5%D0%B4%D0%B0%D1%87) (Register-transfer level) в z386 реализованы аппаратные структуры, которыми управляет оригинальный микрокод. Производительность подготовленной реализации соответствует быстрому 386 ПК (~70MHz). Под управлением z386 удалось успешно запустить DOS 6/7, DOS/4GW, DOS/32A и игры, такие как Doom и Cannon Fodder.
Источник: http://www.opennet.me/opennews/art.shtml?num=65513 (http://www.opennet.me/opennews/art.shtml?num=65513)
https://www.opennet.me/opennews/art.shtml?num=65513

2026-05-25 08:44:25 UTC

Благодаря AI для включения в ядро Linux стали присылать на 20% больше изменений
На конференции Open-Source Summit 2026 (https://events.linuxfoundation.org/open-source-summit-north-america/) во вступительной беседе (https://osselcna2026.sched.com/event/b8eb6b0707c907a32cfe6ce4a909cc6d#sched-content) Линус Торвальдс рассказал (https://www.zdnet.com/article/linus-torvalds-has-a-love-hate-relationship-with-ai/) о тенденциях в использовании AI-инструментов при разработке ядра Linux. По словам Линуса, за последние шесть месяцев значительно увеличился объём коммитов. Например, при формировании последних двух релизов ядра внесено примерно на 20% больше коммитов, чем в ранее выпускавшихся ветках. Изменение объясняется тем, что за последние несколько месяцев AI-инструменты доросли до уровня качества, приемлемого для многих разработчиков, и теперь наблюдается явный рост применения AI практически по всем направлениям разработки.
Обилие присылаемых последнее время отчётов об ошибках, выявленных при помощи AI-ассистентов, Линус охарактеризовал как краткосрочную боль, которая принесёт пользу в долгосрочной перспективе - любая выявленная и исправленная ошибка лучше, чем остающаяся незамеченной. Для небольших команд и одиночных сопровождающих шквал сгенерированных через AI сообщений об ошибках становится проблемой и приводит к выгоранию, особенно когда подобные отчёты отправляются без проверки, а отправивший их не способен ответить на вопросы и предоставить дополнительную информацию.
По поводу AI Линус высказался, что это всего лишь ещё один инструмент, повышающий эффективность работы и меняющий способ разработки, но не меняющий принципы программирования. Когда-то появление компиляторов и высокоуровневых языков повысило производительность разработки в 1000 раз и избавило разработчиков от необходимости вводить дампы машинных кодов и вычислять смещения для операций ветвления. Примерно также AI позволяет повысить производительность, беря на себя выполнение рутинной работы и оставляя разработчику постановку задач и проверку результата. При этом важно, чтобы разработчик не только умел формировать запросы, но и имел компетенцию для оценки и проверки результата. AI-ассистент рассматривается как новое звено перед компилятором, который, в своё время, для упрощения разработки стал звеном перед ассемблером.
Источник: http://www.opennet.me/opennews/art.shtml?num=65517 (http://www.opennet.me/opennews/art.shtml?num=65517)
https://www.opennet.me/opennews/art.shtml?num=65517

2026-05-25 08:44:24 UTC

Нарушение AGPL производителем 3D-принтеров Bambu Lab и создание форка Bambu Studio
В ответ на недавние угрозы (https://www.opennet.me/opennews/art.shtml?num=65299) разработчику, вернувшему возможность прямой печати на 3D-принтерах Bambu Lab без использования проприетарного приложения Bambu Connect, правозащитная организация Software Freedom Conservancy (SFC) объявила (https://sfconservancy.org/news/2026/may/18/bambu-studio-3d-printer-agpl-violation-response/) о проведении расследования возможных нарушений свободных лицензий в ПО и прошивках компании Bambu Lab. Помимо этого, запущена инициатива по отстаиванию права (https://www.ifixit.com/Right-to-Repair) самостоятельно проводить ремонт, в рамках которой началась работа по обратному инжинирингу проприетарных библиотек Bambu Lab и создан независимый форк платформы Bambu Studio.
Развиваемый компанией Bambu Lab пакет Bambu Studio (https://github.com/bambulab/BambuStudio) является форком свободного проекта Prusa Slicer (https://github.com/prusa3d/prusaslicer) и так же как исходный проект распространяется под лицензией AGPLv3. В выпущенное год назад обновление прошивки к 3D-принтерам Bambu Lab было внесено изменение, блокирующее возможность прямой печати. После обновления прошивки для продолжения работы с 3D-принтером в альтернативных пакетах подготовки моделей к 3D-печати, таких как OrcaSlicer (https://github.com/OrcaSlicer/OrcaSlicer), требовалась установка дополнительного проприетарного приложения Bambu Connect, без которого послойный вывод на печать перестал работать.
Один из энтузиастов реализовал для OrcaSlicer возможность напрямую отправлять команды 3D-принтерам Bambu Lab без необходимости установки Bambu Connect, но компания Bambu Studio под угрозой судебного разбирательства вынудила (https://www.opennet.me/opennews/art.shtml?num=65299) разработчика удалить репозиторий с созданным кодом, при том, что реализованный энтузиастом метод прямой отправки команд на 3D-принтеры был основан на содержимом из репозитория AGPL-проекта Bambu Studio.
Организация SFС трактовала данный шаг как ущемление прав, предоставляемых лицензией AGPLv3. При давлении на энтузиаста компания Bambu Lab применила тактику запугивания и утверждала, что условия использования продукта (terms of service) превалируют над требованиями AGPLv3, что является нарушение пункта 10.3 лицензии AGPL. Данный пункт запрещает налагать дополнительные ограничения, мешающие осуществлению прав, предоставленных лицензией.
Помимо этого, правозащитная организация SFC выявила прямое нарушения условий лицензии AGPLv3 в приложении Bambu Studio, в котором используется библиотека libbambu_networking, исходный код которой не предоставляется. Так как Bambu Studio является ответвлением от другого открытого AGPL-проекта, он должен распространяться строго под исходной лицензией APGLv3 и не имеет права вносить в неё исключения. Соответственно, все компоненты должны быть доступны в исходном коде без дополнительных ограничений и комбинирование AGPL-кода с проприетарной библиотеке в одном продукте недопустимо. Библиотека libbambu_networking загружается через интерактивный запрос в интерфейсе пользователя, но подобный манёвр не позволяет обойти условия AGPL.
Для оказания помощи пользователям 3D-принтеров, испытывающим трудности из-за нарушений AGPLv3 компанией Bambu Lab, создан проект baltobu (https://f.sfconservancy.org/baltobu), в рамках которого под защитой SFC создано три репозитория:
- reverse-networking (https://f.sfconservancy.org/baltobu/reverse-networking) - проект по обратному инжинирингу библиотек libbambu_networking.so, bambu_networking.dll и libbambu_networking.dylib, и создания их открытой замены. Подразумевается, что так как данные библиотеки используются в коде под лицензией AGPLv3, на них тоже распространяется данная лицензия, что даёт право на проведение обратного инжиниринга.
- orca-slicer-for-bambu (https://f.sfconservancy.org/baltobu/orca-slicer-for-bambu) - репозиторий для продолжения работы над форком OrcaSlicer, поддерживающим прямую работу с 3D-принтерами Bambu Lab. Репозиторий воссоздаёт код проекта OrcaSlicer-bambulab, который ранее был удалён после угроз от Bambu Lab.
- Viscose (https://f.sfconservancy.org/baltobu/viscose) - репозиторий c форком ПО Bambu Studio, гарантирующий сохранение предоставляемых AGPL свобод и прав пользователей, а также поддерживающий открытую кодовую базу на случай, если компания Bambu Lab решит что-то удалить из своего репозитория.
Источник: http://www.opennet.me/opennews/art.shtml?num=65511 (http://www.opennet.me/opennews/art.shtml?num=65511)
https://www.opennet.me/opennews/art.shtml?num=65511

2026-05-25 08:44:23 UTC

Во Flatpak намерены сделать systemd обязательной зависимостью
На конференции Linux App Summit Себастьян Вик (Sebastian Wick), мэйнтейнер инструментария Flatpak, и Адриан Вовк (Adrian Vovk), создатель инсталлятора для GNOME OS и один из разработчиков systemd-homed и systemd-sysupdate, выступили с докладом (https://www.youtube.com/watch?app=desktop&v=1AXBfsiaQNk&t=16218s) о будущем системы самодостаточных пакетов Flatpak. В докладе упоминается намерение (https://youtu.be/1AXBfsiaQNk?t=17746) создать для нужд Flatpak новый процесс systemd-appd (https://blog.sebastianwick.net/posts/flatpak-happenings/), который будет предоставлять информацию о запущенных экземплярах приложений.
В systemd-appd будет реализована функциональность для назначения приложениям идентификаторов и хранения привязанных к этим идентификаторам полномочий. Использование systemd-appd позволит решить проблемы с надёжной аутентификацией запущенных Flatpak-приложений и определением какое именно приложение пытается получить доступ к системным ресурсам. Благодаря systemd-appd появится возможность использования вложенных sandbox-окружений (например, для дополнительной изоляции процессов в браузерах), реализовать поддержку мультимедийного сервера PipeWire и избавиться от D-Bus прокси, применяемого для фильтрации доступа к системным сервисам.
В докладе также представлен проект Flatpak Next (Flatpak 2.0), в котором планируют переделать архитектуру Flatpak с учётом накопленного опыта и с использованием современных технологий. При этом поддержку systemd-appd планируют добавить не дожидаясь Flatpak Next в ветку Flatpak 1.x.
На вопрос (https://fosstodon.org/@[email protected]/116629547244779517) станет ли systemd-appd обязательной зависимостью во Flatpak, Адриан Вовк ответил (https://fosstodon.org/@AdrianVovk/116629630385486477), что изначально он намеревался очень внимательно отнестись к системам без systemd, но после обрушившейся на него агрессивной критики, возникшей на пустом месте (разработка пока находится только в планах и ни одной строчки кода systemd-appd не написано), он не намерен тратить своё время на поддержку систем без systemd.
На аналогичный вопрос, Джорж Кастро (Jorge Castro), менеджер по взаимодействию с сообществом в проекте FlatHub, подтвердил (https://transfem.social/notes/amkk9ypcps9a002q), что systemd станет обязательной зависимостью во Flatpak.
Источник: http://www.opennet.me/opennews/art.shtml?num=65522 (http://www.opennet.me/opennews/art.shtml?num=65522)
https://www.opennet.me/opennews/art.shtml?num=65522