· | 14.02.2025 | Проекту Fedora пригрозили иском из-за поставки сбойного flatpak-пакета с OBS Studio (146 +22) |
Разработчики системы потокового видеовещания OBS Studio предъявили проекту Fedora претензию, связанную с поставкой некорректно работающего неофициального flatpak-пакета в форме, создающей у пользователей впечатление, что они используют официальный пакет. Проблема в том, что разработчики OBS Studio распространяют через каталог Flathub собственный flatpak-пакет, но вместо него пользователям Fedora предоставляется другой вариант flatpak-пакета, сопровождаемый разработчиками Fedora и при установке являющийся более приоритетным.
Из-за этого пользователи Fedora направляют разработчикам OBS Studio претензии, считая, что проблемы присутствуют в официальном flatpak-пакете. Разработчики OBS Studio попросили пометить предлагаемый в Fedora пакет как неофициальный или удалить его в пользу доступного на Flathub официального пакета. Уведомление о проблеме было направлено три недели назад через системы отслеживания ошибок репозитория fedora-flatpaks, GNOME Software и fedora-workstation. Так как конструктивного обсуждения вопроса добиться не удалось и дискуссия скатилась к личным нападкам, разработчики OBS Studio официально потребовали прекратить использование в дистрибутиве Fedora любых элементов бренда OBS Studio, включая имя и логотип. Для исполнения требования предоставлена одна неделя (до 21 февраля). В случае игнорирования требования разработчики OBS Studio намерены привлечь юристов для подачи судебного иска. В ответ мэйнтейнер пакета заполнил заявку на удаление flatpak-пакета obs-studio из репозиториев Fedora. Проблемы во flatpak-пакете от проекта Fedora возникали из-за поставки версии Qt, в которой присутствуют неисправленные регрессивные изменения. В официальном flatpak-пакете от OBS Studio в обход flatpak-runtime поставляется старая версия Qt, в которой данные регрессии не проявляются. Так как срок сопровождения лишённой регрессий старой версии Qt истёк, в Fedora собирался свой вариант flatpak-пакета с актуальным выпуском Qt.
| ||
Обсуждение (146 +22) |
Тип: К сведению |
| ||
· | 13.02.2025 | Лидер Asahi Linux покинул проект после проблем с продвижением Rust в ядро Linux (237 +40) |
Гектор Мартин (Hector Martin), основатель проекта Asahi Linux, занимающегося портированием Linux для работы на компьютерах Mac с ARM-чипами Apple Silicon, объявил о снятии с себя полномочий лидера и прекращению разработки. Участники Asahi Linux сформировали управляющий совет, в который вошли 7 разработчиков. Совет будет коллегиально принимать решения и совместно координировать работу проекта.
В качестве причины ухода Гектор называет выгорание и потерю интереса к дальнейшей разработке в условиях недооценки выполняемой работы и проблем с продвижением наработок проекта в основной состав ядра. В своём сообщении Гектор упоминает излишне потребительское отношение пользователей, способных лишь требовать и возмущаться отсутствуем желаемой функциональности, при том, что развитием проекта занимаются энтузиасты, а пожертвования на разработку со временем постоянно уменьшаются. Переломным моментом, после которого исчезла мотивация продолжать работу, стало сопротивление продвижению в ядро Linux наработок "Rust for Linux" и создание враждебной атмосферы для участников данного проекта. Для Asahi Linux включение поддержки языка Rust в ядро Linux является важным, так как данный язык использован для разработки трёх драйверов (по словам Гектора, успех в разработке драйвера drm-asahi обусловлен выбором для него языка Rust). На поддержание ветки ядра с собственными изменениями тратится много ресурсов и по мере увеличения не принятого в основной состав ядра кода сопровождение всё больше усложняется. Гектор считает, что следовало форсировать продвижение Rust в состав ядра и оказать его участникам активную поддержку, но Линус Торвальдс занял позицию бездействующего наблюдателя, не вмешивающегося в злоупотребления некоторых мэйнтейнеров, тормозящих интеграцию компонентов для поддержки Rust. Также отмечается, что веру в сообщество разработчиков ядра подорвало лицемерие некоторых участников, которые при личном общении поддерживали Гектора, а за его спиной высказывали недовольство. Кроме того упоминается общий упадок сообщества разработчиков ядра, в котором не осталось былых энтузиастов, а всем заправляют работники корпораций. На прошлой неделе Гектор ушёл с поста мэйнтейнера платформы ARM/Apple в ядре Linux после замечания Линуса Торвальдса о его излишней самоуверенности в желании реформировать процесс разработки ядра и привлечении социальных сетей для раздувания внутренних разбирательств. Судя по всему, Гектор излишне эмоционально реагирует на возникающие трудности и принимает близко к сердцу то, что ему кажется несправедливостью, и при этом не готов учитывать интересы других людей, находить компромиссные решения, вникать в мотивы чужих поступков и допускать, что его мнение может не быть единственным правильным.
| ||
Обсуждение (237 +40) |
Тип: Тема для размышления |
| ||
· | 13.02.2025 | Релиз СУБД DuckDB 1.2.0 (40 +8) |
Опубликован выпуск СУБД DuckDB 1.2.0, ориентированной на выполнение аналитических запросов и концептуально напоминающей SQLite. DuckDB сочетает такие свойства SQLite, как компактность, подключение в форме встраиваемой библиотеки, хранение БД в одном файле и CLI-интерфейс, с возможностями и оптимизациями для выполнения аналитических запросов, охватывающих значительную часть хранимых данных, например, выполняющих агрегирование всего содержимого таблиц или слияние нескольких больших таблиц. Код проекта написан на языке C++ и распространяется под лицензией MIT.
DuckDB предоставляет расширенный диалект языка SQL, включающий дополнительные возможности для обработки очень сложных и длительно выполняемых запросов. Возможно использование сложных типов (массивы, структуры, объединения), а также выполнение произвольных и вложенных коррелирующих подзапросов. Поддерживается одновременное выполнение нескольких запросов, выполнение запросов напрямую из файлов в форматах CSV и Parquet. Доступна поддержка импорта из СУБД PostgreSQL. Проектом используется оболочка из SQLite, парсер из PostgreSQL, компонент Date Math из MonetDB, своя реализация оконных функций (на базе алгоритма Segment Tree Aggregation), обработчик регулярных выражений на основе библиотеки RE2, собственные оптимизатор запросов, MVCC-механизм управления одновременным выполнением заданий (Multi-Version Concurrency Control), а также векторизованный движок выполнения запросов на базе алгоритма Hyper-Pipelining Query Execution, позволяющий в одной операции разом обрабатывать большие наборы значений. В новой версии:
| ||
Обсуждение (40 +8) |
Тип: Программы |
| ||
· | 12.02.2025 | Для systemd развивается возможность загрузки системных образов по HTTP (195 –5) |
Леннарт Поттеринг (Lennart Poettering) предложил включить в системный менеджер systemd изменение, позволяющие загружать систему с использованием образа корневой ФС, получаемого c внешнего хоста по протоколу HTTP. Изменение сводится к расширению systemd возможностью не только скачивать дисковый образ по HTTP на начальной стадии загрузки, но и распаковывать загруженный образ, связывать с блочным устройством в loopback-режиме, монтировать блочное устройство как /sysroot и загружать с него систему.
Поддержка скачивания дисковых образов во время загрузки системы при помощи systemd-import-generator уже включена в состав systemd 257. Остальная функциональности пока находится на стадии рабочего прототипа, требующего доработки. В реализации пока не поддерживается полный цикл загрузки, но в дальнейшем функциональность планируют довести до загрузки через UEFI HTTP Boot универсальных образов ядра UKI (Unified Kernel Image), объединяющих в одном файле загрузчик для UEFI (UEFI boot stub), образ ядра Linux и загружаемое в память системное окружение initrd. URL для загрузки системного образа планируют вычислять на основании URL, заданного для EFI-образа в настройках UEFI HTTP Boot (например, при загрузке через EFI HTTP Boot "http://example.com/somedir/myimage.efi", присутствующий в UKI initrd-обработчик загрузит образ rootfs как "http://example.com/somedir/myimage.raw.xz"). В дальнейшем помимо HTTP в качестве транспорта для получения образа планируется добавить поддержку технологии NVMe-over-TCP, позволяющей обращаться к NVMe-накопителям по сети (NVM Express over Fabrics), используя протокол TCP. Предполагается, что загрузка с образов, получаемых с внешнего хоста, упростит организацию тестирования современных неизменяемых ("immutable") операционных систем на реальном оборудовании. Разработчик может на своём компьютере сформировать образ с системным окружением утилитой mkosi и сделать его доступным через HTTP командой "mkosi -f serve". На компьютере, на котором требуется протестировать работу системы, достаточно включить в EFI загрузку по HTTP и добавить URL загружаемого образа командой: kernel-bootcfg --add-uri=http://192.168.47.11:8081/image.efi --title=testloop --boot-order=0 После чего можно просто перезагрузить компьютер, и он загрузит типовой образ ядра UKI, который затем загрузит подготовленный разработчиком дисковый образ с корневой ФС. До отключения в EFI загрузки по HTTP каждая последующая перезагрузка компьютера будет приводить к загрузке свежего системного образа. При подобном тестировании никак не затрагиваются локальные диски.
| ||
Обсуждение (195 –5) |
Тип: К сведению |
| ||
· | 12.02.2025 | Выпуск языка программирования Go 1.24 (260 +17) |
После шести месяцев разработки представлен релиз языка программирования Go 1.24, развиваемого компанией Google при участии сообщества. Язык сочетает высокую производительность, свойственную компилируемым языкам, с такими достоинствами скриптовых языков, как простота написания кода, высокая скорость разработки и защита от ошибок. Код проекта распространяется под лицензией BSD.
Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Оберон. Язык достаточно лаконичен, но при этом код легко читается и воспринимается. Код на языке Go компилируется в обособленные бинарные исполняемые файлы, выполняемые нативно, без использования виртуальной машины (модули профилирования, отладки и другие подсистемы выявления проблем на этапе выполнения интегрируются в виде runtime-компонентов), что позволяет добиться производительности, сопоставимой с программами на языке Си. Проект изначально разрабатывается с оглядкой на многопоточное программирование и эффективную работу на многоядерных системах. Например, на уровне операторов реализованы средства для организации параллельных вычислений и взаимодействия между параллельно выполняемыми методами. Язык также предоставляет встроенные средства защиты от выхода за границы буфера и обеспечивает возможность использования сборщика мусора. Среди изменений в новом выпуске:
| ||
Обсуждение (260 +17) |
Тип: Программы |
| ||
· | 11.02.2025 | Опубликован свободный звуковой кодек FLAC 1.5 (216 +37) |
Сообщество Xiph.Org опубликовало обновление свободного звукового кодека FLAC 1.5.0, позволяющего сжимать звук без потери качества. FLAC использует только методы кодирования без отбрасывания данных (lossless), что гарантирует полную сохранность изначального качества звукового потока и его идентичность с эталонным вариантом, подвергнутым кодированию. При этом используемые методы сжатия без потерь позволяют уменьшить размер исходного звукового потока на 50-60%. FLAC является полностью свободным потоковым форматом, подразумевающим не только открытость библиотек с реализацией функций кодирования и декодирования, но и отсутствие ограничений по использованию спецификаций и созданию производных вариантов. Код библиотек распространяется под лицензией BSD.
Среди изменений в новой версии:
| ||
Обсуждение (216 +37) |
Тип: К сведению |
| ||
· | 11.02.2025 | Релиз среды рабочего стола KDE Plasma 6.3 (182 +44) |
После четырёх месяцев разработки опубликован релиз среды рабочего стола KDE Plasma 6.3. Для оценки работы новых выпусков KDE можно воспользоваться сборками от проектов KDE Neon и openSUSE (Argon, основанный на openSUSE Leap, и Krypton, основанный на openSUSE Tumbleweed).
![]() Основные изменения:
| ||
Обсуждение (182 +44) |
Тип: Программы |
| ||
· | 10.02.2025 | Опубликована распределённая СУБД Citus 13.0 (58 +9) |
Компания Citus Data, принадлежащая Microsoft, опубликовала распределённую СУБД Citus 13.0, реализованную в форме расширения к PostgreSQL 17. Citus обеспечивает горизонтальное масштабирование PostgreSQL в кластере на базе типового оборудования и позволяет разносить данные по узлам при помощи шардинга (sharding) с настройкой разделения на уровне столбцов и схемы хранения. Для приложений кластер Citus выглядит как один большой сервер PostgreSQL, объединяющий ресурсы образующих его узлов. Код написан на языке Си и распространяется под лицензией AGPLv3.
Шардинг позволяет организовать хранение очень большого объёма данных, суммарный размер которых существенно превышает локальные накопители каждого из узлов кластера. Отдельные таблицы могут принудительно реплицироваться на все узлы для ускорения выполнения операций слияния и работы с внешними ключами. Для экономии дискового пространства распределённые по разным узлам данные могут хранится в сжатом виде. Распределённые запросы могут отправляться на любой из узлов кластера, но управление и изменение схемы данных должно производиться только через узел, координирующий работу кластера. Поступающие от клиентов запросы распределяются по необходимым узлам и, если они охватывают несколько узлов, то их обработка распараллеливается. Кластер можно расширять по мере роста размера хранимых данных, добавляя дополнительные узлы и инициируя ребалансировку. В качестве типовых примеров использования Citus отмечается выполнение аналитических запросов и обработка больших массивов данных в форме временного ряда (например, логи или опрос состояния датчиков). Citus также подходит для модернизации имеющейся инфраструктуры на базе одиночного сервера PostgreSQL, производительности и накопителей на котором перестало хватать из-за увеличения нагрузки или объёма поступающих данных. При помощи инструментария Patroni можно создавать отказоустойчивые конфигурации с реплицированными запасными узлами, способными в случае сбоя занять место основных узлов. Изменения в выпуске Citus 13.0:
| ||
Обсуждение (58 +9) |
Тип: Программы |
| ||
· | 09.02.2025 | Первый выпуск платформы виртуализации SEAPATH (82 +19) |
После пяти лет разработки организация Linux Foundation представила релиз платформы виртуализации SEAPATH 1.0, разработанной с учётом требований к информационным системам для цифровых подстанций в энергосетях. Платформа учитывает специфику энергосетей, но может применяться и в других областях, в которых требуется высокая надёжность. Код платформы опубликован под лицензией Apache 2.0. Выпуск SEAPATH 1.0 признан готовым для промышленного применения и использования в критически важных системах (mission-critical). Платформа уже задействована в рабочей инфраструктуре энергетической компании RTE и проходит тестовое внедрение в компаниях GE Vernova, Alliander, ABB, Red Hat и Enedis. В разработке платформы принимают участие компании RTE, Alliander, GE Vernova, Savoir-faire Linux, Welotec и Red Hat.
Для мониторинга, автоматизации, сопровождения и управления распределением энергопотоков на цифровых подстанциях в современных энергосетях задействованы специализированные приложения от различных поставщиков, которые предлагается запускать в отдельных изолированных виртуальных машинах. SEAPATH реализует платформу для организации работы подобных виртуальных машин, виртуализированные приложения (vPAC - Virtualized Protection, Automation and Control) в которых могут выполняться в режиме реального времени. ![]() Для развёртывания узлов с хост-окружением SEAPATH предоставляется два дистрибутива на базе Debian GNU/Linux 12 и Yocto Scarthgap. Платформа не привязана к какому-то определённому оборудованию, не зависит от отдельных поставщиков и может использоваться на различных типах серверов и аппаратных архитектур. Допускается выполнение приложений для электроподстанций, поддерживающих стандарт МЭК-61850. Отказоустойчивость обеспечивается благодаря применению кластерных конфигураций с резервированием оборудования, а также размещению данных и образов виртуальных машин в распределённом хранилище, реплицированном на разные узлы кластера. Обновления автоматически устанавливаются с внешнего сервера. Управление конфигурацией и администрирование осуществляется централизованно с использованием концепции инфраструктура как код. Платформа построена с использованием уже существующих открытых проектов, для проверки надёжности которых подготовлен тестовый набор, включающий более 700 unit-тестов. Виртуализация реализована с использованием гипервизора KVM и ядра Linux, собранного с опцией PREEMPT_RT для работы в режиме реального времени. В качестве распределённого хранилища, охватывающего весь кластер, используется Ceph. Для виртуализации устройств применяется QEMU, а для виртуализации сети - Open vSwitch. Для управления виртуальными окружениями задействован инструментарий Libvirt. Для управления ресурсами в кластере, обеспечения отказоустойчивости и организации взаимодействия между узлами применяются Pacemaker и Corosync. Централизованное управление инфраструктурой и оркестровка виртуальных машин реализована при помощи Ansible. ![]()
| ||
Обсуждение (82 +19) |
Тип: Программы |
| ||
· | 08.02.2025 | Проект TuxTape для развёртывания инфраструктуры live-патчей к ядру Linux (64 +13) |
Страховая компания GEICO опубликовала предварительный выпуск инструментария TuxTape, позволяющего развернуть собственную инфраструктуру для создания, сборки и доставки live-патчей для ядра Linux. Live-патчи позволяет применять исправления к ядру Linux на лету, без перезагрузки и остановки системы. Код проекта написан на языке Rust и распространяется под лицензией Apache 2.0.
Live-патчи с устранением уязвимостей предоставляют для своих дистрибутивов такие компании, как Red Hat, Oracle, Canonical и SUSE, но открытым у них является лишь низкоуровневый инструментарий для работы с патчами, а сами патчи формируются за закрытыми дверями. Дистрибутивы Gentoo и Debian пытались развивать открытые проекты elivepatch и linux-livepatching, но первый уже 6 лет находится в заброшенном состоянии, а второй затормозил на стадии создания тестового прототипа. TuxTape нацелен на организацию работы собственной системы для создания и доставки live-патчей, не зависящей от сторонних поставщиков и адаптируемой для любых ядер Linux, а не только для пакетов с ядром конкретных дистрибутивов. TuxTape может формировать live-патчи, совместимые с инструментарием kpatch, разработанным компанией Red Hat (помимо kpatch существуют похожие инструменты: kGraft от SUSE, Ksplice от Oracle и универсальный livepatch). Патчи формируются в виде загружаемых модулей ядра, которые заменяют функции в ядре, используя подсистему ftrace для перенаправления на новые функции, включённые в модуль.
![]() TuxTape может отслеживать информацию об исправлении уязвимостей в ядре Linux, публикуемую в списке рассылки linux-cve-announce и в Git-репозитории, ранжировать уязвимости по степени опасности, определять применимость к обслуживаемым ядрам Linux и генерировать live-патчи на основе обычных патчей к LTS-веткам ядра. Применимость исходных патчей оценивается через профилирование сборок ядра. Патчи с не затрагивающими целевое ядро уязвимостями игнорируются. TuxTape включает в себя систему для отслеживания новых уязвимостей в ядре, построитель БД патчей и уязвимостей, сервер для хранения метаданных, систему диспетчеризации сборки ядра, сборщик ядра, генератор патчей, архив патчей, клиент для получения патчей для конечных хостов и интерактивный интерфейс для управления формированием live-патчей.
![]() Разработка находится на стадии экспериментального прототипа. Для начального тестирована предложены: tuxtape-cve-parser для разбора информации об уязвимостях и построения БД с патчами; tuxtape-server c реализацией интерфейса gRPC для сервисов генерирующих патчи; tuxtape-kernel-builder для сборки ядра в заданной конфигурации и формирования профиля сборки; tuxtape-dashboard - консольный интерфейс для рецензирования и создания live-патчей на основе исходных патчей, полученных из tuxtape-server. ![]()
| ||
Обсуждение (64 +13) |
Тип: Программы |
| ||
· | 08.02.2025 | Выпуск компилятора ISPC 1.26, развиваемого Intel для языка Си с расширениями SPMD (32 +10) |
Компания Intel опубликовала компилятор ISPC 1.26 (Implicit SPMD Program Compiler), предназначенный для сборки кода на языке Си с расширениями параллельного программирования SPMD (Single Program, Multiple Data), позволяющими добиться параллельного выполнения нескольких экземпляров одной программы с разными наборами входных данных. Код проекта написан на языке С++ и распространяется под лицензией BSD. Поддерживается работа в Linux, Windows, macOS и FreeBSD.
Си-программы с расширениями SPMD компилируются для выполнения на вычислительных блоках SIMD, предоставляемых CPU и GPU, что позволяет задействовать механизмы векторизации SIMD без низкоуровневых оптимизаций и явного применения в коде SIMD-инструкций. Для написания распараллеливаемых функций используется привычный синтаксис и идиомы языка Си - SPMD-функции напрямую взаимодействуют с функциями и структурами, написанными на C/C++. Для отладки программ могут применяться существующие отладчики. В качестве бэкенда для генерации кода и оптимизации в ISPC используется инфраструктура LLVM. Поддерживаются векторные инструкции x86 (SSE2, SSE4, AVX, AVX2, AVX512) и ARM (NEON), а также вынос вычислений на сторону GPU (Intel Gen9 и Xe). На архитектурах с векторными блоками SSE, обрабатывающими по 4 элемента за раз, применение ISPC даёт возможность добиться ускорения выполнения программы в 3 или более раз, а на архитектурах с векторными блоками AVX, обрабатывающими по 8 элементов за раз, ускорение может достигать 5-6 раз. При этом помимо размера векторного блока, масштабирование также обеспечивается за счёт выполнения на разных процессорных ядрах. Основные новшества, добавленные в версии ISPC 1.26:
| ||
Обсуждение (32 +10) |
Тип: Программы |
| ||
· | 07.02.2025 | Доступен офисный пакет ONLYOFFICE 8.3 (163 +16) |
Опубликован выпуск ONLYOFFICE DocumentServer 8.3 с реализацией сервера для online-редакторов ONLYOFFICE и организации совместной работы. Редакторы можно использовать для работы с текстовыми документами, таблицами и презентациями. Код проекта распространяется под свободной лицензией AGPLv3.
Одновременно сформирован выпуск продукта ONLYOFFICE DesktopEditors 8.3, построенного на единой кодовой базе с online-редакторами. Десктоп-редакторы оформлены в виде приложений для рабочего стола, которые написаны на JavaScript с использованием web-технологий, но объединяют в одном наборе клиентские и серверные компоненты, оформленные для самодостаточного использования на локальной системе пользователя, без обращения к внешнему сервису. Для совместной работы на своих мощностях также можно использовать платформу Nextcloud Hub, в которой обеспечена полная интеграция с ONLYOFFICE. Готовые сборки сформированы для Linux, Windows и macOS. В ONLYOFFICE заявлена полная совместимость с форматами MS Office и OpenDocument. Среди поддерживаемых форматов: DOC, DOCX, ODT, RTF, TXT, PDF, HTML, EPUB, XPS, DjVu, XLS, XLSX, ODS, CSV, PPT, PPTX, ODP. Предусмотрена возможность расширения функциональности редакторов через плагины, например, доступны плагины для создания шаблонов и добавления видео с YouTube. Готовые сборки сформированы для Windows и Linux (deb- и rpm-пакеты).
| ||
Обсуждение (163 +16) |
Тип: Программы |
| ||
· | 07.02.2025 | Кризис в продвижении Rust в ядро из-за опасений усложнения сопровождения (657 +79) |
Кристоф Хелвиг (Christoph Hellwig), мэйнтейнер подсистем DMA, KVM, Slab Allocator и архитектуры PowerPC в ядре Linux, в своё время входивший в управляющий технический комитет организации Linux Foundation и выступавший истцом в связанном с GPL судебном разбирательстве с VMware, отказался подтверждать патчи, связанные с поддержкой разработки драйверов на языке Rust. Предложенные патчи добавляли обвязки над несколькими функциями подсистемы DMA, позволяющие использовать DMA в драйверах на языке Rust.
В качестве причины отказа упомянуто усложнение сопровождения кода при наличии обвязок на других языках и желание сохранить программные интерфейсы к DMA в читаемом виде на языке Си, без размазывания по непонятным обвязкам. Кристоф предложил напрямую обращаться к исходному Си API DMA в каждом драйвере на языке Rust, чтобы не создавать дополнительных абстракций, от которых вынуждены будут зависеть сопровождающие ядра. Разработчики патчей указали, что они возьмут на себя всю работу по сопровождению кода на Rust, готовы сопровождать эти патчи самостоятельно и вынесли обвязки в отдельный подкаталог (rust/kernel/dma.rs). В ответ Кристоф наложил вето ("Nacked-by") на приём связанных с Rust патчей и указал, что ему не нужен ещё один сопровождающий. Кристоф заявил, что если разработчики обвязок хотят добиться невозможности сопровождения Linux из-за смешивания нескольких языков в одной кодовой базе, им следует делать это в своём драйвере, а не распространять эту раковую опухоль на основные подсистемы ядра. При этом Кристоф уточнил, что не имеет ничего против языка Rust и считает его одним из лучших новых языков, но он против смешивания кода на разных языках. По словам Кристофа он за создание новых проектов на Rust, но против примешивания Rust к большим кодовым базам на Си, так как такое смешивание сильно снижает удобство сопровождения ядра, как интегрированного проекта. Суть проблем с сопровождением в том, что Rust-обвязки ставят сопровождающих в зависимость от кода на языке Rust. На первый взгляд кажется, что обвязки лишь надстройки над Си-структурами и функциями, которые никак не влияют на разработку и сопровождение кода на Си. Но это не так. При наличии подобных обвязок разработчики подсистем, написанных на Си, должны учитывать влияние их изменений на продолжение работоспособности обвязок. Любое изменение структур данных или внутренних функций на Си может привести к необходимости изменения кода обвязок, поэтому влияющие на обвязки изменения в Си коде нужно отслеживать и синхронизировать с кодом на Rust. Многие сопровождающие не готовы брать на себя дополнительную ответственность за исправление проблем, возникающих в коде на Rust, и не намерены тратить своё время на отслеживание состояния Rust-обвязок. Ситуация с усложнением сопровождения не умозрительная. К дискуссии подключился Джейсон Ганторп (Jason Gunthorpe), мэйнтейнер TPM, VFIO и Infiniband из компании NVIDIA, который привёл пример отклонения Линусом Торвальдсом pull-запроса с изменениями в подсистеме управления памятью, так как данное изменение приводило к сбою при попытке сборки ядра с включением поддержки Rust. Сбой возник из-за того, что сопровождающие код на Rust не добавили необходимые изменения в генератор обвязок (bindgen). Таким образом, сопровождающие подсистему управления памятью при продвижении изменения, полностью корректного с точки зрения кода на Си и ядра в целом, оказались зависимы от опционального стороннего кода в ядре, за который отвечают другие люди. Отказ принимать код обвязки над вызовами DMA поставил разработчиков проекта Rust for Linux в тупик, так как без подобных обвязок разработка полноценных драйверов на языке Rust будет затруднена. Гектор Мартин (Hector Martin), мэйнтейнер кода для поддержи ARM-чипов Apple и лидер проекта Asahi Linux, в качестве варианта разрешения конфликта предложил добиться принятия обвязки напрямую через Линуса Торвальдса, в обход сопровождающего подсистему DMA. Если Линус согласится на подобное нарушение субординации и сложившейся практики, это может привести к кризису управления разработкой ядра, а если откажется - остановит продвижение Rust в ядро. Как вариант, Гектор упомянул привлечение Кристофа к ответственности за нарушение кодекса поведения из-за комментария, в котором Кристоф сравнил Rust с раковой опухолью. Кроме того, Гектор написал, что устал от всех бюрократических проволочек, не готов просто довериться сложившимся процессам и намекнул на привлечение внимания к проблеме в социальных сетях. Дэйв Эйрли (Dave Airlie), мэйнтейнер подсистемы DRM, посоветовал не раздувать конфликт и понять, что токсичное поведение недопустимо с обеих сторон, независимо от того, прав или не прав участник дискуссии. К обсуждению подключился Линус Торвальдс, который указал, что проблема возможно в самом Гекторе и его самоуверенности в том, что он знает что-то лучше других, а не в текущем процессе разработки ядра, который работает. У процесса разработки ядра есть проблемы, но это жизненная реальность - в жизни нет ничего идеального. Попытки травли через социальные сети - это то, что отбивает желание у Линуса иметь что-либо общее с подходом Гектора. Значение для Линуса имеют технические обсуждения и патчи, а не оказание давления через социальные сети. В ответ Гектор отправил запрос на удаление себя из числа сопровождающих платформу ARM/Apple, так как он потерял веру в применяемый в ядре процесс разработки и подход к управлению сообществом. Он также заявил, что разработка платформы ARM/Apple будет продолжена вне основного ядра Linux. У платформы ARM/Apple в ядре остался ещё один мэйнтейнер - Свен Питер (Sven Peter), который намерен продолжить поддержание платформы в ядре своими силами.
| ||
Обсуждение (657 +79) |
Тип: Тема для размышления |
Интересно
| ||
· | 06.02.2025 | Началось производство чипов на базе открытой платформы OpenTitan (99 +20) |
Компания Google после шести лет работы над проектом объявила о начале производства чипа, построенного на базе открытой платформы OpenTitan. Чип выпускается компанией Nuvoton и отмечен как первая реализация OpenTitan, готовая для использования в рабочих проектах. В настоящее время для тестирования выпущена пробная партия, а запуск массового производства намечен на весну этого года.
OpenTitan представляет собой платформу для создания заслуживающих доверия аппаратных компонентов (RoT, Root of Trust), применяемых там, где нужно гарантировать целостное состояние аппаратных и программных элементов системы. Например, для того, чтобы удостоверить, что критически важные части системы не были подменены и основываются на проверенном и авторизированном производителем коде. Проект предоставляет готовый, проверенный и надёжный каркас, позволяющий повысить доверие к создаваемым решениям и снизить издержки при разработке специализированных чипов для обеспечения безопасности. Чипы на базе OpenTitan могут использоваться в серверных материнских платах, сетевых картах, потребительских устройствах, маршрутизаторах и устройствах интернета вещей для верификации прошивок и загружаемых компонентов, для генерации криптографически уникальных идентификаторов системы (защита от подмены оборудования), для предоставления связанных с безопасностью сервисов, для защиты криптографических ключей (изоляция ключей в случае получения злоумышленником физического доступа к оборудованию) и для ведения изолированного лога аудита, который невозможно отредактировать или стереть. OpenTitan включает логические блоки, востребованные в RoT-чипах, такие как открытый микропроцессор на базе архитектуры RISC-V (RV32IMCB Ibex), криптографические сопроцессоры, аппаратный генератор случайных чисел, менеджер ключей с поддержкой DICE, механизм защищённого хранения данных в постоянной и оперативной памяти, технологии защиты, блоки ввода/вывода и компоненты безопасной загрузки. Устройство также предоставляет блоки с реализацией типовых алгоритмов шифрования, таких как AES и HMAC-SHA256, и ускоритель математических операций, применяемых в алгоритмах для работы с цифровыми подписями на базе открытых ключей. ![]() Проект основан компанией Google, но передан некоммерческой организации lowRISC, после чего к его разработке присоединились такие компании, как Western Digital, Seagate, Nuvoton Technology, Winbond, Rivos, zeroRISC и G+D Mobile Security. Связанный с проектом код и спецификации аппаратных компонентов опубликованы под лицензией Apache 2.0. В основу решений, применяемых в OpenTitan, заложены технологии уже используемые в криптографических USB-токенах Google Titan и TPM-чипах для обеспечения верифицированной загрузки, устанавливаемых на серверах в инфраструктуре Google, а также на устройствах Chromebook и Pixel. В отличие от существующих реализаций Root of Trust, OpenTitan развивается в соответствии с концепцией "безопасность через прозрачность", подразумевающей доступность кода и схем, а также применение полностью открытого процесса разработки, не привязанного к конкретным поставщикам и производителям чипов. OpenTitan стал первой выпущенной на рынок открытой реализацией Root of Trust, в которой имеется поддержка постквантового механизма безопасной загрузки, основанного на использовании алгоритма формирования цифровых подписей SLH-DSA (Sphincs+), стойкого от подбора на квантовых компьютерах. ![]()
| ||
Обсуждение (99 +20) |
Тип: К сведению |
| ||
· | 06.02.2025 | Уязвимости в беспроводных маршрутизаторах Zyxel, D-Link и Netgear (43 +22) |
Несколько уязвимостей в беспроводных маршрутизаторах Zyxel, D-Link и Netgear, позволяющих получить удалённый доступ к устройству без аутентификации.
| ||
Обсуждение (43 +22) |
Тип: Проблемы безопасности |
| ||
Следующая страница (раньше) >> |
Закладки на сайте Проследить за страницей |
Created 1996-2025 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |