· | 01.04 | Второй предварительный выпуск мессенджера Pidgin 3.0 (1) |
Представлен второй экспериментальный выпуск клиента для мгновенного обмена сообщениями Pidgin 3.0 (2.91), позволяющего одновременно работать в нескольких сетях с разными протоколами и переключаться между чатами при помощи вкладок. Выпуск отмечен как имеющий уровень качества предварительной альфа-версии, не рассчитанной на повседневное применение. Сборки подготовлены в формате Flatpak (пока доступен только архив с кодом).
Ветка Pidgin 3 разрабатывается с 2011 года, а до этого ещё три года обсуждалась на уровне концепций и идей. В Pidgin 3 выполнен переход на систему типов GObject, библиотеки GTK4 и Adwaita, сборочную систему Meson, GPlugin для обработки плагинов, SQLite для хранение истории чатов и GSettings для работы с настройками. Полностью переработан API. Для определения элементов интерфейса задействован GTK Builder XML, а для отображения истории чатов создана собственная библиотека виджетов Talkatu. В интерфейсе объединены в одном окне список контактов и окон с чатами. Прекращена поставки консольного клиента Finch (не исключено, что его могут вернуть в будущем). Из протоколов пока поддерживается только IRCv3, а также развиваются новые реализации протоколов XMPP и Bonjour, которые пока поддерживаются частично. Ветка Pidgin 3 несовместима с Pidgin 2 и ранее созданными плагинами, но может быть установлена параллельно с имеющимися сборками Pidgin 2. Среди изменений в представленном обновлении:
| ||
Обсуждение (1) |
Тип: Программы |
| ||
· | 01.04 | Релиз Firefox 137 с поддержкой группировки вкладок (47 +8) |
Состоялся релиз web-браузера Firefox 137 и сформированы обновления прошлых веток с длительным сроком поддержки - 115.22.0 и 128.9.0. На стадию бета-тестирования переведена ветка Firefox 138, релиз которой намечен на 29 апреля.
Основные новшества в Firefox 137:
Кроме новшеств и исправления ошибок в Firefox 137 устранено 14 уязвимостей. 13 уязвимостей помечены как опасные. Все из опасных уязвимостей вызваны проблемами работы с памятью, такими как переполнения буферов и обращение к уже освобождённым областям памяти. Потенциально данные проблемы способны привести к выполнению кода злоумышленника при открытии специально оформленных страниц.
| ||
Обсуждение (47 +8) |
Тип: Программы |
| ||
· | 01.04 | В ядро Linux 6.15 приняты значительные оптимизации сетевой подсистемы и exFAT (83 +30) |
В состав кодовой базы ядра Linux, на основе которой формируется выпуск 6.15, принят набор изменений с оптимизациями, в ряде ситуаций значительно повышающих производительность сетевых операций:
Кроме того, в находящееся в разработке ядро Linux 6.15 принято изменение для драйвера файловой системы exFAT, ускоряющее операции удаления файлов. Ранее драйвер exFAT по отдельности посылал накопителям запросы "discard" на каждый освобождаемый кластер удаляемого файла. Оптимизированная версия группирует запросы, в результате чего время удаления тестового файла размером 80 ГБ сократилось с 286 секунд до 1.6 секунды.
| ||
· | 01.04 | Выпуск системы резервного копирования Restic 0.18. Атака на CDC (25 +4) |
Представлен выпуск системы резервного копирования Restic 0.18, позволяющей хранить резервные копии в зашифрованном виде в версионированном репозитории с поддержкой дедупликации. Система изначально рассчитана на то, что резервные копии сохраняются в окружениях, не заслуживающих доверия, и попадание резервной копии в чужие руки не должно скомпрометировать систему. При создании резервной копии возможно определение гибких правил для включения и исключения файлов и каталогов (формат правил напоминает rsync или gitignore). Поддерживается работа в Linux, macOS, Windows и BSD-системах. Код проекта написан на языке Go и распространяется под лицензией BSD.
Резервные копии могут храниться в локальной ФС, на внешнем сервере с доступом по SFTP/SSH или HTTP REST, в облаках Amazon S3, OpenStack Swift, BackBlaze B2, Microsoft Azure Blob Storage и Google Cloud Storage, а также в любых хранилищах, для которых имеются бэкенды rclone. Для хранения также может использоваться развиваемый проектом rest server, обеспечивающий более высокую производительность по сравнению с другими бэкендами и способный работать в режиме только для дополнения, не позволяющем удалить или изменить резервные копии в случае компрометации исходного сервера и доступа к ключам шифрования. Система поддерживает снапшоты, отражающие состояние иерархии каталогов в разные моменты времени (снапшоты создаются автоматически для каждой резервной копии). Возможно копирование снапшотов между разными репозиториями. Для экономии трафика в процессе создания резервных копий копируются только изменившиеся данные. Снапшот с резервной копией может быть примонтирован в форме виртуального раздела (монтирование осуществляется при помощи FUSE). Также предоставляются команды для анализа изменений и выборочного извлечения файлов. Хранилище резервных копий в Restic манипулирует не целыми файлами, а блоками плавающего размера, выбираемыми с использованием подписи Рабина. Информация хранится в привязке к содержимому, а не именам файлов (связанные с данными имена и объекты определяются на уровне метаданных блока). Для экономии места в хранилище и исключения лишнего копирования данных выполняется дедупликация. На внешних серверах информация сохраняется в зашифрованном виде - для контрольных сумм и дедупликации используются хэши SHA-256, для шифрования - алгоритм AES-256-CTR, а для гарантирования целостности - коды аутентификации на основе Poly1305-AES. Предусмотрена возможность верификации резервной копии по контрольным суммам и кодам аутентификации для подтверждения, что целостность файлов не нарушена.
В новой версии устранена возможность совершения атаки (PDF) по определению наличия заданных файлов в зашифрованном хранилище резервных копий. Атака позволяет определить находится ли в зашифрованном бэкапе какой-то конкретный файл, получив доступ к хранилищу резервных копий или при возможности анализа сетевого трафика с резервными копиями. Например, атаку может совершить администратор сервера, на который сохраняются бэкапы, интернет-провайдер или спецслужбы, получившие доступ к серверу или трафику. Целью совершения атаки может стать расследование утечки информации, в котором спецслужбы смогут оценить наличие интересующих документов в хранилище резервных копий. Для эксплуатации уязвимости атакующий должен добиться добавления своих данных в резервную копию жертвы или знать, что известный ему файл находится в резервной копии. Если в резервной копии имеется файл, о котором знает атакующий (например, какой-то типовой системный или мультимедийный контент), то получив доступ к зашифрованному хранилищу атакующий может определить, есть ли внутри другие интересующие его файлы. Метод основан на том, что исходя из особенностей сжатия контента, можно определить параметры блоков, используемых при дроблении содержимого. Для определения подобных параметров достаточно определить 3 зашифрованных блока, содержащих данные, известные атакующему. Уязвимость не специфична для Restic и затрагивает другие системы резервного копирования, использующие разделение данных на блоки при помощи техники CDC (Content-Defined Chunking), такие как BorgBackup, Tarsnap, Bupstash и Duplicacy. В Tarsnap проблема устранена в обновлении 1.0.41, в BorgBackup ведётся работа над исправлением, которое намерены включить в ветку borg 2. В Bupstash последнее изменение было 2 года назад, а в Duplicacy - 4 месяца назад. Дополнительно отмечается, что в системах, использующих дедупликацию, при наличии возможности добавлять свои файлы в резервную копию можно поступить проще и определить наличие интересующих файлов косвенным путём. После добавления проверяемого файла можно оценить изменение размера хранилища - если файл уже имеется в хранилище, то его повторное добавление из-за дедупликации не приведёт к должному увеличению размера. Кроме устранения уязвимости в Restic 0.18 также предложено несколько новшеств:
| ||
Обсуждение (25 +4) |
Тип: Программы |
| ||
· | 31.03 | Выпуск Phosh 0.46.0, GNOME-окружения для смартфонов (89 +5) |
Опубликован релиз Phosh 0.46, экранной оболочки для мобильных устройств, основанной на технологиях GNOME и библиотеке GTK. Окружение изначально развивалось компанией Purism в качестве аналога GNOME Shell для смартфона Librem 5, но затем вошло в число неофициальных проектов GNOME и используется в postmarketOS, Mobian, Droidian, некоторых прошивках для устройств Pine64 и редакции Fedora для смартфонов. Phosh использует композитный сервер Phoc, работающий поверх Wayland, а также собственную экранную клавиатуру squeekboard. Наработки проекта распространяются под лицензией GPLv3+.
![]()
| ||
Обсуждение (89 +5) |
Тип: Программы |
| ||
· | 31.03 | Разработчики OrioleDB предложили улучшить API для альтернативных движков PostgreSQL (28 +12) |
Разработчики OrioleDB проанализировали текущее состояние низкоуровневого API, применяемого для доступа расширений к таблицам и индексам в PostgreSQL (Table/Index Access Method (AM) API), и предложили пути его улучшения. С момента появления в PostgreSQL 12 подобного API разработчики получили возможность создавать альтернативные механизмы хранения данных. Однако, несмотря на наличие этого API и известные ограничения встроенного механизма хранения, до сих пор не появилось полнофункциональных транзакционных движков хранения, реализованных исключительно в виде расширений.
Наиболее востребованными функциями для альтернативных табличных движков PostgreSQL являются:
Изменения, необходимые в API Table/Index AM для поддержки альтернативных реализаций MVCC, рассматриваются с оглядкой на расширение OrioleDB, разработанное для устранения известных недостатков встроенного механизма хранения PostgreSQL. Проблема в том, что для полной интеграции OrioleDB с PostgreSQL требуются внесение изменений в код PostgreSQL, что усложняет внедрение проекта и подчёркивает необходимость модернизации текущего API Table AM. API Table AM не навязывает напрямую способ реализации MVCC. Тем не менее, API Table AM и API Index AM делают следующее предположение: каждый TID (Tuple/row Identifier) либо индексируется всеми индексами, либо не индексируется вообще. Даже если Index AM имеет несколько ссылок на один TID (например, GIN), все эти ссылки должны соответствовать одному и тому же индексированному значению.
![]() Этот принцип критиковали за увеличение числа операций записи ("write amplification") - если обновляется один индексированный атрибут, необходимо обновить каждый индекс в таблице. При необходимости в полной мере использовать преимущества журнала UNDO или построить другой метод хранения без "усиления записи" (например, метод WARM), требуется нарушить это предположение.
![]() Table AM основанный на UNDO, который не будет нарушать это предположение, напоминает существующий метод HOT (Heap-Only Tuples), за исключением того, что старые версии строк сохраняются в журнале UNDO и не должны умещаться в той же странице. Но, по мнению авторов, этого преимущества недостаточно, чтобы оправдать существование отдельного Table AM. Практические ограничения существующего API:
Предложено два способа преодолеть ограничения на практике:
Подход 1: API Index AM предоставляет возможности для альтернативной реализации MVCC. В то время как Table AM продолжает отвечать за все компоненты MVCC, Index AM предоставляет необходимые возможности для альтернативной реализации MVCC, а именно: хранение пользовательской полезной нагрузки (payload) вместе с TID, метод точечного удаления и даже метод точечного обновления (если TID в индексе не может быть изменён, пользовательская полезная нагрузка – может). Кроме этого, так как необходимо разрешить нескольким кортежам индекса ссылаться на один и тот же TID, методы API, применяемые при сканировании индекса, также нуждаются в обновлении. Подход 2: Индексы, поддерживающие MVCC. Альтернативой было бы разрешить индексы, поддерживающие MVCC. То есть "executor" (или, возможно, Table AM) просто вызывает методы insert() и delete() в Index AM, в то время как Index AM предоставляет возможность сканирования c учётом MVCC. Это значительно упростило бы сканирование с использованием только индексов (index-only). Даже весь Table AM в таком случае мог бы стать промежуточным слоем, хранящим данные в индексе. На диаграмме ниже приведён пример. Значение индекса 2 обновляется транзакцией 11 со значения "A" на значение "B". Поэтому значение "A" отмечено как xmax == 11, а значение "B" отмечено как xmin == 11. Таким образом можно сканировать индекс 2 и получать только видимые кортежи в соответствии с MVCC без проверок кучи (heap). Сборка мусора индекса 2 также может быть выполнена без использования кучи.
![]() При внедрении всех перечисленных новшеств в API индексных методов доступа, маловероятно, чтобы удалось одновременно доработать все индексы для поддержки всех новых возможностей. Более реалистично разрешить несколько реализаций для одного индексного метода доступа. Например, в дополнение к обычному B-tree, расширение сможет реализовать альтернативный B-tree с поддержкой MVCC внутри индекса и поддержкой идентификаторов записи произвольной длины.
![]() Таким образом, предлагается пересмотреть не только API Table AM, но и API Index AM, который исправно служил сообществу PostgreSQL на протяжении многих лет. Более того, предлагается разделить Index AM на логический слой и слой реализации. Эта переосмысленная архитектура позволит PostgreSQL поддерживать различные модели хранения.
| ||
· | 31.03 | Доступна платформа обмена сообщениями Zulip 10 (72 +12) |
Опубликован релиз Zulip 10, серверной платформы для развёртывания корпоративных мессенджеров, подходящих для организации общения сотрудников и групп разработчиков. Проект изначально был разработан компанией Zulip и открыт после её поглощения компанией Dropbox под лицензией Apache 2.0. Код серверной части написан на языке Python с использованием фреймворка Django. Клиентское ПО доступно для Linux, Windows, macOS, Android и iOS, также предоставляется встроенный web-интерфейс.
Система поддерживает как прямой обмен сообщениями между двумя людьми, так и проведение групповых обсуждений. Zulip можно сравнить с сервисом Slack и рассматривать как внутрикорпоративный аналог Twitter, применяемый для общения и обсуждений рабочих вопросов в больших группах сотрудников. Предоставляются средства для отслеживания состояния и участия одновременно в нескольких обсуждениях с использованием нитевидной модели отображения сообщений, которая является оптимальным компромиссом между привязкой к комнатам в Slack и единым публичным пространством Twitter. Одновременное нитевидное отображение всех обсуждений позволяет в одном месте охватить все группы, при этом сохранив логическое разделение между ними. Из возможностей Zulip также можно отметить поддержку отправки сообщений пользователю в offline-режиме (сообщения будут доставлены после появления в online), сохранение полной истории обсуждений на сервере и средства для поиска в архиве, возможность отправки файлов в режиме Drag-and-drop, автоматическую подсветку синтаксиса для передаваемых в сообщениях блоков кода, встроенный язык разметки для быстрого оформления списков и форматирования текста, средства для групповой отправки уведомлений, возможность создания закрытых групп, интеграция с Trac, Nagios, Github, Jenkins, Git, Subversion, JIRA, Puppet, RSS, Twitter и другими сервисами, средства для привязки к сообщениям наглядных меток. Основные новшества:
| ||
Обсуждение (72 +12) |
Тип: Программы |
| ||
· | 31.03 | Выпуск дистрибутива CachyOS 250330, поставляющего ядро с дополнительными оптимизациями (81 +9) |
Опубликован выпуск дистрибутива CachyOS 250330, основанного на пакетной базе Arch Linux и применяющего непрерывную модель доставки обновлений. Дистрибутив примечателен включением оптимизаций для повышения производительности и предоставлением возможности установки различных сред рабочего стола. Помимо базового окружения на основе KDE для установки доступны GNOME, Xfce, i3WM, Wayfire, LXQT, OpenBox, Cinnamon, Cosmic, UKUI, LXDE, Mate, Budgie, Qtile, Hyprland и Sway. Размер установочного iso-образа 2.7 ГБ. Отдельно поставляются сборки (2.8 ГБ) для носимых устройств (Handheld Edition) с интерфейсом в стиле GameMode и компонентами для любителей компьютерных игр.
В дистрибутиве по умолчанию включён планировщик задач BORE, оптимизированный для снижения задержек на рабочем столе и повышения приоритета интерактивных процессов. Ядро и пакеты собраны с включением LTO-оптимизаций (Link-Time Optimization) и задействованием инструкций, доступных в процессорах на базе микроархитектур x86-64-v3, x86-64-v4 и Zen4. При сборке базовых пакетов дополнительно включены оптимизации PGO (Profile-Guided Optimization) или BOLT (Binary Optimization and Layout Tool). В дистрибутиве поставляется web-браузер Cachy-Browser, основанный на Firefox с патчами для усиления безопасности и повышения производительности, а также изменениями от проекта Librewolf. В качестве файловых систем могут использоваться btrfs, zfs, ext4, xfs и f2fs. Основные изменения:
| ||
Обсуждение (81 +9) |
Тип: Программы |
| ||
· | 30.03 | Опубликован свободный видеокодек Theora 1.2 (150 +39) |
Организация Xiph.Org, известная разработкой видео- и аудиокодеков Daala, Opus, FLAC, Vorbis и Speex, представила новую редакцию свободного кодека Theora 1.2, сформированную спустя 15 с половиной лет после прошлого обновления. Кодек распространяется под свободной лицензией без сбора лицензионных отчислений (royalty-free). Формат сжатия видео Theora, как правило, используется совместно с аудиокодеком Vorbis в контейнерах Ogg и может работать в режимах с переменным и фиксированным битрейтом. По уровню качества кодирования Theora близок к H.264 и DiVX. Эталонная реализация кодека распространяется под лицензией BSD.
Основное внимание при подготовке новой редакции было уделено повышению производительности и эффективности кодирования. На уровне битового потока (bitstream) Theora 1.2 полностью соответствует стандартизированному в 2004 году формату кодирования видео Theora. API и ABI интерфейсы новой версии также сохраняют полную совместимость с прошлыми выпусками Theora. В состав Theora 1.2 включены 190-страничная спецификация, документация на API, черновик спецификации RTP-расширений для потокового вещания и эталонные реализации кодировщика и декодировщика. Главным изменением в Theora 1.2 стала новая реализация эталонного кодировщика, предложенного под кодовым именем "Ptalarbvorm". В новой реализации значительно повышена производительность и обеспечен более высокий уровень сжатия. При этом создаваемые новым кодировщиком файлы полностью совместимы с декодировщиками, предлагавшимися в прошлых версиях. Кроме того, в Theora 1.2 проведена оптимизация эталонного декодировщика, добавлена поддержка платформы RISC OS и значительно улучшена поддержка архитектуры ARM. Добавлены оптимизации для CPU ARM и DSP TI C64x+. Предложено три уровня скорости кодирования (старый уровень 2 переименован в 3, а вместо второго предложен новый промежуточный уровень).
| ||
Обсуждение (150 +39) |
Тип: К сведению |
| ||
· | 30.03 | Выпуск видеоредакторов Shotcut 25.03 и Flowblade 2.20 (45 +9) |
Опубликован релиз видеоредактора Shotcut 25.03, развиваемого автором проекта MLT и использующего данный фреймворк для редактирования видео. Поддержка форматов видео и звука реализована через FFmpeg. Возможно использование плагинов с реализацией видео и аудио эффектов, совместимых с Frei0r и LADSPA. Из особенностей Shotcut можно отметить возможность многотрекового редактирования с компоновкой видео из фрагментов в различных исходных форматах, без необходимости их предварительного импортирования или перекодирования. Имеются встроенные средства для создания скринкастов, обработки изображения с web-камеры и приёма потокового видео. Код написан на C++ с использованием фреймворка Qt и распространяется под лицензией GPLv3. Готовые сборки доступны для Linux (AppImage, flatpak и snap), macOS и Windows.
Среди изменений в новом выпуске:
![]() Кроме того, состоялся релиз многотрекового редактора видео Flowblade 2.20, предназначенного для компоновки видеороликов из отдельных видео, звуковых файлов и изображений. Редактор предоставляет средства для обрезки клипов с точностью до отдельных кадров, использования фильтров, определения своего порядка применения инструментов, корректировки поведения шкалы времени, композитинга изображений (например, можно поворачивать, постепенно замещать и создавать переходные эффекты). Код проекта написан на языке Python (MLT, FFmpeg, PyGTK) и распространяется под лицензией GPLv3. Сборки подготовлены в формате Flatpak. Среди изменений в новом выпуске:
![]()
| ||
Обсуждение (45 +9) |
Тип: Программы |
| ||
· | 30.03 | Доступны утилиты мониторинга nvtop 3.2.0 и htop 3.4.0. Уязвимость в atop (83 +25) |
Опубликован выпуск консольной утилиты nvtop 3.2.0, предназначенной для интерактивного мониторинга работы GPU и аппаратных ускорителей. Утилита позволяет наглядно отслеживать на графиках нагрузку, потребление памяти и изменение частоты GPU, а также просматривать процессы, наиболее активно нагружающие GPU. Поддерживаются GPU и ускорители компаний AMD, Intel, NVIDIA, Apple (M1 & M2), Huawei (Ascend), Qualcomm и Broadcom (VideoCore). Возможно отслеживание на одном экране работы сразу нескольких чипов.
В новой версии реализована поддержка драйверов Intel XE и Broadcom V3D (Raspberry Pi). Добавлена поддержка AI-ускорителя Google TPU (Tensor Processing Unit). Добавлены опции "-P" и -s" для скрытия области со списком процессов и для сохранения состояния в формате JSON. ![]() Одновременно состоялся выпуск утилиты Atop 2.11.1, предназначенной для интерактивного мониторинга параметров работы системы и отображения активности процессов. От утилиты top программа atop отличается большей детализацией (CPU, GPU, память, диски, сеть, потоки, контейнеры) и возможностью периодического сброса отчётов в файл для последующего анализа. Код написан на языке Си и распространяется под лицензией GPLv2. В новой версии устранена уязвимость (CVE-2025-31160), позволяющая локальному пользователю вызвать переполнение буфера при запуске утилиты atop другим пользователем. Например, непривилегированный пользователь может организовать атаку на администратора, запускающего утилиту atop. Проблема вызвана тем, что в atop опционально поддерживается сбор статистики о работе GPU, который вынесен в отдельный процесс atopgpud. Взаимодействие с этим процессом осуществляется через TCP-порт. Во время запуска atop пытается соединиться с данным TCP-портом и периодически загружает через него статистику, не обеспечивая при этом должной проверки размера передаваемых данных. Метод атаки сводится к тому, что любой пользователь в системе может запустить на сетевом порту atopgpud свой обработчик, который выдаст данные заведомо большего размера, что приведёт к переполнению буфера в atop при попытке разбора статистики. Возможность создания рабочего эксплоита для выполнения кода пока не продемонстрирована. В новой версии atop по умолчанию отключён сбор статистики через TCP-порт и добавлена опция "-k" для активации поддержки atopgpud. Также внесены дополнительные проверки в код разбора статистики для предотвращения переполнений. ![]() В заключении можно отметить выпуск top-подобной утилиты htop 3.4.0, примечательной такими возможностями, как свободная вертикальная и горизонтальная прокрутка списка процессов, средства оценки эффективности работы SMP и использования каждого процессорного ядра, наличие древовидного режима просмотра, гибкие возможности по настройке интерфейса, поддержка фильтрации процессов и управления ими (завершение работы, настройка приоритета). Код проекта написан на языке Си и распространяется под лицензией GPLv2 В новой версии добавлено отслеживание активности GPU в Linux; улучшена работа на ARM-компьютерах Apple; решены проблемы со сборкой для DragonFlyBSD, Darwin, NetBSD, OpenBSD и Solaris; обеспечен учёт дисковой и сетевой активности в DragonFlyBSD; добавлена информация о потоках и состоянии процессов в macOS; расширена поддержка Unicode; переработан код для работы с датчиками температуры; повышена производительность кода для разбора статистики; добавлена поддержка скрытия данных о кэше и буферах. ![]()
| ||
Обсуждение (83 +25) |
Тип: Программы |
| ||
· | 30.03 | Выпуск утилиты GNU patch 2.8 (40 +20) |
Спустя семь лет с прошлого выпуска и двенадцать с половиной лет с момента публикации ветки 2.7 представлен релиз утилиты GNU patch 2.8. Утилита позволяет применить к файлам патчи, включающие списки изменений, созданные программой diff. Код написан на языке Си и распространяется под лицензией GPLv3+.
В новой версии:
| ||
Обсуждение (40 +20) |
Тип: Программы |
| ||
· | 29.03 | Представлен формат сжатия изображений Spectral JPEG XL (74 +34) |
Инженеры из компании Intel представили формат изображений Spectral JPEG XL, оптимизированный для эффективного сжатия изображений, охватывающих области спектра за границей диапазона видимого излучения. Предложенный формат предоставляет возможности, аналогичные спектральной редакции формата OpenEXR, но в отличие от последнего обеспечивает кодирование с потерями, что позволяет добиться сокращения размера файлов в 10-60 раз по сравнению со сжатием без потерь.
Спектральные изображения содержат не только информацию об интенсивности света в трех основных цветовых каналах (RGB), но охватывают часть ультрафиолетового и инфракрасного диапазонов. Подобные изображения используются в таких областях, как высококачественный рендеринг, анализ материалов и визуализация научных данных. Например, спектральные изображения могут использоваться для точного моделирования реальных оптических эффектов при рендеринге, для оценки того, как выглядит краска при различном освещении, и для идентификации материалов по их световым сигнатурам. Съёмка с захватом диапазонов вне видимого спектра даёт возможность более точно моделировать взаимодействие света с материалами, но приводит к значительному увеличению информации, хранимой для каждого пикселя.
Спектральные изображения могут включать десятки каналов, охватывающих различные диапазоны длин волн, и использовать для каждого канала 16- или 32-разрядные числа с плавающей запятой, что позволяет охватить более широкий диапазон значений яркости, чем на обычных фотографиях. Ценой подобной возможности становится существенное увеличение размера по сравнению с традиционными изображениями. В качестве примера упомянуто изображение с 81 дополнительным спектральным каналом, занимающее в формате OpenEXR 300 МБ. При помощи Spectral JPEG XL данное изображение удалось сжать до 3.9 МБ без потери спектральных характеристик.
![]() Для сокращения размера Spectral JPEG XL использует разделение данных о яркости и форме спектра, и применяет дискретное косинусное преобразование, позволяющее сохранить основные спектральные характеристики, но отбросить несущественные высокочастотные спектральные детали. Суть метода в преобразовании плавного изменения волновых характеристик в набор волновых коэффициентов (коэффициентов частоты), при совмещении воссоздающих исходную спектральную информацию. Более высокочастотные спектральные коэффициенты затем нормируются по отношению к общей яркости, что позволяет агрессивнее сжимать менее значимые данные. Идея в том, что с точки зрения восприятия наиболее важна средняя яркость и она сохраняется с наиболее высоким качеством, а коэффициенты высоких частот не столь важны и к ним применяется более высокий уровень сжатия и опционально более низкие разрешения. После этого информацию обрабатывает кодек, реализованный на базе существующего движка сжатия, разработанного для формата JPEG XL.
| ||
Обсуждение (74 +34) |
Тип: К сведению |
| ||
· | 29.03 | Изучение начинки sandbox-окружения, используемого в Google Gemini для запуска Python-кода (19 +13) |
Опубликованы результаты исследования защищённости изолированного окружения для выполнения Python-кода, применяемого компанией Google в чатботе Gemini. Чатбот Gemini предоставляет средства для генерации кода по описанию задачи и для языка Python позволяет сразу запустить созданный код, чтобы избавить разработчика от лишних действий при его проверке. Код запускается в изолированном окружении, которое отрезано от внешнего мира и допускает только исполнение интерпретатора Python. Для определения начинки sandbox-окружения исследователи добились запуска кода, использующего возможности Python-библиотеки os для перебора содержимого всех каталогов и построения карты файловой системы.
Особый интерес вызвал исполняемый файл /usr/bin/entry/entry_point, который занимал 579 МБ. Для извлечения данного файла исследователи создали скрипт, который последовательно небольшими порциями выводил на экран содержимое в формате Base64. На своей стороне они автоматизировали склейку данных отрывков при помощи инструментария Caido и получили копию файла на своей системе. Для анализа полученного исполняемого файла была применена утилита binwalk, предназначенная для извлечения файлов, встроенных в прошивки. Среди извлечённых данных оказался каталог google3, в котором, судя по названиям файлов, находился Python-код с различными компонентами для обеспечения работы сервиса, например, RPC для взаимодействия AI-модели Gemini с внешними сервисами Google, такими как YouTube, Google Flights и Google Maps. ![]() ![]() Изучение содержимого файлов показало, что это не конфиденциальный код и он был одобрен для публичного доступа службой безопасности Google. При этом дальнейший анализ дампа выявил наличие в нём proto-файлов (Protocol Buffer) со спецификациями внутренних структур данных, позволяющих понять тонкости обмена данными между различными сервисами Google. Польза от получения выявленных proto-файлов сомнительна, так как семь лет назад подобные proto-файлы уже были извлечены другими исследователями из Google App Engine.
| ||
Обсуждение (19 +13) |
Тип: Проблемы безопасности |
| ||
· | 29.03 | В пакетном менеджере Zypper реализована параллельная загрузка пакетов (71 +12) |
Разработчики дистрибутива openSUSE реализовали в пакетном менеджере Zypper возможность распараллеливания загрузки пакетов и метаданных. Дополнительно предложен новый бэкенд, более оптимально повторно использующий уже установленные соединения и повышающий эффективность обработки метаданных. При обновлении 250 пакетов суммарным размером 100 МБ время загрузки после включения нового бэкенда и параллельного режима сократилось с 68.7 секунд до 13.1 секунд, а при обновлении 407 пакетов размером 1 ГБ - с 281.1 cекунды до 119.6 секунд.
Распараллеливание доступно начиная с выпусков libzypp 17.36.4 и zypper 1.14.87, пока размещённых только в репозиториях Tumbleweed и Slowroll. По умолчанию упомянутые возможности пока отключены и преподносятся как экспериментальные. Для включения параллельной загрузки и нового бэкенда можно использовать переменные окружения "ZYPP_PCK_PRELOAD=1" и "ZYPP_CURL2=1", а настройка числа одновременных соединений регулируется при помощи параметра "download.max_concurrent_connections" в файле конфигурации zypp.conf.
| ||
Обсуждение (71 +12) |
Тип: К сведению |
| ||
Следующая страница (раньше) >> |
Закладки на сайте Проследить за страницей |
Created 1996-2025 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |