Распаковываю их программой bunzip2, никогда ничего не усекалось.

Пётр.

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

А у меня есть такая программа

Пётр.

ну и что? возможно (надо сырцы глянуть), эта версия применяется например в инсталляторах для лёгкости - ведь инсталлятор ничего не пакует, а только запаковывает. Или ещё где-нибудь. (Кстати, замете, она у вас в /bin - там лежит необходимый МИНИМУМ для старта системы. А зачем при старте что-то паковать? А весь остальной софт лежит в /usr, который может быть и удалённо. Кроме того, не забывайте про встроенные системы)

зачем?
ЗЫЖ

PACKAGE NAME:     bzip2-1.0.6-i486-1_slack13.1
...
lib/
lib/libbz2.so.1.0.6
bin/
bin/bzip2
bin/bzip2recover
usr/
usr/lib/
usr/lib/libbz2.a
...
usr/bin/
usr/bin/bzdiff
usr/bin/bzgrep
usr/bin/bzmore
...

многопоточность - не нужно. (С) Патрег

Ой-ли? Пользовались. Только вы об этом не знаете. В Linux одна большая задача решается десятками, а иногда тысячами мелких утилиток.

Что до многозадачности... Понимаете, bzip2 безнадёжно устарел, и его держат исключительно ради совместимости. xz даёт намного более лучшие результаты (алгоритм LZMA2). Эффективно распараллелить сжатие почему-то не получается, ИМХО это связанно с особенностями архитектуры x86 (любопытный, кстати, случай - идеально распараллеливамый алгоритм с т.з. математики не распаралеливается на практике. Видимо это связано с тем, что архиваторы работают с огромными массивами памяти, но у нас нет "двух-памятных" компьютеров (двойная скорость - не то). Мало того, у нас даже двухпроцессорных нету - потому как ядро CPU это вовсе не процессор). Потому, в архивировании и распаковке данных многопоточность - не нужна.
(я не говорил о специальных случаях! например про MPEG).

zet_lab, кстати, распаковка "не нужна", в том смысле, что она часто выполняется сама по себе. Например можно сохранить web страничку с картинками и прочим, потом сжать, а потом просматривать этот архив обычным браузером как обычный каталог. Воспринимайте архив как обычный каталог

(хотя почему у нас глючит ark - без понятия - по идее, можно прямо мышкой перетаскивать файлы из ark'а на ваш сайт, но у меня так не получается - Application: Ark (ark), signal: Segmentation fault )

Для выяснения проблем запускайте ark в консоли.

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

Я имел в виду, что руками его не запускал, а log-файлы сжимаются gzip'ом.
Вот о существовании xz действительно не знал, хотя он у меня есть.
Я не силён в терминологии, но аппаратное ядро считаю процессором, т.к. в нём есть всё,
чтобы так называться, и при работе кэш 3-го уровня у каждого ядра свой. Они могут
изменять свой размер, но всё же область памяти у каждого ядра своя.

Пётр.

Всё-таки аппарато ядро - это отдельный процессор, в нём же есть всё,
что есть в отдельном процессоре.
Насчёт работы с памятью и использования кэша 3-го уровня - точно не знаю,
но, насколько мне запомнилось, одно ядро не может захватить весь кэш
процессора, что-то всегда остаётся и другим ядрам, т.е. они работают всё же
каждое со своим кэшем.
Вот шина памяти для обращения к ОЗУ действительно одна, если одно ядро
инетенсивно обменивается с памятью, то другим приходится ждать, но от
этого они не перестают же быть процессорами.

Пётр.

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

Пётр.