LINUX.ORG.RU

The Community Choice Awards 2007


0

0

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

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

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

Ответ на: комментарий от 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
()
Ответ на: комментарий от anonymous

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

вы написали не правду.

wget http://rarlab.com/rar/rarlinux-3.7.0.tar.gz
tar -zxf rarlinux-3.7.0.tar.gz
less rar/technote.txt

и читайте техническое описание формата .rar хоть до посинения, 
technote.txt присутствует во всех дистрибутивах rar испокон веков

если там что-то не понятно - есть ещё общедоступный unrarsrc
wget http://www.rarlab.com/rar/unrarsrc-3.7.6.tar.gz
"The source code of UnRAR utility is freeware"

Eshkin_kot ★★
()
Ответ на: комментарий от 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
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.