LINUX.ORG.RU

The Community Choice Awards 2007


0

0

На сайте http://sourceforge.net были опубликованы результаты голосования за лучшие проекты в своей категории. Всего было предоставлено 11 категорий в которых были представлены 10 проектов. С результатами можно ознакомиться по ссылке.

ЗЫ: Лучшим проектом "The all-over best project" стал - 7-Zip.

>>> Победители

Ответ на: комментарий от frame

Сейчас ради интереса взял с kernel.org исходники ядра 2.6.22.1 и 
протестировал gzip, bzip2 и 7z.

Чтобы уравнять конкурентов, исходники заархивировал tar-ом, размер
архива составил 262,922,240 байт. Степень сжатия всех компрессоров
была дефолтная, для 7z дополнительно тестировалась опция быстрого
сжатия.

Результаты:
________________________________________________________
        | Размер сжатого  | Время компрессии |Процент   |
        |  архива (байт)  |  (сек.)          |компрессии|           
--------|-----------------|------------------|----------|
gzip    |  58,563,460     |  25,770          |  22,3%   |
--------|-----------------|------------------|----------|
7z -mx=1|  53,535,829     |  58,629          |  20,4%   |
--------|-----------------|------------------|----------|
bzip2   |  45,892,487     |  124,207         |  17.5%   |
--------|-----------------|------------------|----------|
7z      |  40,194,356     |  335,616         |  15,3%   |
--------------------------------------------------------'

grad
()
Ответ на: комментарий от grad

То есть чуда не произошло - удвоение времени за каждые десять процентов отвоёванного дискового пространства. IMHO, пока объём дисков растёт быстрее чем мегагерцы.

Evgueni ★★★★★
()
Ответ на: комментарий от Evgueni

> удвоение времени за каждые десять процентов отвоёванного дискового пространства.

Почему же за каждые десять? За каджые 2 дополнительных процента приходится расплачиваться удвоением времени компрессии.

Кстати, можно заметить, что bzip жмёт оптимально, потому что дальнейшее увеличение компрессии требует намного больше времени. Это заметно по тому, что разница в степени компрессии между bzip2 и 7z составляет всего 2%, но времени 7z нужно почти в 3 раза больше.

То есть, можно резюмировать, что gzip оптимален для скоростной компрессии, bzip2 - для средней.

Ниша 7z - очень сильное сжатие, которое не под силу gzip и bzip2.

grad
()
Ответ на: комментарий от grad

> Почему же за каждые десять? За каджые 2 дополнительных процента приходится расплачиваться удвоением времени компрессии.

Это мне напоминает анекдот: встречаются два бывших одноклассника один из которых школу закончил полным \ldots, в общем даже и не закончил, но очень "конкретно" прикинут. Спрашивает его другой: "а на что живёшь, то так не плохо". "А, не важно", - отвечает первый: "покупаю по три, продаю по пять - вот на эти _два_ процента и живу" :)

Надо не просто проценты друг от друга отнимать, а ещё и поделить на один из них, дабы действительно сравнивать.

Evgueni ★★★★★
()
Ответ на: комментарий от Evgueni

> Надо не просто проценты друг от друга отнимать

Хорошо, один из архивов больше другого в 1.1 раза (на 10%). Но если говорить об этих архивах, имея в виду размер исходного несжатого архива, то разница в размере сжатых архивов равна двум прцентам от размера _исходного_ архива. ;)

grad
()
Ответ на: комментарий от grad

А теперь кошерный бенчмарк, ядро 2.6.22, 262922240 байт

darkstar ~ # md5sum linux-2.6.22-*
2edfd190ac09c0e5b998ab8514488cfa  linux-2.6.22-1.tar
2edfd190ac09c0e5b998ab8514488cfa  linux-2.6.22-2.tar
2edfd190ac09c0e5b998ab8514488cfa  linux-2.6.22-3.tar
2edfd190ac09c0e5b998ab8514488cfa  linux-2.6.22-4.tar
2edfd190ac09c0e5b998ab8514488cfa  linux-2.6.22-5.tar

darkstar ~ # ls -l linux-2.6.22-*
56913991 2007-07-29 15:31 linux-2.6.22-1.tar.gz
45119878 2007-07-29 15:33 linux-2.6.22-2.tar.bz2
52406904 2007-07-29 15:35 linux-2.6.22-3.tar.7z
38438896 2007-07-29 15:40 linux-2.6.22-4.tar.7z
38145234 2007-07-29 15:43 linux-2.6.22-5.tar.rar
________________________________________________________________
                | Размер сжатого  | Время компрессии |Процент   |
                |  архива (байт)  |  (сек.)          |компрессии|
----------------|-----------------|------------------|----------|
gzip -9v        |  56913991       |  35.271          |  21.65   |
----------------|-----------------|------------------|----------|
bzip2 -9v       |  45119878       |  91.770          |  17.16   |
----------------|-----------------|------------------|----------|
7z -mx=1        |  52406904       |  34.327          |  19.93   |
----------------|-----------------|------------------|----------|
7z              |  38438896       |  219.295         |  14,62   |
----------------|-----------------|------------------|----------|
rar -m5 -md4096 |  38145234       |  110.166         |  14,51   |
----------------------------------------------------------------'

Также, стоит учитывать, что 7z умеет работать в SMP среде,
т.е. для сжатия использовались сразу 2 ядра, а RAR - не умеет,
и это ещё не считая сжираемой памяти. К слову о птичках ;)

Разница с раром - в 3-4 раза (не забываем о SMP) при равном сжатии.

Апологеты опенсорца, разумеется, мощно взвоют на тему:
"Дык, пля, 7z не на максимуме жал!", я же спрошу:
"А ви таки готовы ждать часами до этого самого максимума?".

Засим тему предлагаю сворачивать.

Gharik
()
Ответ на: комментарий от grad

linux-2.6.21.6.tar: 254,423,040b (накатывал патчами ещё от 2.6.18)

bzip2 -9 : 2m33s - 44,309,289b
bzip2 -5 : 2m16s - 45,976,252b

7zG [fast,lzma mf=hc4 d=27 mc=16 lc=8 fb=128]: 2m26s - 44,208,953b
7zG [fast,lzma mf=hc4 d=27 mc=18 lc=8 fb=273]: 2m33s - 43,991,419b

7zG это Win32GUI-версия, т.е. от времени можно смело отнимать порядка 5%. Про скорость распаковки (а она наряду с размером как раз и
важнее всего для пользователя, который качает архив с сайта) и говорить нечего. Выводы делайте сами.

frame ★★★
()
Ответ на: комментарий от Gharik

>rar -m5

Да будет тебе известно, что rar для сжатия текстовых данных в этом режиме автоматом использует PPM, скорость работы которого и потребляемая память как при запаковке так и при распаковке приблизительно равны. Принудительно указав использвание PPMd для 7z можно добиться даже лучших результатов. Поэтому "кошерность" твоего теста под большим вопросом, ибо ниасилил ты -mct- и man, который я тебе советовал.

frame ★★★
()
Ответ на: комментарий от frame

> Да будет тебе известно, что rar для сжатия текстовых данных в этом режиме автоматом использует PPM, скорость работы которого и потребляемая память как при запаковке так и при распаковке приблизительно равны. Принудительно указав использвание PPMd для 7z можно добиться даже лучших результатов. Поэтому "кошерность" твоего теста под большим вопросом, ибо ниасилил ты -mct- и man, который я тебе советовал.

А пофиг что оно там использует, главное, что жмёт очень быстро и качественно, сохраняя пропорциональность между временем сжатия и размером архива.

А тебе слабо показать настройки, с которыми 7z выиграет у rar'а 10% в сжатии, проиграв 10% по времени, или засчитываем полнейший слив? Особенно будет хорошо, если словарик у 7z составит 4Mb, а расход памяти - не более 30 метров. И пофиг на конкретный алгоритм, у рара в ГУЕ есть всего одна настройка - "уровень сжатия", от 1 до 5, детали меня не волнуют.

Или закрываем спор нафик, как тупой и бессмысленный, это всё равно что фонатегам ассемблера доказывать, что их техника "поибстись пару суток и прибегнув к чудовищным извратам выиграть 1% скорости" сосёт у обыкновенного написания кода на C с переложением оптимизаций на компилятор ключиком "-O2".

Gharik
()
Ответ на: комментарий от Gharik

>Пожалста, ещё один косяк, с использованием гномьего манагера архивов

у меня KDE и таких проблем нет

>А тебе слабо показать настройки, с которыми 7z выиграет у rar'а 10% в сжатии, проиграв 10% по времени,

Ты уже потихоньку начинаешь доказывать преимущества проприетарных поделок для однокнопочных перед продвинутыми консольными *GPL утилитами? И имя тебе Gharik? Мухахa!)))

>или засчитываем полнейший слив?

>Или закрываем спор нафик, как тупой и бессмысленный

Слив защитан )))

>Ты меня достал уже

>Gharik (*) (29.07.2007 17:48:22)

Свершилось! =8-D

>Только 7z у нас пипец какой альтернативный и навороченный, наверное поэтому и требует росписи в командной строке чуть не ли не "Войны и мира", чтобы получился приличный результат.

7z просто даёт тебе больше выбора, если ты его боишься - значит не хочешь думать

frame ★★★
()
Ответ на: комментарий от frame

> 7zG [fast,lzma mf=hc4 d=27 mc=16 lc=8 fb=128]: 2m26s - 44,208,953b

Ну вот, сжимают практически одинаково. Только заметь, в 7z нужно подбирать идеальные опции сжатия, т.к. по дефолту 7z жмёт немного сильнее и намного дольше.

Насчёт распаковки точно не скажу, но в моём тесте разница во времени была не более 10 секунд в пользу 7z. Это совсем не много, учитывая, что 7z сжимал архив в 2,5 раза дольше, чем bzip2.

grad
()
Ответ на: комментарий от frame

> 7z просто даёт тебе больше выбора

Действительно, 7z позволяет гибко задавать опции компрессии. Но посмотри как ведёт себя bzip: и с опцией -9 и с опцией -5 он жмёт практически одинаково, потому что эта степень сжатия - оптимальна и сохраняет пропорциональность между временем сжатия и размером архива. Разницу во времени распаковки "меньше в разы" я не заметил.

grad
()
Ответ на: комментарий от grad

>Только заметь, в 7z нужно подбирать идеальные опции сжатия, т.к. по дефолту 7z жмёт немного сильнее и намного дольше.

bzip2 заточен под текст, 7z более универсален и допускает настройку многих параметров, по умолчанию которые видимо для текста не оптимальные, но их всегда можно подобрать, и для любого типа данных + прикрутить фильтры для исполняемых файлов и пр.

>Насчёт распаковки точно не скажу, но в моём тесте разница во времени была не более 10 секунд в пользу 7z.

у себя точно скажу: 10 секунд у 7z против 28 у bz2, т.е. более чем в 2,5 раза

>Но посмотри как ведёт себя bzip: и с опцией -9 и с опцией -5 он жмёт практически одинаково, потому что эта степень сжатия - оптимальна и сохраняет пропорциональность между временем сжатия и размером архива.

Уже не буду пробовать, но уровня компрпесии bzip2 -5 я 7zip-ом добивался за ~1m40s. BlockSorting и LZ77 работают по разному и параллели здесь неуместны.

frame ★★★
()
Ответ на: комментарий от frame

> у меня KDE и таких проблем нет

Там ещё и венда, судя по всему, что чётко показывает аудиторию программы =)

> Ты уже потихоньку начинаешь доказывать преимущества проприетарных поделок для однокнопочных перед продвинутыми консольными *GPL утилитами? И имя тебе Gharik? Мухахa!)))

Какая генерализация, вы только посмотрите ;) Мне-то пофиг, троллем жил и троллем же помру, а вот как ты жить будешь, так и не сумев доказать задекларированное общее превосходство 7z над rar? :)

> Слив защитан )))

+1, это было ясно с самого начала :)

> Свершилось! =8-D

Не торопись, это я трезветь начал на момент написания той фразы, счас всё поправим =))

> 7z просто даёт тебе больше выбора, если ты его боишься - значит не хочешь думать

Какого выбора? Сидеть под вендой с документацией или сидеть в линуксе в консоли шаманя и пытаясь угадывать опции?

Тогда, следующий вопрос - а какого хрена у 7zip'а нет нормальный онлайн документации, несмотря на версию __4.хх__, а у рара, жзипа, бзипа и прочих - её навалом?

Gharik
()
Ответ на: комментарий от frame

Пусть 7z незначительно опережает конкурентов, но почему его не используют в продакшене? Наверное потому, что стандартные gzip/bzip2 замечательно работают с пайпами, жмут предсказуемо и не имеют косяков, которые обозначил Gharik. Всё же, проект начинался как вендовый и в Linux среде, как говорится, "некошерен".

grad
()
Ответ на: комментарий от Gharik

Народ конечно пошёл ленивый, всё приходится самому за них делать,
даже с самим собой спорить, епта:

darkstar ~ # time 7z a -m0=ppmd -mx=9 linux-2.6.22.tar.7z linux-2.6.22.tar

7-Zip 4.48 beta  Copyright (c) 1999-2007 Igor Pavlov  2007-06-26
p7zip Version 4.48 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)
Scanning

Creating archive linux-2.6.22.tar.7z

Compressing  linux-2.6.22.tar      

Everything is Ok

real    1m43.100s
user    1m39.710s
sys     0m0.980s

darkstar ~ # time rar a -m5 -md4096 linux-2.6.22.tar.rar linux-2.6.22.tar

RAR 3.70   Copyright (c) 1993-2007 Alexander Roshal   22 May 2007
Registered to Avinash Gaikwad

Creating archive linux-2.6.22.tar.rar

Adding    linux-2.6.22.tar                                            OK 
Done

real    1m41.883s
user    1m40.500s
sys     0m0.570s

darkstar ~ # ls -acl linux-2.6.22.tar*
-rw-rw-r-- 1 root portage 262922240 2007-07-29 18:17 linux-2.6.22.tar
-rw------- 1 root root     36037982 2007-07-29 18:26 linux-2.6.22.tar.7z
-rw-r--r-- 1 root root     38145232 2007-07-29 18:29 linux-2.6.22.tar.rar

Епта!!! 7Z выиграл!!! И много выиграл!!!
Только вот буковки "(2 CPUs)" несколько смущают,
есть что сказать, или опять 10% ценой 2х времени?

Gharik
()
Ответ на: комментарий от grad

> Пусть 7z незначительно опережает конкурентов, но почему его не используют в продакшене? Наверное потому, что стандартные gzip/bzip2 замечательно работают с пайпами, жмут предсказуемо и не имеют косяков, которые обозначил Gharik. Всё же, проект начинался как вендовый и в Linux среде, как говорится, "некошерен".

Тсссс, КДЕ - это почти виндавс.

Так вот, я сейчас активно играюсь с раровской технологией добавления избыточной информации для восстановления побитых архивов, и честно сказать - в полном восторге. А где такое в 7z?

Gharik
()
Ответ на: комментарий от Gharik

> Епта!!! 7Z выиграл!!! И много выиграл!!!

Да чё спорить с человеком? По его словам: "7zG это Win32GUI-версия" уже всё понятно :))

Нет, конечно, в винде 7-Zip - это реальная опенсорс замена проприетарному винрару, для чего и разрабатывался, но в Линуксе 7-Zip просто не нужен.

grad
()
Ответ на: комментарий от grad

Не, в целом сей товарищ таки зело крут, я бы не смог физически столько трахаться с опциями, подбирая единички в куче параметров, и оптимизировать процесс. Его бы энергию, да автору семь-зипа, для оптимизаций алгоритмов, вместо комбайнописательства, и вылизывания консольного режима (или создания выделенной библиотеки).

Gharik
()
Ответ на: комментарий от Gharik

>Там ещё и венда, судя по всему, что чётко показывает аудиторию программы =)

ты таки ни разу не был на сайте программы? сделай для себя открытие.

>Мне-то пофиг, троллем жил и троллем же помру, а вот как ты жить будешь, так и не сумев доказать задекларированное общее превосходство 7z над rar? :)

безмозглый тролль, найди строчку где я декларировал "общее превосходство 7z над rar", для начала

>Не торопись, это я трезветь начал на момент написания той фразы, счас всё поправим =))

видимо солидол на закуску хороший попался )))

>Тогда, следующий вопрос - а какого хрена у 7zip'а нет нормальный онлайн документации, несмотря на версию __4.хх__, а у рара, жзипа, бзипа и прочих - её навалом?

это волнует только тебя

frame ★★★
()
Ответ на: комментарий от grad

>Да чё спорить с человеком? По его словам: "7zG это Win32GUI-версия" уже всё понятно :))

Ещё одна улыбающаяся обезьяна...

7zFM.exe - файловый менеджер 7zG.exe - ему передаются параметры от 7zFM для компресии и именно он висит в списке процессов во время архивации

frame ★★★
()
Ответ на: комментарий от grad

>Пусть 7z незначительно опережает конкурентов, но почему его не используют в продакшене?

Почему SD нет в ядре?

frame ★★★
()
Ответ на: комментарий от frame

> безмозглый тролль

> улыбающаяся обезьяна

Давай будем оставаться в рамках приличий и держать себя в руках, а то пропадёт желание общаться.

Просто согласись, что серьёзные люди 7z в Линуксе использовать не будут, по причинам, названным выше по треду. Посмотри что используют дистростоители: для исходников - bzip2, для бинарников - gzip. И ни один не использует 7z.

grad
()
Ответ на: комментарий от frame

> ты таки ни разу не был на сайте программы? сделай для себя открытие.

Проснись, дорогуша, посмотри на название __сайта на которым ты сейчас находишься__ ;))

> безмозглый тролль, найди строчку где я декларировал "общее превосходство 7z над rar", для начала

То есть ты согласен, что по большинству пунктов 7zip сливает рару и пользователи не зря остаются на WinRAR, а пользователи юниксов - совершенно не зря и в хер не ставит ни rar ни 7zip?

http://www.linux.org.ru/jump-message.jsp?msgid=2056311&cid=2056424

> видимо солидол на закуску хороший попался )))

Генерализации кончились, начались проекции? :)

> это волнует только тебя

А должно волновать многих, программа, особенно с GUI, под юниксы без онлайн-помощи обречена на смерть и может рассчитывать максимум на статус студенческой поделки.

Gharik
()
Ответ на: комментарий от frame

> Почему SD нет в ядре?

Неуместная аналогия. Повторяю: стандартные gzip/bzip2 замечательно работают с пайпами, жмут предсказуемо и не имеют косяков.

Ты можешь с полной уверенностью с первого раза подобрать опции 7z, чтобы оптимально сжать исходники, бинарники? Врядли. Вот и майнтайнеры не хотят забивать себе голову десятком опций 7z, если можно просто набрать "tar cjvf" и быть уверенным, что сжатие не будет длиться полчаса и размер архива будет достаточно малым. А домашний юзер может себе позволить играться с настройками, поэтому, как бы тебе не хотелось, но 7z останется поделкой для домашнего использования.

grad
()
Ответ на: комментарий от grad

>>Да чё спорить с человеком? По его словам: "7zG это Win32GUI-версия" уже всё понятно :))

>Давай будем оставаться в рамках приличий и держать себя в руках, а то пропадёт желание общаться.

Не выдавай своё невежество за такую снисходительность, это во многом определяет характер ответов на подобные сообщения.

>Просто согласись, что серьёзные люди 7z в Линуксе использовать не будут, по причинам, названным выше по треду.

причины, названные выше - сугубо от незнания и далеко не от серьёзных людей

>Посмотри что используют дистростоители: для исходников - bzip2, для бинарников - gzip. И ни один не использует 7z.

_единственная_ на то причина: малая распространённость формата, что со временем уладится и первые шаги к этоу делаются (в дебиане вроде это сжатие в пакетах пожжерживается). Я даже скажу, что всё больше проектов на SF предлагают скачивать бинарники/исходники в 7z (тот же phpMyAdmin или MPC)

frame ★★★
()
Ответ на: комментарий от Gharik

>А должно волновать многих, программа, особенно с GUI, под юниксы без онлайн-помощи обречена на смерть и может рассчитывать максимум на статус студенческой поделки.

Люкальный файл справки тебя уже не устраивает, нужен обязательно онлайн? Это твои сетевые проблемы.

>То есть ты согласен, что по большинству пунктов 7zip сливает рару и пользователи не зря остаются на WinRAR

перечисляя пункты не забудь купить лицензию.

Ты мне когда-то доказывал, что опен-сорц программа (МС) всяко лучше проприетарной (Far) уже только потому, что она опенсорц, а значит бесконечно-расширяема-улучшаема и т.п. Сейчас говоришь, что проприетарный и фичастый rar рулит, gpl-7z отстой. Где логика в твоих мышлениях?

frame ★★★
()
Ответ на: комментарий от grad

> причины, названные выше - сугубо от незнания и далеко не от серьёзных людей

Вот когда на 7z перейдёт большинство дистрибутивов, серьёзных контор и формат 7z станет общепринятым стандартом, какими сейчас являются gzip и bzip2, тогда и поговорим. А пока это всего лишь "yet another compressor", который иногда, при указании 10 правильных опций жмёт на 1% лучше.

grad
()
Ответ на: комментарий от frame

> Люкальный файл справки тебя уже не устраивает,
> нужен обязательно онлайн? Это твои сетевые проблемы.

> Мену ниипут трудности афтара, осилившего склепать справку в наглухо
> проприетарном формате, и не могущего выложить эти же .html в паблик.

> перечисляя пункты не забудь купить лицензию.

darkstar ~ # stat /usr/local/bin/rar 
  File: `/usr/local/bin/rar'
  Size: 877060          Blocks: 1728       IO Block: 4096   regular file
Device: 803h/2051d      Inode: 17314       Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2007-07-29 19:08:13.000000000 +0400
Modify: 2007-05-22 09:11:15.000000000 +0400
Change: 2007-07-20 06:34:47.000000000 +0400

Не сцы, 30-дней триала ещё не миновали,
а закрытыми фишками я не пользуюсь ;)


> Ты мне когда-то доказывал, что опен-сорц программа (МС) всяко
> лучше проприетарной (Far) уже только потому, что она опенсорц,
> а значит бесконечно-расширяема-улучшаема и т.п. Сейчас говоришь,
> что проприетарный и фичастый rar рулит, gpl-7z отстой.
> Где логика в твоих мышлениях?

В функционале и качестве, отсутствии комбайнёрства.
В полной мере это относится и к MC, фар - лишь костыльное
поделие для бессильных духом и моском вендузятнегов.
Но 7z пошёл именно что по пути фара, и там где закрытый софт
имеет полное право на комбайнообразность (пользователь платит
за это), опенсорц-софт должен блестяще выполнять свою прямую
функцию, иначе он влетает в списки "бестолкового отстоя".

Gharik
()
Ответ на: комментарий от grad

>Вот и майнтайнеры не хотят забивать себе голову десятком опций 7z, если можно просто набрать "tar cjvf" и быть уверенным, что сжатие не будет длиться полчаса и размер архива будет достаточно малым.

У майнтейнеров нет особого выбора: выбирая bz2 они стремятся в первую очередь - уменьшить размер по сравнению с gz и наверняка архивируют с опцией "-9". Время сжатия зависит от поступающих данных, уверенность может быть лишь относительная. Про то, как "майнтайнеры не хотят забивать себе голову" я скажу, что ты в корне не прав.

>А домашний юзер может себе позволить играться с настройками, поэтому, как бы тебе не хотелось, но 7z останется поделкой для домашнего использования.

Уже сейчас он много где используется: mozilla жмёт им свои дистрибуции FF для win (с далеко не дефолтными ключиками), upx, многие инсталляторы (там, где я раньше замечал испольхование bz2) и коммерческие проекты взяли на вооружение этот метод. И то, что в WinRAR и других серъёзных коммерческих архиваторах появилась поддержка этого формата архива и то, что LZMА уже в zip-спецификации говорит о том, что это далеко не "поделка для домашнего использования". Автор всячески улучшает SDK. Использование его в linux - только дело времени.

frame ★★★
()
Ответ на: комментарий от frame

> У майнтейнеров нет особого выбора: выбирая bz2

Не поверишь, но в потрохах RPM лежит никакой не bz2, а самый что ни на есть cpio.gz ;)

Ибо есть ещё и "стандарты" в системах управления пакетами, дабы не раздувать кодовые базы и не придумывать костыли на каждый чих.

Gharik
()
Ответ на: комментарий от Gharik

> Мену ниипут трудности афтара, осилившего склепать справку в наглухо
> проприетарном формате, и не могущего выложить эти же .html в паблик.

Это _твои_ трудности, никто до тебя их не называл. И с каких это пор chm(+lzx)- наглухо проприетарный формат?

>Не сцы, 30-дней триала ещё не миновали,
а закрытыми фишками я не пользуюсь ;)

да ты варезник обычный 

>В функционале и качестве, отсутствии комбайнёрства.
>В полной мере это относится и к MC, фар - лишь костыльное
>поделие для бессильных духом и моском вендузятнегов.
>Но 7z пошёл именно что по пути фара, и там где закрытый софт
>имеет полное право на комбайнообразность (пользователь платит
>за это), опенсорц-софт должен блестяще выполнять свою прямую
>функцию, иначе он влетает в списки "бестолкового отстоя".

приведёшь хоть один пример комбайнёрства?

frame ★★★
()
Ответ на: комментарий от frame

> Это _твои_ трудности, никто до тебя их не называл. > И с каких это пор chm(+lzx)- наглухо проприетарный формат?

Да проснись же ты наконец, адепт философии завязанных глаз! :)

http://ru.wikipedia.org/wiki/HTMLHelp

> да ты варезник обычный

Переходим на лица? Ну поди, почитай лицензионное соглашение и вспомни мои слова по поводу "избыточной информации в архивах" вместе с инфой о бинарнике "rar" (размер в частности), авось дойдёт, ради чего я специально перекомпилировал ядро для поддержки 32-битного отстоя ;))

> приведёшь хоть один пример комбайнёрства?

Плагины, шифрование, куча консольных огрызков, GUI при толком недоработанном и мега-прожорливом основном же алгоритме (LZMA). КДЕ напоминает, и венду ещё.

Gharik
()
Ответ на: комментарий от Gharik

>Плагины, шифрование

Ну уж если такое "комбайнёрство" тебе не приемлемо... в WinRAR'е точно так же

>куча консольных огрызков

открой для себя 7za

>GUI при толком недоработанном и мега-прожорливом основном же алгоритме (LZMA)

Проснись, LZMA уже в zip-спецфикации. И почитай чейнджлог на досуге.

>КДЕ напоминает, и венду ещё.

7-zip не имеет к этому никакого отношения, это болезнь

frame ★★★
()
Ответ на: комментарий от frame

> У майнтейнеров нет особого выбора: выбирая bz2 они стремятся в первую очередь - уменьшить размер по сравнению с gz и наверняка архивируют с опцией "-9".

Выбор всегда есть. Кстати, в репозитарии Дебиана нашёл компрессоры lzma
и rzip. Почему же они не распространены как gzip/bzip2 ?? Тем более lzma использует тот же алгоритм компрессии, что и 7z.

Как я уже говорил, опции компрессии "-5" и "-9" сильно друг от
друга не отличаются:

_____________________________________________________
                | Размер сжатого  | Время компрессии |
                |  архива (байт)  |  (сек.)          |
----------------|-----------------|------------------|
gzip            |  58563460       |  25,770          |
----------------|-----------------|------------------|
gzip -9         |  58045925       |  46,376          | 
-----------------------------------------------------'

А bzip2 вообще по умолчанию сжимает с максимальной компрессией. И вообще, дефолтная компрессия в gzip/bzip2 - оптимальна, не то что в поделке 7z.

grad
()
Ответ на: комментарий от frame

> Ну уж если такое "комбайнёрство" тебе не приемлемо... в WinRAR'е точно так же

Понимаю, историю сейчас никто не читает, не говоря уже об учёбе, но напомню:: когда в раре появилось шифрование (пусть простенькое) - он уже был отличным архиватором.

> открой для себя 7za

Не поверишь, но он тоже консольный! Нет GUI под линукс, неееееет! Да и среди виндовых нет такого, чтобы позволял тонко ковырять параметры мышкой :)

> Проснись, LZMA уже в zip-спецфикации. И почитай чейнджлог на досуге.

Да пофиг, где же его преимущества? Когда явно видно, что PPMd и жмёт лучше и работает быстрее.

> 7-zip не имеет к этому никакого отношения, это болезнь

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

Gharik
()
Ответ на: комментарий от Gharik

>Я не зря говорю о необходимости онлайн-доков ;)

В которых даже ответа на поставленный мною вопрос... Плохо, когда онлайн-доки заменяют людям мозги.

Я тебе отвечу: если бы вместо gz использовался bz2 установка пакета длилась бы в раз 5 дольше из-за низкой скорости распаковки, и сейчас очень немногие (вроде Arch) рискуют делать пакеты на bz2. И поэтому bz2 никогда не будет в этом плане широко востребован, а LZMA - очень даже с большой вероятностью.

frame ★★★
()
Ответ на: комментарий от Gharik

>Понимаю, историю сейчас никто не читает, не говоря уже об учёбе, но напомню:: когда в раре появилось шифрование (пусть простенькое) - он уже был отличным архиватором.

Я застал его в районе 1.5х-версий. И по меркам того времени он был комбайном

>Да пофиг, где же его преимущества?

читай readme в lzma-sdk

>Когда явно видно, что PPMd и жмёт лучше и работает быстрее.

"There is no difference between compression speed and decompression speed. Memory requirements for compression and decompression also are the same", - переводи и думай

frame ★★★
()
Ответ на: комментарий от frame

> Я тебе отвечу: если бы вместо gz использовался bz2 установка пакета длилась бы в раз 5 дольше из-за низкой скорости распаковки, и сейчас очень немногие (вроде Arch) рискуют делать пакеты на bz2. И поэтому bz2 никогда не будет в этом плане широко востребован, а LZMA - очень даже с большой вероятностью.

Если бы ты умел читать, то прочитал, что цели "save space" и скорость там рядышком. Дальше погугли про формат пакетов Генты, уж её-то ты в "низкой скорости" обвинять не будешь? ;)

Gharik
()
Ответ на: комментарий от frame

> Я застал его в районе 1.5х-версий. И по меркам того времени он был комбайном

Где противоречие-то?

> читай readme в lzma-sdk

Заметны невооружённым глазом: "высокая скорость" компресии (ppmd на 9-м режиме быстрее), "хорошее" сжатие (ppmd делает на раз на добрый десяток процентов) и т.п. Может это они простебались мощно так над авторами спеков официальных? :)

> "There is no difference between compression speed and decompression speed. Memory requirements for compression and decompression also are the same", - переводи и думай

А типа гигабайты ОЗУ, требуемые для сжатия по LZMA (отменяемые лишь при условии сурового тюнинга, что пожрёт ещё кучу времени), это - фигня полная и мелочь несущественная, зато разжимается быстро и мало памяти съест.

Вижу я, что юникс-джедай истинный ты, клиент серверную философию полностью постигший, и на мегасервере сжатие проводящий , а распаковку тонким клиентам оставляющий :) Вешай медальку, с такими людьми я спорить не в состоянии :)

Gharik
()
Ответ на: комментарий от grad

>Кстати, в репозитарии Дебиана нашёл компрессоры lzma и rzip. Почему же они не распространены как gzip/bzip2 ?

проследи, когда они там появились и сам догадаешься

>И вообще, дефолтная компрессия в gzip/bzip2 - оптимальна, не то что в поделке 7z.

угу, только ни на {kernel,kde,mozilla,gcc,...}.org никто архивы с исходниками сжатыми с опциями по дефолту не выкладывает почему-то. И все релизы как правило пакуются посильней, чтобы пользователю было меньше скачивать, т.к. это меньше нагрузка на сервер.

оптимально для всего быть не может по определению.

frame ★★★
()
Ответ на: комментарий от Gharik

>Дальше погугли про формат пакетов Генты, уж её-то ты в "низкой скорости" обвинять не будешь? ;)

Хочешь сказать, что компилирование из исходников быстрее установки пакета из архива? Или хоть с CFLAGS=" -O99 -finline-limit=дох*я " ты libbz2 скомпилируй, он всё равно будет тормозить при распаковке как по сравнению с gz так и по сравнению с lzma. И не пугай LSF-сника своей тормознутой гентой ;)

frame ★★★
()
Ответ на: комментарий от frame

> Хочешь сказать, что компилирование из исходников быстрее установки пакета из архива?

Нет, то что мощности нынче великие и экономить проц на столь мелкой и cpu-intensive операции как "распаковка" нынче смотрится маразмом, ибо в разы больше времени занимает ввод-вывод.

> Или хоть с CFLAGS=" -O99 -finline-limit=дох*я " ты libbz2 скомпилируй, он всё равно будет тормозить при распаковке как по сравнению с gz так и по сравнению с lzma.

Один паренёк беспокойный вычислял тут недавно CFLAGS, что давали bzip2'у прирост в почти полтора раза. А это уже близко к gzip'у, дядя ;)

> И не пугай LSF-сника своей тормознутой гентой ;)

Это да, узнаю своё прошлое, тогда тоже казалось, что геморрой нон-стоп оправдывается рады 0.5% выигрыша на general-purpose софте.

Gharik
()
Ответ на: комментарий от Gharik

>А типа гигабайты ОЗУ, требуемые для сжатия по LZMA (отменяемые лишь при условии сурового тюнинга, что пожрёт ещё кучу времени)

вызывающе неверная информация. ppm тем более совершенно не подходит для быстрого restore, особенно если данных очень много, распаковать их нужно быстро, а памяти - очень мало.

>Вешай медальку, с такими людьми я спорить не в состоянии :)

Я напишу эту фразу на медальке, ибо очень немногие удостоились такой чести. Теперь можно спокойно умереть %)

frame ★★★
()
Ответ на: комментарий от Gharik

>Один паренёк беспокойный вычислял тут недавно CFLAGS, что давали bzip2'у прирост в почти полтора раза. А это уже близко к gzip'у, дядя ;)

В теме о процессорах? Это был я, наверное :) Но с теми флагами (c которыми у меня он сейчас и скомпилен) bzip'у всё равно ещё далеко ехать.

frame ★★★
()
Ответ на: комментарий от frame

> вызывающе неверная информация. ppm тем более совершенно не подходит для быстрого restore, особенно если данных очень много, распаковать их нужно быстро, а памяти - очень мало.

Неужели? А словарик потолще выставить не пробовал? ;) Тем более, не имеет смысла быстрая распаковка, которую не в состоянии отработать сторадж (да-да, тот самый ввод-вывод).

> Я напишу эту фразу на медальке, ибо очень немногие удостоились такой чести. Теперь можно спокойно умереть %)

Луговского нет, жалко, ага... =))

Gharik
()
Ответ на: комментарий от frame

> В теме о процессорах? Это был я, наверное :) Но с теми флагами (c которыми у меня он сейчас и скомпилен) bzip'у всё равно ещё далеко ехать.

А хрен его знает, вроде тогда ленин ещё самозобанился, а может я это дело с чем-то по пьяни путаю... старость не радость...

Gharik
()
Ответ на: комментарий от frame

> если бы вместо gz использовался bz2 установка пакета длилась бы в
раз 5 дольше из-за низкой скорости распаковки

Ну и правильно, gzip - для бинарников, bzip2 - для исходников! gzip -
самый быстрый, быстрее него только lzop. 

> и сейчас очень немногие (вроде Arch) рискуют делать пакеты на bz2.
 
Хмм, если мне не изменяет память, в Арче пока ещё tgz-пакеты.

> И поэтому bz2 никогда не будет в этом плане широко востребован, а
LZMA - очень даже с большой вероятностью.

С удешевлением дискового пространства и интернет-трафика, боюсь,
что LZMA никогда не будет востребован, а будут востребованы как раз
алгоритмы типа LZO, позволяющие сжимать данные в реальном режиме
времени.

Решил провести тестирование с большим количеством компрессоров. 
На этот раз взял файл поменьше, хендбук FreeBSD в html размером
4391495 байт.

Результаты отсортированы по размеру сжатого файла:
_____________________________________________________________
             | Размер сжатого  | Время компрессии |Процент   |
             |  файла (байт)   |  (сек.)          |компрессии|           
-------------|-----------------|------------------|----------|
lzop         |   2374774       |   0.109          |  54,1%   |
-------------|-----------------|------------------|----------|
gzip         |   1659014       |   0,433          |  37.8%   |
-------------|-----------------|------------------|----------|
7z -mx=1     |   1607435       |   1,460          |  36,6%   |
-------------|-----------------|------------------|----------|
7z -mx=3     |   1557456       |   1,854          |  35.5%   |
-------------|-----------------|------------------|----------|
lzma -2      |   1544736       |   1,890          |  35.2%   |
-------------|-----------------|------------------|----------|
rzip -3      |   1472704       |   1,600          |  33.5%   |
-------------|-----------------|------------------|----------|
rzip         |   1449121       |   1,897          |  33.0%   |     
-------------|-----------------|------------------|----------|
rzip -9      |   1445667       |   3,961          |  32,9%   | 
-------------|-----------------|------------------|----------|
lzma -3      |   1426222       |   5,557          |  32.5%   |        
-------------|-----------------|------------------|----------|
bzip2        |   1420923       |   2,086          |  32.3%   |  
-------------|-----------------|------------------|----------|
7z           |   1406167       |   5,315          |  32.0%   |     
-------------|-----------------|------------------|----------|
7z -mx=9     |   1394735       |   6,294          |  31.8%   |     
-------------|-----------------|------------------|----------|
lzma -5      |   1392573       |   6,564          |  31.7%   |
-------------|-----------------|------------------|----------|
lzma         |   1390163       |   6,685          |  31.6%   |
-------------|-----------------|------------------|----------|
lzma -9      |   1390048       |   7,090          |  31,6%   |
-------------|-----------------|------------------|----------|
ppmd         |   1364053       |   1,930          |  31,0%   |
-------------|-----------------|------------------|----------|
ppmd -o16    |   1345173       |   2,570          |  30,6%   |
-------------|-----------------|------------------|----------|
ppmd -o16 -r1|   1295524       |   5,557          |  29,6%   |
-------------------------------------------------------------'

Среднее время декомпрессии в секундах:

lzop: 0,035 
gzip: 0,1
lzma: 0,3
7z:   0,35
bzip: 0,6
rzip: 0,8
ppmd: 1,9 - 5,5


Итоги: 
bzip2 по времени компрессии сильно превосходит соседей, 
что говорит об оптимальном алгоритме сжатия, но почти в 2 раза 
уступает lzma и 7z по времени распаковки. 
lzop - прекрасный алгоритм для real-time компрессии. 
gzip - очень быстр как в сжатии, так и в распаковке.
rzip - позиционируется, как компрессор для очень больших файлов,
поэтому результаты плохие.
lzma - по дефолту сжимает лучше, чем 7z примерно за одинаковое 
время, распаковывает немного быстрее.
ppmd - хоть и обошёл всех, показав наилучшее сжатие,
но время декомпрессии просто огромно.

grad
()
Ответ на: комментарий от grad

>Хмм, если мне не изменяет память, в Арче пока ещё tgz-пакеты.

изменяет

>С удешевлением дискового пространства и интернет-трафика, боюсь, что LZMA никогда не будет востребован, а будут востребованы как раз алгоритмы типа LZO, позволяющие сжимать данные в реальном режиме времени.

Можешь не бояться: применимые на практике алгоритмы с сильной компрессией были и будут востребованы ВСЕГДА (тормозной bz2 и проприетарный rar ведь живые?), LZO разрабатывался _именно_ для сжатия/распаковки на лету, а LZMA - для архивов. Ты сравниваешь пинцет с плоскогубцами.

>На этот раз взял файл поменьше, хендбук FreeBSD в html размером 4391495 байт.

ты знаешь, в архивах может быть не только текст, - добавь тогда уж бинарники, bmp, wav, таблицы с данными, если претендуешь на то, чтобы твои тесты претендовали хоть на какую-то долю объективности

frame ★★★
()
Ответ на: комментарий от frame

> Можешь не бояться: применимые на практике алгоритмы с сильной компрессией были и будут востребованы ВСЕГДА (тормозной bz2 и проприетарный rar ведь живые?), LZO разрабатывался _именно_ для сжатия/распаковки на лету, а LZMA - для архивов. Ты сравниваешь пинцет с плоскогубцами.

Дык понятно, но поскольку таких архиваторов как собак - то в первую голову будут смотреть на ресурсоёмкость, а вот тут lzma в большущем пролёте.

> ты знаешь, в архивах может быть не только текст, - добавь тогда уж бинарники, bmp, wav, таблицы с данными, если претендуешь на то, чтобы твои тесты претендовали хоть на какую-то долю объективности

rar/flac/ape/jpeg2000-lossless/etc рулят, и вообще, всегда лучше юзать специализированный софт, а не валить всё в единую свалку по старой вендузячьей привычке. Rar, кстати, жмёт мультимедию иной раз покруче специально заточенных под оную компрессоров ;)

Gharik
()
Ответ на: комментарий от frame

>> Хмм, если мне не изменяет память, в Арче пока ещё tgz-пакеты.

> изменяет

Может, всё-же у тебя склероз? Посмотри внимательно на расширения пакетов в официальном репозитарии Арча:

ftp://ftp.archlinux.org/current/os/i686/

Мне думается, что gzip хорошо и быстро сжимает бинарники, поэтому большинство пакетов распространяется в TGZ формате.

> добавь тогда уж бинарники

Надо ещё потестить смешанные данные и просто бинарники.

grad
()
Ответ на: комментарий от Gharik

>Дык понятно, но поскольку таких архиваторов как собак - то в первую голову будут смотреть на ресурсоёмкость, а вот тут lzma в большущем пролёте.

Ты не догоняешь: 7-zip изначально позиционировался именно как _архиватор с высокой степенью сжатия и скоростью распаковки_, т.е "в первую очередь будут смотреть на ресурсоёмкость" разве что те, котому это в первую очередь критично и владельцы первых селеронов (без кэша). Динамика загрузок с сайста проекта никак не кореллирует с твоими выводами.

Обрати свой взор на Mozilla FF и подумай, почему под win размер дистрибутива гораздо меньше. Ресурсоёмкость (когда файл сжимается _один_ раз и выкладывается на сервер) никого не волнует, пользователя же скачивающего файл с сервера волнует только размер и относительно вторично - скорость распаковки. И не нужно рассказывать "в наш век терабайтных стораджей", т.к. файл жмут не для экономии дискового пространства на сервере как правило, а для ускорения его загрузки пользователем по сети. И экономия 5-30% трафика на фактически пустом месте никогда не будет лишней. Если ты считаешь, что ради этого не стоит заморачиваться - будешь доплачивачь за более широкий канал, когда он (рано или поздно) станет узким местом, и за сторадж в том числе.

>rar/flac/ape/jpeg2000-lossless/etc рулят

Ты уже начинаешь фанатеть от патентованой проприетарщины?

frame ★★★
()
Ответ на: комментарий от frame

> Ты не догоняешь: ... > Обрати свой взор на Mozilla FF и подумай, почему под win размер дистрибутива гораздо меньше.

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

Не боись, всё я догоняю (но нужно как следует потроллить, сие тут мне по должности положено, э? =) ), но это, опять же, применимо лишь к безмоглой массе, а основное же воинство линуксоидов прекрасно живёт с 1991 года, пользуясь gz/bz2 и в ус не дуя. Главное - не пользоваться варезом и прочим мега-массивным софтом, вот уж где нужно мега-сжатие при распространении по сети.

А основная масса поделок вендовых, между прочим, до сих пор лежит в zip'ах и cab'ах, кои сами по себе отстойны в плане сжатия. Так что ты описываешь настолько удалённую перспективу, "шопесдец" (ТМ).

> Ты уже начинаешь фанатеть от патентованой проприетарщины?

Ты не в Казахстане живёшь случаем? А то у нас в России так повелось, что патенты на софт сосут причмокивая, хоть это мало кому и известно.

Gharik
()
Ответ на: комментарий от frame

Провёл тест компрессии бинарников (3 файла разного размера).
Каждый бинарный файл сжимал:
1. gzip'ом
2. 7z с дефолными настройками
3. 7z с опцией быстрого сжатия (-mx=1)

При дефолтных настройках 7z:
7z сжимал в 8,5 раз дольше gzip, распаковывал в 4,8 раза дольше gzip.
Разница в размере архивов ~10%

С опцией быстрого сжатия 7z:
7z сжимал в 2,2 раза дольше gzip, распаковывал в 4,7 раза дольше gzip.
Разница в размере архивов ~7%

7z сжимает чуть лучше, при этом время распаковки увеличивается в 5 раз.
Кому это поделие нужно?

grad
()
Ответ на: комментарий от Gharik

>А основная масса поделок вендовых, между прочим, до сих пор лежит в zip'ах и cab'ах, кои сами по себе отстойны в плане сжатия.

zip и cab - это _форматы_ файлов, в zip'е может (согласно спецификации) быть от store(без сжатия) до lzma c ppm и _идентичный_ gz'повскому deflate, в cab'e - LZX (дающий ОЧЕНЬ неплохое сжатие при хорошей скорости упаковки и одновременно самую высокую скорость распаковки среди всех остальных в группе) и модификация deflate - mszip.

frame ★★★
()
Ответ на: комментарий от grad

>7z сжимает чуть лучше

Ещё раз говорю: 7z и gz в разных весовых категориях. У gz словарь максимум 32к(64к в deflate64) и он хорошо заточен работать именно с ним. У 7z он может быть гораздо больше и для примера (что он этого зависит) сжал много скриптов (phpMyAdmin) 7z: 2,266к, gz: 3,934k

>при этом время распаковки увеличивается в 5 раз.

Слабо верится в такие цифры, чтобы время распаковки было более чем в 4 раза больше (если не использовать ppm), чем у gz: у меня никогда не было более чем в 2 раза (без использования BCJ* и ppm).

>Кому это поделие нужно?

Я для себя это решил. И многие люди тоже. В других проектах это тоже решили. Один ты ну и видимо владельцы допотопных машин продолжают повторять себе этот глупый вопрос, как мантру (строя сцену, как в басне с мартышкой и очками). Посмотри на статистику скачиваний и активность на sf.net: проект свою награду заслужил и не одним миллионом. Даже в горячо любимом Gharik'ом WinRAR'е (и многих других, в т.ч. - в линуксовых архивных мордах) появилась поддержка этого формата (и далеко не вчера) - что ясно даёт понять определённые вещи всем, кроме особо мыслящих, - видимо, вершащих чужие судьбы одарённых личностей )))

frame ★★★
()
Ответ на: комментарий от frame

> Посмотри на статистику скачиваний и активность на sf.net: проект свою награду заслужил и не одним миллионом.

Посмотрел. Да, качают миллионы, но посмотри _КТО_ качает!! Виндузятники! Пакетов для Linux _НЕТ_.
А мы, вообще-то, говорим о 7-Zip _в Linux_!

Ну сколько можно повторять, что 7z стал популярен именно в _винде_, как свободная замена проприетарным архиваторам типа WinRAR и WinZip.

А в Linux он нах никому не нужен, потому что в Linux давно есть открытые компрессоры проверенные десятилетиями и на очередную поделку их никто менять не будет!! Смирись с этим.

grad
()
Ответ на: комментарий от grad

Кстати, провёл тест с rzip. Как я говорил, этот компрессор использует
алгоритм компрессии, такой же, как и в bzip2, но оптимизирован для
больших файлов (увеличен размер словаря).

Для теста взял всё содержимое /usr/bin и /usr/sbin, и запихнул в TAR.
Архив получился размером 202117120 байт (193 МБ)
_________________________________________________________________
             | Размер сжатого  | Время компрессии/    |Процент   |
             |  файла (байт)   |  декомпрессии (сек.) |компрессии|           
-------------|-----------------|----------------------|----------|
rzip         |   40899605      |    55,6 / 23,5       |  20,2%   |
-------------|-----------------|----------------------|----------|
7z           |   45230910      |   250,9 / 16,1       |  22,4%   |
-------------|-----------------|----------------------|----------|
7z -mx=1     |   76488352      |    71,5 / 18,6       |  37,8%   |
-----------------------------------------------------------------'

Из теста ясно, что 7z - тормоз и для компрессии больших архивов 
в Linux 7-Zip не нужен.

В дополнение, результаты тестов компрессоров linuxjournal.com:
http://www.linuxjournal.com/articles/lj/0137/8051/8051f2.png

grad
()
Ответ на: комментарий от grad

>Да, качают миллионы, но посмотри _КТО_ качает!! Виндузятники!

НЕлюди прям таки

>Пакетов для Linux _НЕТ_.

В дебиане есть. Пакетами должен заниматься мейнтейнер, а не разработчик. Разработчик должен написать внятную документацию и SDK - всё это есть.

>А мы, вообще-то, говорим о 7-Zip _в Linux_!

мы говорим о lzma в линукс, как компрессоре

>А в Linux он нах никому не нужен, потому что в Linux давно есть открытые компрессоры проверенные десятилетиями и на очередную поделку их никто менять не будет!! Смирись с этим.

продолжай молиться

frame ★★★
()
Ответ на: комментарий от grad

>Из теста ясно, что 7z - тормоз и для компрессии больших архивов в Linux 7-Zip не нужен.

Аминь :)

frame ★★★
()
5 сентября 2007 г.
Ответ на: комментарий от grad

>Просто согласись, что серьёзные люди 7z в Линуксе использовать не будут, по причинам, названным выше по треду. Посмотри что используют дистростоители: для исходников - bzip2, для бинарников - gzip. И ни один не использует 7z.

Используют, вот например: http://sorcerer.aakin.net/download/iso9660/

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.