Компания Meta* представила инструментарий для сжатия и распаковки данных OpenZL, по сравнению с форматами Zstd и XZ демонстрирующий более высокий уровень сжатия и скорость работы. OpenZL разработан для эффективного сжатия структурированных наборов данных, например, применяемых при машинном обучении, а также хранилищ, содержащих поля с различными повторяющимися типами информации. Код OpenZL написан на C/C++ и открыт под лицензией BSD...Подробнее: https://www.opennet.me/opennews/art.shtml?num=64019
Так все красочно и вкусно. А закладки с бэкдорами прилагаются?
конечно, именно поэтому код открыт, ага
то что код открыт, не означает, что в нем найдут закладку
То что в нем найдут закладку равна коэффициенту популярности языка программирования - Виликая Python лучше всех!
xz тоже был открыт, ага
Но Jia Tan в проектировании формата участия не принимал и изначально код не писал. Решил лишь подрихтовать сбочный скрипт.
И в чём он не прав?
сам посмотрим - https://github.com/facebook/openzl
xz тоже был открыт
как страшно жить то...
шарахайтесь теперь от любого кода
Не от любого, а от даров данайцев.
В xz закладку нашли за две тестовые версии, так что если там действительно что-то есть, то тоже быстро найдут
К сожалению, нашли случайно из-за CPU overload. Если б китайцы аккуратнее свой имплант написали, то далеко не факт, что обнаружили быстро.
Это "поляки" были ж, при чём тут китайцы?
Потому что васян с кор2дуба заметил как проц грузили типичные задачи с зксзед и обратился к профи из Майкрософт,который и выяснил в чем дело? Великий опенсурс!
То что закладка в xz лежала долгие годы - следствие лишь твоей личной лени и некомпетентности.
Да, прилагаются. Они там свой ЯП развели!
> Simple Data Description LanguageИнтересно, чем им Kaitai Struct не угодил. По описанию вроде почти одно и то же.
Там есть крайне фатальный недостаток – его писали не они!
Ага.
Они то могут в сериализацию.
А Kaitai Struct пока только серят.
Katai Struct до сих пор не умеет в (де)сериализацию. Фатальный недостаток.
ну вот, могли бы исправить :)
Могли.
Но это нужно идти к каким-то васянам, предлагать свои патчи, оформлять как тем хочется...
Или сделать свое, в котором ты сам себе хозяин.
да, не посмотрел, что у kaitai struct неудобная лицензия
Неудобная для проприерастов.
Я имел в виду только язык описания структур. А генератор могли бы свой уже писать, хоть с сериализацией, хоть без. Всяко проще чем с нуля изобретать.
Это абсолютно не важно. То что он не умеет (на самом деле умеет, просто рудиментарно, что характерно - для тупых случаев вроде того, что обрабатывает OpenZL - как раз умеет!) в сериализацию (а в десериализацию он как раз умеет) - это абсолютно иррелевантно, так как они не собирались использовать ни компилятор KS (который требует JVM!), ни производимые им артефакты (исходник на различных языках). На самом деле им KS не подошёл потому, что им был нужен язык не только для описания форматов, но и для описания своих пайплайнов. Я полагаю (git не проверял), что они сначала сделали язык для описания своих пайплайнов, а потом уже прикрутили туда описание форматов, как ещё одну голову у Горыныча, на тот же язык, и чтобы не городить 10 языков в одном приложении - туда же в тот же синтаксис засунули описание форматов. Грязно, но практично.
Т.е. её ещё и обучать надо? Перед упаковкой.
Файлы как набор структурированных данных жуёт или только жмёт один файл как хранилище?> команду "zli train"
Результат СЕЙЧАС насколько зависит от версии и от машины, на которой формируется профиль?
А чего не сравнили с непрерывном методом сжатия (solid archive) rar архивов? Он уже отлично сжимал повторяющиеся данные лет 25 назад.p.s. а лучше бы вообще уже выкупили rar у Рошала и сделали бы алгоритм открытым и бесплатным.
Кто за него готов хоть три копейки заплатить? И ещё заново вложиться в популяризацию. Просто чтобы ванаби виндузятник порадовался?
Вендузятникам и так хорошо, это убогие линуксоиды страдают из-за лицензий.
А может наоборот? Из открытого достояния приватизировать в частное владение.
Я бы запантетовал колесо, алфавит и т.д. А то ишь, пользуетесь бесплатно! А разработчики чем будут питаться? Им тоже надо на хлеб с маслом!!1!Нажо выдать ЖКХ право дарить людей! Не нравиться - прокладыватйте труб к своему дому сами! А платить по раздельному тарифу, в ванной - по аналогии с сотовыми оператороми, покупаете "пакет" литров.
Тех в провайдерам интернета надо выдать право банить людей за блокировку рекламы, торренты и подозрительую активность... А ещё лучше сделать реестр недобосовечных лиц.
Зачем покупать? Игорь Павлов смог с 7зип реализовать свой них синдром. Дерзайте и вы.
У него нет дедупликации по факту, только частичная. На и в целом zpaq поинтересней, он лучше комбинации lzss с ppmd. Lrzip, к примеру, действительно дедуплицирует, и легко может обойти и 7z, и, тем более, rar.
> А чего не сравнили с непрерывном методом сжатия (solid archive) rar архивов? Он уже отлично сжимал повторяющиеся данные лет 25 назад.Много кто отлично сжимает, мало кто умеет делать это БЫСТРО.
> p.s. а лучше бы вообще уже выкупили rar у Рошала и сделали бы алгоритм открытым и бесплатным.
Это вот сейчас к кому обращено было?
а чем вам tar+<что-то еще>, появившийся за 10 до rar, не угодил ?
Тут стоило бы сходу крыть аргументом что rar это просто мешанина файлов для юзерскихзадачь, а tar это слепок файловой системы с атрибутами, с симлинками даже вроде с дедупликацией, который в дальнейшем можно чем нибудь сжать, в том числе и rar-ом
А можно вспомнить, что tar — это рудимент времён ленточных накопителей.
Дедупликация в tar это сомнительной живости клон. Но вот гну тар действительно наверно единственный вариант, позволяющий сохранить все метаданные и атрибуты из реальных архиваторов. Потом просто натравливаешь lrzip.
Ну вообще-то да, если знать структуру данных можно пожать гораздо лучше чем общим алгоритмом.Например, взять 12-битные изображения. Там тупо верхних 4-бита каждый второй байт забит нулями. Из четырех байт тривиально получается три. Не говоря уже о разностном кодировании, потому что каждое последующее значение лежит довольно таки близко к предыдущему. Так вот - лет 10-15 назад редко какой архиватор умел пожимать такие файлы. Потом появился zstd, который с этим справляется лучше, но и он до ужатия до 75% от оригинала не дотягивает. Позже появился jxl (lossless jpeg)- он умел таки пожимать лучше чем до тривиальных 75%. Но данные к тому моменту и так уже лежали на zfs / zstd.
Топик как-раз движется в этом направлении - похоже ему будет достаточно сказать что файлы надо рассматривать как последовательность word (16-bit), и кодировать их разность.
Отлично. Ждём в BTRFS.
Не является универсальным, на уровне файлухи работать не будет. Не ждите.
Бинарник в разы больше, чем у zstd или 7-zip$ ls -l /usr/bin/zli
-rwxr-xr-x 1 root root 5494744 окт 9 18:20 /usr/bin/zli
$ zli --version
zstrong-cli version 0.1$ zli list-profiles
Available profiles:
-| csv = CSV. Pass optional non-comma separator with --profile-arg <char>.
-| le-i16 = Little-endian signed 16-bit data
-| le-i32 = Little-endian signed 32-bit data
-| le-i64 = Little-endian signed 64-bit data
-| le-u16 = Little-endian unsigned 16-bit data
-| le-u32 = Little-endian unsigned 32-bit data
-| le-u64 = Little-endian unsigned 64-bit data
-| parquet = Parquet in the canonical format (no compression, plain encoding)
-| pytorch = Pytorch model generated from torch.save(). Training is not supported.
-| sao = SAO format from the Silesia corpus
-| sddl = Data that can be parsed using the Simple Data Description Language. Pass a path to the data description file with --profile-arg.
-| serial = Serial data (aka raw bytes)
Ну так не zli ни list-profiles ни другие файлы, зачем ты это делаешь, вот они у тебя и не сжимаются
>Для описания сложных форматов со вложенными структурами и определения раскладки форматов данных в структурах может применяться язык SDDL (Simple Data Description Language).Могли бы не выпендриваться и Kaitai Struct взять, или DFDL.
До PNG никогда не доберётся - там стандарт раз в 20 лет выходит. Пока новый стандарт выйдет - PNG будет вытеснен уже.
Корпораст выдавил из себя софт с пермиссивной лицензией. И почему я не удивлён?
Сборочная система крайне уродская - для того, чтобы собрать колесо для Python, нужно отдельно запускать через `python3 -m build -nwx .`, а это пересоберёт всё заново, что, мягко говоря, небыстро. Можно при обычной сборке сказать собрать питоьний модуль ... но это будт не колесо, а для сборки колеса придётся тогда менять `pyproject.toml` вручную на `setup.py` и вручную же копировать питоний модуль в директорию, чтобы он вошёл в колесо.При этом содержимое автоматически-собранного колеса такое:
--
Path = dist/openzl-0.1.0-cp312-abi3-linux_x86_64.whl
Type = zip
Physical Size = 4643707Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------ ------------------------
2025-10-09 13:41:12 ..... 26516 6558 include/zdict.h
2025-10-09 14:01:28 ..... 181748 46086 include/zstd.h
2025-10-09 13:41:12 ..... 4278 1624 include/zstd_errors.h
2025-10-09 14:34:10 ..... 1053 514 lib/cmake/zstd/zstdConfig.cmake
2025-10-09 14:02:12 ..... 2762 887 lib/cmake/zstd/zstdConfigVersion.cmake
2025-10-09 14:34:12 ..... 1430 441 lib/cmake/zstd/zstdTargets-relwithdebinfo.cmake
2025-10-09 14:34:12 ..... 4633 1403 lib/cmake/zstd/zstdTargets.cmake
2025-10-09 14:35:38 ..... 3727650 2336425 lib/libzstd.a
2025-10-09 14:39:48 ..... 662360 273065 lib/libzstd.so
2025-10-09 14:39:48 ..... 662360 273065 lib/libzstd.so.1
2025-10-09 14:39:48 ..... 662360 273065 lib/libzstd.so.1.5.7
2025-10-09 14:34:10 ..... 476 312 lib/pkgconfig/libzstd.pc
2025-10-09 14:39:48 ..... 53 55 openzl/__init__.py
2025-10-09 14:39:44 ..... 6810 856 openzl/ext/graphs.pyi
2025-10-09 14:39:44 ..... 38213 2405 openzl/ext/nodes.pyi
2025-10-09 14:39:48 ..... 4385136 1421292 openzl/ext.abi3.so
2025-10-09 14:39:46 ..... 14158 2059 openzl/ext.pyi
2025-10-09 14:39:48 ..... 131 117 openzl-0.1.0.dist-info/METADATA
2025-10-09 14:39:48 ..... 124 117 openzl-0.1.0.dist-info/WHEEL
2025-10-09 14:39:48 ..... 1562 891 openzl-0.1.0.dist-info/RECORD
------------------- ----- ------------ ------------ ------------------------
2025-10-09 14:39:48 10383813 4641237 20 files
Заметьте директорию lib:1. её присутствие в колесе вообще некорректно
2. в CMake-файле написано, что с динамическими библиотеками питоний модуль вообще быть собран не может, а тут libzstd динамически прилинкована.
3. если они такие умные, что линкуют libzstd динамически, то могли бы её вообще не пересобирать, а использовать из системыК сожалению нельзя просто запаковать содержимое директории src в zip-архив, так как RECORD содержит хеши всех файлов, и отсутствие файлов, или несовпадение хеша, очен не понравится некоторым пакетам для управления пакетами питона (и нет, я не имею в виду pip, есть другие модули питона, они предназначены для использования как либы, в то время как pip это крайне не рекомендует и предлагает плодить процессы)
4. libzstd они таки линкуют статически. Вообще не понятно какого хрена она в колесе.
5. ломать не строить - из record-файла подчистить лишние файлы и пересобрать колесо 7zipом тривиально. Но почему я вообще должен это делать? Нормальные пакеты обычно делают так: у них есть pyproject.toml чтобы собрать через build, а если мы собираем через cmake, то cmake генерит свою sdist-директорию, где можно python3 -m build -nwx -- и соберётся колесо с уже предсобранной библиотекой.
>Our main theoretical contribution is the graph model of compression, defined formally in section 3. In summary, we define a compression graph as a computational graph [ 20] where the nodes are codecs and edges represent data generated as output of one codec and used as input for another.Могли бы и расширение для onnx сделать, а не NIH городить. libonnx - это только сериализация графа, небольшая либа, это вообще чисто protobuf.
Это как в том анекдоте. Сжимает хорошо и быстро, а разжимать мы пока не научилсь.
>On the other hand, html is structured but not repetitive and will therefore not benefit much from parsing.Звездёж. HTML избыточен, там эскейпинг, entities, отступы, встроенный base64, и вообще встроенные другие форматы. Если его просто токенизовать (даже без всякого BPE, просто по словарю известных тегов) и сериализовать результат в бинарный иерархический формат (то есть без дупликации открывающих и закрывающих тегов) - это уже выигрыш даст. Если же формато-специфичным образом обработать встроенные объекты, SVG и JavaScript - то выигрыш ещё больше будет. Я вообще ожидал от этой либы как раз эффективной компрессии HTMLя (потому что авторы бэкендов многих сайтов - больные yблюдки, не осилившие IEC 60027-2 и Systeme international).
какой еще встроенный base64? HTML это дистилированный XML1.1 без неймспейсов и прочего, но поскольку его парсят/обходят полноценной xml-библиотекой с поддержкой полного стандарта, то глупо было не добавить встраивание SVG.
Вот пример отсюда: https://openzl.org/api/c/graphs/sddl/#bitmap-imagesА вот результат компиляции ("компилятор" сериализует граф в CBOR, но я его десериализовал в JSON и почислил скриптом https://paste.debian.net/1400224/) этого графа: https://0x0.st/Kuyp.yddd/bmp.yddd
а никого не смущает пейсбук?git clone --depth 1 -b release https://github.com/facebook/openzl.git