fd 10.0.0 и bfs 3.2

неужто тянет на главную? а можете показать ldd на исполняемые файлы этих утилит?

Нужно, пользуюсь. Только жаль, конечно, оно на Rust.

неужто тянет на главную?

Да, утилита категории must have.

После последнего разговора про Rust, у меня сложилось впечатление что за него в основном топят вчерашнии виндузятники, ну не осили в windows mingw, make. Это понятно и вопросов не особо возникает.

Но так наглеть :

минимальная поддерживаемая версия Rust теперь 1.77.2

Это уже через чур :(

А можете мне указать, чем вам обычный find не катит ?

vadim@aquila:/tmp/1/fd-v10.0.0-x86_64-unknown-linux-gnu$ ls -lh ./fd
-rwxr-xr-x 1 vadim vadim 3,9M мая  6 13:09 ./fd
vadim@aquila:/tmp/1/fd-v10.0.0-x86_64-unknown-linux-gnu$ ldd ./fd
	linux-vdso.so.1 (0x00007ffd2d32f000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007bdd825e5000)
	librt.so.1 => /usr/lib/librt.so.1 (0x00007bdd825e0000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007bdd825db000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007bdd825d6000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007bdd823f2000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007bdd8265c000)
vadim@aquila:/tmp/1/fd-v10.0.0-x86_64-unknown-linux-gnu$ 

Консольная утилита поиска файлов весом 4 мегабайта.

И это даже не статическая линковка, она еще и glibc тащит. В 4 метра весь рантайм не влез.

Ну с такими программами теперь я знаю, чем мне забить SSD.

А можете мне указать, чем вам обычный find не катит ?

Он недостаточно гламурный, про него не получится записать видео на ютубе «15 КРУТЫХ инструментов, которые делают вашу работу в терминале macOS ВОСХИТИТЕЛЬНОЙ».

не знал про fd. засетапил. удобнее find’a на первый взгляд. ну и существенно быстрее за счет параллелизации (обходить дерево фс последовательно в наши дни это какое-то средневековье)

ну и существенно быстрее за счет параллелизации

bfs ещё быстрее: В утилиту bfs добавлена возможность использования liburing (комментарий)

А 2 мая состоялся выпуск 3.2 аналогичной утилиты bfs, но написанной на языке C.

vadim@aquila:~$  pacman -Qql bfs
/usr/
/usr/bin/
/usr/bin/bfs
/usr/share/
/usr/share/bash-completion/
/usr/share/bash-completion/completions/
/usr/share/bash-completion/completions/bfs
/usr/share/fish/
/usr/share/fish/vendor_completions.d/
/usr/share/fish/vendor_completions.d/bfs.fish
/usr/share/licenses/
/usr/share/licenses/bfs/
/usr/share/licenses/bfs/LICENSE
/usr/share/man/
/usr/share/man/man1/
/usr/share/man/man1/bfs.1.gz
/usr/share/zsh/
/usr/share/zsh/site-functions/
/usr/share/zsh/site-functions/_bfs
vadim@aquila:~$ ls -lh /usr/bin/bfs
-rwxr-xr-x 1 root root 235K апр  2 09:29 /usr/bin/bfs
vadim@aquila:~$ ldd /usr/bin/bfs
	linux-vdso.so.1 (0x00007ffdd5d9b000)
	libonig.so.5 => /usr/lib/libonig.so.5 (0x00007a4c3388e000)
	libacl.so.1 => /usr/lib/libacl.so.1 (0x00007a4c33885000)
	libcap.so.2 => /usr/lib/libcap.so.2 (0x00007a4c33879000)
	liburing.so.2 => /usr/lib/liburing.so.2 (0x00007a4c33872000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007a4c3368e000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007a4c339b4000)

Итого цена программирования на гламурном языке – 20-кратное увеличение бинарника.

io_uring же решето, которое по-умолчанию выключили в ядре

поправил оптимизацию в конфиге, собрал через musl:

ldd ./fd
	statically linked

ls -alh fd
-rwxr-xr-x 2 snk users 2,8M мая  7 09:49 fd

io_uring же решето

Прямо вот все функции?

В 2.8М бинарного кода может уместиться встраиваемая операционная система с поддержкой сети, графическим интерфейсом, иконками и приложениям.

А в запорожец может поместиться 10 человек. Дальше то что? Какой практический смысл этого заявления? Автору нужно бросится переписывать приложение на bash?

чем вам обычный find не катит ?

Отсутствием интуитивного синтаксиса, более низкой скоростью работы, длиной поисковых команд, нет вменяемой параллельности (как параллельное выполнение команд, так и параллельный обход каталогов), нет качественной цветной подсветки расширений файлов и прочего (подобно ls).

может, но это совсем другая ситуация.

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

Свежак: $ hyperfine -N -w 5 "fd . /bin" "bfs /bin/" "rh -y /bin" "find /bin/" --export-markdown finders.md

Summary
  find /bin/ ran
    1.82 ± 0.54 times faster than bfs /bin/
    2.30 ± 0.68 times faster than fd . /bin
    2.87 ± 0.87 times faster than rh -y /bin

жаль, конечно, оно на Rust

Что ж так? Очень сильно жаль или совсем немножко жаль?
Не все ли равно, на чем написано?

Ну тогда читаем вторую часть новости и юзаем другую утилиту, раз мсье настолько Брезгливых.

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

Да, Раст – это новая Node.js

Когда жалуются, что «у Си плохой тулинг, ведь я не могу как в nodejs поставить все зависимости – что за средний век!», то результат будет вот такой.

Не все ли равно, на чем написано?

Мне всё равно, на чем написано приложение, пока его размер как-то соотносится с реализуемыми фичами.

ldd

linux-vdso.so.1
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1
librt.so.1 => /usr/lib/librt.so.1
libpthread.so.0 => /usr/lib/libpthread.so.0
libdl.so.2 => /usr/lib/libdl.so.2
libc.so.6 => /usr/lib/libc.so.6
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2

Да, четыре мегабайта очень много нынче, согласен (мы же про ембед и «640 КБ, которых хватит всем» не говорим, верно?)

Потребление памяти:

vadim@aquila:/tmp$ cat test.sh 
test_find()
{
    "$@" /usr >/dev/null 2>&1 &
    local pid="$!"
    ps -o cmd,rss -p $pid
    kill $pid
}

test_find find
test_find bfs
test_find fd --base-directory
vadim@aquila:/tmp$ sh ./test.sh 
CMD                           RSS
find /usr                    7240
CMD                           RSS
bfs /usr                    29548
CMD                           RSS
fd --base-directory /usr    29692

Так оно ещё и тормознее обычного find, а растовая версия тормознее сишной? Может быть разработчиков на rust не просто так недолюбливают…

А там, где реально много файлов и характерное время десятки секунд (а не миллисекунды)?

где реально много файлов

Это сколько? В bin у меня 9222 файлов.

А директорий мало. Срани с /usr или /var хохмы ради.

А ещё лучше с /.

Понятно вопросов больше нет.

И кстати я хз что там у народа за дистрибутивы и ДЕ, но у меня полно всякого : начиная с locate и т.д. которое давно всю фс проиндексировало ночью и т.д.

Да я пользуюсь find но редко.

Да, четыре мегабайта очень много нынче, согласен (мы же про ембед и «640 КБ, которых хватит всем» не говорим, верно?)

Давай-ка подумаем:

vadim@aquila:~$ find /usr/bin -type f -printf "%s\n" | awk '{s+=$1} END {print s}'
2393499114
vadim@aquila:~$ find /usr/bin -type f | wc -l
6367
vadim@aquila:~$ echo 2393499114 / 6367 | bc 
375922
vadim@aquila:~$ 

Средний размер бинарника на моей системе составляет 376 килобайт.

Это при том, что у меня стоят не «консольные утилиты для поиска файлов», а весь зоопарк от компиляторов до половины KDE.

Во что превратится система, если каждая сраная «утилита для поиска файлов» будет занимать по 4 метра бинарника?

Это при том, что зоопарк фреймворков в /usr/lib тоже никуда не денется.

Сколько места это всё будет занимать?

Во сколько раз возрастёт нагрузка на IO при запуске программ?

На сколько возрастёт нагрузка на ОЗУ?

На сколько возрастёт нагрузка на процессорный кэш?

А потом вы еще жалуетесь на блоатварь, и что компы тормозят. И что для нормальной работы прикладного кода нужный утюги, рассеивающие по 100+ Вт на кулере.

hyperfine -N -w 5 -i "fd . /home" "bfs /home/" "find /home/" --export-markdown finders.md
Benchmark 1: fd . /home
  Time (mean ± σ):     425.4 ms ±   7.5 ms    [User: 804.2 ms, System: 804.1 ms]
  Range (min … max):   417.5 ms … 438.4 ms    10 runs

Benchmark 2: bfs /home/
  Time (mean ± σ):     600.1 ms ±  10.7 ms    [User: 643.8 ms, System: 1317.0 ms]
  Range (min … max):   581.6 ms … 619.4 ms    10 runs

  Warning: Ignoring non-zero exit code.

Benchmark 3: find /home/
  Time (mean ± σ):      3.724 s ±  0.031 s    [User: 1.603 s, System: 2.110 s]
  Range (min … max):    3.684 s …  3.792 s    10 runs

  Warning: Ignoring non-zero exit code.

Summary
  fd . /home ran
    1.41 ± 0.04 times faster than bfs /home/
    8.75 ± 0.17 times faster than find /home/

не знаю как rh как пакет зовется потому пока выкинул

С /lib: $ hyperfine -N -w 5 "fd . /lib/" "bfs /lib/" "rh -y /lib" "find /lib/" --export-markdown finders.md

Summary
  fd . /lib/ ran
    1.73 ± 0.05 times faster than find /lib/
    1.84 ± 0.05 times faster than bfs /lib/
    3.00 ± 0.09 times faster than rh -y /lib

Но!
$ fd . /lib/ | wc -l

225641

$ find /lib/ | wc -l

226146

$ bfs /lib/ | wc -l

226146

не знаю как rh как пакет зовется

Наверное, нигде нет: Rawhide -- утилита поиска файлов с Си-подобным синтаксисом выражений

неужто тянет на главную?

Почему нет? Полезность наравне с ripgrep и fzf.

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

Но. Всё равно я find не брошу, потому что он хороший. :)

в ауре нашлась

тут дело привычки, я просто не вспомню, ни одну тулзу кроме find, уже через неделю

неужто тянет на главную?

Версия же мажорней некуда.

Для комплекта добавил lr.

hyperfine -N -w 5 "fd . /lib/" "bfs /lib/" "rh -y /lib" "find /lib/" "lr /lib/" --export-markdown finders.md

Summary
  fd . /lib/ ran
    1.74 ± 0.07 times faster than find /lib/
    1.83 ± 0.06 times faster than bfs /lib/
    2.65 ± 0.09 times faster than lr /lib/
    3.00 ± 0.09 times faster than rh -y /lib

Но!
$ fd . /lib/ | wc -l

225641

$ find /lib/ | wc -l

226146

$ bfs /lib/ | wc -l

226146

$ lr /lib/ | wc -l

226146

Средний размер бинарника на моей системе составляет 376 килобайт.

Уточнённый результат:

$ find /usr/bin -type f | xargs file -i | grep '/x-.*-executable' | grep -E -o '^/[^:]+' | xargs stat -c "%s" | awk '{s+=$1} END {print s}'
2058508880
$ find /usr/bin -type f | xargs file -i | grep '/x-.*-executable' | grep -E -o '^/[^:]+' | wc -l
4884
$ echo 2058508880 / 4884 | bc 
421480

Отсутствием интуитивного синтаксиса,

Вкусовщина. По-моему у find очень понятный синтаксис

более низкой скоростью работы,

Не актуально. Мой home find обходит за 3 секунды, fd за пол-секунды. Ну и что? Там 300k файлов. Само по себе их нахождение нафиг не нужно, их нужно как-то потом обрабатывать. Скорость такой обработки на порядок медленнее поиска, даже если это find.

длиной поисковых команд,

См. выше.

нет вменяемой параллельности (как параллельное выполнение команд, так и параллельный обход каталогов),

Параллельных обход сам по себе также нафиг не упал. Это нужно для повышения скорости, а про скорость см. выше. Параллельное же выполнение команд ты просто не осилил, оно есть.

нет качественной цветной подсветки расширений файлов и прочего (подобно ls).

Ненужно. Поиск нужен не для того чтобы глядеть на 100500 названий файлов, а для обработки.

После последнего разговора про Rust, у меня сложилось впечатление что за него в основном топят вчерашнии виндузятники, ну не осили в windows mingw, make

Под винду, скорее на c# напишут. Думаю, дело все-же не в этом. Пока - это все еще мода. И погоня за «безопасностью» теми товарищами, кто не хочет особо заморачиваться. Впрочем - большинство программистов - не хочет особо заморачиваться, что, в очередной раз, подводит меня к мысли о том, что программистов, на рабочем месте нужно ПОРОТЬ три раза в день, чтоб у них включались мозги :)

Надо бы на каких-то хитрых регулярках потестировать.
bfs по умолчанию использует Oniguruma; думаю, что победит. :)

Под винду, скорее на c# напишут. Эээ, хм видать я не понятно написал.

Вчерашний виндузятник, он или осиляет Убунту но уже на маке его стопорит, либо вообще сидит под виндовс и ему нужно писать под линукс. В любом случае руст пользуется как склейкой си либ с кучей unsafe.

Помню 2000х, виндузятники так ныли на php что ужасть, пока какой то чел им Денвер (хз как точно не помню, не выкатил). А продвижение всех этих электронов с npm и т.д. Так это считай сразу клеймо - программирует под виндой.

Нужно признать тут заслугу Убунты, установка в один клик дала этим доморощенным программмерам покрайне мере сидеть в нормальной ос.

Если сравниваешь с find, то правильнее fd -u.

Не актуально. Мой home find обходит за 3 секунды, fd за пол-секунды. Ну и что? Там 300k файлов. Само по себе их нахождение нафиг не нужно, их нужно как-то потом обрабатывать. Скорость такой обработки на порядок медленнее поиска, даже если это find.

Ну это уже перебор. Я ни разу не сторонник раста, но то что fd быстрее обходит дерево это большой заметный плюс. Иногда нужно действительно найти какие-то файлы. Иногда из 100500 файлов надо обработать десяток. Так что ускорение работы это полезно и нужно.