ugrep 7.1 и 7.1.1

Для более эффективного поиска в больших файловых системах на медленных носителях,

больших файловых системах

Честно говоря, не особо понимаю, как размер ФС на это вообще влияет, да и в оригинале этого не вижу.

Сам не тестил случаем, как оно?

да и в оригинале этого не вижу.

Please note that indexing is effective for large file systems on slower storage media or when searching many zip and tarball archives. Indexing won’t speed up regular file searching on fast nVME SSDs, for example.

Сам не тестил случаем, как оно?

Тестировал на HDD/Btrfs+zstd, хорошо. :)

Indexing won’t speed up regular file searching on fast nVME SSDs, for example.

А почему?

Понятия не имею, у меня нет SSD.

как размер ФС на это вообще влияет

Фраза «большой размер ФС» как-бы подразумевает «100ТБ старый и поганый составной массив на убогих дисках, полностью засраный невменяемым количеством мелких файлов». Без индекса тут вообще никак.

Интересно, сколько бы собирался индекс на таком диске: гогол лет, или гоголплекс, хммм?)

Я так понимаю, над емаксом больше не смеёмся?

написанной на языке C++

Фатальный недостаток.

Хорошая вещь

Хорошая тулзень, когда нужно быстренько что-то глянуть в логе, который на пару десятков гигов. Под Фряшкой можно его сбилдить с портов добавив поддержку AVX и SSE2.

7.1 и 7.1.1

Странное версионирование.

Нет. Странное, когда из четырёх чисел. :)

Уже понял. Просто выпустили новее версию с фиксами. Почему-то подумал сначала, что это две ветки. Ты так не делай больше, в чем смысл? :)

в чем смысл?

Список солидней. :)

Для более эффективного поиска в больших файловых системах на медленных носителях,

больших файловых системах

Честно говоря, не особо понимаю, как размер ФС на это вообще влияет

На HDD, чем ближе данные находятся к концу диска, тем медленнее они пишутся/читаются.

И не надо сейчас про NVMe и прочее. Речь не только о личном ноутбуке.

Странное, когда из четырёх чисел

Да, не особо понятно:

$ [version]::new('7.5.0.1')

Major  Minor  Build  Revision
-----  -----  -----  --------
7      5      0      1

На HDD, чем ближе данные находятся к концу диска, тем медленнее они пишутся/читаются.

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

когда из четырёх чисел

Арч: 0.8.0-2
Дебиан: 6.11.10-1

Почему? Вполне понятно. Как уже написали выше: мажор, минор, билд, ревизия.

А бывает еще так:

alsa-plugins 1:1.2.12-4

Вот это я уже не совсем догоняю…

Googling files

занятно…

Для консольной утилиты пофиг.

Понятия не имею, у меня нет SSD.

Это такой скуф’ский прикол? Давай я тебе подкину SSD’ху.
Может ты там на CD-ROM’е диски ещё жгёшь…?

Зачем ты оскорбляешь растоманов?

Проверил поиск простой подстроки в проекте. Файлы (~3,500) были подсунуты в аргументы команды. Медленнее всего сработала входящая в состав macOS реализация grep. Затем примерно одинаково сработали GNU grep и p9p grep. Преимущество p9p версии в том, что она не ждёт завершения всего поиска, чтобы вывести результаты, а выводит их постепенно. Ну и ugrep и ripgrep оказались значительно быстрее.

Обидно за p9p: в нём был впервые реализован Thompson NFA. Видимо, ugrep и ripgrep каким-то образом лучше справляются с IO.

От выстрела в ногу ещё никто не умирал.

А причём тут emacs?

Видимо, собеседник хочет сказать, что в сабже есть всё, кроме…

А размер ФС причём?

Черепичная запись, которая применяется на дисках большого объёма.

Невозможно создать файловую систему больше, чем объём диска. Если только это не RAID-0, но там свои нюансы.

Причём тут это всё…

При том, что пере-грепалка/недо-фм – это первый шаг к ОС из текстового редактора

4 != 4.0

Скорее имелось ввиду - индексирует дерево каталогов для ускорения поиска в медленных файловых системах и файловых системах, которые «холодные», т.е. недавно не кэшировались в памяти.

для ускорения поиска в медленных файловых системах и файловых системах, которые «холодные», т.е. недавно не кэшировались в памяти

Да, это я и прочитал на гитхабе. И это вполне логично. А вот откуда именно большие ФС в новости — пытаюсь выяснить.

Это где такое?. Типа слот, как в gentoo? gcc-14.2.1_p20241116:14

мажор, минор, билд, ревизия

Если следовать https://semver.org/lang/ru, то ревизия не обязательна.

скуф’ский

Вообще мимо. Советую не использовать слов из новояза, не зная ни их значений, ни «обласканных» ими людей.

Давай я тебе подкину SSD’ху.

В другую страну? Сильно вряд ли.
Но можно деньгами. С нетерпением жду! :-D

А для чего BuildLabel, для распознавания разлия в сборке одного и того же?

$ [semver]::new(1,2,3,'preview','test-1')           

Major  Minor  Patch  PreReleaseLabel BuildLabel
-----  -----  -----  --------------- ----------
1      2      3      preview         test-1

$ [semver]::new(1,2,3,'preview','test-1').ToString()
1.2.3-preview+test-1

Вообще конструктор в pwsh (.Net) такой:

$ [System.semver]::new                                     

OverloadDefinitions
-------------------
semver new(string version)
semver new(int major, int minor, int patch, string preReleaseLabel, string buildLabel)
semver new(int major, int minor, int patch, string label)
semver new(int major, int minor, int patch)
semver new(int major, int minor)
semver new(int major)
semver new(version version)

А для чего BuildLabel, для распознавания разлия в сборке одного и того же?

Дата сборки или SHA, например.

10. Сборочные метаданные МОГУТ быть обозначены добавлением знака плюс и ряда разделённых точкой идентификаторов, следующих сразу за патчем или предрелизной версией. Идентификаторы ДОЛЖНЫ содержать только ASCII буквенно-цифровые символы и дефис [0-9A-Za-z-]. Идентификаторы НЕ ДОЛЖНЫ быть пустыми. Сборочные метаданные СЛЕДУЕТ игнорировать, когда определяется старшинство версий. Поэтому два пакета с одинаковой версией, но разными сборочными метаданными, рассматриваются как одна и та же версия.

Примеры: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

Спасибо, понял.

Это где такое?

Арч:

https://archlinux.org/packages/extra/x86_64/alsa-plugins/

Объяснение:

https://wiki.archlinux.org/title/PKGBUILD#epoch

Debian:

https://packages.debian.org/bookworm/vim

Объясниение:

https://www.debian.org/doc/debian-policy/ch-controlfields.html#version

The Silver Searcher вызывается сокращением ag, ripgrep — rg. Здесь ug? Было бы в тему.

Upd. Посмотрел мануал — да, ug.

Здесь ug

Угадал. Держи пирожок.

Спасибо.

Если следовать https://semver.org/lang/ru, то ревизия не обязательна.

Это не какая-то абстрактная «ревизия» от разрабов программы. Это патч-номер дистрибутива. То есть версия патча, которую в этом дистрибутиве накладывают на эту версию пакета. Версия 1.2.3-4 означает, что на оригинальный пакет версии "1.2.3" в самом дистрибутиве наложили патч, и версия этого патча - "4".

К примеру:

$ apt show build-essential
Package: build-essential
Version: 12.9
...

Это пакет от самих разрабов дистрибутива, у него патч-номера нет.

$ apt show dmidecode
Package: dmidecode
Version: 3.4-1
Priority: important
...

$ apt show xterm
Package: xterm
Version: 379-1
...

Это типичные пакеты из опакаченного апстрима с использованием версии апстрима, к ним накатили один типовой патч и больше не меняли этот патч в течении жизни этого релиза. В таком виде находится большинство пакетов. Но есть исключения:

$ apt show gcc
Package: gcc
Version: 4:12.2.0-3
...

В этом релизе к gcc уже дважды модифицировали дистрибутивный патч. Кроме того, у gcc - есть номер «эпохи», отличный от нуля - значит схему версионирования пакетов уже меняли четыре раза.

Выглядит прекрасно. Но возникают вопросы отвлечённого плана: если я введу строку за три секунды и найду не за ноль три, а за ноль ноль три, как это уже влияет на рабочий процесс?

Хорошая тулзень, когда нужно быстренько что-то глянуть в логе, который на пару десятков гигов.

Тут уже пора задуматься об Elasticsearch.

Тут уже пора задуматься об Elasticsearch.

Он нужен только если нужно часто заглядывать в логи. А если раз в пару месяцев – нет смысла тратить ресурсы на него.