gzip 1.7

ЕМНИП эту функциональность разрабатывали чуваки из Parallels для OpenVZ

Если ты хоть как то знаком с этой фичей, задам один вопрос

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

Но чем это отличается от двух сжатых файлов, один из которых это прежний архив, второй содержит новые файлы ?

Я с опцией не знаком, затрудняюсь сказать. Возможно порядок файлов, подаваемых компрессору гарантируется при использовании опции --rsyncable, а без неё - нет.

ототож там там такого ***дства нет)

Тем, что получаешь 1 файл и файлы в архиве лежат правильно, очевидно. Если досжимать дополнительные файлы, то они приклеятся отдельно и для реконструкции исходной структуры директории придётся их при распаковке руками докопировать.

Наличие комментария Мужика - знак качества новости.

Я просто не в курсе, что там в маке по дефолту.

Очень своеобразная у Вас логика и математика. В одном сообщении умудриться сравнить сжатие сферического, судя по всему русскоязычного, текста в UTF-8 с koi8-r и с упоением рассказать об 40 Гб англоязычного «IRC bookz».

Вы там определитесь умный Вы или красивый. И зачем на 29-гиговую флешку столько книг? Вы сколько ЭТО читать будете, если, судя по lib.ru, вся «Война и Мир» Толстого размером около 3 мб?

И почему именно koi8-r, а не cp866 или windows-1251?

почему именно koi8-r

Потому, что Unix. Все true Unix'оиды юзают локаль KOI8-R. Так писали в документации когда я начинал юзать Linux.

сферического

Нет. Я конвертировал реальный текст из KOI8-R в UTF-8, сжимал и то и другое, а потом сравнивал.

Вы сколько ЭТО читать будете

А кто сказал, что под рукой нужно держать исключительно те тексты, которые в ближайшее время будут прочитаны от корки до корки? Во-первых, все ли читали абсолютно все бумажные книги, которые есть у них в шкафах? Даже на этом примере это абсурд. Многие бумажные книги приобретались людьми по случаю на всякий случай, но последний так никогда и не наступал. в наше время многообразие книг в цифровом виде создаёт огромную проблему отфильтровывания тех книг, которые таки будут прочитаны. Можно, конечно, качать отдельные книги по одной, но не обязательно. Можно скачивать коллекции, а уже потом в них находить нужные. Во-вторых, с текстами можно работать самым разным образом. Даже просто grep'ать. Зачем? А это уже дело того, кто grep'ает.

Все true Unix'оиды юзают локаль KOI8-R
Даже просто grep'ать. Зачем? А это уже дело того, кто grep'ает.

Я тебе просто дам ссылки: https://fr.wikipedia.org/wiki/Alphabet_français и http://az.lib.ru/t/tolstoj_lew_nikolaewich/text_0040.shtml

Я уже в 2048-й раз пишу на ЛОРе: у меня нет повседневной необходимости писать на французском языке. Мне уже предлагали изучать языки с иероглифами, но один вопрос всё равно остаётся открытым: почему не сразу атлантийский? На всё подряд тысяч жизней не хватит. Время нужно использовать рационально, а потому все действия должны быть реакционными, а не так что «это модно и молодёжно, а потому - вперёд!». Стар я уже для этих ваших «модно и молодёжно».

http://az.lib.ru/t/tolstoj_lew_nikolaewich/text_0040.shtml

И? Если это к размеру произведения, то если тратить время только на чтение, то я за день не менее чем 600 Кб текста вполне прочитаю. А если это к тому, что в том произведении есть вставки на французском языке, то кто их читает? То, что эти вставки своей нечитаемостью только мешают чтению, является одной из основных причин почему многие люди отрицательно к нему относятся. И, да, к творчеству Толстого я отношусь отрицательно не только по этой причине. И к творчеству Лермонтова тоже. У меня своё видение художественных текстов, я сам их тоже пишу. Так что, ваша классика мне не указ. Как и ваш модерн тоже. Что хочу - то и делаю.

опция --rsyncable для оптимального сжатия файлов при синхронизации, архив остается прежним за исключением новых данных, что позволяет не передавать архив целиком при синхронизации;

gzip --version
gzip 1.6

PAGER=cat man gzip | grep rsyncable
gzip [ -acdfhklLnNrtvV19 ] [--rsyncable] [-S suffix] [ name ... ]
--rsyncable

в зеркале OpenBSD для пакетов это rsyncable уже давным-давно используется

Все true Unix'оиды юзают локаль KOI8-R. Так писали в документации когда я начинал юзать Linux.

Ну да, прямо так и писали в документации: если ты true - используй koi8-r.
Все документации по юниксам такие: если true - используй csh вместо bash (и так далее). На самом деле я помню зачем нужен был убогий костыль в виде koi8-r и жаль что для Вас он стал религией.

Я конвертировал реальный текст из KOI8-R в UTF-8, сжимал и то и другое, а потом сравнивал.

UTF-8 - это кодировка с переменным количеством байт на символ. На выходе после измерений кривая должна получиться с зависимостью от количества русских букв. Там не будет константы.

Во-вторых, с текстами можно работать самым разным образом. Даже просто grep'ать. Зачем? А это уже дело того, кто grep'ает.

То есть Вы тоже не знаете зачем Вам столько книжек на 29-гб флешке?
Кстати почему такой странный размер у нее?

А вот мне всегда CP866 нравилась, потому что железо несло в себе отпечатки доса повсюду и казалось глупым пользоваться кривой кодировкой только потому что «мы не такие, как все». Это помимо того, что она совместима с ASCII. И вообще, мне ни разу не попадались файлы KOI8-R, зато куча в CP866.

Нет, набором костылей является именно юникод. Использование мной KOI8-R - вопрос именно удобства. Если бы мне было удобнее я бы спокойно использовал UTF-8.

Там не будет константы.

Я этого и не утверждал. Я и пишу: «в среднем».

То есть Вы тоже не знаете зачем Вам столько книжек на 29-гб флешке?

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

Кстати почему такой странный размер у нее?

Потому, что, как писали в советских учебниках, 1 Гб == 1024 Мб, 1 Мб == 1024 Кб, 1 Кб == 1024 б. Но, современные маркетологи про это не знают. Вот после форматирования носителя с маркетологическим объёмом 32 Гб «df -h» и показывает 29 Гб по факту.

И вообще, мне ни разу не попадались файлы KOI8-R, зато куча в CP866.

... в .ha архиве.

На самом деле koi8-r использовали не из-за хипстерского задора и желания быть Ъ. Многие программы (sendmail например) тогда работали исключительно с 7-ми битной кодировкой (ASCII7) и получая 8-ми битные символы просто не трогали последний бит. Поэтому и нужен был механизм, позволяющий оставить текст читаемым даже при такой трансформации. Им и стал koi8. Убирая последний бит получали более-менее читаемую латиницу, но при этом пришлось пожертвовать сортировкой по алфавиту и частью псевдографики.

А самое забавное что даже в 2005-ом году (я тогда работал в достаточно крупном провайдере) попадались клиенты, представители больших организаций, которые писали исключительно латиницей, аргументируя это тем, что они привыкли так писать со времен UUCP. И у меня был коллега, который считал такое поведение элитарностью и тоже втихаря так писал свои письма. Но в итоге удалось объяснить, что он выставляет себя полным придурком, а не легендой интернета «тех времен».
И упертых клиентов тоже, кстати, научили пользоваться русским алфавитом, но это уже другая история.

Вот после форматирования носителя

Зачем же форматировать носитель? В тех же книжках для Ъ-юниксоидов сказано как пользоваться внешними носителями - записывать tar-ом через блочное устройство. При использовании файловых систем куча места уходит впустую на служебную информацию. А тут глядишь и еще пол-года «IRC bookz» поместится. И grep чудесно будет работать с tar архивом если добавить в ~/.bashrc

targrep () {
    for i in $(tar -tzf "$1"); do
        results=$(tar -Oxzf "$1" "$i" | grep --label="$i" -H "$2")
        echo "$results"
    done
}

targrep /dev/$flash $pattern

О, спасибо за полезную информацию.