Незамеченным остался факт того, что разработка консольной версии архиватора p7zip (http://p7zip.sourceforge.net/) (порт 7z.exe для Unix-систем) возобновилась с начала с марта этого года, а на этой неделе проект был синхронизирован с новейшей кодовой базой 7z (http://www.7-zip.org/).
Основные новшества (http://sourceforge.net/projects/p7zip/files/p7zip/15.09/):- Добавлена поддержка распаковки образов в формате ext2, ext3, ext4 и многотомных VMDK;
- Добавлена поддержка 64-битной платформы cygwin, включая ассемблерное ускорение;
- Стала поддерживаться компиляция для aarch64, arm, PPC, PPC64, PPC64LE и S390x;
- Добавлена поддержка распаковки образов QCOW2, VMDK, VDI, а также GPT партиций, содержащихся внутри;
- Стали поддерживаться образы WIM (Windows Imaging Format) с форматом сжатия LZMS;
- Добавлена поддержка распаковки архивов RAR5;
- 7-Zip больше не сортирует файлы по расширению при добавлении в архив (что субъективно ухудшает степень архивации). Для возвращения старого поведения следует использовать флаг "-mqs";
- Максимальный размер словаря для 7z и xz архивов увеличен до 1,5GB;
- Добавлена поддержка распаковки архивов zipx с сжатием XZ.
URL: http://sourceforge.net/projects/p7zip/files/p7zip/15.09/
Новость: http://www.opennet.ru/opennews/art.shtml?num=43586
Хм, не знаю, как оно раньше было, но судя по списку изменений - это не архиватор, которым я его всегда считал, а уродский комбайн
Впрочем, как и винрар с винзипом.
Так он всегда и был открытым аналогом winrar.
Если нужен архиватор, используй xz
Это компрессор. Tar- архиватор
Как раз xz не архиватор, а компрессор. А архиватор - это tar.
> Как раз xz не архиватор, а компрессор. А архиватор - это tar.Молодец, всё правильно пишешь, сожми компрессором этот tar да отправь по почте.
И выпей чаю )))
хахаха :)
> сожми компрессором этот tar да отправь по почте.И что будет?
к тебе приедет Тим
Чем уродский, сэр?Может быть там уродский код? Или что-то ещё? Что плохого в поддержке распаковки тучи всего? Это удобно очень многим людям.
// b.
> Или что-то ещё?Нет штатной возможности выкинуть ненужные алгоритмы. В итоге бинарник + библиотека в десять раз больше busybox.
ffmpeg или curl тоже вполне себе комбайны, но с возможностью выкинуть все не нужное и получить практически идеальный инструмент.
Не юникс-вей, когда есть стремление - одна функция=одна программа.
7z всегда был комбайном, то что он мог делать самораспаковывающиеся (SFX) архивы вас не смущало? :-) Чистый архиватор это lzma/xz утилиты, основанные на том же SDK от автора 7z.
Не смущало - это был/есть его вполне уникальный функционал, как возможнсть комбинаци архивации и сжатия - её не получить комбинированием набора утилит.А вот распаковка ext3 и возня с GPT - смущает, потому что для этого есть совершенно штатные средства в системе.
> А вот распаковка ext3 и возня с GPT - смущает, потому что
> для этого есть совершенно штатные средства в системе.А заход в iso из Total/Double Commander-a не смущает? Это же типа файловый менеджер. Может и фтп выпилить из него, а ходить специальной утилитой. Ну бред же.
В Total - не смущает, это винда, там с переиспользованием всё плохо. Double Commander не видел. А вот в mc - смущает, в идеале это должна быть морда для чего-то - либо шареной либы, либо внешнего приложения. Но бог с ним, с mc - у него архитектура исторически сложившаяся и крайне убогая, особенно в области VFS.А в целом - всё это совершенно очевидные задачи для FUSE, а никак не p7zip.
> А вот в mc - смущает, в идеале это должна быть морда для чего-то - либо шареной
> либы, либо внешнего приложения.Так и есть, см. /usr/lib/mc/extfs.d/iso9660 (используется isoinfo, там только лет десять тому пришлось поправить под съехавший формат вывода).
Ясно, буду знать.
А я заморачивался в студенчестве с этим вопросом
- делал монтирование во временную папку и переход в нее по нажатию исошника, да надо потом отмонтировать руками, зато можно использовать грепы и прочее - это не не удобно, просто по другому, но смонтировать архив не получится.
- Была идея и даже реализация fuse-демона, который работал также как vfs от mc, сливал списки - строил дерево, довольно долго пользовался этой штукой для обмена файлами со своей нокией через синезуб, были там всякие извращения с rpm и ftp. Но уперлось в невозможность реализации всех идей без создания дикотормозного комбайна.А вот сегментирование выводило все на новый уровень, где нужен был резидентный процесс в памяти, который должен был контролировать кэш и процессы-исполнители бэкграундных-задач, короче нереальный батхерд для студентика, чья специальность к компутерам вообще отношения не имеет. Хоть с тех пор лет десять и прошло, но особо ничего не поменялось.
> - делал монтирование во временную папку и переход в нее по
> нажатию исошника, да надо потом отмонтировать рукамиНа эту тему были supermount/subfs, да все померли; на тему архивов был такой avfs, но у меня не прижился (не помню уж, почему).
>> - делал монтирование во временную папку и переход в нее по
>> нажатию исошника, да надо потом отмонтировать руками
> На эту тему были supermount/subfs, да все померли; на тему архивов был
> такой avfs, но у меня не прижился (не помню уж, почему).Да вариантов хватало,но все уперались в муторное межпроцессорное взаимодействие, с тех пор появились, и системд, и dbus, но задачи не решили, то есть как было так и осталось муторно.
7-zip - изначально для винды делали. это потом его портанули в виде p7zip. так что вот эти фичи - изначально для винды.
>А вот распаковка ext3 и возня с GPT - смущает, потому что для этого есть совершенно штатные средства в системе.А есть ли другая программа, поддерживающая ext3 и GPT, не используя драйверов ядра?
Зачем, если они уже и так есть? Для альтернативных ОС был проект ядро как библиотека.
> Зачем, если они уже и так есть?Вдруг у меня нет прав монтировать диски, или ядро собрано без поддержки ext3 (админ свято верит в btrfs) или GPT, или у меня какая-нибудь другая POSIX-система? Зачем выкидывать функции, если под виндой они совершенно точно нужны, а под другими ОС могут быть нужны в некоторых случаях?
> Вдруг у меня нет прав монтировать диски, или ядро собрано без поддержки
> ext3 (админ свято верит в btrfs) или GPT,Так может нужно получить права/добавить ext3/gpt если в круг ваших задач входит работа сними, а не искать обходные пути? Ведь может понадобится и запись на ext3.
> или у меня
> какая-нибудь другая POSIX-система?Нужно смотреть что за система, какая задача и какие есть варианты ее решения.
> Зачем выкидывать функции, если под виндой они совершенно
> точно нужны, а под другими ОС могут быть нужны в некоторых
> случаях?Подобный функционал (дублирующий уже имеющийся в системе) должен быть опцией.
вот проект на базе ядра (да, в виде библиотеки), умеющий в пространстве пользователя работать со всеми FS, что умеет ядро, и предоставляющий их через FUSE - был бы крут, кстати.
User mode linux? Не знаю только насколько он поддерживается сейчас.
> А есть ли другая программа, поддерживающая ext3debugfs из e2fsprogs
Нет ничего плохого в прикладных программах-комбайнах, ибо они очень удобны для пользователя. Другое дело - ядра операционных систем и мутные системные менеджеры.
Если в твоей ос нет поддержки ext3?
> Если в твоей ос нет поддержки ext3?Это что ж за "ос" такая?
Эверест-манифест!
xml, jar?
exe :D
Октоберфест?
не нравится - покупайте рар, перепаковывайте 7zip под себя без функций, но не надо тут писать про излишний функционал. Он очень часто реально выручает. Быстро и четко.
Зачем тебе и рот и уши и даже руки одновременно? Исправь себя!
Как вы вообще с таким настроем живёте? Если у вас программа такие чувства вызывает.
Tar и gzip это замечательный юникс-вей. Из за юниксвея чтобы получить список файлов или извлечь один маленький файл нужно делать декомпрессию всего огромного архива.
Что касается комбайна, то очень удобно получив непонятный контейнер открыть его "уродским комбайном" и достать все что тебе нужно или хотя бы понять что-то такое и что там внутри.
> Tar и gzip это замечательный юникс-вей. Из за юниксвея чтобы получить список
> файлов или извлечь один маленький файл нужно делать декомпрессию всего огромного
> архива.Нет.
Почитайте наконец про то, как tar.gz (сперва архивируем, затем жмём) называется в терминах того же RAR ("solid archive") и посмотрите, какие действия выполняются при вынимании из такого "одного маленького файла".
У rar это опция. А что может предложить unix way для оперативного доступа к отдельным файлам в архиве?
> У rar это опция. А что может предложить unix way для оперативного
> доступа к отдельным файлам в архиве?Точно так же -- сперва жать, затем архивировать.
ИМХО подобное решение будет проигрывать обычному rar/7z как по удобству так и по эффективности сжатия.Нужен контейнер (архив) содержащий индекс с исходными (до сжатия) именами файлов, их размерами и прочими атрибутами. Да и сам индекс должен сжиматься. Тогда бы мы получили действительно интересный симбиоз в лучших традициях unix way использующий многопоточную упаковку/распаковку (в духе make -jN).
> У rar это опция. А что может предложить unix way для оперативного
> доступа к отдельным файлам в архиве?dar
dar не следует концепции unix way: он является и архиватором и компрессором.
> dar не следует концепции unix way: он является и архиватором и компрессором.tar тоже, как ни странно, позволяет создавать и распаковывать gzip,
bzip и прочее. Равно как и работать без компрессии. Чем не комбайн?Был вопрос про сжатие индивидуальных файлов? Был. Дар подходит? Подходит.
Строго говоря, в процессе дискуссии вы, задав вопрос, уже почти на
него ответили. Нужен доступ к индивидуальным файлам без декомпрессии
всего архива — делайте архивацию после сжатия. Любой образ файловой
системы со сжатием вам в этом подойдёт. Очень даже юниксвейно.
>> dar не следует концепции unix way: он является и архиватором и компрессором.
> tar тоже, как ни странно, позволяет создавать и распаковывать gzip,
> bzip и прочее. Равно как и работать без компрессии. Чем не комбайн?Комбайн. Нет у unix way архиватора - тему можно закрывать ;)
> Был вопрос про сжатие индивидуальных файлов? Был. Дар подходит? Подходит.
Но чем он в таком случае отличается от 7z или rar?
> Строго говоря, в процессе дискуссии вы, задав вопрос, уже почти на
> него ответили. Нужен доступ к индивидуальным файлам без декомпрессии
> всего архива — делайте архивацию после сжатия.Это не удобно - изменяется имя и размер файла.
> Любой образ файловой
> системы со сжатием вам в этом подойдёт. Очень даже юниксвейно.Это интересный вариант. Но эта будет специфическая фс с плохой переносимостью между системами. Да и не понятно, чем это будет лучше 7z/rar/dar?
>> Был вопрос про сжатие индивидуальных файлов? Был. Дар подходит? Подходит.
> Но чем он в таком случае отличается от 7z или rar?Ну-у-у здрасьте. Я не буду долго рассказывать, вы лучше сходите на сайт к создателю и прочитайте. Это как раз где-то замена или, можно так фигурально выразиться, весьма улучшенная версия tar.
>> Строго говоря, в процессе дискуссии вы, задав вопрос, уже почти на
>> него ответили. Нужен доступ к индивидуальным файлам без декомпрессии
>> всего архива — делайте архивацию после сжатия.
> Это не удобно - изменяется имя и размер файла.Эмм. Вот тут не понял, честно говоря.
>> Любой образ файловой
>> системы со сжатием вам в этом подойдёт. Очень даже юниксвейно.
> Это интересный вариант. Но эта будет специфическая фс с плохой переносимостью между
> системами. Да и не понятно, чем это будет лучше 7z/rar/dar?Я же говорю «например». С постановки проблемы и цены решения вопроса, собственно, и начинается инженерная работа.
>>> Был вопрос про сжатие индивидуальных файлов? Был. Дар подходит? Подходит.
>> Но чем он в таком случае отличается от 7z или rar?
> Ну-у-у здрасьте. Я не буду долго рассказывать, вы лучше сходите на сайтЯ не о технических возможностях, а о принадлежности/соответствии unix way.
>>> Строго говоря, в процессе дискуссии вы, задав вопрос, уже почти на
>>> него ответили. Нужен доступ к индивидуальным файлам без декомпрессии
>>> всего архива — делайте архивацию после сжатия.
>> Это не удобно - изменяется имя и размер файла.
> Эмм. Вот тут не понял, честно говоря.Если я сперва сожму файл, то его исходное имя (test.cpp) изменится (test.cpp.gz), размер тоже. При листинге архива я естественно хочу видеть исходное имя (test.cpp) и его размер.
> Я не о технических возможностях, а о принадлежности/соответствии unix way.Ну тогда нет ничего юниксвейного в этом мире. Прекращайте уже быть таким пуристом, честное слово же...
> Если я сперва сожму файл, то его исходное имя (test.cpp) изменится (test.cpp.gz),
> размер тоже. При листинге архива я естественно хочу видеть исходное имя
> (test.cpp) и его размер.А, вы всё так же про тар. Я же говорю о подходе к созданию архиваторов вообще.
> Ну тогда нет ничего юниксвейного в этом мире.Не, это только с архиваторами все плохо ;) С остальными утилитами типа ls,cat,grep все нормально.
> Прекращайте уже быть таким
> пуристом, честное слово же...В этом плане я совсем не пурист и считаю, что архиватор должен сам уметь сжимать. Более того - у меня в системе комбайн 7z заменил другие архиваторы/компрессоры (gzip/xz/rar/zip).
Я считаю, что на unix way нужно смотреть шире - если программа/библиотека охватывает конкретную задачу (область применения) и не лезет в другие - то это вполне адекватный подход. Мне нравится busybox, ffmpeg, curl, kernel. Вот qt, systemd - наоборот, стараются охватить как можно больший круг задач и включают в себе все подряд, что ИМХО плохо.
В rar не нужно все распаковывать чтобы получить список файлов, а в tar.gz нужно.Открываю архив в графической программе. Должно жду, получаю список файлов. Это ваш юникс-вэй.
> Должно жду,
> Это ваш юникс-вэй.Нет _Ваш_. Мы ж Вас не заставляли жать файлы не подходящим по Вашему же мнению инструментом?
Назло маме, уши -- аргумент? Нет, спасибо.
Наш ю-вей как-то -- инструмент под задачу.
Ваши проблемы с Вашими ушами и архмвами не проблемы Великого и Могучего.
> Добавлена поддержка распаковки образов в формате ext2, ext3, ext4 и многотомных VMDKоу оу полегче!
В original release notes сказано, что словарь 1,5GB можно использовать и для архивов в zip - увы, это полный бред.У zip максимальный словарь - 64KB.
// b.
Линуксовые права на папки/файлы все еще не сохраняет, если в 7z?
Нет смысла грейдится.
> http://sourceforge.net/p/p7zip/discussion/383043/thread/f85a...Еще и фичи вырезают/ломают...
И не научится. В man по этому поводу отдельный пункт, как комбинировать с tar.
Спасибо я знаю как это работает. Но потом, если что на винде такой архив открывается 3 раза через этот же 7-zip.
Ты думаешь, тут кого-то волнует боль, рождённая виндой?
> Линуксовые права на папки/файлы все еще не сохраняетНет, только на мамки.
А почему вендузятника это так интересует?
> Нет, только на мамки.
> А почему вендузятника это так интересует?Потому что работа происходит не в чисто линуксовой среде, ваш Кэп.
>> Нет, только на мамки.
>> А почему вендузятника это так интересует?
> Потому что работа происходит не в чисто линуксовой среде, ваш Кэп.Вендузятник должен страдать.
оно уже научилось не корёжить кодировки зипов, прилезая в зависимостях какой-то десктопной херни в убунте?
Э... вы про что?
Лично я использую 7z для распаковки зипов с русскими буквами в именах файлов и каталогов. И это потому, что по стандарту, pkzip был сделан с актуальными на тот момент времени ограничениями.
Это проблемы твоей убунты, что она его в зависимости тащит
это проблема 7зипа, которым графические морды для архиватором начинают распаковыватб всё подряд, а не только 7z. мне с консолью пофиг, а пользователи стпадают. Кстати, в вантузной версии 7зипа та же фигня.
> оно уже научилось не корёжить кодировки зиповПатчить надо unzip.
Это проблема zip.
> Это проблема zip.запрещаю исполнять или удаляю бинари 7зипа - обычные зипы начинают нормально распаковываться
Многопоточную декомпрессию добавили хотя бы для bzip2?
https://www.mediawiki.org/wiki/Dbzip2
> https://www.mediawiki.org/wiki/Dbzip2Parallel decompression: no
Я скинул сравнения всех, Ваш КЭП.
> Многопоточную декомпрессию добавили хотя бы для bzip2?Кто-то ещё пользуется bzip2? Им ничто уже не поможет, даже такие примочки.
Многие до сих пор выкладывают исходники в tar.bz2, в том числе и сам p7zip.
> Многие до сих пор выкладывают исходники в tar.bz2Это ж не повод брать именно в .bz2, если рядом есть .gz/.xz :)
.gz больше по размеру, а те, кто выкладывает .bz2 обычно не выкладывают .xz и наоборот. А упомянутый p7zip вообще только в bz2.
>> Многие до сих пор выкладывают исходники в tar.bz2
> Это ж не повод брать именно в .bz2, если рядом есть .gz/.xz
> :)У gz файл больше, а xz существенно медленнее, bz2 золотая середина :-)
> У gz файл больше, а xz существенно медленнее, bz2 золотая середина :-)У bz2 размер файла больше чем у xz. По скорости декомпрессии xz в разы быстрее bz2.
> а xz существенно медленнее, bz2 золотая середина :-)Нет.
>> а xz существенно медленнее, bz2 золотая середина :-)
> Нет.Да.
Нет. Игрался ключиками у xz, достигал размера архива как у бзипа2, но время упаковки было меньше. Про дико асимметричную распаковку lzmaтых даже не вспоминаю.
> Игрался ключиками у xz, достигал размера архива как у бзипа2, но время упаковки было меньшеНикогда не видел время меньше, сколько ни сравнивал - у xz время всегда больше, распаковка быстрее, да.
> У gz файл больше, а xz существенно медленнее, bz2 золотая серединаНе звезди: на декомпрессии xz в 4-5 раз быстрее bzip2.
>> У gz файл больше, а xz существенно медленнее, bz2 золотая середина
> Не звезди: на декомпрессии xz в 4-5 раз быстрее bzip2.На сжатии больше потеряешь чем выиграешь на распаковке.
Смотря что чаще.
.bz2 был стандартом во FreeBSD. Теперь (с 10-ки) там .xz Собственно всё :)
>> Многопоточную декомпрессию добавили хотя бы для bzip2?
> Кто-то ещё пользуется bzip2? Им ничто уже не поможет, даже такие
> примочки.Комплект Debian GNU/Linux 7.9, 8 "source" DVD + 10 "i386" DVD:
$ xzegrep -o <indeX.xz '\.[^.]+\.tar\.[^|]+' |awk '{sub("^\\.orig-[^.]+",".orig")}!/^\.debian/{sub("^\\.[^.]+","")}{print}'|sort |uniq -c |less
177 .debian.tar.bz2
11108 .debian.tar.gz
207 .debian.tar.xz
1795 .tar.bz2
15452 .tar.gz
724 .tar.xzКто-то пользуеься, да. ...о лечении [покойника] припарками, не уверен, что это хоть как-то связано в [форматом] bzip2.
> Кто-то пользуеься, да.Здесь как раз хорошо видна пропорция, причём ещё неплохая.
> Многопоточную декомпрессию добавили хотя бы для bzip2?давно уже - pbzip, только на декомпрессии выигрыш не очень, а вот на компрессии очень даже заметно
> Кто-то ещё пользуется bzip2? Им ничто уже не поможет, даже такие примочки.а что не так с bzip2?
>> Кто-то ещё пользуется bzip2?
> а что не так с bzip2?Жуткое соотношение производительности к степени сжатия по отношению к xz.
>>> Кто-то ещё пользуется bzip2?
>> а что не так с bzip2?
> Жуткое соотношение производительности к степени сжатия по отношению к xz.Что-то я не понимаю о чём вы:
$ time bzip2 -9k /var/tmp/linux-3.10.17.tarreal 0m46.186s
user 0m46.006s
sys 0m0.161s$ time xz -9k /var/tmp/linux-3.10.17.tar
real 5m6.156s
user 5m5.291s
sys 0m0.735s-rw-r--r-- 1 users users 86M дек 25 18:14 /var/tmp/linux-3.10.17.tar.bz2
-rw-r--r-- 1 users users 71M дек 25 18:14 /var/tmp/linux-3.10.17.tar.xz17% экономии за 6x рост времени сжатия? Зачем это нужно?
> 17% экономии за 6x рост времени сжатия? Зачем это нужно?Зачем нужен h264/h265/etc?
Упаковывается один раз - распаковывается может миллион раз. Посчитайте сколько экономит kernel.org трафика, а пользователи на времени распаковки.
>>>> Кто-то ещё пользуется bzip2?
>>> а что не так с bzip2?
>> Жуткое соотношение производительности к степени сжатия по отношению к xz.
> Что-то я не понимаю о чём вы:А теперь bzcat/xzcat. :)
PS: и да, -9 тоже не запрашивал.
>>>>> Кто-то ещё пользуется bzip2?
>>>> а что не так с bzip2?
>>> Жуткое соотношение производительности к степени сжатия по отношению к xz.
>> Что-то я не понимаю о чём вы:
> А теперь bzcat/xzcat. :)
> PS: и да, -9 тоже не запрашивал.При распаковке xz в два раза быстрее, 5s vs 12s, понятно. Для домашнего использования мне это не нужно, мне надо один раз сжать и один раз распаковать и ждать 5 минут вместо 40 секунд я не буду :-) bzip2 тут явно лучше.
Для домашнего использования можно ставить степень сжатия меньше.
> Для домашнего использования можно ставить степень сжатия меньше.Вот с xz -2:
real 0m40.062s-rw-r--r-- 1 sergey users 86M дек 25 18:14 /var/tmp/linux-3.10.17.tar.bz2
-rw-r--r-- 1 sergey users 88M дек 25 18:14 /var/tmp/linux-3.10.17.tar.xzна 2 секунды быстрее bzip2, файл на 2 мегабайта больше, одно и то же, нет смысла всё равно.
> Вот с xz -2:Идиот. С дефолтным сжимать нужно.
>> Вот с xz -2:
> Идиот. С дефолтным сжимать нужно.Не пойму, ты зачем меня обзываешь? :-)
>>> Вот с xz -2:
>> Идиот. С дефолтным сжимать нужно.
> Не пойму, ты зачем меня обзываешь? :-)Идиот - это не "обзываловка".
>>>> Вот с xz -2:
>>> С дефолтным сжимать нужно.
>> Не пойму, ты зачем меня обзываешь? :-)
> это не "обзываловка".Саш, для медицинской характеристики требуется образование, которого у тебя вроде всё-таки тоже не было; с другой стороны, человек, который пытается чего-то натестить такими бросками из крайности в крайность, и впрямь немного удивляет.
>>>>> Вот с xz -2:
>>>> С дефолтным сжимать нужно.
>>> Не пойму, ты зачем меня обзываешь? :-)
>> это не "обзываловка".
> Саш, для медицинской характеристики требуется образование, которого у тебя вроде всё-таки
> тоже не было; с другой стороны, человек, который пытается чего-то натестить
> такими бросками из крайности в крайность, и впрямь немного удивляет.Ну удивляйтесь :-) Хамить то зачем?
>>>> Вот с xz -2:
>>> Идиот. С дефолтным сжимать нужно.
>> Не пойму, ты зачем меня обзываешь? :-)
> Идиот - это не "обзываловка".А что это?
Представился.
> Вот с xz -2:
> на 2 секунды быстрее bzip2, файл на 2 мегабайта больше, одно и
> то же, нет смысла всё равно.Присоединяюсь к оратору из #73. Хотя там вы оба излишне обобщали.
> на 2 секунды быстрее bzip2, файл на 2 мегабайта больше, одно и
> то же, нет смысла всё равно.А если учесть скорость распаковки?
>> на 2 секунды быстрее bzip2, файл на 2 мегабайта больше, одно и
>> то же, нет смысла всё равно.
> А если учесть скорость распаковки?И умножить на "я даже сам хотя б два-то раза, да распакую", то и xz -3, и xz -5 "становятся ближе"ТМ. А уж при умножении на миллион xz -9e становится как родной и исключения типа "у нас тут arm, а на нём 65 MiB при распаковке может не везде найтись *и* мы ж Debian!" занимают своё почётное место.
ЗЫЖ Я уже упомянул об xz -e?
>> на 2 секунды быстрее bzip2, файл на 2 мегабайта больше, одно и
>> то же, нет смысла всё равно.
> А если учесть скорость распаковки?Давай сделаем чтоб от xz была выгода, то есть чтоб файл был не сильно больше, тогда надо xz -3:
time (xz -3vvk /var/tmp/linux-3.10.17.tar; xz -dkvvc /var/tmp/linux-3.10.17.tar.xz > /dev/null)real 1m16.314s
user 1m16.054s
sys 0m0.221stime (bzip2 -9k /var/tmp/linux-3.10.17.tar; bzip2 -dkc /var/tmp/linux-3.10.17.tar.bz2 > /dev/null)
real 0m58.145s
user 0m57.941s
sys 0m0.177s89 165 963 /var/tmp/linux-3.10.17.tar.bz2
89 466 416 /var/tmp/linux-3.10.17.tar.xzфайл у xz чуть больше, сжимает и распаковывает в сумме дольше, bzip2 выиграл :-)
У вас процессор с одним ядром? xz дает существенный выигрыш на многоядерных процессорах.
> У вас процессор с одним ядром? xz дает существенный выигрыш на многоядерных
> процессорах.А как называется параллельная версия? У меня нет поддержки параллелизации сейчас:
xz (XZ Utils) 5.0.5
liblzma 5.0.5
> А как называется параллельная версия? У меня нет поддержки параллелизации сейчас:
> xz (XZ Utils) 5.0.5
> liblzma 5.0.5Думал, что это стандартная фишка всех xz. Сам я обычно использую "7z a -txz -mx=9 -md=8m -si" для сильного сжатия и "7z a -txz -mx=0 -md=8m -si" для быстрого.
Стандартный xz тоже умеет, начиная с версии 5.2:
http://www.phoronix.com/scan.php?page=news_item&px=MTg3MDM
> xz дает существенный выигрыш на многоядерных процессорах.За ним такого не припоминаю, а pxz сравнивать разумно с lbzip2/pbzip2 тогда уж (кстати, всё это хозяйство тоже есть в altlinux.org/rescue).
PS: с другой стороны, поток pxz пригоден для распаковки xz.
Вы не понимаете современные архиваторы: сжимают они иногда медленней, но распаковывают очень быстро.$ ls -la
-rw-rw-r-- 1 user user 103956814 Nov 2 00:23 linux-4.3.tar.bz2
-rw-rw-r-- 1 user user 86920812 Nov 2 00:23 linux-4.3.tar.xz$ time xz -dk *xz
real 0m9.643s
user 0m9.431s
sys 0m0.193s$ time bzip2 -dk *bz2
real 0m21.752s
user 0m21.292s
sys 0m0.326sРазница в степени сжатия почти 20%. XZ распаковывает в два с лишним раза быстрее.
До кучи:
rar5 - 95,233,116 bytes, время распаковки - 2.8 секунды.
7z (lzma2) - 84,857,730 bytes, время распаковки - 8.7 секунд (на 2,43% лучше, чем XZ/LZMA).// b.
> bzip2 тут явно лучше.А теперь без -9. :)
>> bzip2 тут явно лучше.
> А теперь без -9. :)bzip2 -9 сжимает с такой же скоростью как xz -2 у xz -2 чуть побольше файл.
> давно уже - pbzip, только на декомпрессии выигрыш не очень, а вот
> на компрессии очень даже заметноpbzip2 can only parallel-decompress its own funky output files. Regular bzip2 streams must be processed on a single thread.
Для lzma2 должна использоваться.
я понимаю что при сжатии затык на cpu. но при распаковке??
Ты не понимаешь
Ладно, хочу уточнить. Я надеялся на многопоточку декомпрессии хотя бы bzip2, т.к. кое-какие реализации встречал, и это не было бы сверхсложным. Но! Многопоточной декомпрессии xz, zip, gzip просто не существует в природе. Да, у меня упиралось в процессор так, что компрессия происходила 12 часов (на 8 ядрах), а декомпрессия, кроме как многопоточного bzip2, длилась больше суток, потому что задействовано было 1 ядро.Все тут спорят о высоких материя сжатия. При этом сами компрессоры так убого выполнены, что столкнувшись с ними на объёмах довольно больших, когда сыграли бы все преимущества и крутость, вижу только недостатки. Поработайте с парой десятков сжатых архивов по 2TB каждый - вы на такие грабли наткнетесь в обыденных инструментах , мама не горюй. Это и архиваторов и компрессоров касается.
Пришёл к выводу что победила консольная программа 7z, выбрав архиватор-формат 7z и сжатие bzip2. При этом в таком решении так же куча недостатков : взять хотя бы кривую поддержку командной строки наркоманом-автором 7z. А его lzma не поддерживает многопоточную распаковку, автор-наркоман уверял меня, что оно никогда не упирается в процессор!! Такого не может быть, ага.
Для вашего случая стоит попробовать lzham: compression ratio similar to LZMA but with 1.5x-8x faster decompression speed.https://github.com/richgel999/lzham_codec
> Да, у меня упиралось в процессор так, что компрессия происходила 12 часов (на 8 ядрах), а декомпрессия, кроме как многопоточного bzip2, длилась больше суток, потому что задействовано было 1 ядро.
Что значит «субъективно ухудшает степень архивации»? Архивирует ровно так же, но кажется, что хуже?
> Что значит «субъективно ухудшает степень архивации»?Некоторым нравится, а некоторым "так". Вон, смотри как там наверху Аноним "субъективно улучшил" bzip2 в 9000+ раз.
>Архивирует ровно так же, но кажется, что хуже?
Архивирует лучше, но нравится "хуже". Суб-ъек-тив-изм!
> Что значит «субъективно ухудшает степень архивации»? Архивирует ровно так же, но кажется, что хуже?А это как фальшивые ёлочные игрушки. Такие же цветные и блестящие, но не радуют. (с)
Игорь не натестил ухудшений - у меня только ухудшения, поэтому и "субъективно". Мне кажется, ответ прост: если компрессить небольшой объём данных ( = влезающих, например, в словарь), то разницы не будет. Если компрессить тучу данных, то разница будет существенной.// b. Автор новости.
Когда ж они GUI'ню починят ?
LZMS - это "улучшенный" LZMA от MS?
> LZMS - это "улучшенный" LZMA от MS?LZMS is an undocumented compression format that Microsoft released in 2012 or 2013. It perhaps could be described as Microsoft's answer to LZMA (i.e. the format used in 7z and xz files), although LZMS usually produces a worse compression ratio than LZMA. Like LZMA, LZMS is an LZ77-based algorithm. It achieves a relatively high compression ratio by relying on a large LZ77 dictionary size (up to 67,108,864 bytes) and statistically modelling the LZ77 stream of literals and matches. Unlike LZMA but like some LZMA competitors such as LZHAM, LZMS uses Huffman coding in addition to the more concise arithmetic coding, presumably to make decompression faster. The Huffman codes are rebuilt periodically and are not stored with the compressed data. The format includes a preprocessing step for x86 and x86_64 machine code. It does not include a "delta" filter for multimedia data but rather allows a special "delta" match type in addition to the traditional LZ77 match type.
// b.
Адекватного GUI так и нет.
PeaZip.
Имелось ввиду,что в самом проекте 7zip адекватного GUI так и нет, а то, что его библиотеки куча программ использует это и так понятно.
> PeaZip.Оно уже перестало глючить и тормозить?
Наоборот, у 7-zip самый нормальный интерфейс из архиваторов. Просто, шустро, понятно.
даже в твоём вантузе гуй адекватен: заархивировать-разархивировать правой кнопкой меню в ехплорер.ехе
Есть ли у p7zip преимущества перед обычными zip/unzip?
> Жуткое соотношение производительности к степени сжатия по отношению к xz.Я может что пропустил конечно
# time xz -z 2gb.img
real 16m48.053s
user 16m14.133s
sys 0m18.846s# du 2gb.img.xz
2062444 1gb.img.xz# time bzip2 2gb.img
real 6m28.489s
user 5m30.422s
sys 0m10.898s# du 2gb.img.bz2
2071444 1gb.img.bz2О каком таком соотношении производительности к степени сжатия вы тут сказки рассказываете?
> О каком таком соотношении производительности к степени сжатия вы тут сказки рассказываете?Обэкспоненциальном? Каждые сленующие m% сжания -- *N раз по времени. Или типа того.
>> Жуткое соотношение производительности к степени сжатия по отношению к xz.
>2gb.img
> 2062444 1gb.img.xz
> 2071444 1gb.img.bz2Я правильно понимаю, что этот файл почти не сжимается (то есть, видимо, уже сжат)?
Сжатие сжатого -- вообще пустая трата времени и электричества, и хороший бредогенератор результатов бентчмарков, в частности.
> О каком таком соотношении производительности к степени сжатия вы тут сказки рассказываете?
Гм? Вы "забыли", как отвечать, "не ломая тред", и перелогиться "тем" Анонимом?..
> Каждые сленующие m% сжания -- *N раз по времени. Или типа того.Из того, что я увидел, с xz я потратил почти в 3 раза больше времени, при этом получил выигрыш менее 1%. Может конечно в какой то узко специфической сфере у xz и есть преимущества, но для обычного пользователя точно нет, имхо
> в какой то узко специфической сфере у xz и есть преимущества,
> но для обычного пользователя точно нет, имхоЯ у него спрашивал. Говорит, ты, извините, брешешь. //Да, я *тоже* могу говорить за него.