Broot v1.0.2 (консольная утилита для поиска и манипуляции с файлами)

Хочу такой же но на swift

Установленный размер: 5,46 MiB

Это до strip?

Je suis Broot?

Выглядит красиво, работает быстро. Моя прошлая попытка использовать broot имела место примерно полгода назад, стоит отдать должное, пользоваться стало действительно приятнее.

К минусам: при наборе поискового запроса зависает после каждого 1-2 символов. А еще у него абсолютно деревянное управление, даже у mc более удобное.

Это до strip?

Не знаю, выполнялся ли при пакетировании strip, но это уже финальный размер, при установке бинарного пакета.

А чем превьюшка рисуется? Или это встроенная функция?

Это после strip.

Название намекает, конечно ;) Кто ставил? Сколько это чудо жрёт ресурсов и как реальзована 2х-панельность например, делением рабочего пространства на одном экране или же как у наркоманов - вкладками?!

Если насчёт минусов это всё так на текущий момент, тогда это печально.

Подозрительно жирный. Там в 1МБ можно всё впихнуть.

как реальзована 2х-панельность

По ссылке в ОП немало скриншотов. И вообще с документацией неплохо.

делением рабочего пространства на одном экране

Да, делением. Можно разделить более, чем на две панели.

для поиска ... с файлами

Проверено: Shaman007

Вы там киргизы что-ли?

напоминает templeos. погуглите.

в тегах не хватает «осеннее обострение».

Это как в консолях фотографии смотреть? 😯

даже смотреть не буду, пока не перепишут на rust

И ты, Broot?

управление для инопланетян

Это костыль. Но вообще в некоторых терминалах есть поддержка sixel, погугли если интересно, в т. ч. и на ЛОРе.

Каждый начинающий программист обязан написать файловый менеджер и плеер.

Особенности:

…

С таким функционалом тянет аж на хорошую лабораторную работу студента-программиста.

Давно ли в Линуксе всё так плохо, что мы радуемся появлению ПО такого уровня?

Вы там киргизы что-ли?

Тебя действительно интересует национальность авторов или это просто наезд?

Это быстрый интерактивный tree, как бы. Давно пора такой иметь.

Правда, «Установленный размер: 5,46 MiB» для интерактивного tree — чудовищно.

О. Шаман вернулся

В нем 200 крейтов разной степени жирности. Собрал сейчас из сырцов, стрипнул, сравнил с тем, что в репозиториях арча. Как-то так:

$ exa $(which broot) -al
.rwxr-xr-x 5.7M root  1 Oct  9:20 /usr/bin/broot
$ exa target/release/broot -al
.rwxr-xr-x 7.6M siborgium  5 Oct 18:31 broot
$ strip target/release/broot
$ exa target/release/broot -al
.rwxr-xr-x 5.8M siborgium  5 Oct 18:31 broot

Собирал на

stable-x86_64-unknown-linux-gnu (default)
rustc 1.46.0 (04488afe3 2020-08-24)

Консольный файловый менеджер

посмотрел на скриншот

скорее уж фейловый менеджер

системный ЯП (тм) во все поля

А прикольно было бы запилить хранение чексумм из выбранных директорий + опционально хранить мету по их кол-ву/составу. Чтобы в случае подозрения на «похакали» было ясно куда копать с одного взгляда.

и ты, брут

git init

Ну такое себе для какого-нибудь /usr/bin/* например, для конфигов то норм.

Вполне норма с учётом того, что все либы статично слинкованы и исполняемый файл вполне самодостаточен

Для сравнения: mc сейчас запросил 55 МБ зависимостей :)

Ликбез по размерам бинариков в Rust.

% cat hello.rs
fn main() {
    println!("Hello, Rust!");
}

Отладочная сборка

% rustc -C debuginfo=2 -C opt-level=0 -o hello hello.rs
% du -bhs hello
3.1M	hello

% strip hello
% du -bhs hello
279K	hello

Релизная сборка

% rustc -C debuginfo=0 -C opt-level=3 -o hello hello.rs
% du -bhs hello
3.1M	hello
% strip hello
% du -bhs hello
279K	hello

Релизная сборка с LTO и в один поток.

% rustc -C debuginfo=0 -C opt-level=3 -C lto=fat -C codegen-units=1 -o hello hello.rs
% du -bhs hello
1.4M	hello
% strip hello
% du -bhs hello
255K	hello

Жирно, что аж плакать хочется, да? У Rust [пока] нет стабильного ABI, поэтому все библиотеки линкуются по дефолту статически. Но технически никто не мешает совершить линковку динамически.

Релизная сборка в один поток с предпочтением динамической линковки (Включая стандартную библиотеку).

% rustc -C debuginfo=0 -C opt-level=3 -C codegen-units=1 -C prefer-dynamic=on -o hello hello.rs
% du -bhs hello
17K	hello
% strip hello
% du -bhs hello
14K	hello

14K!

Ровно столько же весит этот ваш хеллоуворлд на C:

% cat hello.c
#include <stdio.h>

int main() {
	printf("Hello, C!");
}

% gcc -O2 -o hello hello.c
% du -bhs hello
16K	hello

% strip hello
% du -bhs hello
14K	hello

Слинкуем glibc статически)0

% gcc -O2 -static -o hello hello.c
% ldd hello
	not a dynamic executable
% du -bhs hello
750K	hello

% strip hello
% du -bhs hello
679K	hello

И что же консольного в этом просмотрщике фотографий.

В роот мне нооги!

В нем 200 крейтов разной степени жирности

Карго карго, кричали они мастурбируя вприсядку. Ну жрите теперь.

О, в полку «слышу звон, не знаю где он» прибыло. И чем же 200 маленьких (Скажем < 500-1000 LOC) standalone-библиотек хуже жиробасиков, вроде OpenSSL или Boost, которые ещё и CMake-костылями нормально не собрать?

Для сабжевой фигни нужен openssl или boost? Не смеши мои тапки. Для чего-то более серьезного твой карго притащит 2000 крейтов в том числе обертки вокруг десятка дырявых сишных библиотек.

Попробовал, под виндой, на мой взгляд неудобный.

Не думаю. Поинт не в этом. А в подходах к разработке. Чем один монолит лучше кучи маленьких библиотек? И да, притащит. Может не 2000, может 4000 - дальше что? (На практике не видел больше 300)

Напоминаю 2 важных факта:

1. Многие крейты объединены в воркспейсы.
   • Например. 15 крейтов, 1 воркспейс. Так же можно обратить внимание, что та же организация хостит ещё несколько воркспейсов с шифрами. Итого: 1 организация - несколько десятков-сотен крейтов.
   • Противовес Одна организация - одна, очень жирная, библиотека. Вот я и спрашиваю, чем подход 1 хуже подхода 2?
2. Многие крейты - генераторы кода и в конечном бинарике от них не остаётся вообще ничего. Например. Всё что делает - упрощает написание имплементаций для std::error::Error и std::fmt::Display.

Проверено: Shaman007

Ох щи

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

несмотря на то, что размер бинарника вызывает некоторые вопросы, мне в целом понравилось, по крайней мере первое впечатление

у меня от его использования по сравнению с vifm и ranger такое же ощущение легкости при выполнении тех же самых действий, как если сравнивать fish с bash и zsh

Broot v1.0.2 (консольная утилита для поиска и манипуляции с файлами) (комментарий)

и видел твоё сообщение, но я, скорее, о:

В нем 200 крейтов разной степени жирности

(Broot v1.0.2 (консольная утилита для поиска и манипуляции с файлами) (комментарий))

5Мб для чего-то вроде AppImage, я считаю, - по божески. Плюс в него включено несколько цветовых схем, несколько десятков определений синтаксиса для разных ЯП (syntect). Если смущает количество, то нужно просто понимать чего там «215 штук». Из того что я вижу, там подавляющее большинство - ОЧЕНЬ маленькие крейты.

Да, запихнуть broot в роутер - не выйдет, но в остальном то в чём проблема?

Для примера.

Из крайне мелкого: itoa lazy_static either url base64 arc-swap percent-encoding

Из того, что не включено в бинарик и нужно только для сборки: thiserror thiserror-impl pkg-config cc cfg-if autocfg syn quote

в некоторых терминалах есть поддержка sixel

И не только. Terminology и kitty, например, умеют JPEG'и, PNG и т.д.