Проект GNU опубликовал релиз пакета gzip 1.14, включающего утилиты gzip, gunzip, zmore и zcat для сжатия и распаковки данных при помощи алгоритма LZ77. В новом выпуске существенно ускорены операции распаковки. На системах x86_64, поддерживающих процессорные инструкции PCLMUL, прирост производительности достигает 40%, а на системах без поддержки PCLMUL - до 20%...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63050
> As this can cause problems when using scripts, this feature is supported only for --rsyncable, --synchronous, and options like -9 that set the compression level; any other options or operands in GZIP are silently ignored.Ну такое
А ведь правда какая-то дичь, но имя переменной не особо удачное. Ну вот есть ZSTD_CLEVEL для задания пресета сжатия, а есть XZ_OPT и XZ_DEFAULTS, где это сделано нормально.
Написаны на Си, и ничего - эти утилиты просто работают, делают своё дело на миллиардах серверов в режиме 24/7/365. Надёжность - 99.999%!
А что эти утилиты делают на серверах, есть примеры? Что и зачем надо искать grep-ом в сотне тысяч файлов? И почему для этого не использовать подходящий инструмент?
они и есть подходящий инструмент под свои задачи. Можешь лучше, делай.
Так он и просит конкретизировать задачу, а то неясно, может лучше и нельзя уже.
Еще раз: какие задачи они решают "в режиме 24/7/365"?
> Еще раз: какие задачи они решают "в режиме 24/7/365"?ровно те для которых они предназначены :)
А что конкретно - по ссылкам ниже:
https://www.gnu.org/software/grep/manual/grep.html
https://www.gnu.org/software/gzip/manual/gzip.html
https://www.gnu.org/software/diffutils/manual/diffutils.html
https://www.gnu.org/software/coreutils/manual/coreutils.html
>> Еще раз: какие задачи они решают "в режиме 24/7/365"?
> ровно те для которых они предназначены :)
> А что конкретно - по ссылкам ниже:
> https://www.gnu.org/software/grep/manual/grep.htmlЕщё раз исходный вопрос: "...есть примеры?"
Что, например, приходится искать grep-ом "в режиме 24/7/365"?
Вопрос не к теоретиками, а к практикам. Если кому-то действительно приходится, очень любопытно узнать подробности.
> Что, например, приходится искать grep-ом "в режиме 24/7/365"?Вот писал ниже, удалили :)
он делает акцент на "в режиме 24/7/365", ему надо просто сказать, что это означает доступность инструментов. А задачи про которые он спрашивает, надо просто сказать - каждый час каждого дня недели месяца года поищи в сырых логах с помощью греп то-то, потом сырые логи загзипуй и т.д. куча корутилсов на все случаи жизни.
Да, надо признать, что изначально сформулировано неверно. Приложения ничего не делают 24/7/365, просто в̶а̶л̶я̶ю̶т̶с̶я ждут своего звёздного часа.
> Приложения ничего не делаютони же в base system, необходимы всегда, на все случаи жизни. Ну эт как мизинец на левой руке :)
пс: аппендикс
В смысле, что? Ты спрашиваешь, что делают базовые утилиты, "строительные кирпичики" на серверах?)
> В смысле, что? Ты спрашиваешь, что делают базовые утилиты, "строительные кирпичики" на
> серверах?)Да, я спрашиваю, что делают базовые утилиты "в режиме 24/7/365"
Видимо человек ни когда консоли не видел
Может и наоборот, видел и дошёл до того уровня, когда стало ясно, что консоль — последнее средство спасения, когда всё остальное отказало.
В логах админам помогают нужное отыскивать, не?
Не. На локалхостах под кроватью если только. В проде логи на сервере грепать так себе занятие.
Летом под кроватью сервер держать - так себе занятие. И без него жарко.
А вот на серверах предприятий по профилю не IT, админы ещё как в логи заглядывают. Это не про хостинговые компании.
greylog и splunk не ?
> А что эти утилиты делают на серверах, есть примеры? Что и зачем
> надо искать grep-ом в сотне тысяч файлов? И почему для этого
> не использовать подходящий инструмент?Так много вопросов и так мало ответов! Но ничего, скоро пойдешь в школу и там умные педагоги всё расскажут.
Сколько налетело фанатов СПО и сишки! А по существу никто не ответил! А всё потому что юноши оценивают СПО именно по этим хэловордам, и потом кичатся этим! А то что, в СПО нет ни одного нормального видео редактора например, и нет альтернативы simatic step7 и другого очень нужного для ПЛК софта для линукса, и то что много чего ещё нет в СПО, так это они предпочитают не замечать.
Потому что хелловорл или утилитку в 10к строк может написать почти каждый.
А сложный проект, а да еще и требующий понимания предметной области - нет.
Тут нужна команда, тут нужны ресурсы.
Сообщество не может/хочет предоставлять их.
Поэтому почти все крупные СПО проекты это детище корпораций.
Достаточно сравнить линукс и хурд.Вот такая грустная правда((
> Потому что хелловорл или утилитку в 10к строк может написать почти каждыйНу конечно..) Это только на вид эти утилиты простые, а за кажущейся простотой скрывается далеко нетривиальная математическая база.
> Поэтому почти все крупные СПО проекты это детище корпорацийНе правда, существует много больших и сложных безкорпоративных проетов.
И какая нетривиальная математическая база скрывается по подобными утилитами?
Греп умудряется тормозить даже на простых задачах.
И вместо приходится использовать ugrep, написанный на нормальном языке и руками, который обгоняет его в разы.> существует много больших и сложных безкорпоративных проетов.
Примеры в студию.
В защиту своей точки зрения:
linux kernel, blender, firefox, chrome, ASOP, X11 и вейланд.
> И вместо приходится использовать ugrep, написанный на нормальном языкеC++ то? :) Ну лана ... пусть будет :)
А теперь следи за руками: grep на любом хосте гарантированно _будет_...
А твой ugrep, хоть и не плох! - но надо озаботится его наличием в нужное время в нужном месте САМОМУ :( ...
Если ты понял о чём я - ТЫ ПОНЯЛ! :) А нет ... ну значит ты - на яббле %-))))> и руками, который обгоняет его в разы.
И чо? ... там у них на хомяке есть строчка:
>>>See also: gnu grep, bsd grep, git grep, pcre grep, agrep, ack, ag, rg, siftЯ вот лично, кроме sift - всё попробовал, даже ripgrep ... лично мне больше всего зашёл ag (тоже зааза - плюсовый ;) ... но то - на моем компе, где я работу работаю и не-работу не-работаю ;-)
А ещё хочу отметить что тему "grep-но-луДше" начал ack 20 лет назад ещё и оно вообще на Perl-е :)
Ну и да: на вкус и цвет - все фломастеры разные :)
> Не правда, существует много больших и сложных безкорпоративных проетов.Это интересно какие?
Вот чтобы прям и большие, и сложные! Чтобы сразу было видно преимущество базара васянов над базаром корпов. Ну и неплохо было бы, чтобы списочек был не на пару пунктов, а тоже большой))Осилишь такой запрос?
Выбирай ПЛК, которые можно программировать на языках общего назначения и будет тебе счастье. А поскольку, в их недрах, чаще всего, используются ARM-микроконтроллеры, то чем скомпилировать для них, легко найдёшь в опенсорсе.
> И почему для этого не использовать подходящий инструмент?у вас КМП в грепе и в "подходящем инструменте" отличается?
>> И почему для этого не использовать подходящий инструмент?
> у вас КМП в грепе и в "подходящем инструменте" отличается?У нас есть понимание, сколько времени занимает чтение с накопителя, как последовательное, так и при случайном доступе.
:)))) это вопрос?
Это утверждение. Чтение несоизмеримо дольше поиска в ОЗУ. Что бы "в сотне тысяч файлов" начал играть заметную роль КМП, данные сначала надо "закешировать".
> данные сначала надо "закешировать"Ну этим к примеру занимается ФС при чтении файла, и вообще если у меня "в сотне тысяч файлов" надо что-либо искать, разве не последовательно файл за файлом я буду читать и искать в нем? Есть польза от кеша?
пс: а начинать надо было с того, что никакого КМП в том же самом грепе нету :Р, но это условно, вопрос в другом был, чем же условный КМП должен был отличаться в грепе и в "подходящем инструменте".
>> данные сначала надо "закешировать"
> Ну этим к примеру занимается ФС при чтении файла,Нет, ФС занимается кешированием в прямом смысле -- без кавычек -- то есть не очищает лишний раз ОЗУ после чтения. Оно ускоряет, когда файл читать надо несколько раз, то есть не в данном сценарии.
> и вообще если
> у меня "в сотне тысяч файлов" надо что-либо искать, разве не
> последовательно файл за файлом я буду читать и искать в нем?
> Есть польза от кеша?Понятия не имею, что будет читать кто-то. Если это частая операция, я не буду читать "последовательно" 100 тысяч файлов - физически они расположены как попало. Быстрее читать последовательно сырые (в обход ФС) блоки, а в случае нахождения сопоставлять сектор с файлом. Ну или взять инструмент, где это уже сделано до нас.
> пс: а начинать надо было с того, что никакого КМП в том
> же самом грепе нету :Р, но это условно, вопрос в другом
> был, чем же условный КМП должен был отличаться в грепе и
> в "подходящем инструменте".Если важна скорость, то начинать надо с самой медленной операции, что я и сделал.
> Быстрее читать последовательно сырые (в обход ФС) блокиА как мы будет отличать блоки? Выделены они под файл или нет без информации из ФС? У меня в ФС лежат два файла размером в мегабайт, а блочное устройство размером в терабайт, я должен по всему терабайту пройтись? Ваш случай быстроты будет в том случае, когда реально необходимо искать по всем блокам устройства (заполненный диск - 100 тысяч файлов) с сильной фрагментацией ФС.
> Если важна скорость, то начинать надо с самой медленной операции, что я и сделал.
Асимптотическая сложность алгоритма поиска от этого же не изменится.
>> Быстрее читать последовательно сырые (в обход ФС) блоки
> А как мы будет отличать блоки? Выделены они под файл или нет
> без информации из ФС?Я никак не буду различать, пока вопрос не дойдёт до дела. Если дойдёт, буду писать "различатель".
> У меня в ФС лежат два файла
> размером в мегабайт, а блочное устройство размером в терабайт, я должен
> по всему терабайту пройтись?Я должен заметить, что происходит попытка подменить условие "задачи" (100 тысяч файлов).
> Ваш случай быстроты будет в том случае,
> когда реально необходимо искать по всем блокам устройства (заполненный диск -
> 100 тысяч файлов) с сильной фрагментацией ФС.Мой случай здесь и сейчас - это любопытство, что там за работа такая у grep 24/7. По всему похоже, что гипотетическая.
>> Если важна скорость, то начинать надо с самой медленной операции, что я и сделал.
> Асимптотическая сложность алгоритма поиска от этого же не изменится.Ну да. Искать-то нечего.
> Если дойдёт, буду писать "различатель"."а в случае нахождения сопоставлять сектор с файлом."
> Я должен заметить, что происходит попытка подменить условие "задачи" (100 тысяч файлов).
ничего подобного, 100к файлов по мегабайту - 100 гигабайта, размер блочного устройства 1 терабайт и никакой фрагментации ФС. Повторяю, я должен пройтись по всему терабайту за места 100 гигабайтов?
> По всему похоже, что гипотетическая.
Поэтому они в базовой системе?
>> Если дойдёт, буду писать "различатель".
> "а в случае нахождения сопоставлять сектор с файлом."И? Что удивляет? Ещё раз: я не вижу смысла расписывать подробнее, поскольку задача надумана. Так что не надо за меня додумывать и приписывать мне неспособность пропустить незанятое место.
>> Я должен заметить, что происходит попытка подменить условие "задачи" (100 тысяч файлов).
> ничего подобного, 100к файлов по мегабайту - 100 гигабайта, размер блочного устройства
> 1 терабайт и никакой фрагментации ФС. Повторяю, я должен пройтись по
> всему терабайту за места 100 гигабайтов?Если оно прописано в каком-то договоре, значит должен. Я должен заметить, что мне о том договоре ничего не известно, стало быть и вопрос ко мне неуместен.
>> По всему похоже, что гипотетическая.
> Поэтому они в базовой системе?Поэтому произошла подмена "лежат без дела" на "работают "24/7".
hacmp состоит из ksh, grep, cat и echo чуть более, чем на половину, если что.
А хорошая программа наполовину состоит из комментариев и сообщений сообщений об ошибках.
Дядя, ты спросил, где эти тулзы крутятся 24/7Я ответил. Таким примером, штоб понятнее было.
Хочешь повилять тухесом -твое дело, никто за язык не тянет.
Ну я и понял, что hacmp - хорошая программа, много пишет сообщений посредством echo. Не очень понял, 24/7 она занята этим, или чем-то другим?
> Ну я и понял, что hacmp - хорошая программа, много пишет сообщений
> посредством echo. Не очень понял, 24/7 она занята этим, или чем-то
> другим?wiki://hacmp
>> Ну я и понял, что hacmp - хорошая программа, много пишет сообщений
>> посредством echo. Не очень понял, 24/7 она занята этим, или чем-то
>> другим?
> wiki://hacmpman 3 printf
GFL подключиться printf к листенеру на порт 1521 и распарсить его выхлоп.
Ты не прав! Там надежность OVER 9000!!!!Была бы.
Если бы их писали на не кривыми ногами на ЯП из прошлого тысячелетия.Уязвимость в утилите GNU split, приводящая к переполнению буфер
opennet.ru/opennews/art.shtml?num=60490Уязвимость в утилите GNU sort
opennet.ru/opennews/art.shtml?num=42235Опасные уязвимости в утилитах beep и patch
opennet.ru/opennews/art.shtml?num=48427
Эти уязвимости как-то проявились, к каким-либо последствиям привели? Нет. Поэтому это просто обнаруженные ошибки, которые есть в любой программе на любом языке. Нашли - исправили, делов - на копейку, а шуму - на миллион!
> Эти уязвимости как-то проявились, к каким-либо последствиям привели?О, надеюсь твой водитель, проежая на красный свет, или врач отвечают точно так же "ну в же не умерли"))?
Вот тебе еще "Написаны на Си, и ничего - эти утилиты просто работают"
Критическая уязвимость в sudo, позволяющая получить привилегии root
opennet.ru/opennews/art.shtml?num=60490
Уязвимость проявляется с июля 2011 года и вызвана переполнением буфера.Десять лет дырявости, однако.
> проежая на красный светПроезд на красный свет - это грубое нарушение правил, а эти утилиты никаких правил не нарушали, так что аналогия неверна. Скорее так: в двигателе автомобиля обнаружен дефект, который в очень экзотических условиях и при особом стечении обстоятельств может привести к тому, что мотор заглохнет. О дефекте сообщено инженерам, они внесли изменения в конструкцию и двигатель больше не глохнет.
> Критическая уязвимость в sudosudo вообще не нужно, не знаю, кто им пользуется.
> sudo вообще не нужно, не знаю, кто им пользуется.А список того, что не нужно и чем никто не пользуется можно где-то посмотреть? Или это снова фантазии админа высоконагруженного локалхоста с LA 0.0?
> Ты не прав! Там надежность OVER 9000!!!!
> Была бы. Если бы их писали на не кривыми ногами на ЯП из прошлого тысячелетия.межушная ржавчина детектед(С)
Ваша безопасТность - нет программы - нет уязвимости. раст-вЭй(С)
PS: Ваши пишут замену кор-утилям ... но даже сами _это_ не пользуют :)))
:-р
> Опасные уязвимости в утилитах beep и patchтоварищ, вы забыли про опасную уязвимость в утилите saltshaker
Не только Си, этот ряд можно продолжать - GNU, Столлман и копилефт вот за что мы должны держаться, и на что молиться.В ядре никакого Раста быть не должно, и точка.
> GNU, Столлман и копилефт вот за что мы должны держатьсяА за какую часть Столлмана ты хочешь держаться?
Кстати вопрос - когда он помрет (а все люди смертные), вы будете его мощи возить по городам, целовать, окроплять, читать Манифест и тк.?
Мне просто интересно насколько далеко зайдет ваша секта.> В ядре никакого Раста быть не должно, и точка.
Поздно, аноним, уже поздно.
Сишка уже проиграла с++ (да, именно плюсам, а не расту, и произошло это лет 10-15 назад).
Популярность GNU упала очень сильно.
За его душу.Зачем какие-то мощи? Нужно преемника ему искать. Жаль, что он об этом сам не позаботился.
> За его душуБог мёртв. Души нет.
> Зачем какие-то мощи?
Ну хз, вот у некоторых такое практикуется.
Только представьте - в ваше город приехал палец левой руки самого Столлмана!
Вот его череп в молодости. А это его череп в старости)))
И кто пойдёт преклоняться этому? Разве что, старушки, которое готовы целовать что угодно, что объявлено святым? Айтишники точно не пойдут.
> когда он помрет (а все люди смертные)Столлман — бог опенсорса, он бессмертен!
> эти утилиты просто работают, делают своё дело на миллиардах серверов в режиме 24/7/365. Надёжность - 99.999%!Сервера в режиме 24/7/365 работают сами по себе, а эти утилиты работают раз в месяц когда туда зачем-то входит администратор
Они в скриптах работают и по cron'у. Например, gzip жмёт суточные логи.
Да по exec[velxКЛМН]( ..bin/proga ...) - тоже.
Но откуда Ынженерам опеннета об этом знать? Ты их ещё спроси зачем контуперу байты? :)))
То есть exec() выполнятся 24/7/365? А что мешает исключить непрерывное порождение процессов?
Ну и как ты предлагаешь мне обЪяснить "Основы: как работает контупер для самых маленьких." в одном посте да ещё походу - продавцу помидоров?!?!Нееее мужчино - я пас! :-р
Что надо объяснять? exec() довольно много всего делает, всё это занимает время. Если это необходимо часто, значит следует исключить накладные расходы, встроить нужную функциональность в вызывающую программу, либо держать процесс постоянно в памяти и общаться с ним через разделяемую память или сокет, например.
>встроить нужную функциональность в вызывающую программуКто позволит программе, от обычного пользователя, создавать отдельное адресное пространство для друго процесса своими руками, не прибегая к помощи системных вызовов? А если ненужно отдельное - прямо в своём, то просто воспользоваться многопоточностью.
>>встроить нужную функциональность в вызывающую программу
> Кто позволит программе, от обычного пользователя, создавать отдельное адресное пространство
> для друго процесса своими рукамиНаписавший своими руками exec()
> не прибегая к помощи системных вызовов?
А это откуда взялось? Создание АП и прочего и есть накладные расходы, требующие исключения.
> А если ненужно отдельное - прямо в своём, то просто воспользоваться
> многопоточностью.Если в исходном варианте после запуска процесса ждёт завершения для получения результата, то поток кажется лишним.
>>встроить нужную функциональность в вызывающую программу
> Кто позволит программе, от обычного пользователя, создавать отдельное адресное пространство
> для друго процесса своими руками, не прибегая к помощи системных вызовов?
> А если ненужно отдельное - прямо в своём, то просто воспользоваться
> многопоточностью.coreutils весь по сути короткие обёртки над системными вызовами, и не нужно ничего встраивать
grep/diffutils сложнее, однако оба реализованы в виде библиотек, которые при этом зачастую более эффективны
gzip - zlib
И никакие exec не нужны
Делать shell-out для вызова coreutils вместо того чтобы просто дёргать libc? Мсье знает толк в извращениях
У нормальных людей локальным сбором логов занимается journald, а не непонятные скрипты по крону
О, да, очень приятны, а гавное, понятны человеку бинарные логи.
> О, да, очень приятны, а гавное, понятны человеку бинарные логи.Есть программа для чтения этих бинарных логов, которая позволяет задавать нормальные фильтры
Удачи grepом выбирать временные промежутки, особенно в уже ротировавшихся логах (Которые, как уже было сказано выше, при этом сжаты).
> особенно в уже ротировавшихся логах (Которые, как уже было сказано выше, при этом сжаты).Мсье не подозревает о существовании утилиты zcat ?
>> особенно в уже ротировавшихся логах (Которые, как уже было сказано выше, при этом сжаты).
> Мсье не подозревает о существовании утилиты zcat ?Которая cat + gzip -d
Факт в том что они такие же бинарные как и от journald, journalctl ты тоже можешь как zcat использовать, но при этом journalctl умеет больше фич, включая нормальные фильтры по временным интервалам.
>99.999%1 процент - это сотая часть чего-либо. Не тысяная и не десятитысячная. Предел дробления 100 частей, не более. Не бывает половины процента или треть из одного процента. Так-что выбирай, или 99%, или 100%.
Процент - это мнемоническая запись часто используемой в быту дроби 1/100. Десятая доля процента это 1/100/10 = 1/1000, сотая - 1/10000 и т.д. Так что всё делится, всё бывает, фиговый из тебя математик.
У процента (%) нет дробей. У дробей есть дроби, мнемоник ты наш. Всё делится, но не один процент.
Нобелевку по математике! Получишь у Пушкина))
> Процент - это мнемоническая запись часто используемой в быту дроби 1/100. Десятая
> доля процента это 1/100/10 = 1/1000, сотая - 1/10000 и т.д.
> Так что всё делится, всё бывает, фиговый из тебя математик.Очень хорошо, что есть способность к арифметике, в отличие от того "Математика".
Теперь считаем:
"на миллиардах серверов в режиме 24/7/365. Надёжность - 99.999%!"
99,999% * 1 000 000 000
;)
Это с каого перепуга проценты стали измерять только целыми числами, горе-математик?
Проценты "не измеряют" целыми числами. 1% - это просто сотая часть чего либо (целостного). Например, сейчас твой мозк работает на 1%. :)
А промилле это что?
> 1 процент - это сотая часть чего-либо. Не тысяная и не десятитысячная. Предел дробления 100 частей, не более. Не бывает половины процента или треть из одного процента. Так-что выбирай, или 99%, или 100%.https://medicalgenomics.ru/blog/ustanovlenie-rodstva/chto-za.../
Вероятность сходства пишут 99,9% Потому как не бывает абсолютно идентичной ДНК, как в примере с ДНК.
Чувак, я знаю ещё круче примеры. Например у экономистов читал "прибыли" в 200%, 900% :)P.S.
А вы знаете, что есть такое ошибочное определение энергетических потребностей человека, "килокалория" называется. Придумано в XIX века, и до сих пор в научных журналах и книгах публикуется. Круто да?
> читал "прибыли" в 200%, 900%Значит прирост.
> Предел дробления 100 частей, не болееЧуров смотрит на тебя, как на двоечника.
>Написаны на Си
>и ничего - эти утилиты просто работают, делают своё дело на миллиардах серверов в режиме 24/7/365. Надёжность - 99.999%!Хотел было сначала написать что тонко, но почитал другие твои комментарии в ветке и понял что умысла на тонкость не было, просто бессознательное вышло в такой по истине гениальной форме.
Отличненько, осенью после выхода нового релиза LFS, посмотрим. Пока не до этого, текущий релиз нужно допилить. Не смотря на то какие бы тарифные и прочие воины не велись.
Grep есть у меня в turbo-си под дос. В турбо паскаль вроде тоже был?
Да, в BP 7.0 был.
В 42-ю Федору, с обновлениями, принесут или придётся 43-ю ждать?
> gzip, gunzip, zmore и zcat для сжатия и распаковки данных при помощи алгоритма LZ77.Разве они используют чистый LZ77? А не deflate Фила Каца, который LZ77+Huffman?