LINUXTALKS.CO

Сообщения MrSugoma

 

Выпуск дистрибутива MX Linux 23.5

Группа Debian

Опубликован релиз легковесного дистрибутива MX Linux 23.5, созданного в результате совместной работы сообществ, образовавшихся вокруг проектов antiX и MEPIS. Выпуск основан на пакетной базе Debian с улучшениями от проекта antiX и пакетами из собственного репозитория. В дистрибутиве используется система инициализации sysVinit и собственные инструменты для настройки и развёртывания системы. Для загрузки доступны 32- и 64-разрядные сборки (x86_64, i386) с рабочим столом Xfce (2.4 ГБ), а также 64-разрядные сборки с рабочим столом KDE (2.7 ГБ) и сборки (1.8 ГБ) с оконным менеджером Fluxbox.

В новом выпуске:

  • Среда рабочего стола Xfce обновлена до выпуска 4.20.
  • Осуществлена синхронизация с пакетной базой Debian 12.9. Обновлены версии приложений. Как и в прошлых выпусках по умолчанию продолжает использоваться система инициализации sysVinit, а systemd можно установить в качестве опции.
  • Базовый пакет с ядром Linux обновлён до версии 6.1.123. Отдельно подготовлены сборки с расширенной поддержкой оборудования (AHS), которые поставляются с Xfce и ядром 6.12.8 c патчами от проекта liquorix.
  • Обновлена сборка MX Raspberry Pi Respin (RPI) для плат Raspberry Pi, поставляемая с Xfce.
  • В графическом интерфейсе для установки пакетовMX Packageinstaller обеспечен показ скриншотов, имеющихся на сайте screenshots.debian.net, а также улучшено отображение версий пакетов из сторонних репозиториев.
  • Добавлено предупреждение о попытке включения постоянного хранилища при загрузке с носителя, доступного только для чтения.
  • В инсталлятор добавлены дополнительные fallback-режимы.

>>> Подробности

 , , , ,

MrSugoma ()

Выпуск встраиваемой СУБД libmdbx 0.13.3

Группа Open Source

Опубликован выпуск библиотеки libmdbx 0.13.3 (MDBX) с реализацией высокопроизводительной компактной встраиваемой базы данных класса ключ-значение. Код libmdbx распространяется под лицензией Apache 2.0. Поддерживаются все актуальные операционные системы и архитектуры, а также российский Эльбрус 2000. Для libmdbx предлагается развитое API для C++, а также поддерживаемые энтузиастами привязки к языкам Rust, Haskell, Python, NodeJS, Ruby, Go, Nim, Deno, Scala.

Исторически libmdbx является глубокой переработкой СУБД LMDB и превосходит своего прародителя по надёжности, набору возможностей и производительности. В сравнении с LMDB, в libmdbx большое внимание уделяется качеству кода, стабильной работе API, тестированию и автоматическим проверкам. Поставляется утилита проверки целостности структуры БД с некоторыми возможностями восстановления. Технологически libmdbx предлагает ACID, строгую сериализацию изменений и неблокирующее чтение с линейным масштабированием по ядрам ЦПУ. Поддерживается автокомпактификация, автоматическое управление размером БД, оценка объёма выборок по диапазонам (range query estimation).

Основные изменения:

  • Ветка 0.13.x получила статус стабильной. Началась разработка ветки 0.14.x.
  • В C API добавлена функция mdbx_cursor_count_ex(), позволяющая получить как количество мульти-значений соответствующих текущему ключу, так и информацию о вложенном дереве, хранящем эти значения.
  • В C++ API добавлен метод mdbx::txn::make_broken() аналогичный mdbx_txn_break().
  • В утилитах mdbx_copy, mdbx_drop, mdbx_dump, mdbx_load, mdbx_stat реализовано логирование ошибок, предупреждений и важных сообщений от libmdbx.
  • Изменение поведения:
  • При включении профилирования сборщика мусора (сборка с опцией MDBX_ENABLE_PROFGC=ON) теперь подсчитываются затраты времени CPU на слияние списков страниц, т.е. на работу функции pnl_merge().
  • В утилите тестирования значение режима данных переименовано из data.dups в data.multi.
  • Доработан контроль длины ключа внутри cursor_seek().
  • Если посредством mdbx_env_set_option(MDBX_opt_txn_dp_limit) пользователем не задано собственно значение, то выполняется подстройка dirty-pages-limit при старте каждой не вложенной пишущей транзакций, исходя из объёма доступного ОЗУ и размера БД.
  • В режиме MDBX_NOSTICKYTHREADS допускается commit/abort вложенных транзакций из любого треда/потока.
  • При попытке запуска вложенных транзакций в режиме MDBX_WRITEMAP производится логирование и возврат ошибки MDBX_INCOMPATIBLE.
  • В C++ API в конструкторах/инициализаторах и методах, связанных с формированием геометрии БД, по умолчанию используются только default-значения.
  • Внутри mdbx_env_set_geometry() доработаны эвристики для подбора параметров геометрии БД запрошенных пользователем "по умолчанию".
  • Исправления:
  • Устранён регресс неразблокировки мьютекса при попытки повторного закрытия dbi-дескриптора, в том числе при попытке явно закрыть дескриптор после удаления связанной с ним таблицы.
  • Устранён регресс состояния вложенного/dupsort курсора после вставки данных в MDBX_APPEND-режиме.
  • Поддержка получения boot_id при работе внутри LXC-контейнера.
  • Устранёна ошибка неверной обработки попытки запуска вложенной читающей транзакции. Теперь в таких ситуациях возвращается ошибка MDBX_EINVAL, так как вложенность поддерживается только для транзакций чтения-записи.
  • Устранён SIGSEGV-регресс обращения к нулевому адресу при работе в режиме только-чтение без использования LCK-файла, например при размещении БД на носителе доступном только для чтения.

>>> Подробности

 

MrSugoma ()

В готовящемся в релизу ядре Linux 6.13 выявлен сбой, вызванный кодом сотрудника Microsoft

Группа Ядро Linux

Линус Торвальдс намеревался опубликовать релиз ядра Linux 6.13 в это воскресенье, но, скорее всего, тестирование ветки 6.13 будет продлено на неделю из-за проблем со стабильностью в изменениях, подготовленных сотрудником Microsoft и принятых в ветку 6.13 в ноябре. Дополнительно отмечается, что патч, ставший причиной сбоя, был подан нестандартно - но был принят, хотя не получил ни одного подтверждения (ACK) от мэйнтайнеров архитектуры x86, что является нарушением общепринятых практик.

Патч добавлял возможность использования больших страниц памяти в режиме ROX (Read Only Execute) при выделении памяти, предназначенной для размещения исполняемого кода. ROX позволяет использовать память с исполняемым кодом в режиме только для чтения, что усложняет эксплуатацию некоторых уязвимостей. В ядре 6.13 для исполняемого кода модулей на системах x86_64 по умолчанию было включено использование кэша больших исполняемых страниц памяти, отражённых как ROX. Изменение решало проблему с маппингом в режиме ROX страниц для ещё полностью не сформированного исполняемого кода и позволяло обойтись без временного репаминга ROX-страниц в режим записи до завершения подготовки модулей ядра к работе.

На финальном этапе тестирования ядра 6.13 инженер из компании Intel выявил сбой, не позволяющий ядру корректно выйти из спящего режима на некоторых ноутбуках с процессорами Intel (например, с CPU на базе микроархитектуры Alderlake). Сбой проявлялся при сборке ядра компилятором Clang с включённым режимом защиты CFI (Control Flow Integrity), блокирующим нарушения нормального порядка выполнения (control flow) в результате применения эксплоитов, изменяющих хранимые в памяти указатели на функции. В качестве временного решения мэйнтейнеры из компаний Intel и AMD, отвечающие за архитектуру x86, предложили отключить использование EXECMEM_ROX в ядре 6.13, до того как будет подготовлен и протестирован полноценный патч, решающий проблему (первый вариант исправления не решил проблему).

>>> Подробности

 , , ,

MrSugoma ()

Релиз Linux Mint 22.1 «Xia»

Группа Canonical / Ubuntu

Разработчики Linux Mint анонсировали релиз версии 22.1 под кодовым названием «Xia». Система имеет статус LTS (Long Term Support) с поддержкой до 2029 года. Дистрибутив основан на Ubuntu 24.04 и работает на ядре Linux 6.8.

Обновление системы управления пакетами

Aptkit заменяет aptdaemon для управления пакетами. Captain объединяет функции GDebi и apturl. Обновление позволило улучшить локализацию, уменьшить количество ошибок и добавить графический интерфейс для управления сторонними пакетами.

Управление питанием

Система получила три режима энергопотребления:

  1. Энергосберегающий - снижает производительность для экономии заряда.
  2. Сбалансированный - адаптирует производительность под текущие задачи.
  3. Производительный - доступен на совместимых системах.

Обновление Cinnamon 6.4

Рабочий стол Cinnamon обновился до версии 6.4:

  1. Новый дизайн с закругленными элементами
  2. Собственные диалоговые окна
  3. Функция Night Light для снижения нагрузки на глаза
  4. Улучшенная поддержка Wayland
  5. Новые настройки уведомлений
  6. Оптимизация переключателя окон Alt-Tab
  7. Поддержка горячих клавиш в Nemo

Системные изменения

  1. Оптимизация Центра приложений
  2. Поддержка миниатюр OpenRaster
  3. Новая организация обоев по темам
  4. Переход на звуковой сервер Pipewire
  5. Обновление файлового менеджера Bulky

Технические особенности

Время выключения системы в новой версии сокращено до 10 секунд. При необходимости увеличения времени ожидания пользователи могут изменить значение в файле /etc/systemd/system.conf.d/60_custom.conf.

Разработчики отключили магазин Snap Store по умолчанию. Для его активации требуется ручное включение.

В системе используются обновленные шрифты Ubuntu с более тонким начертанием. При желании можно вернуть старую версию шрифтов, загрузив соответствующий пакет.

Операционная система перешла на звуковой сервер Pipewire. В случае проблем со звуком возможен возврат к PulseAudio через удаление пакетов pipewire и перезагрузку системы.

В ядре 6.8 обнаружена регрессия при работе с NTFS-разделами. При появлении ошибки монтирования следует использовать утилиту Disks для восстановления файловой системы.

Из установщика удалена поддержка ZFS из-за низкой востребованности и сложности поддержки.

При проблемах с загрузкой системы рекомендуется:

  • использовать режим совместимости (Compatibility Mode);
  • добавить параметр nomodeset в параметры загрузки;
  • для видеокарт Nvidia установить проприетарные драйверы через Менеджер драйверов.

В случае использования монитора с высоким разрешением (HiDPI) рекомендуется установить пакет grub2-theme-mint-2k для корректного масштабирования загрузчика.

При использовании тачпада доступен выбор между драйверами libinput (по умолчанию) и synaptics. Переключение осуществляется через установку соответствующих пакетов.

>>> Подробности

 , , , ,

MrSugoma ()

Релиз OpenZFS 2.3.0, реализации ZFS для Linux и FreeBSD

Группа Open Source

После более года разработки опубликован релиз проекта OpenZFS 2.3.0, развивающего реализацию файловой системы ZFS для Linux и FreeBSD. Проект получил известность как "ZFS on Linux" и ранее ограничивался разработкой модуля для ядра Linux, но после слияния с кодом из FreeBSD был признан основной реализацией OpenZFS и переименован.

Работа OpenZFS проверена с ядрами Linux c 4.18 по 6.12 и всеми ветками FreeBSD, начиная с 13.3. Код распространяется под свободной лицензией CDDL. OpenZFS уже используется во FreeBSD и входит в состав дистрибутивов Debian, Ubuntu, Gentoo, NixOS и ALT Linux. Пакеты с новой версией в ближайшее время будут подготовлены для основных дистрибутивов Linux, включая Debian, Ubuntu, Fedora, RHEL/CentOS.

OpenZFS предоставляет реализацию компонентов ZFS, связанных как с работой файловой системы, так и с функционированием менеджера томов. Реализованы компоненты: SPA (Storage Pool Allocator), DMU (Data Management Unit), ZVOL (ZFS Emulated Volume) и ZPL (ZFS POSIX Layer). Проект также позволяет использовать ZFS в качестве бэкенда для кластерной файловой системы Lustre. Наработки OpenZFS основаны на оригинальном коде ZFS, импортированном из проекта OpenSolaris и расширенном улучшениями и исправлениями от сообщества Illumos. Проект развивается при участии сотрудников Ливерморской национальной лаборатории по контракту с Министерством энергетики США.

Код распространяется под свободной лицензией CDDL, которая несовместима с GPLv2, что не позволяет добиться интеграции OpenZFS в состав основной ветки ядра Linux, так как смешивание кода под лицензиями GPLv2 и CDDL недопустимо. Для обхода лицензионной несовместимости было решено распространять продукт для Linux целиком под лицензией CDDL в виде отдельно загружаемого модуля, поставляемого отдельно от ядра. Стабильность кодовой базы OpenZFS оценивается как сопоставимая с другими ФС для Linux.

Основные изменения:

  • Реализована возможность добавления на лету новых дисков в существующий массив RAIDZ для увеличения размера хранилища без остановки работы и без необходимости создания новой группы накопителей. Перераспределение избыточных данных с учётом новых дисков осуществляется автоматически. Для добавления диска к существующей группе можно использовать команду "zpool attach POOL raidzP-N NEW_DEVICE", а для отслеживания окончания фонового процесса расширения массива - "zpool status".
  • Значительно ускорено выполнение операций, связанных с дедупликацией блоков данных. Оптимизации среди прочего затронули формат таблиц дедупликации, поэтому для задействования предложенных оптимизаций в уже существующих пулах необходимо включить опцию "fast_dedup", после чего будет созданы новые таблицы дедупликации, которые будут использованы параллельно со старыми таблицами.
  • Добавлен режим прямого ввода/вывода (Direct IO), позволяющий совершать операции чтения и записи в обход кэша ARC (Adaptive Replacement Cache). Режим позволяет повысить эффективность работы в ситуациях, когда кэширование может негативно влиять на производительность из-за дополнительных операций копирования в памяти, например, при использовании устройств NVMe.
  • В большинство команд (zfs list|get|mount|version, zpool status|list|get|version) добавлена опция "-j" для вывода в формате JSON.
  • Допустимый размер имён файлов и каталогов увеличен c 255 до 1023 символов (новый размер выбран с расчётом размещения 255 4-байтовых символов).
  • Внесены оптимизации производительности, охватывающие различные части кодовой базы.
  • В модуль ядра добавлены опции:
  • dmu_ddt_copies
  • raidz_expand_max_copy_bytes
  • raidz_expand_max_reflow_bytes{rel=«nofollow»}
  • raidz_io_aggregate_rows{rel=«nofollow»}
  • spa_cpus_per_allocator{rel=«nofollow»}
  • spa_num_allocators{rel=«nofollow»}
  • zap_shrink_enabled{rel=«nofollow»}
  • zfetch_max_idistance{rel=«nofollow»}
  • zfs_active_allocator{rel=«nofollow»}
  • zfs_arc_shrinker_seeks{rel=«nofollow»}
  • zfs_dedup_log_flush_entries_min{rel=«nofollow»}
  • .zfs_dedup_log_flush_flow_rate_txgs{rel=«nofollow»}
  • zfs_dedup_log_flush_min_time_ms{rel=«nofollow»}
  • zfs_dedup_log_flush_passes_max{rel=«nofollow»}
  • zfs_dedup_log_mem_max{rel=«nofollow»}
  • zfs_dedup_log_mem_max_percent{rel=«nofollow»}
  • zfs_dedup_log_txg_max{rel=«nofollow»}
  • zfs_dio_enabled{rel=«nofollow»}
  • zfs_dio_write_verify_events_per_second{rel=«nofollow»}
  • zfs_resilver_defer_percent{rel=«nofollow»}
  • zfs_scrub_after_expand{rel=«nofollow»}
  • zfs_snapshot_no_setuid{rel=«nofollow»}
  • zfs_vdev_direct_write_verify{rel=«nofollow»}
  • zio_taskq_write_tpq{rel=«nofollow»}

>>> Подробности

 , , ,

MrSugoma ()

Выпуск Rust 1.84. Ядра Tock и Vekos, написанные на Rust. Диалект Mini-C

Группа Open Source

Опубликован релиз языка программирования общего назначения Rust 1.84, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки).

Методы работы с памятью в Rust избавляют разработчика от ошибок при манипулировании указателями и защищают от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo. Для размещения библиотек поддерживается репозиторий crates.io.

Безопасная работа с памятью обеспечивается в Rust во время компиляции через проверку ссылок, отслеживание владения объектами, учёт времени жизни объектов (области видимости) и оценку корректности доступа к памяти во время выполнения кода. Rust также предоставляет средства для защиты от целочисленных переполнений, требует обязательной инициализации значений переменных перед использованием, лучше обрабатывает ошибки в стандартной библиотеке, применяет концепцию неизменяемости (immutable) ссылок и переменных по умолчанию, предлагает сильную статическую типизацию для минимизации логических ошибок.

Основные новшества:

  • В пакетном менеджере Cargo стабилизирован механизм обработки зависимостей, выбирающий версии зависимых компонентов с учётом совместимости с версиями компилятора Rust, заявленными как минимально поддерживаемые проектом (MSRV, Minimum Supported Rust Version). Новая возможность позволяет избавить сопровождающих от необходимости ручного выбора старых версий каждой зависимости в проектах, сохраняющих совместимость со старыми версиями инструментария Rust. Новый режим определения зависимостей будет активирован по умолчанию в выпуске Rust 1.85, а пока доступен в формате опции, для включения которой в секции "[resolver]" в файле ".cargo/config.toml" следует указать 'incompatible-rust-versions = "fallback"'.
  • Начат перевод компилятора на новый обработчик типов (trait solver), предназначенный для проверки границ применимости типажей, нормализации типов и оценки совместимости типов.В версии 1.84 новый обработчик задействован для проверки согласованности реализаций типажей, т.е. оценки существования не более одного типажа для рассматриваемого типа с учётом кода из других crate-пакетов. Указанная проверка позволила избавиться от проблем в старой реализации обработчика типов, потенциально способных привести к появлению конфликтов из-за пересечения разных реализаций типажей.
  • Предложен новый API "Strict Provenance", который можно использовать для приведения указателя к целому числу и обратно с учётом прикреплённых к указателю метаданных с информацией о его происхождении и области использования (помимо адреса к указателю прикрепляется значение "provenance" с информацией о связи с другими указателями, позволяющей определить где и когда указатель может обращаться к памяти). При приведении указателя к целому числу и обратно возникает неопределённое поведение из-за проблематичности отследить происхождение результирующего указателя. Новый API позволяет выполнять низкоуровневые операции с указателями, такие как сохранение дополнительной информации в младших битах указателя, без приведения указателя к целому числу.
  • В разряд стабильных переведена новая порция API, в том числе стабилизированы методы и реализации типажей:
  • Ipv6Addr::is_unique_local
  • Ipv6Addr::is_unicast_link_local
  • core::ptr::with_exposed_provenance
  • core::ptr::with_exposed_provenance_mut
  • <ptr>::addr
  • <ptr>::expose_provenance
  • <ptr>::with_addr
  • <ptr>::map_addr
  • <int>::isqrt
  • <int>::checked_isqrt
  • <uint>::isqrt
  • NonZero::isqrt
  • core::ptr::without_provenance
  • core::ptr::without_provenance_mut
  • core::ptr::dangling
  • core::ptr::dangling_mut
  • Pin::as_deref_mut
  • Признак "const" применён в функциях:
  • AtomicBool::from_ptr
  • AtomicPtr::from_ptr
  • AtomicU8::from_ptr
  • AtomicU16::from_ptr
  • AtomicU32::from_ptr
  • AtomicU64::from_ptr
  • AtomicUsize::from_ptr
  • AtomicI8::from_ptr
  • AtomicI16::from_ptr
  • AtomicI32::from_ptr
  • AtomicI64::from_ptr
  • AtomicIsize::from_ptr
  • <ptr>::is_null
  • <ptr>::as_ref
  • <ptr>::as_mut
  • Pin::new
  • Pin::new_unchecked
  • Pin::get_ref
  • Pin::into_ref
  • Pin::get_mut
  • Pin::get_unchecked_mut
  • Pin::static_ref
  • Pin::static_mut
  • Стабилизирована поддержка ассемблерных inline-вставок для архитектур s390x и Arm64EC.
  • Для целевой платформы WebAssembly стабилизирована поддержка функциональности multivalue, reference-types и tail-call.
  • Реализован второй уровень поддержки платформы wasm32v1-none. Второй уровень поддержки подразумевает гарантию сборки.

Дополнительно можно отметить несколько проектов, связанных с Rust:

  • Опубликован релиз операционной системы Tock 2.2, написанной на языке Rust и ориентированного на использование в микроконтроллерах. Система позволяет организовать одновременное выполнение нескольких не заслуживающих доверия приложений на встраиваемых устройствах, имеющих ограниченный размер ОЗУ, таких как датчики, TPM (Trusted Platform Module), брелоки аутентификации и носимые устройства. Поддерживаются платформы с микроконтроллерами на базе архитектур ARM Cortex-M и RISC-V. Ключевой особенностью Tock является изоляция уровней приложений, ядра и слоя с драйверами, а также изоляция каждого приложения и драйвера по отдельности. Для изоляции используются как возможности языка Rust, так и разделение на уровне защиты памяти.

  • Проект VEKOS (Verified Experimental Kernel OS) развивает ядро операционной системы на языке Rust, обеспечивающее верификацию выполняемых компонентов. При каждой операции с файловой системой, создании процесса и выделении памяти формируется криптографическое подтверждение, позволяющее верифицировать операцию во время выполнения (реализация сравнивается с применением блокчейна для верификации действий в операционной системе). В файловой системе VKFS для обеспечения целостности и защиты от искажения задним числом задействована структура "дерево Меркла" (Merkle Tree), каждая ветка в котором верифицирует все нижележащие ветки и узлы, благодаря древовидному хешированию. Выделение памяти производится в режиме COW (Copy-On-Write).

  • Группа исследователей из Microsoft и Inria развивает подмножество языка Си - Mini-C, предназначенное для автоматической трансляции программ на языке Си в представление на языке Rust. В отличие от компилятора c2rust, новый проект позволяет генерировать Rust-код без использования unsafe, но нацелен главным образом на преобразование Си-проектов, имеющих формальное доказательство надёжности. Подразумевается, что будет проще вначале перевести Си-проект в представление на Mini-C, в котором не допускаются арифметические операции с указателями, чем переписывание unsafe-блоков после прямой компиляции из Си в Rust.
    Реализация компилятора базируется на инструментарии KaRaMeL. Mini-C разработан и опробован в рамках проекта по переписыванию на Rust криптографической библиотеки HACL*, для которой предоставлено формальное доказательство надёжности. Подобное доказательство было использовано для демонстрации возможности генерировать из Mini-C безопасный код на Rust.

  • Дэниел Cтенберг (Daniel Stenberg), автор утилиты curl, объявил о прекращении разработки и поддержки проектом Curl альтернативного HTTP-бэкенда, написанного на Rust с использованием библиотеки Hyper. В качестве причины указано отсутствие интереса со стороны разработчиков и пользователей.

  • Анонсирован бета-выпуск командной оболочки Fish 4.0, переписанный на языке Rust. Отмечается, что после двух лет разработки кодовая база Fish была полностью переведена с С++ на Rust.Переход на Rust позволил решить проблемы с многопоточностью, получить современный инструментарий, выявляющий ошибки на этапе компиляции, повысить безопасность работы с памятью и сделать проект более привлекательным для новых разработчиков.

  • Проект Tor опубликовал выпуск Arti 1.3.2, альтернативной реализации Tor-клиента на языке Rust.Arti предоставляет встраиваемую библиотеку, которую могут использовать различные приложения. При создании Arti учтён прошлый опыт разработки Tor для того, чтобы избежать известных архитектурных проблем, сделать проект более модульным и эффективным. Ветка 1.x отмечена как пригодная для использования обычными пользователями и обеспечивающая тот же уровень конфиденциальности, юзабилити и стабильности, что и основная реализация на языке Си. В новой версии продолжена разработка RPC, поведена подготовка в реализации поддержки релеев и добавлена защита от DoS-атак на Onion-сервисы.

  • Опубликован выпуск игрового движка Bevy 0.15, написанного на Rust. В движке применяется датацентричная модель (Data Driven) определения игровой логики, построенная поверх набора готовых компонентов Bevy ECS (Entity Component System), которые могут выполняться параллельно. Поддерживается 2D и 3D рендеринг, скелетная анимация, определение графа рендеринга, система формирования сцен, фреймворк для построения интерфейса пользователя, внесение изменений в сцены и ресурсы без необходимости перезапуска.

  • Опубликован консольный текстовый редактор Helix 25.01, написанный на Rust и расширяющий идеи, заложенные в vim и neovim. Поддерживается интеграция с LSP-серверами и с Tree-sitter, одновременное выделение нескольких блоков, использование нескольких курсоров при редактировании, темы оформления, отладочный протокол DAP (Debug Adapter Protocol).

  • В браузерный движок Servo, написанный на Rust, добавлена поддержка тёмного режима оформления. На 20% сокращён размер браузера ServoShell. Поддержка web-спецификаций доведена до возможность входа и чтения сообщений в Discord (отправка сообщений пока невозможна).

  • Компания Mozilla представила инструментарий Uniffi for React Native для создания модулей к React Native на языке Rust.

  • Проведено тестирование производительности кодировщиков изображений в формате PNG. Декодировщики на Rust (png, zune-png, wuffs) оказались быстрее декодировщиков на Си (libpng, spng, stb_image). Например, crate-пакет png (image-rs) обогнал libpng в 1.8 раза на системе x86 и в 1.5 раза на системе ARM.

image-rs:375.401 MP/s (average) 318.632 MP/s (geomean)
zune-png:376.649 MP/s (average) 302.529 MP/s (geomean)
wuffs:376.205 MP/s (average) 287.181 MP/s (geomean)
libpng:208.906 MP/s (average) 173.034 MP/s (geomean)
spng:299.515 MP/s (average) 235.495 MP/s (geomean)
stb_image:234.353 MP/s (average) 171.505 MP/s (geomean)

>>> Подробности

 , ,

MrSugoma ()

Выпуск пользовательского окружения Enlightenment 0.27 и библиотек EFL 1.28

Группа Open Source

После года разработки состоялся релиз пользовательского окружения Enlightenment 0.27, которое базируется на наборе библиотек EFL (Enlightenment Foundation Library) и виджетах Elementary. Выпуск доступен в исходных текстах без публикации готовых сборок.

Список изменений для выпуска 0.27 не сформирован, доступен лишь перечень коммитов, в котором в основном перечислены исправления ошибок и незначительные улучшения в виджетах.

Рабочий стол в Enlightenment формируют такие компоненты, как файловый менеджер, набор виджетов, панель запуска приложений и графические конфигураторы.

Графические конфигураторы предоставляют как высокоуровневые средства настройки (изменение оформления, настройка виртуальных рабочих cтолов, управление шрифтами, разрешением экрана, раскладкой клавиатуры, локализацией и т.п.), так и возможности по низкоуровневому тюнингу (например, можно настроить параметры кэширования, графического ускорения, потребления энергии, изменить логику работы оконного менеджера).

Для расширения функциональности предлагается использовать модули (гаджеты), а для переработки внешнего вида - темы оформления.

Доступны модули для отображения на десктопе календаря-планировщика, прогноза погоды, данных мониторинга, регулятора громкости, виджета для оценки заряда аккумулятора. Составляющие Enlightenment компоненты жёстко не привязаны друг к другу и могут использоваться в других проектах или для создания специализированных окружений, таких как оболочки для мобильных устройств.

Из обязательных зависимостей заявлены EFL, libexif и libpam (только в Linux).

Среди рекомендованных зависимостей, необходимых для достижения полноценной функциональности: connman для настройки сети; bluez5 для работы с Bluetooth; bc для встроенного калькулятора; pulseaudio для управления звуковыми устройствами; acpid для обработки различных аппаратных событий; packagekit для отслеживания системных обновлений; udisks2 для монтирования внешних дисков; ddcutil для управления подсветкой экрана; gdb для трассировки аварийных завершений.

Одновременно проект Enlightenment опубликовал набор библиотек EFL 1.28 (Enlightenment Foundation Library), позволяющих создавать визуально привлекательные графические интерфейсы, отличающиеся компактностью, низким потреблением ресурсов и высокой производительностью.

Несмотря на изначальное развитие в качестве базиса для окружения Enlightenment, компоненты EFL часто используются для построения интерфейсов потребительской электроники и мобильных устройств. Например, EFL является составной частью мобильной платформы Tizen, используются в бытовой технике Electrolux, продуктах Samsung, ProFUSION, Free.fr и Calaos.

Состав EFL:

Eina - библиотека с реализацией типов данных (массив, хэш, список, дерево) и вспомогательных инструментов (работа с логами, оценка производительности, преобразование форматов и т.д.).

Eet - библиотека для записи произвольного набора блоков данных в файл для последующего быстрого чтения в произвольном порядке.

Evas - система рендеринга для организации вывода на экран.

Evas оперирует содержимым экрана как сценой с объектами, состояние которых можно отслеживать. Над сценой можно проделывать такие операции как масштабирование, вращение и 3D-трансформации.

Подобный подход, абстрагированный от размещения экранных элементов, позволяет разрабатывать интерфейс пользователя с точки зрения дизайнера, а не программиста (в коде достаточно определить только логику и не думать о прорисовке и выводе на экран). Evas также абстрагирует метод вывода, что позволяет использовать один и тот же код в сочетании с программным и аппаратно ускоренным рендерингом.

Ecore - библиотека для организации цикла обработки событий, предлагающая набор модулей для упрощения связанных с обработкой событий задач, таких как работа с Evas, нитями, сетевыми соединениями и т.п.

Embryo - библиотека для написания небольших компилируемых приложений для встраиваемых устройств. Edje - графическая библиотека, отделяющая внешний вид от кода (оформление задаётся в виде загружаемого из файла шаблона).

Edje занимает нишу между HTML+CSS и SVG. При помощи данной библиотеки можно сформировать пользовательский интерфейс, снабжённый анимированными визуальными эффектами и поддерживающий динамическое оформление (внешний вид можно полностью поменять просто сменив EDJ-шаблон и не трогая код, при этом, в отличие от визуальных тем, порядок расположения элементов может быть произвольно изменён).

Efreet - библиотека, позволяющая использовать в приложениях спецификации Freedesktop.org для работы с пиктограммами, Desktop-файлами и меню.

Eeze - библиотека для организации взаимодействия с внешними устройствами через udev, HAL и другие механизмы.

Expedite - инструментарий для измерения производительности, который может тестировать различные движки Evas, такие как X11,

XRender, OpenGL, SDL и DirectFB.

Evil - реализация уровня совместимости для работы на платформе Windows.

Eio - абстрактный интерфейс для доступа к файловой системе и реализации асинхронного ввода/вывода.

Emotion - библиотека для интеграции в приложения обработчиков для проигрывания звука и видео. Воспроизведение видео может осуществляться с использованием Gstreamer, Xine или других внешних плагинов (например, VLC), при этом видео отображается как стандартный объект в Evas.

Ethumb - библиотека для формирования эскизов изображений, соответствующих стандартам freedesktop.org. Ethumb реализован в виде сервиса dbus и клиентской библиотеки, взаимодействующей с данным сервисом.

Elementary - набор виджетов с готовой реализацией разнообразных графических элементов (от кнопок и элементов управления, до календаря и модуля редактирования текста).

Eldbus - надстройкой над DBus.

Ephysics - предоставляет средства для использования движка симуляции физических процессов Bullet в приложениях на базе EFL.

Ephysics обеспечивает связку Bullet с библиотеками Ecore и Evas.

Ecore Audio - API для работы со звуком.

>>> Подробности

 

MrSugoma ()

В Fedora 42 планируют поставлять оптимизированные варианты исполняемых файлов

Группа RHEL совместимые

В выпуске Fedora 42, намеченный на конец апреля, предложено разрешить сопровождающим включать в пакеты дополнительные варианты исполняемых файлов, собранные с включением оптимизаций для микроархитектур x86-64-v2, x86-64-v3 и x86-64-v4. Отмечается, что Fedora продолжает собирать пакеты для архитектуры x86-64-v1, в то время как CentOS использует при сборке архитектуру x86-64-v2, а RHEL 10 - x86-64-v3. В большинстве случаев прирост производительности при сборке для подобных архитектур не превышает 10%, но в отдельных ситуациях приводит к заметному повышению производительности (до 120%). Предложение пока не утверждено комитетом FESCo (Fedora Engineering Steering Committee), отвечающим за техническую часть разработки дистрибутива Fedora.

В Fedora уже допускается поставка дополнительных библиотек, оптимизированных для расширенных версий архитектуры x86_64, и подобную возможность теперь планируют распространить на исполняемые файлы. Загрузка оптимизированных реализаций библиотек осуществляется компоновщиком (dynamic linker), который проверяет наличие дополнительных вариантов в подкаталогах glibc-hwcaps, размещаемых в областях ФС, просматриваемых при поиске библиотек (например, /usr/lib64/glibc-hwcaps/x86-64-v2).

В случае исполняемых файлов предлагается использовать прослойку hwcaps-loader, которая будет выбирать и запускать вариант исполняемого файла, соответствующий возможностям текущей системы. Для пакетов, поставляющих несколько вариантов исполняемых файлов данную прослойку предлагается выставлять через символическую ссылку. Решение о добавлении дополнительно оптимизированных исполняемых файлов будут принимать сопровождающие, в зависимости от результатов тестирования производительности конкретных пакетов.

Версии x86-64-v* определяют неофициальный способ идентификации срезов состояния микроархитектуры, охватывающих определённые наборы расширений:

  • x86-64-v2 охватывает расширения SSE3, SSE4_2, SSSE3, POPCNT, LAHF-SAHF и CMPXCHG16B.
  • x86-64-v3 - AVX, AVX2, BMI2, FMA, LZCNT, MOVBE и SXSAVE.
  • x86-64-v4 - AVX512F, AVX512BW, AVX512CD, AVX512DQ и AVX512VL.

Дополнительно можно отметить предложение по унификации обновления загрузчиков grub и shim в атомарных и обычных вариантах Fedora. Вместо обновления содержимого каталогов /boot и /boot/efi через вызов скрипта во время установки rpm-пакета, для обновления загрузчика предлагается использовать инструментарий bootupd, который уже применяется в атомарно обновляемых вариантах Fedora. В rpm-пакетах с загрузчиками содержимое предлагается устанавливать не напрямую в каталоги /boot и /boot/efi, а в отдельный каталог внутри раздела /usr, после чего синхронизировать с ним содержимое /boot и /boot/efi. Подобный подход даст возможность реализовать запасной вариант загрузки, который можно использовать для отката к старой конфигурации в случае проблем после обновления загрузчика.

>>> Подробности

 ,

MrSugoma ()

Выпуск дистрибутива Debian 12.9

Группа Debian

Сформировано девятое корректирующее обновление дистрибутива Debian 12, в которое включены накопившиеся обновления пакетов и добавлены исправления в инсталлятор. Выпуск включает 72 обновления с устранением проблем со стабильностью и 38 обновлений с устранением уязвимостей.

Из изменений в Debian 12.9 можно отметить обновление до свежих стабильных версий пакетов ansible, intel-microcode, nvidia-graphics-drivers, qemu, systemd, tzdata. Удалены пакеты criu (проблемы со сборкой на архитектуре arm64) и tk-html3 (прекращено сопровождение основного проекта).

Для загрузки и установки "с нуля" подготовлены установочные сборки c Debian 12.9. Системы, установленные ранее и поддерживаемые в актуальном состоянии, получают обновления, присутствующие в Debian 12.9, через штатную систему установки обновлений. Исправления проблем безопасности, включённые в новые выпуски Debian, доступны пользователям по мере выхода обновлений через сервис security.debian.org.

>>> Подробности

 

MrSugoma ()

fastfetch 2.34.0

Группа Open Source

9 января состоялся выпуск 2.34.0 кроссплатформенных консольных утилит fastfetch и flashfetch, написанных на языке C и распространяемых по лицензии MIT.
Утилиты предназначены для вывода информации о системе подобно neofetch. Поддерживаются Linux, Android, FreeBSD, macOS, SunOS и Windows 7+. В отличие от fastfetch, flashfetch не поддерживает расширенные возможности вывода информации, профили и многое другое.

( читать дальше... )

>>> Подробности

 

MrSugoma ()

Инициатива по поддержке проектов, использующих движок Chromium

Группа Chromium совместимые

Организация Linux Foundation объявила о создании инициативы «Supporters of Chromium-Based Browsers», предоставляющей нейтральную площадку, на которой лидеры индустрии, академическое сообщество, разработчики и сторонники открытого программного обеспечения могут совместно работать над проектами, связанными с браузерным движком Chromium. Учредителями выступили компании Google, Meta, Microsoft и Opera.

Целью инициативы заявлено поддержание экосистемы, сформировавшейся вокруг движка Chromium, стимулирование сотрудничества между проектами, использующими Chromium, и оказание финансовой поддержки сообществу разработчиков, желающих участвовать в развитии данного движка. Предполагается, что совместная инициатива поможет устранить преграды, затрудняющие продвижение инноваций, а также предоставит недостающие ресурсы для проектов, связанных с Chromium. Управление разработкой непосредственно движка Chromium продолжит осуществляться компанией Google, которая выступает гарантом его устойчивого развития.

>>> Подробности

 , , , ,

MrSugoma ()

Выпуск интегрированного набора интернет-приложений SeaMonkey 2.53.20

Группа Firefox

Опубликован выпуск набора интернет-приложений SeaMonkey 2.53.20, объединяющего в одном продукте web-браузер, почтовый клиент, клиент NNTP-конференций, систему агрегации новостных лент (RSS/Atom) и WYSIWYG-редактор html-страниц Composer. В форме предустановленных дополнений предлагаются IRC-клиент ChatZilla, набор средств для web-разработчиков DOM Inspector и календарь-планировщик Lightning. В новый выпуск перенесены исправления и изменения из актуальной кодовой базы Firefox (SeaMonkey 2.53 основан на браузерном движке Firefox 60.8 с портированием связанных с безопасностью исправлений и некоторых улучшений из актуальных веток Firefox).

В версии 2.53.20 предложена новая реализация менеджера закладок, основанная на интерфейсе Firefox Library. В конфигуратор добавлен интерфейс для настройки цветовой схемы, меняющий параметр browser.display.prefers_color_scheme. В инсталляторе обеспечена регистрация в системе MIME-типов, обрабатываемых в SeaMonkey.

Проведена большая чистка кодовой базы IRC-клиента ChatZilla и устранены выявленные при этом недоработки. Например, вместо обработчиков arrayContains, arrayIndexOf, arrayRemoveAt и arrayInsertA в ChatZilla задействован штатный объект Array, вместо обработчика stringTrim - метод Trim из JavaScript-объекта String, вместо обработчика fopen - API LocalFile. Решены проблемы при использовании протокола IRC поверх TLS.

>>> Подробности

 ,

MrSugoma ()

Релиз Firefox 134

Группа Firefox

Состоялся релиз web-браузера Firefox 134 и сформированы обновления прошлых веток с длительным сроком поддержки - 115.19.0 и 128.6.0. На стадию бета-тестирования переведена ветка Firefox 135, релиз которой намечен на 4 февраля.

( читать дальше... )

>>> Подробности

 ,

MrSugoma ()

В среде рабочего стола Budgie 10.10 будет оставлена только поддержка Wayland

Группа Open Source

Опубликован годовой отчёт о развитии среды рабочего стола Budgie, в котором кроме достижений за 2024 год упомянуты планы на 2025 год. Основная работа в 2024 году была сосредоточена на развитии сеанса, использующего протокол Wayland, разработке композитного менеджера Magpie, создании управляющего процесса Budgie Daemon v2 и его портировании на Qt6. В следующем выпуске Budgie 10.10, который намерены опубликовать в течение первого квартала 2025 года, решено полностью отказаться от поддержки X11 и оставить только возможность работы в окружениях на базе протокола Wayland. В git-репозитории Budgie полный переход на Wayland был осуществлён в июле 2024 года.

Из задач, которые необходимо решить до релиза Budgie 10.10, упоминается достижение паритета в функциональности апплетов со старым окружением на базе X11, доработка MenuManager и стабилизация нового интерфейса для настройки параметров экрана. Пакеты с Budgie 10.10 планируют включить в состав осенних выпусков Fedora 43 и Ubuntu 25.10. После релиза Budgie 10.10 ветка 10.x будет переведена в режим сопровождения, в котором допускается только исправление ошибок. В дальнейшем все ресурсы будут брошены на развитие ветки Budgie 11, примечательной отделением функциональности рабочего стола от слоя, обеспечивающего визуализацию и вывод информации.

>>> Подробности

 , ,

MrSugoma ()

Мэтью Гаррет опроверг критику TPM, распространяемую Фондом СПО

Группа Open Source

Мэтью Гаррет (Matthew Garrett), разработчик ядра Linux, в 2013 году получивший премию Фонда СПО за вклад в развитие свободного ПО, пояснил суть работы современных технических средств защиты авторских прав (DRM), используемых видеосервисами. К написанию статьи Мэтью подтолкнули встречающиеся в обиходе предубеждения, связывающие DRM c использованием криптопроцессоров (TPM, Trusted Platform Module).

Заблуждение о связи DRM с TPM среди прочего упоминаются в проводимой Фондом СПО кампании «Defective by Design» («Дефектный из коробки»), направленной против DRM, в которой утверждается, что большинство крупных платформ потокового вещания используют TPM для дешифровки медиапотоков, специально выводя дешифровку из-под контроля пользователя. В качестве подтверждения подобного тезиса указано, что Microsoft настаивает, что только оборудование с TPM может работать под управлением Windows 11, и сделано это для помощи компаниям, занимающимся потоковым вещанием, в их попытке обеспечить воспроизведение контента только в жёстко ограниченных средах.

Мэтью Гаррет не знает, чем на самом деле руководствуется Microsoft, требуя TPM в Windows 11, и не уверен, что это оправданно. При этом, так как его текущая работа непосредственно связана с написанием кода, использующего TPM, он считает, что наличие TPM позволяет реализовать ряд полезных функций безопасности, и если бы пришлось выбирать, он бы выбрал компьютер с TPM. По мнению Гаррета заявление Фонда СПО на 100% неверно и он не знает ни одной платформы потокового вещания, использующей TPM. Существует аппаратная DRM, которую медиакомпании применяют для ограничения пользователей, но она реализуется не на базе TPM, а на стороне графического процессора.

Доступны три основные реализации DRM:

  • Widevine - принадлежит Google, используется в Android, Chromebook и некоторых других устройствах.
  • Fairplay - реализация Apple, используется для Mac и iOS.
  • Playready - реализация Microsoft, используется в Windows, на некоторых аппаратных устройствах потокового вещания и телевизорах.

Как правило, данные реализации поддерживают несколько уровней функциональности, применяемых в зависимости от возможностей имеющегося устройства - от программной реализации всех функций DRM до аппаратной обработки. Провайдеры потокового вещания могут выбирать, какой уровень функциональности и качества предоставлять в зависимости от возможностей DRM, реализованных на клиентском устройстве. Для контента 4K и HDR обычно используется аппаратный DRM. В любом случае системы потокового вещания передают клиенту зашифрованный контент, а стек DRM расшифровывает его, прежде чем сжатые данные могут быть декодированы и воспроизведены.

При использовании программных реализаций DRM расшифрованный материал размещается в области памяти, к которой имеет доступ операционная система. Таким образом, пользователь может перехватить расшифрованный поток, что сводит на нет весь замысел защиты. Поставщики пытаются усложнить эту задачу, максимально завуалировав свой код, а в некоторых случаях переместив часть функциональности на уровень ядра. Но это не помогает и практически все программные DRM хотя бы в некоторой степени взломаны, а копии фильмов довольно быстро оказываются доступны через Bittorrent после выхода. Именно поэтому видео высокого качества, как правило, доступно только клиентам, поддерживающим аппаратный DRM.

Аппаратные реализации DRM отличаются между собой. На устройствах ARM расшифровка производится в доверенной среде исполнения (TEE, Trusted Execution Environment), такой как ARM TrustZone. Выполняемый в TEE код полностью изолирован от операционной системы. При помещении кода DRM в TrustZone, криптографические операции выполняются в области памяти, к которой у операционной системы нет доступа, что делает невозможным описанный ранее захват картинки.

На системах x86 TEE не унифицирован (Intel продвигал SGX, но он больше не применяется в потребительских устройствах), поэтому вместо него эта задача обычно переносится на сторону GPU. Из ранее упомянутых реализаций DRM только Playready предоставляет аппаратный режим на системах x86, и не удалось найти публичной документации о том, какие функции должны предоставлять драйверы для работы подобного аппаратного DRM.

В общем виде работа аппаратного DRM сводится к следующим операциям: Во время согласования сеанса между клиентом и платформой потокового вещания, ключи шифрования контента формируются с использованием ключей, хранимых в GPU или TEE, и недоступных из операционной системы. После расшифровки данные декодируются и отображаются. Декодирование производится на стороне GPU или в TEE. При этом даже в реализациях, которые используют для криптографии TEE, фактическое декодирование потока может происходить на стороне GPU.

Основное отличие аппаратного DRM в том, что декодированный видеоматериал по-прежнему хранится в оперативной памяти, к которой операционная система не имеет доступа, а GPU подставляет этот видеоматериал в финальный вывод. Именно поэтому, если сделать снимок экрана браузера, воспроизводящего видео с использованием аппаратного DRM, на изображении будет просто чёрное окно.

Иногда TPM называют TEE, и в некотором смысле так оно и есть, за исключением того, что TPM предоставляет строго определённые функции - пользователь не может запустить произвольный код на TPM и ему доступна только та функциональность, которую предоставляет TPM. Функций для расшифровки данных с помощью ключей, привязанных к TPM, недостаточно, так TPM получает данные от операционной системы и не может напрямую взаимодействовать с GPU.

Таким образом, операционная система может передавать TPM зашифрованные данные и получать обратно расшифрованный вариант, но это мало чем отличается от программного DRM, так как весь смысл аппаратной защиты в том, чтобы расшифрованная версия потока никогда не была видна операционной системе. Кроме того, чипы TPM сами по себе медленные и маловероятно, что на рынке есть TPM, способный расшифровать поток 1080p в реальном времени, не говоря о потоке 4K.

То, что Фонд СПО сосредоточился на TPM, не только технически неверно, но и свидетельствует о непонимании того, что на самом деле происходит в индустрии. Пока Фонд СПО фокусировал внимание на TPM, производители GPU спокойно внедрили необходимые для DRM технологии без каких-либо жалоб со стороны данной организации. Компания Microsoft с энтузиазмом участвовала в создании аппаратной DRM в Windows, в результате чего пострадала свобода пользователей, но аппаратная DRM на основе Playready прекрасно работает на оборудовании, не оснащённом TPM, и будет продолжать работать.

>>> Подробности

 , , , ,

MrSugoma ()