| · | 12.05.2025 | Проект Planka переходит на несвободную лицензию (133) |
|
Проект Planka, предлагающий запускаемый на собственном оборудовании сервис канбан-доски для организации командной работы и отслеживания задач, перешёл на несвободную лицензию. Изначально проект использовал лицензию Expat/MIT, в 2023 году перешёл на лицензию AGPLv3, а теперь задействовал несвободную лицензию "Fair Use License", основанную на "Sustainable Use License". Смена лицензии произведена во втором кандидате в релизы Planka 2.0, таким образом ветка 2.0 будет проприетарной.
Автор проекта считает дискуссию о смене лицензии закрытой. Разработчики уверяют, что "для большинства пользователей community-версии продукта ничего не изменится", умалчивая о том, что новая лицензия не одобрена организацией OSI и Фондом СПО, так как не соответствует определению Open Source и критериям Свободного ПО. Лицензия Fair Use License допускает использование и модификацию исходного кода только при персональном использовании, в процессе обучения или для обеспечения работы внутренних процессов в компании. Использование кодовой базы для создания платных продуктов или для запуска сервисов, предлагаемых третьим лицам (например, предоставление доступа других юридических лиц к развёрнутому экземпляру Planka), запрещено без покупки отдельной коммерческой лицензии. Тем временем, более двух лет (с момента перехода проекта Planka на лицензию AGLPv3) активно разрабатывается форк 4gaBoards, продолжающий использовать лицензию Expat/MIT. В форке реализован ряд новых функции, отсутствующих в Planka, среди которых: расширенные возможности кастомизации интерфейса (сворачивание колонок, отображение в виде списка); средства для интеграции с внешними сервисами (включая способы авторизации и синхронизацию); боковая панель для навигации между проектами и досками; шаблоны досок. 
| ||
| · | 11.05.2025 | Доступен OpenSearch 3.0, форк платформы Elasticsearch (31 +12) |
|
Некоммерческая организация OpenSearch Software Foundation, контролируемая Linux Foundation, опубликовала релиз проекта OpenSearch 3.0, развивающего форк платформы поиска, анализа и хранения данных Elasticsearch и web-интерфейса Kibana. В разработке форка принимают участие такие компании, как Amazon, SAP, Uber, Aryn, Atlassian, Canonical, DigitalOcean и NetApp. Код распространяется под лицензией Apache 2.0.
Форк был создан в 2021 году в ответ на перевод проекта Elasticsearch на несвободную лицензию SSPL (Server Side Public License) и прекращение публикации изменений под старой лицензией Apache 2.0. Несмотря на возвращение Elasticsearch на использование свободной лицензии, проект OpenSearch не потерял актуальность, так как в нём продолжено использование пермиссивной лицензии Apache 2.0 вместо лицензии AGPLv3, на которую перешёл Elasticsearch, а также развивается ряд специфичных надстроек, ранее поставлявшихся компанией Amazon в отдельном дистрибутиве Open Distro for Elasticsearch и заменяющих платные компоненты Elasticsearch. OpenSearch включает движок хранения и поиска OpenSearch, web-интерфейс и среду визуализации данных OpenSearch Dashboards, а также набор дополнений для машинного обучения, поддержки SQL, генерации уведомлений, диагностики производительности кластера, шифрования трафика, разграничения доступа на основе ролей (RBAC), аутентификации через Active Directory, Kerberos, SAML и OpenID, реализации единой точки входа (SSO) и ведения детального лога для аудита. Среди изменений в OpenSearch 3.0:
| ||
|
Обсуждение (31 +12) |
Тип: Программы |
| ||
| · | 08.05.2025 | openSUSE прекращает поставку Deepin из-за установки небезопасных компонентов в обход RPM (105 +36) |
|
Разработчики проекта openSUSE объявили об удалении из репозитория пакетов с рабочим столом Deepin из-за нарушения правил проекта в отношении проверки безопасности размещаемых пакетов. Было выявлено, что сопровождающий Deepin попытался обойти принятые в openSUSE правила рецензирования пакетов и не уведомив команду, отвечающую за безопасность, разместил в репозитории пакет "deepin-feature-enable". Пакет был размещён в апреле 2021 года и включал функциональность, нацеленную на установку дополнительных компонентов, не прошедших проверку и содержащих неустранённые проблемы с безопасностью.
Пакет осуществлял вывод диалога для подтверждения пользователем согласия с условиями лицензии. В условиях было сказано, что ряд компонентов, необходимых для корректной работы Deepin, не включены в официальный репозиторий из-за сомнений в их безопасности у разработчиков openSUSE. Если пользователь выразил готовность пойти на снижение безопасности и согласился с лицензией, осуществлялась распаковка в системные каталоги дополнительных файлов конфигурации D-Bus и политик Polkit из tar-архивов, включённых в состав пакетов deepin-daemon-dbus и deepin-daemon-polkit. Операция выполнялась в обход штатных механизмов установки системных компонентов, предоставляемых пакетным менеджером RPM. В диалоге принятия лицензионного соглашения также приводилась инструкция, предлагающая пользователю вручную установить пакеты depin-file-manager-dbus и deepin-file-manager-polkit, после чего запустить скрипт для загрузки дополнительных файлов конфигурации, необходимых для работы сервиса Deepin File Manager D-Bus.  Правила openSUSE предписывают сопровождающим устанавливать файлы конфигурации сервисов D-Bus и политики Polkit только после проверки их безопасности участниками SUSE Security Team и помещения в белый список допустимых компонентов. Часть подобных компонентов Deepin прошла проверку и была включена в штатные пакеты, но некоторые компоненты были возвращены на доработку из-за выявленных проблем с безопасностью. Проблемы не были устранены должным образом и желаемые компоненты не получили одобрение на включение. Вместо устранения замечаний сопровождающий Deepin продвинул проблемные компоненты обходным путём. Команда SUSE Security Team не рекомендует использовать Deepin в настоящее время из-за нерешённых проблем с безопасностью и общей низкой культурой проекта в отношении безопасности. Все пакеты Deepin будут удалены из репозитория openSUSE Tumbleweed и не войдут в состав будущего релиза openSUSE Leap 16.0. В openSUSE Leap 15.6 решено удалить только проблемный пакет "deepin-feature-enable". Пользователям, желающим установить или продолжить использование Deepin в openSUSE, оставлена возможность установки пакетов из отдельных репозиториев Deepin Factory для openSUSE Tumbleweed и Deepin Leap для openSUSE_Leap.
| ||
|
Обсуждение (105 +36) |
Тип: Проблемы безопасности |
| ||
| · | 08.05.2025 | Релиз Mesa 25.1, свободной реализации OpenGL и Vulkan (211 +27) |
|
После трёх месяцев разработки представлен релиз свободной реализации API OpenGL и Vulkan - Mesa 25.1.0. Первый выпуск ветки Mesa 25.1.0 имеет экспериментальный статус - после проведения окончательной стабилизации кода будет выпущена стабильная версия 25.1.1.
В Mesa 25.1 доступна поддержка графического API Vulkan 1.4 в драйверах ANV для GPU Intel, RADV для GPU AMD, NVK для GPU NVIDIA, Asahi для GPU Apple, Turnip для GPU Qualcomm, в программном растеризаторе lavapipe (lvp) и в режиме эмулятора (vn). В драйвере PanVK для GPU ARM Mali - Vulkan 1.2, а в драйверах v3dv (GPU Broadcom VideoCore для Raspberry Pi 4+) и dzn (реализация Vulkan поверх Direct3D 12) - Vulkan 1.0. В Mesa также обеспечивается полная поддержка OpenGL 4.6 для драйверов iris (GPU Intel Gen 8+), radeonsi (AMD), Crocus (старые GPU Intel Gen4-Gen7), zink, llvmpipe, virgl (виртуальный GPU Virgil3D для QEMU/KVM), freedreno (Qualcomm Adreno), d3d12 (прослойка для организации работы OpenGL поверх DirectX 12) и asahi (GPU AGX, используемый в чипах Apple M1 и M2). Поддержка OpenGL 4.5 доступна для GPU AMD (r600) и NVIDIA (nvc0). Поддержка OpenGL 3.3 присутствует в драйверах softpipe (программный растеризатор) и nv50 (NVIDIA NV50). В драйверах panfrost (GPU ARM Mali) и v3d (GPU Broadcom VideoCore) поддерживается OpenGL 3.1. Основные новшества:
| ||
|
Обсуждение (211 +27) |
Тип: Программы |
| ||
| · | 07.05.2025 | В iVentoy выявлена подстановка корневого сертификата при запуске Windows (100 +41) ↻ |
|
В инструментарии iVentoy, применяемом для загрузки и установки по сети произвольных операционных систем, выявлена подозрительная активность. При загрузке по сети ОС Windows инструментарий осуществлял подстановку в систему бинарного драйвера httpdisk.sys и установку в системное хранилище корневых сертификатов своего самоподписанного сертификата, применяемого для заверения драйвера цифровой подписью. 31 из 70 антивирусных пакетов, в которых был проверен файл httpdisk.sys, выдали предупреждение о наличии вредоносного ПО.
Подобная активность была воспринята как потенциальная попытка продвижения бэкдора и подняла вопрос доверия к открытому проекту Ventoy. Ситуацию усугубляло то, что в прошлом году после инцидента с бэкдором в проекте XZ сообщество уже обращало внимание на поставку подозрительных блобов в дереве исходных текстов Ventoy. Разработчики NixOS предложили заменить Ventoy в репозитории nixpkgs на форк fnr1r (как альтернатива также может рассматриваться glim). Проекты Ventoy и iVentoy развиваются одним автором и имеют похожее назначение. Отличия в том, что Ventoy полностью открыт и нацелен на загрузку операционных систем с USB-носителей, а iVentoy является лишь частично открытым и предназначен для загрузки по сети с использованием технологии PXE. К обсуждению проблемы подключился автор проектов Ventoy и iVentoy, который пояснил, что код драйвера httpdisk.sys является открытым, а сам драйвер предназначен для монтирования в Windows дисковых образов по сети поверх протокола HTTP, что используется в iVentoy для получения с сервера установочных данных Windows. Подстановка драйверов и скриптов в систему после загрузки является документированным поведением. Собственный сертификат, при помощи которого был подписан данный драйвер, был добавлен в хранилище корневых сертификатов для того, чтобы обеспечить загрузку драйвера в обход применяемой в Windows системы верификации программ по цифровой подписи. Сертификат подставлялся только в одноразовое окружение WinPE (Windows Preinstallation Environment), создаваемое в оперативной памяти. В размещаемые на диске стационарные установки Windows изменения не вносились. Заявлено, что в следующем выпуске iVentoy подстановка своего сертификата будет прекращена, так как для обеспечения загрузки драйвера будет использован запуск WinPE в тестовом режиме. По поводу поставки блобов (1, 2, 3) в Ventoy разработчик заявил, что эти бинарные файлы напрямую получены из других открытых проектов и Ventoy использует их без внесения изменений. Готовые исполняемые файлы применяются в процессе настройки запускаемых систем. В качестве альтернативного варианта предлагается не брать готовые сборки, а собирать их для релизов Ventoy самостоятельно при помощи GitHub CI. Дополнение: Опубликован выпуск iVentoy 1.0.21, в котором прекращена установка своего сертификата (для подписи теперь задействован сертификат WDKTestCert), добавлено пояснение про драйвер httpdisk и информация о том, что iVentoy и Ventoy совершенно разные продукты.
| ||
|
Обсуждение (100 +41) ↻ |
Тип: Проблемы безопасности |
| ||
| · | 07.05.2025 | В Ubuntu 25.10 решено задействовать аналог sudo, написанный на Rust (350 –6) |
|
Компания Canonical намерена в осеннем выпуске Ubuntu 25.10 задействовать по умолчанию аналог утилиты sudo, развиваемый проектом sudo-rs и написанный на языке Rust. В марте аналогичное решение было принято в отношении замены утилит GNU Coreutils на инструментарий uutils. На стадии рассмотрения находятся инициативы по замене zlib и ntpd на zlib-rs и ntpd-rs, а также задействованию Sequoia вместо GnuPG в пакетном менеджере APT.
В sudo-rs по возможности обеспечена совместимость с классическими утилитами sudo и su, позволяющая использовать sudo-rs в качестве прозрачной замены sudo в большинстве сценариев использования. Для пользователей, не желающих переходить на uutils и sudo-rs, в Ubuntu 25.10 будет предоставлена опция для отката на классические варианты системных утилит coreutils и sudo. Протестировать использование sudo-rs, не дожидаясь выпуска Ubuntu 25.10, можно при помощи инструментария oxidizr. В настоящее время в oxidizr доступны эксперименты для перехода по умолчанию на использование пакетов uutils coreutils, uutils findutils, uutils diffutils и sudo-rs. Например, для замены в своей системе sudo достаточно выполнить команду "sudo oxidizr enable --experiments sudo-rs", а для возвращения в исходное состояние можно использовать команду "oxidizr disable". Замена системных компонентов производится в рамках инициативы по повышения качества системного окружения через поставку программ, изначально разрабатываемых с оглядкой на безопасность, надёжность и корректность. Поставка утилит, написанных на языке Rust, даст возможность снизить риск появления ошибок при работе с памятью, таких как обращение к области памяти после её освобождения и выход за границы буфера. Если эксперимент будет признан удачным, то утилиты на Rust будут задействованы по умолчанию в LTS-ветке Ubuntu 26.04. В анонсе также упоминается поддержка компанией Canonical работы по расширению возможностей sudo-rs и uutils. Среди задач, которые планируют реализовать в sudo-rs до выпуска Ubuntu 25.10: реализация режима NOEXEC, добавление поддержки профилей AppArmor, создание утилиты sudoedit и обеспечение поддержки старых ядер Linux (старше выпуска 5.9). Режим NOEXEC позволит через фильтрацию системных вызовов execve и execveat блокировать запуск дочерних процессов для запущенных через sudo приложений. Из проспонсированных Canonical доработок в uutils упоминается реализация поддержки SELinux в типовых утилитах, таких как mv, ls и cp, а также добавление поддержки интернационализации в утилиты (например, в утилите sort не полностью поддерживаются параметры локали).
| ||
|
Обсуждение (350 –6) |
Тип: К сведению |
| ||
| · | 06.05.2025 | Опубликована платформа Node.js 24.0.0 (57 +9) |
|
Состоялся релиз Node.js 24.0.0, платформы для выполнения сетевых приложений на языке JavaScript. Node.js 24.0 отнесён к веткам с длительным сроком поддержки, но данный статус будет присвоен только в октябре, после проведения стабилизации. Поддержка Node.js 24.x будет осуществляться до 30 апреля 2028 года. Сопровождение прошлой LTS-ветки Node.js 22.x продлится до апреля 2027 года, а позапрошлой LTS-ветки 20.x до апреля 2026 года. Сопровождение LTS-ветки 18.x прекращено 30 апреля 2025 года, промежуточной ветки Node.js 23.x будет прекращено 1 июня 2025 года.
Основные улучшения:
Платформа Node.js может быть использована как для серверного сопровождения работы Web-приложений, так и для создания обычных клиентских и серверных сетевых программ. Для расширения функциональности приложений для Node.js подготовлена большая коллекция модулей, в которой можно найти модули с реализацией серверов и клиентов HTTP, SMTP, XMPP, DNS, FTP, IMAP, POP3, модули для интеграции с различными web-фреймворками, обработчики WebSocket и Ajax, коннекторы к СУБД (MySQL, PostgreSQL, SQLite, MongoDB), шаблонизаторы, CSS-движки, реализации криптоалгоритмов и систем авторизации (OAuth), XML-парсеры. Для обработки большого числа параллельных запросов Node.js задействует асинхронную модель запуска кода, основанную на обработке событий в неблокирующем режиме и определении callback-обработчиков. В качестве способов мультиплексирования соединений поддерживаются такие методы, как epoll, kqueue, /dev/poll и select. Для мультиплексирования соединений используется библиотека libuv, которая является надстройкой над libev в системах Unix и над IOCP в Windows. Для создания пула потоков (thread pool) задействована библиотека libeio, для выполнения DNS-запросов в неблокирующем режиме интегрирован c-ares. Все системные вызовы, вызывающие блокирование, выполняются внутри пула потоков и затем, как и обработчики сигналов, передают результат своей работы обратно через неименованный канал (pipe). Выполнение JavaScript-кода обеспечивается через задействование разработанного компанией Google движка V8 (дополнительно Microsoft развивает вариант Node.js с движком Chakra-Core). По своей сути Node.js похож на фреймворки Perl AnyEvent, Ruby Event Machine, Python Twisted и реализацию событий в Tcl, но цикл обработки событий (event loop) в Node.js скрыт от разработчика и напоминает обработку событий в web-приложении, работающем в браузере.
| ||
|
Обсуждение (57 +9) |
Тип: Программы |
| ||
| · | 06.05.2025 | В GNOME SDK добавлена поддержка языка построения интерфейсов Blueprint (132 +6) |
|
В состав предлагаемого проектом GNOME инструментария для разработки приложений (GNOME SDK) включён компилятор blueprint-compiler, позволяющий использовать для определения интерфейса приложений разметку Blueprint. Поддержка Blueprint в GNOME SDK даст возможность применять данный язык описания интерфейса в приложениях GNOME без ручной установки дополнительных зависимостей. В настоящее время Blueprint добавлен в ночные сборки GNOME SDK и войдёт в состав релизов, начиная с осеннего выпуска GNOME 49.
Blueprint упрощает создание интерфейса с использованием библиотеки GTK4 и отличается задействованием простого декларативного синтаксиса, повторяющего модель виджетов GTK, поддерживающего типовые шаблоны, типы и обработчики. В отличие от формата ui-файлов GTK в Blueprint не применяется разметка XML, которая воспринимается как перегруженная и неудобная для редактирования вручную. Для интеграции с интегрированными средами разработки и редакторами кода предоставляется LSP-сервер (Language Server Protocol), который можно использовать для подсветки, анализа ошибок, вывода подсказок и автодополнения кода. Поддержка Blueprint уже встроена в GNOME Builder и доступна в форме плагинов для Vim, GNU Emacs и Visual Studio Code. Имеется утилита для упрощения портирования определений интерфейса из XML в Blueprint. Благодаря читаемому синтаксису формат Blueprint позволяет обойтись без применения специализированных визуальных редакторов интерфейса. При этом Blueprint не требует внесения изменений в GTK и позиционируется как надстройка, компилирующая разметку в штатный для GtkBuilder формат XML. Функциональные возможности Blueprint полностью соответствуют GtkBuilder, отличается лишь метод представления информации. Код инструментария написан на языке Python и распространяется под лицензией LGPLv3.
using Gtk 4.0;
template $MyAppWindow: ApplicationWindow {
default-width: 600;
default-height: 300;
title: _("Hello, Blueprint!");
[titlebar]
HeaderBar {}
Label {
label: bind template.main_text;
}
}
| ||
|
Обсуждение (132 +6) |
Тип: К сведению |
| ||
| · | 06.05.2025 | Open WebUI перешёл на ограничивающую лицензию, запрещающую удаление бренда (100 +5) |
|
Проект Open WebUI, развивающий платформу для развёртывания больших языковых моделей на своём оборудовании и взаимодействия с ними через web-интерфейс, перешёл на ограничивающую лицензию, запрещающую переименование. Изначально проект поставлялся под лицензией BSD-3, но начиная с выпуска 0.6.6 в текст лицензии были добавлены ограничивающие изменения. Кроме того, проектом введено обязательное подписание соглашения о передаче имущественных прав для участников из сообщества, желающих передавать свои изменения.
При установке или распространении копий Open WebUI пользователь теперь обязан сохранять изначальные элементы бренда, название и логотип. Исключение сделано только для разработчиков, отправлявших изменения до смены лицензии, обладателей коммерческой лицензии и установок, с которыми взаимодействует менее 50 пользователей в месяц. Подобные условия не соответствуют критериям открытых лицензией OSI, поэтому проект теперь можно рассматривать как проприетарный, несмотря на слово "Open" в его названии. Код, выпущенный до версии 0.6.6, остаётся под лицензией BSD. При этом разработчики Open WebUI не считают, что изменение сделало проект проприетарным. Требование по сохранению бренда преподносится как копилефт-подобная защита, нацеленная на борьбу со злоупотреблениями и нечестными поставщиками, выдающими чужую работу за свой продукт. В остальном проект сохраняет все права, предоставляемые лицензией BSD, такие как возможность распространения, модификации и создания форков. При создании форка или собственной редакции, основанных на кодовой базе после версии 0.6.6, требуется сохранить элементы бренда и указать, что продукт является неофициальным ответвлением. Упоминание Open WebUI должно быть явным и видимым. Запрещены заявления о том, что сторонняя редакция развивается с одобрения проекта Open WebUI или при его участии. Отмечается, что причиной изменения лицензии стали злоупотребления со стороны некоторых потребителей, которые просто удаляли упоминания связи кода с проектом Open WebUI, выдавали результат за новую разработку и пытались продавать как собственный продукт. Также вокруг проекта образовались паразитирующие на проекте посредники, которые вводили пользователей в заблуждение и продвигали свои сборки как официальные редакции Open WebUI, сопровождаемые разработчиками оригинального проекта. В случае проблем создатели подобных модификаций перекладывали работу по поддержке на основной проект, не внося при этом вклада в общее дело и не участвуя в разработке.
| ||
|
Обсуждение (100 +5) |
Тип: К сведению |
| ||
| · | 06.05.2025 | Проект CoMaps начал развитие форка приложения Organic Maps (122 +31) |
|
Представлен CoMaps - форк проекта Organic Maps, развивающего мобильное приложение для автономной навигации с картографическими данными OpenStreetMap. Форк основан участниками сообщества, недовольными зависимостью проекта от интересов акционеров коммерческой компании Organic Maps OÜ, закрытостью процесса управления и непрозрачностью распределения пожертвований.
Созданный форк будет развиваться в соответствии с принципами открытости, прозрачности и совместной работы. За принятие решений будет отвечать управляющий совет, избираемый из представителей сообщества. Для проекта зарегистрирован домен comaps.app, но сайт ещё не запущен. Структура проекта CoMaps подразумевает ведение только некоммерческой деятельности и подотчётность сообществу. Основной целью форка называется работа для удовлетворения интересов сообщества, а не с целью получения прибыли. Все ресурсы, кодовая база и интеллектуальная собственность будет принадлежать сообществу и будут распространяться только под открытой лицензией. В плане функциональности приложения заявлены следующие принципы:
Проект Organic Maps развивает бесплатные мобильные приложения (Android, iOS, альфа поддержка Linux) для оффлайн навигации, использующие картографические данные из OpenStreetMap. Код проекта распространяется под лицензией Apache 2.0. В приложении делается упор на простоту использования и конфиденциальность (не отслеживает местоположение пользователя и не собирает личные данные). Organic Maps основан как форк приложения MAPS.ME, созданный в том числе его изначальными авторами после продажи MAPS.ME компанией Mail.ru компании Daegu Limited, которая перевела проект на проприетарную модель разработки.   
| ||
|
Обсуждение (122 +31) |
Тип: К сведению |
| ||
| · | 05.05.2025 | Новые версии сервисного менеджера s6-rc и системы инициализации s6-linux-init (61 +16) |
|
Представлен выпуск сервисного менеджера s6-rc 0.5.6.0, предназначенного для управления запуском скриптов инициализации и сервисов. Поддерживается отслеживание дерева зависимостей и автоматический запуск или завершение сервисов для достижения указанного состояния. Инструментарий s6-rc может применяться как в системах инициализации, так и для организации запуска произвольных сервисов в привязке к событиям, отражающим изменение состояния системы. Система поддерживает скрипты инициализации, совместимые с sysv-init, и может импортировать информацию о зависимостях из sysv-rc или OpenRC. Код написан на языке Си и распространяется под лицензией ISC.
Сервисный менеджер s6-rc включает набор утилит для запуска и остановки длительно функционирующих процессов (демонов) или сразу завершаемых скриптов инициализации. В процессе работы обеспечивается параллельный запуск не пересекающихся между собой сервисов и гарантируется повторяющаяся при разных запусках последовательность выполнения скриптов. Все изменения состояния обрабатываются с учётом зависимостей, например, при запуске какого-то сервиса будут автоматически запущены необходимые для его работы зависимости, а при остановке - остановлены и зависимые сервисы. В отличие от других сервисных менеджеров s6-rc поддерживает упреждающее (в offline-режиме) построение графа зависимостей для имеющегося набора сервисов, что позволяет выполнить ресурсоёмкий анализ зависимостей отдельно, а не во время загрузки или изменения состояния. При этом система не является монолитной и разбита на серию отдельных и заменяемых модулей, каждый из которых в соответствии с философией Unix решает только определённую задачу. Проект s6-rc придерживается философии минимализма (не содержит ничего лишнего) и потребляет минимум ресурсов. Вместо уровней запуска (runlevel) в s6-rc предлагается концепция наборов (bundles), позволяющая группировать сервисы по произвольным признакам и решаемым задачам. Для повышения эффективности работы используется скомпилированная БД зависимостей, создаваемая утилитой s6-rc-compile на основе содержимого каталогов с файлами для запуска/остановки сервисов. Для разбора и манипуляций с БД предлагаются утилиты s6-rc-db и s6-rc-update. Одновременно сформированы новые версии сопутствующих пакетов, дополняющих s6-rc:
В новых версиях во все пакеты добавлена поддержка pkg-config. В библиотеке skalibs реализованы варианты функций ввода/вывода, время работы которых можно ограничить таймаутом. В mdevd добавлена опция "-I" для задания имени группы netlink для приёма запросов, размер буфера по умолчанию увеличен до 1 МБ. В tipideed обеспечена возможность потоковой трансляции вывода CGI-скриптов, добавлена поддержка методов PUT, DELETE и PATCH, реализована директива autochunk для chunked-кодирования передаваемых данных.
| ||
|
Обсуждение (61 +16) |
Тип: Программы |
| ||
| · | 04.05.2025 | Разработчики ядра Linux на пути к удалению поддержки процессоров i486 (585 +75) |
|
Инго Молнар (Ingo Molnar), мэйнтейнер архитектуры x86, механизма блокировок и планировщика задач в ядре Linux, выставил на обсуждение набор патчей, удаляющих из ядра поддержку процессоров 486 (M486, M486SX, AMD ELAN) и начальных серий процессоров 586. В ядре предлагается оставить только возможность работы с процессорами x86, поддерживающими инструкцию CX8 (CMPXCHG8B) и регистр TSC (Time Stamp Counter), которые появились в CPU Pentium.
Отмечается, что для поддержки CPU 486 в ядре приходится держать код, эмулирующий операции CX8 (сравнить и обменять 8 байт) и TSC (счётчик циклов CPU, используемый в планировщике задач). Подобный код усложняет ядро, затрудняет сопровождение и временами становится источником проблем, разбор которых отнимает время у разработчиков. Прекращение поддержки 486 позволит удалить из ядра 14104 строки кода, что значительно упростит некоторые функции в ядре за счёт исключения прослоек, эмулирующих CX8 и TSC, и позволит избавиться от библиотеки math-emu, эмулирующей FPU. За день до публикации патчей вопрос целесообразности удаления поддержки 486 поднял Линус Торвальдс при обсуждении очередной проблемы, проявляющейся при эмуляции CX8. Линус считает, что настало время отказаться от поддержки CPU 486 и не видит причин, чтобы продолжать тратить время разработчиков на решение возникающих из-за них проблем. Поддержка процессоров 386 была удалена из ядра в 2012 году. По мнению участников дискуссии, сейчас настало время для удаления поддержки CPU 486. В октябре 2022 года Линус уже публиковал подобное предложение, но оно не получило развития. В остающихся в обиходе системах 486 актуальные ядра Linux практически не используются. Специализированные варианты процессоров 486 для встраиваемых систем, такие как Intel Quark, поддерживают CX8 и TSC, их изменение не коснётся. Старые оригинальные CPU 486, как правило, продолжают использоваться с устаревшими дистрибутивами, поставляющими старые версии ядра Linux. Современные дистрибутивы Linux давно прекратили поддержку 32-разрядных систем x86 или перешли на использование при сборке опции X86_PAE, требующей наличия поддержки CX8.
| ||
|
Обсуждение (585 +75) |
Тип: К сведению |
| ||
| · | 03.05.2025 | Представлены принципы дизайна компилятора Nimony для будущего Nim 3.0 (179 +13) |
|
В процессе разработки языка программирования Nim 3.0 развивается новый компилятор Nimony, основополагающим принципом проектирования которого является достижение предсказуемости времени выполнения в худшем случае (Worst Case Execution Time, WCET). Это требование продиктовано ориентацией на системы жёсткого реального времени, где недетерминированное поведение недопустимо. Как следствие, архитектура Nimony исключает использование JIT-компиляторов и сборщиков мусора с трассировкой (tracing garbage collectors), поскольку их операции могут вносить непредсказуемые задержки.
Для достижения предсказуемости, примитивные типы данных (целые числа, символы) напрямую отображаются на машинные слова и байты соответствующей архитектуры. Композитные типы (структуры, объекты) формируются без использования косвенной адресации (indirection), размещаясь непосредственно в стеке или внутри других структур данных. Такой подход минимизирует накладные расходы и обеспечивает более прозрачное соответствие между исходным кодом и генерируемым машинным кодом. В области автоматического управления памятью (MM), Nimony отходит от многообразия опций, доступных в Nim 2.0, предлагая единственный стандартизированный режим: "mm:atomicArc". Данный режим базируется на подсчёте ссылок с использованием атомарных операций, дополненном семантикой перемещения (move semantics) и вызовом деструкторов при уничтожении объекта, что сближает подход с практиками, принятыми в Rust и современном C++. Ключевым нововведением является явное разделение объектов на ацикличные и потенциально цикличные. По умолчанию объекты считаются ацикличными (.acyclic), что является новым поведением. Для типов данных, экземпляры которых могут формировать циклические ссылки, требуется явная аннотация прагмой .cyclic. Отмечается, что ведётся разработка нового алгоритма сборки циклических ссылок, однако его готовность к промышленному использованию на данный момент не гарантирована. Преимуществом MM на основе деструкторов называется его композируемость: управление ресурсами, требующими освобождения (например, файловые дескрипторы, сетевые сокеты, каналы), интегрируется естественным образом через деструкторы соответствующих типов. Подход к обработке ошибок в Nimony претерпел значительные изменения. Автор Nim выражает неудовлетворённость традиционными механизмами исключений и их эмуляцией через алгебраические типы данных (sum types). Вместо этого предлагается концепция интеграции состояния ошибки непосредственно в сам объект данных. В качестве примеров приводятся: представление ошибки в потоках ввода-вывода через специальное состояние, использование NaN для чисел с плавающей запятой, или low(int) для невалидных целочисленных значений. В случаях, когда объект не может инкапсулировать состояние ошибки, предлагается использовать потоко-локальную (thread-local) переменную для сигнализации. Тем не менее, традиционный механизм исключений Nim сохраняется, но с одним важным уточнением: любая процедура, способная порождать исключение, теперь должна быть в обязательном порядке аннотирована прагмой {.raises.}. Это требование направлено на явное обозначение потенциальных нелокальных переходов управления. В качестве альтернативы или дополнения вводится новый перечислимый тип ErrorCode. Данный тип является типобезопасным и требует исчерпывающей обработки всех возможных вариантов (аналогично case для enum). ErrorCode спроектирован с учётом возможности отображения на стандартные коды ошибок различных систем и протоколов, таких как POSIX errno, коды ошибок Windows API и статусы HTTP. Цель — унифицировать обработку ошибок между различными библиотеками и обеспечить возможность прямой трансляции системных ошибок (например, "диск переполнен") в соответствующие коды состояния (например, HTTP 507) без дополнительных преобразований. Использование ErrorCode также позволяет обрабатывать и распространять ошибки без выделения памяти в куче, что критично для обработки ситуаций нехватки памяти (OOM). Обработка ситуаций исчерпания памяти (Out of Memory, OOM) в Nimony реализована с отходом от распространенной практики аварийного завершения программы ("die on OOM"). Вместо этого предлагается механизм, позволяющий приложению продолжить работу. Контейнеры и операции выделения памяти, которые не могут выполнить запрос, вызывают переопределяемый обработчик oomHandler. Реализация по умолчанию записывает размер неудавшегося запроса в потоко-локальную переменную и позволяет выполнению продолжиться. Состояние нехватки памяти для текущего потока может быть проверено вызовом threadOutOfMem(). Разработчик может предоставить собственную реализацию oomHandler, например, для логирования или аварийного завершения приложения, если такое поведение является предпочтительным. Важным аспектом является обработка операций конструирования ссылочных объектов (ref object), которые могут завершиться неудачей из-за OOM. В Nimony результат таких операций (например, через new или аналогичные конструкторы) может быть nil, и компилятор форсирует обработку этого случая аналогично работе с опциональными типами (Option), предотвращая таким образом ошибки разыменования нулевого указателя. В контексте процедур, аннотированных {.raises.}, возвращаемое значение nil может быть автоматически преобразовано в ErrorCode.OutOfMemError. Механизм обобщённого программирования (generics) в Nimony получил развитие по сравнению с Nim 2.0. Ключевое улучшение заключается в том, что полная проверка типов обобщённого кода теперь выполняется на этапе его определения, а не только при инстанцировании конкретными типами. Ожидается, что это позволит выявлять ошибки на более ранних стадиях компиляции, предоставлять более информативные сообщения об ошибках и улучшить поддержку со стороны средств разработки (IDE), в частности, автодополнение кода. Концепции (concepts), уже присутствующие в Nim, сохраняют свою роль как механизм статического описания требований к типам-параметрам обобщённых функций и типов. Они позволяют формально указать, каким операциям или свойствам должен удовлетворять тип для использования в данном обобщённом контексте. Nimony стремится к унификации моделей асинхронного и многопоточного программирования под единой конструкцией spawn. Решение о том, будет ли задача, запущенная через spawn, выполняться в том же потоке (асинхронно) или в отдельном потоке из пула (многопоточно), принимается планировщиком во время выполнения (runtime). Это накладывает определённые требования на аргументы, передаваемые в spawn: они должны быть потокобезопасными. Внутренняя реализация модели конкурентности будет основана на продолжениях (continuations), а компилятор будет выполнять преобразование программы в стиль передачи продолжений (Continuation-Passing Style, CPS). Отмечается, что сама конструкция spawn реализована не как встроенная возможность языка, а как плагин компилятора. Параллелизм рассматривается как более простая задача по сравнению с конкурентностью. Для написания чисто параллельного кода, ориентированного на вычисления (например, обработка массивов данных), Nimony предложит специальные конструкции, такие как параллельные циклы for, обозначаемые оператором "||". Это позволит реализовывать параллельные алгоритмы без необходимости использования переменных потока управления (flow vars), что может быть удобно для задач научных вычислений или программирования для GPU. Система метапрограммирования Nim, известная своими макросами, в Nimony эволюционирует в сторону плагинов компилятора (compiler plugins). Плагины представляют собой код, который компилируется в нативные инструкции и выполняется на поздних стадиях работы компилятора, после этапа проверки типов. Это даёт плагинам доступ к полной информации о типах и семантике анализируемого кода. Обещаны улучшенные и более удобные API для разработки плагинов. Использование промежуточного формата NIF (Nim Intermediate Format) также должно упростить реализацию различных трансформаций кода. Плагины могут выполняться инкрементально и параллельно, что способствует повышению производительности компиляции. Типы плагинов:
Для документации Nimony предусмотрен сайт, полностью сгенерированный ИИ и проверенный автором Nim на достоверность.
| ||
| · | 03.05.2025 | Проект Debian начал общее голосование по критериям открытости AI-моделей (147 +11) |
|
Проект Debian объявил о проведении общего голосования (GR, general resolution) разработчиков проекта для утверждения критериев принятия моделей машинного обучения в состав основного репозитория проекта. На данном этапе запущена фаза обсуждения, после которой начнётся сбор голосов (дата начала голосования пока не определена). Право голоса имеют около тысячи разработчиков, участвующих в сопровождении пакетов и поддержании инфраструктуры Debian.
AI-модели, распространяемые под открытыми лицензиями, но без предоставления исходного материала и инструментария для обучения модели, предлагается признать несовместимыми с критериями Debian, определяющими свободное ПО (DFSG, Debian Free Software Guideline). В случае утверждения предложения подобные модели не смогут быть включены в основной репозиторий проекта ("main"). Возможность поставки таких моделей в репозитории "non-free" в запущенном голосовании не рассматривается. Среди проблем, возникающих при отсутствии данных, используемых при обучении, упомянуты:
В октябре прошлого года организация OSI (Open Source Initiative) опубликовала определение открытой AI-системы (Open Source AI). Открытая AI-система должна предоставлять следующие возможности: использование в любых целях без необходимости получения отдельного разрешения; изучение работы системы и инспектирование её компонентов; внесение изменений для любых целей; передача другим лицам как исходного варианта, так и редакции после внесения изменений, без ограничения целей использования. Открытая AI-система должна включать детальную информацию об архитектуре модели, данных, использованных при обучении, и методологии обучения, а также исходный код для запуска и обучения AI-системы. Информации должно быть достаточно для того, чтобы профессиональный разработчик смог своими силами воссоздать эквивалентную AI-систему, используя для обучения те же самые или похожие данные. Правозащитная организация Software Freedom Conservancy (SFC) выступила с критикой подобного определения. Недовольство вызвано тем, что в критериях отсутствуют требования по предоставлению данных, использованных для обучения модели. В определении OSI требуется лишь предоставить подробную информацию об использованных при обучении данных, но не сами данные. Принятое определение гарантированно предоставляет лишь две из четырёх заявленных свобод Open Source - возможность использовать и возможность распространять, при том, что возможности изменять и изучать обеспечены не полностью. Решение OSI объясняется тем, что публикация исходных данных во многих случаях невозможна в силу причин, не зависящих от разработчика AI-модели, таких как необходимость сохранения конфиденциальности, использование материалов, защищённых авторским правом, лицензирование данных у сторонних поставщиков и т.п. В случае добавления требования по предоставлению данных ни одна из существующих больших языковых моделей не получила бы статус открытой, а само определением стало бы недостижимой утопией.
| ||
|
Обсуждение (147 +11) |
Тип: К сведению |
| ||
| · | 02.05.2025 | Intel открыл iaprof, инструментарий для профилирования производительности GPU (28 +10) |
|
Брендан Грег (Brendan Gregg), один из разработчиков системы динамической отладки DTrace, ныне работающий в Intel и развивающий средства для анализа производительности на базе eBPF в ядре Linux, объявил об открытии исходного кода инструментария iaprof (AI Flame Graphs). Инструментарий предназначен для анализа информации о производительности GPU Intel и её наглядной визуализации. Код написан на языке Си и открыт под лицензией Apache 2.0.
Из аппаратных платформ поддерживаются графические карты Intel Arc на базе микроархитектуры Battlemage (серия "B"), GPU для датацентров серии "Max" и различные графические карты Intel Xe2, среди прочего на базе iGPU Lunar Lake. В системе требуется наличие ядра Linux со свежими драйверами для GPU Intel (для Intel Battlemage требуется ядро 6.15 и драйвер Xe, а для Intel Max Series достаточно ядра 5.15 и драйвер i915). Ядро Linux должно быть собрано со специфичными для драйверов Intel интерфейсами EU Stall и EU Debug. В собираемых профилях отражаются задержки в работе исполнительных блоков (Execution Unit), состояние CPU и информация о ядрах GPU. Собираемые сведения позволяют связать метрики производительности GPU с кодом, выполняемым на CPU. На практике инструментарий удобно использовать для анализа производительности компьютерных игр и AI-приложений, активно использующих GPU, сопоставляя нагрузку на GPU с выполнением на CPU компонентов ядра ОС, runtime-библиотек и AI-фреймворков. Результаты профилирования могут быть сохранены в формате SVG для интерактивного анализа в браузере (пример), используя цветные диаграммы "FlameGraph" и карты "FlameScope" с выделением цветом проблемных мест. Графики интерактивные и позволяют увеличивать детализацию до кадров стека и выполняемых инструкций GPU, просматривать подробности и выполнять операции поиска. 
| ||
|
Обсуждение (28 +10) |
Тип: Программы |
| ||
| Следующая страница (раньше) >> | ||
