почему исходный код не пакуют в 7zip?

потому что процесс сжатия и распаковки занимает на много больше времени

скорость это раз.

7z не так распространен -- два

а не распространен из-за огромной сложности:

# du -c /usr/lib/libbz2.so.1.0 /usr/bin/bzip2 | tail -n1
86 total
# du -c /usr/local/bin/7za | tail -n1
1024 total

Соответственно вероятность бага в 7z выше.

А 10% разница в размере архива погоды не делает

Ну и главная причина: он под всеми архитектурами работает?

Главная причина в том, что он не поддерживает права доступа!

Ну и опять гон какой-то нездравый... Это tar.7z-то не поддерживает права доступа? А чем оно отличается от tar.gz или tar.bz2 в этом смысле, интересно?

Не разглядел, что tar.7z, думал, что просто 7z.

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

7z не потоковый, AFAIR.

Ну это-то для исходников не принципиально. Хотя в принципе и налагает некоторые ограничения.

Как по мне, хуже, что он пытается брать на себя несвойственные компрессору функции tar'а (как это делает и пришедший с винды rar), вместо того чтобы ограничиться собственно компрессией.

Опционально потоковый, но сделано через "опции", т.е. ИМХО "через жопу".

Это как? Перечитал man, вроде не вижу ничего такого.

-si Read data from StdIn

(p7zip Version 4.14.01)

> Как по мне, хуже, что он пытается брать на себя несвойственные компрессору функции tar'а (как это делает и пришедший с винды rar), вместо того чтобы ограничиться собственно компрессией.

А я о чем?

упаковщик должен сжимать входящий поток. tar, файл, HTTP stream, whatever. Семантика файловой системы ему должна быть абсолютно ортогональна.

Есть rzip. Он не строит из себя замену tar'у, но и поток (например stdin) сжимать не умеет: ему нужен весь входной файл до конца, чтобы начать работать. В этом его принципиальное отличие от gzip/bzip2, которые входной файл жмут блоками по несколько килобайт (зависит от настроек). Обычно под способностью сжать поток именно это имеется в виду.

Ну там выше написали: -si/-so (std in/out).

Подтверждаешь? :)

под потоковостью разное можно подразумевать.. sort тоже потоковый, но ему нужно засосать весь поток..

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

> под потоковостью разное можно подразумевать..

Можно... Но не нужно. :)

> sort тоже потоковый, но ему нужно засосать весь поток..

Это псевдопотоковость. Ну хочешь я тебе математически строгое определение сформулирую? Понятно, что можно было бы и к тому же rzip прифигачить сохранение входного потока во временный файл или память, но это только введёт пользователя в заблуждение. sort - дело другое, вне конвейеров он малополезен. Но вообще это конечно же тоже утилита, не способная работать с потоком, в этом смысле.

Я просто хочу сказать, что если определять потоковость как формальную способность читать stdin, то это не очень полезная и легко (в несколько строчек на C) изменяемая характеристика утилиты. В то время как есть и более глубинное различие, тоже нуждающееся в термине.

> в контексте компрессии можно хотеть потоковость в форме, чтобы можно было сделать декомпрессию с промежуточных позиций.

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

> Ну хочешь я тебе математически строгое определение сформулирую?

> потоковость в моём смысле (отсутствие необходимости в буфере заранее неизвестного размера и последовательная выдача результата по мере чтения, могу если надо сформулировать чётче)

ну я боюсь что в таком смысле останутся только cat и tr:)

awk и sed интуитивно потоковы. Но во первых не для любой программы (ну типа если
в awk использовать массивы, то бумс..). И также размеры строк могут быть
большими. Конечно в позиксе есть ограничение на размеры строк, но я подозреваю что
гнутые утилиты гордятся тем что они могут обрабатывать произвольно длинные строки:)

$ wc -l /tmp/sss
1 /tmp/sss
$ wc -c /tmp/sss
816010 /tmp/sss
$ cat /tmp/sss | gawk '{ print $NF }'
sdgfsg


А вообще, потоковость это наверно одно из главных отличий bzip2 от 7z. bzip2
ограничивается мегабайтным lookahead'ом. Если бы 7zip им ограничивался то
продемонстрированная 10% разница испарилась бы:)

> Подтверждаешь? :)

Конечно. Маны ниасиливаем? ;)

> то продемонстрированная 10% разница испарилась бы:)

Текстовики, между прочим, bzip2 жмёт гораздо лучше rar'а 7z'а вместе взятых, несмотря на все понты раровской гуёвины. Ибо Юникс-вей. А что у нас в текстовиках - все сорцы... Отсюда следствие - бинарные дистры суть зло и вообще любые бинарники от проклятого Билла.