#zstd — Public Fediverse posts

Use-As-Dictionary: как мы перестали отдавать один и тот же бандл по пять раз в день

У нас в среднем два релиза в день, бандл весит 7,76 МиБ после brotli, и половина клиентов качает его заново по несколько раз в сутки: хеш в имени файла поменялся - значит, кеш мимо. Compression Dictionary Transport (RFC 9842) позволяет объявить вчерашнюю сборку словарём для сегодняшней, и вместо 7,76 МиБ уезжает 15 КБ. Рассказываю, что из этого работает на практике при непрерывной поставке: почему дельты только к предыдущей сборке хватает лишь на 43% визитов, как считать окно словарей по своим логам, как отдавать дельты из nginx без reload на каждый релиз, и что ломается на откатах, канарейках и бампах зависимостей. Все цифры - с нашего портала, методика в конце.

https://habr.com/ru/articles/1070382/

#compression_dictionary_transport #RFC_9842 #brotli #zstd #nginx #дельтасжатие #непрерывная_поставка #оптимизация_загрузки

borg 2.0.0b23-pre benchmarks from some essential components of borg:

https://github.com/borgbackup/borg/discussions/10056

#borgbackup #blake3 #hashing #chunking #zstd #compression #algorithms #simd

We have proof automation now

https://www.imperialviolet.org/2026/07/26/zstd-lean.html

Comments: https://news.ycombinator.com/item?id=49062291

#HackerNews #automation #proof #technology #zstd #innovation #future

EVRTCK: тайловый дельта-кодек для удалённого рабочего стола — как мы убили H.264 для UI-контента

Я Артур Валиев, разработчик EVRT Когда мы форкнули RustDesk и начали строить EvertyDesk — корпоративный удалённый рабочий стол с поддержкой Hyper-V, Proxmox, VirtualBox и умным агентом — первое, во что упёрлись, было видео. H.264 — стандарт де-факто. TeamViewer, AnyDesk, Windows App — все используют H.264. Он работает. Но он lossy. И вот здесь начинается проблема, о которой в статьях про remote desktop обычно не говорят. Когда оператор смотрит на терминал с git diff или читает трейс в VSCode — один размытый пиксель в букве это уже другой символ. H.264 при любом разумном битрейте вносит артефакты в области с резким контрастом. Точно туда, где у нас весь текст. Это неприемлемо. H.264 в lossless режиме ( QP=0 , lossless profile) существует, но поддержка в декодерах — через пень-колоду, а для mostly-static контента предикторы рассчитанные под видео с движением дают нулевой выигрыш над тривиальным delta-кодером. Нам не нужен motion estimation. Нам нужно: вот предыдущий кадр, вот текущий, вот список изменившихся тайлов, сожми только их. Мы написали EVRTCK.

https://habr.com/ru/articles/1059238/

#rust #remote_desktop #кодек #lossless #rayon #zstd #delta_encoding #видеокодек #EvertyDesk #производительность

❯ time xz -T0 -9 -k a.sql

________________________________________________________
Executed in  364.44 secs    fish           external
   usr time   17.34 mins    1.80 millis   17.34 mins
   sys time    0.16 mins    1.61 millis    0.16 mins

❯ time zstd -T0 -19 -k a.sql
a.sql                : 13.74%   (  2.69 GiB =>    378 MiB, a.sql.zst)

________________________________________________________
Executed in  186.74 secs    fish           external
   usr time   27.11 mins    1.79 millis   27.11 mins
   sys time    0.11 mins    1.94 millis    0.11 mins

❯ time lbzip2 -9 -k a.sql

________________________________________________________
Executed in   12.37 secs    fish           external
   usr time  115.07 secs    0.27 millis  115.07 secs
   sys time    0.94 secs    1.47 millis    0.94 secs

❯ time zip -9 a.sql.zip a.sql
  adding: a.sql (deflated 78%)

________________________________________________________
Executed in  120.95 secs    fish           external
   usr time  120.01 secs    1.75 millis  120.01 secs
   sys time    0.77 secs    2.49 millis    0.77 secs

❯ ls -lhS a.sql*
-rw-r--r--@ 1 rainer  wheel   2,7G  1 Juli 01:05 a.sql
-rw-r--r--@ 1 rainer  wheel   596M  1 Juli 12:08 a.sql.zip
-rw-r--r--@ 1 rainer  wheel   515M  1 Juli 01:05 a.sql.bz2
-rw-r--r--@ 1 rainer  wheel   378M  1 Juli 01:05 a.sql.zst
-rw-r--r--@ 1 rainer  wheel   358M  1 Juli 01:05 a.sql.xz

Did you notice? With the new queue-runner we are compressing all nars with zstd 19.

If all goes well, we'll start publishing `nixexprs.tar.zst` tarballs soon and announce the discontinuation of the `nixexprs.tar.xz` tarball in one year.

https://github.com/NixOS/nixpkgs/pull/535272

#nixos #zstd

Native #zstd compression support in #asciinema CLI landed in `develop` branch!

All commands (rec, play, convert, cat, upload) support it.

Average `.cast.zst` file for a typical session takes about 8% of the uncompressed (plain `.cast` file) version 🎉

Note: The server doesn't support zstd compressed uploads yet, but will soon!

Тест современных компрессоров для HTTP

Сжатие текста уже давно стало стандартом в мире веб‑приложений. Сокращение объёма данных даёт сокращение времени передачи и снижение нагрузки на сетевой канал. Однако, часто настройка компрессии сводится к динамическому сжатию gzip и настройкам по умолчанию. В этой статье разберём вопрос сжатия более глубоко. Для начала вспомним основные технологии сжатия, доступные в вебе.

https://habr.com/ru/articles/1040692/

#angie #gzip #brotli #zstd #zstandard

Creating .tar.zst archives on Windows doesn’t require extra software. The native tar command already supports Zstandard (zstd). Simply add the context menu option to get started: https://github.com/SamiLehtinen/CompressTarZstd #Windows #Zstandard #Zstd #compression

Software developer Steven Geisel highlights one of the new features of up and coming .NET 11, which is a ready-to-use implementation of the Zstd compression algorithm (https://github.com/facebook/Zstd).

Published by Facebook in 2018 as RFC 8478, Zstd is a high performance, lossless compression algorithm that can produce close to instant results under certain configurations.

"Zstandard compression in .NET 11"

https://steven-giesel.com/blogPost/6066abb6-640a-4225-ac33-3f4d5a1a1d16

#dotnet #csharp #zstd #programming #algorithms #compression

#WinRAR 7.22 has been released (#RAR / #ZIP / #ZIPX / #7Zip / #7z / #GZip / #zstd / #Zstandard / #FileArchiver / #DataCompression / #DarkMode) https://rarlab.com/

maxpack: межфайловая дедупликация на версионных данных

Разбор межфайловой дедупликации на версионных данных: почему обычная упаковка упирается в потолок и что меняется на CPython, Go и Node.js.

https://habr.com/ru/articles/1019718/

#сжатие_данных #дедупликация #архивация #versioned_data #tar #zstd #7z #snapshots

Oh, my #ccache is filling up:

Cache size (GiB): 40.3 / 100.0 (40.25%)

Note that this is #zstd compressed.

#dev

@davidculley so what? Actually, many contributions from #meta #facebook to #opensource world including #MySQL. #RocksDB born there. And don't forget #zstd.

My new daily backup script, pg_dump with zstd compression level 19.

docker exec \
   ak-postgres-1 \
   pg_dump -U umeyashiki umeyashiki_akkoma | \
   nice -n 19 \
   ionice -c 3 \
   chrt --idle 0 \
   zstd -T0 -19 --rsyncable -q > "$BACKUP_DIR/db_latest.sql.zst";

Today I learned something new about the scheduling priority. Since zstd compression is very CPU-intensive, set it to low priority so it doesn’t slow the entire system down during compression.

Commands that precede zstd here are:

• nice -n 19 [cmd]
• ionice -c 3 [cmd]
• chrt --idle 0 [cmd]

By chaining nice, ionice, and chrt together before the zstd command, the script forces the compression process to run with the absolute lowest possible priority for both the CPU and the disk.

• nice 19 is the lowest priority CPU priority.
• ionice with class 3 means idle. A program running with idle I/O priority will only get disk time when no other program has asked for disk I/O for a defined grace period.
• chrt --idle 0: Set scheduling policy to SCHED_IDLE (scheduling very low priority jobs).

References:

• man 1 chrt
• man 1 nice
• man 1 ionice

#linux #docker #zstd #postgresql #sched

Interesting blog post about text classification using compression, specifically the new "compression.zstd" module contributed by @emmatyping

https://maxhalford.github.io/blog/text-classification-zstd/

#compression #zstd #zstandard #classification

[Перевод] Пишем свой git: минимальная реализация на Rust

Контроль версий долгое время был для меня «чёрным ящиком»: я не понимал, как именно хранятся файлы, как формируются diff’ы и из чего состоят коммиты. А поскольку я люблю изобретать велосипеды, почему бы не попробовать реализовать git самому?

https://habr.com/ru/companies/cloud4y/articles/990052/

#git #rust #контроль_версий #sha256 #zstd #хеширование #petproject #системы_контроля_версий #объекты_git #commit

If you use #btrfs on kernels ranging from 6.12 to 6.19 and get the error:

VFS: Unable to mount root fs on unknown_block(0,0)

Add the 'btrfs' and 'microcode' hooks to /etc/mkinitcpio.conf via chroot and rerun initramfs generation.

If that doesn't help install `intel-ucode.img` and add it to your grub boot parameters in the initrd list.

If that still doesn't help (happens on Intel 3770k and older) disable #zstd initramfs compression, use gzip instead.

You are welcome

#initramfs #microcode

ZSTD with level MEDIUM gives you the same runtime as the traditional MS_XPRESS algorithm, but the backup is around 14 GB smaller. The level LOW is really fast (203 sec. vs. 305 sec., and the backups are still smaller (58 GB vs. 50 GB). #sqlserver #zstd #compression #performance

@asgrim I've just checked back and this now works, any idea what could have been the problem here? #php #pie #zstd

Issues with PHP PIE this morning building a Docker image. Seems to be failing to auth against Github on one of the installs here "Could not authenticate against github.com”. Other extensions seem ok though 🤔

#php #pie #zstd

Введение в zram и сжатие памяти

zram — это механизм ядра Linux, создающий сжатый блок памяти в RAM, используемый как пространство подкачки (swap). Это позволяет эффективнее использовать оперативную память, особенно на системах с ограниченным объемом ОЗУ. Вместо записи данных на медленный диск, zram сжимает их и хранит в RAM, обеспечивая значительно более высокую скорость доступа.

Выбор алгоритма сжатия — ключевой момент при настройке zram. Наиболее популярные варианты — LZ4, Zstd и LZO. Каждый из них предлагает разный баланс между скоростью сжатия/распаковки и степенью сжатия.

Сравнение LZ4 и Zstd

Хотя ваш вопрос предполагает, что LZ4 предпочтительнее Zstd, на практике это не всегда так. Предпочтение зависит от конкретных целей:

LZ4 оптимизирован для максимальной скорости. Он обеспечивает очень быстрое сжатие и распаковку, что критично при высокой нагрузке на систему.

Zstd (Zstandard), разработанный Facebook, предлагает лучшее сжатие при сохранении высокой скорости. Он может достигать степени сжатия, близкой к gzip, но со скоростью, сравнимой с LZ4.

Таким образом, Zstd часто считается более сбалансированным выбором, а не менее предпочтительным.

Производительность: скорость vs степень сжатия

По скорости: LZ4 быстрее Zstd. В сценариях, где CPU является узким местом, или при очень высокой частоте обращений к swap, LZ4 может предотвратить лаги и задержки. Один из пользователей на Reddit отметил, что при тяжелых нагрузках (например, эмуляция игр) Zstd вызывал заметные лаги, которых не было с LZ4 при стандартных настройках.

По степени сжатия: Zstd превосходит LZ4. Это означает, что с Zstd можно сэкономить больше RAM, что особенно важно на системах с малым объемом памяти (например, 4–8 ГБ).

Сценарии использования и рекомендации

Используйте LZ4, если:

1. У вас ограниченная мощность CPU.

2. Вы хотите минимизировать задержки при активной подкачке.

3. Система работает в реальном времени или чувствительна к лагам (например, игры, аудио-обработка).

Используйте Zstd, если:

1. У вас мало RAM, и вы хотите максимально эффективно её использовать.

2. Процессор достаточно мощный (современные CPU хорошо справляются с Zstd).

3. Вы готовы настроить систему (например, использовать оптимизированные параметры ядра).

Как отмечается в одном из обсуждений, Zstd — это "золотая середина" между скоростью и сжатием, что делает его предпочтительным по умолчанию для многих пользователей.

Заключение

Неверно утверждать, что LZ4 предпочтительнее Zstd в zram. Наоборот, Zstd часто рекомендуется как более сбалансированный и современный алгоритм. Хотя LZ4 быстрее, Zstd обеспечивает значительно лучшее сжатие при сохранении высокой скорости. При правильной настройке системы (например, с ядром 6.7+ и оптимизированными параметрами) Zstd может превзойти LZ4 по общей производительности.

Вывод: Zstd — отличный выбор для большинства пользователей, особенно на системах с малым объемом RAM. Однако LZ4 остаётся предпочтительным при высокой нагрузке и слабом CPU.

#zram #zramen #Linux #LZ4 #zstd

https://blog.gslin.org/archives/2025/09/17/12630/zstd-%e7%9a%84-long-%e7%9a%84%e6%95%88%e6%9e%9c/

zstd 的 --long 的效果

#compression #long #ratio #size #time #zstandard #zstd