> В любом случае, исполняемый файл -- это не "типипичный бинарник",А какой же он?! Вся система ими забита. Достаточно типичные для того чтобы САБЖ а также 7z/xz и еще несколько даже сделали префильтры для улучшения их сжатия. И даже бывают выделенные "упаковщики исполняемых файлов" навроде UPX (этот с исходниками и жрет чертову кучу форматов).
> и исполняемый код -- не то, что сжимают.
Это не соответствует действительности, начиная с kernel/initrd допустим. А в мелких девайсах плотно сжатый squashfs вообще их все. Да и в обычной системе сжатие бинарей может ускорить загрузку системы. Если алгоритм распаковки быстрый (LZO, LZ4, ZSTD на медленных накопителях).
> Там есть, что сжать, тот же upx не на пустом месте родился.
А, то-есть вы еще и в курсе что так бывает но все равно признать неправоту не смогли?!
> Подобное сжатие работает только когда файл 1 и когда все данные в окне в него
> помещаются, а сжатие файлов по-отдельности куда менее эффективно.
Подобное сжатие позволяет запускать программу как если бы она сжата не была - небольшой депакер распаковывает прогу и делает вид что никакого сжатия (с точки зрения программы) не было.
> Поэтому, это задача для архиватора.
У solid сжатия есть опредеденные проблемы. Например с рандомным доступом к данным. А также с разрушением всего что за битым блоком. Это накладывает лимиты на его применение как в целях резервного копирования, так и рандомного доступа. Скажем zip можно грубо говоря "смонтировать" и юзать сжатые файлы как будто они не сжатые. Некоторые гамесы и проги примерно так и делают, правда иногда с кастомным форматом архива, но порой и zip бывает. А вот с сабжем этот номер уже не катит - в том числе и из-за solid сжатия. Это другой кейс.
> Обычные бинарные файлы это тоже сотни-тысячи мегабайт, в которых
> не найти достаточно повторений,
Кто вас уполномочил решать какие файлы обычные? Более того - это в любом случае лишь частный случай бинарных файлов. Для тех кто не понял еще раз: бинарные файлы могут быть как уже сжатые (с высокой энтропией), так и несжатые.
