mc-4.1.40-MP: Двадцать лет спустя...

видишь ли… я так-то - не фришник, я линуксоид и немножко опенщик. Как ты знаешь - «в каждой bsd - своя атмосфера». Я примерно полтора месяца как к проекту вернулся, последние две недели - «плотно». Приходится навёрстывать, многое пролетело мимо за время, пока проект был stalled. так что - терпение. Всё будет.

UTF вроде работает из коробки, но с каких пор - не знаю, мне он не нужен. Недавно стал замечать что набранные случайно русские буквы (через ssh) перестали портить строку ввода при дефолтных настройках.

Почему не cmake, который тоже ещё более suckless?

Потому что это кривое говно, которое делают какие-то наркоманы.

НИЧОСИ! а я в своё время много чего из твоего форка в апстрим перетащил. Моё почтение!

но был в -MP существенный недостаток - отказ от glib. и главное непонятен профит был, glib2 в 21 веке был везде. Реализовал базовый минимум из хэш-таблиц, массивов, строк, имел адекватное апи и позволял не изобретать велосипеды.

mc.po: а они сегодня кому-то нужны? Ну, один я сделал (русский), как-нибудь займусь остальными…

довольно удобная платформа https://weblate.org/ более модная и молодежная чем Transifex

ответ очень простой - «glib=ненужно». Его отсутствие - не недостаток, а преимущество. Преход мейнлайна на glib и был основной причиной, почему этот мой форк стал публичным ТОГДА, и почему я его мейнтейнил. Sapienti sat.

Помимо явно более высокой скорости работы (по сравнению с mainline), меньшего футпринта по памяти и дисковому пространству - это позволяло запустить mc-MP там, куда у mainline mc «морда не пролезала» и где он едва шевелился - mc-MP работал вполне сносно. :)

// А я собрал себе «[не]приличную» ретро-сборочку на Pentium III Coppermine /866 / i815/ Matrox G450/ 512Mb RAM, набил IDE hdd с антресолей, подкинул CT5808, Adaptek 4xIDE, гигабиный ethernet насунул туда Void Linux на 4-м ядре и современном юзерленде, подкинул netbsd/openbsd… Да, я «вот так» развлекаюсь. :)

И что меня на этой сборке ОСОБЕННО угнетало - это работа mainline mc…

Я не против, только я не понял - зачем? :) ты предлагаешь заселфхостить их решение, чтобы принмать донаты переводами?

Действительно - не понял… :(

VFS: поддержка архивов 7z, zip, rar, ace, lha, lzh приведена к современной реальности, добавлены SFTP/SSH VFS.

однонаправленность текущей реализации VFS в mc имеет существенный недостаток/подводный камень, невозможность взаимодействия с ней когда у нее есть вопросы к пользователю. Она учтет все что ты хотел ей сказать но только до ее инициализации. А дальше просто зависнет ожидая пользовательского ввода если она захочет например пароль от архива или еще что то типа того.

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

Ну и насчёт «glib везде» - неправда. Там где гуи он скорее всего будет, да, но на более чистых системах его обычно нет.

предлагаешь заселфхостить

Необязательно. У Weblate есть и собственный хостинг, для опенсорс-проектов бесплатный. Довольно удобно, я пользуюсь. Интегрируется с гитхабом, переводчики при этом работают через их web-интерфейс (правда, пару раз за 8 лет пришлось разрулировать конфликты). У меня, правда, переводы не в .po, а в .ts, но поддержка .po там тоже есть.

Я не против, только я не понял - зачем

вот примерно так я подключил переводы строк https://translate.codeberg.org/projects/mc6/mc6/ на гитхабе сделал 2 экшена, один пушит новые строки, и один пулит переводы. так примерно и на Transifex работает. нужно это чтобы те кто знает испанский на уровне нэйтива проверить могли перевод сделанный нейросетью и/или поправить его

«glib везде» - неправда. Там где гуи он скорее всего будет

где связь гуи и glib?

Хеш-таблицы

я не писал про «Хеш-таблицы», я писал про хэш-таблицы, массивы, работа со строками. Каждую функцию по отдельности не сложно реализовать, но в итоге получится glib (утрирую)

Действительно :) ведь добрая половина популярного gui-софта, использующая gtk, никак не тянет за собой glib, а всякий gimp есть почти везде… Ладно, не буду больше язвить, однако скажу, что, да - таки бывает gui БЕЗ gtk (а следовательно - и без glib). И бывают системы, где glib - не было, нет и не будет. :) не буду вдаваться в подробности - это лишнее. И на многих таких системах mc - бывает очень «кстати».

Поэтому предлагаю этот спор отставить в сторону. glib был создан как неотъемлемая часть GimpToolKit, и впоследствие стал де-факто стандартом для gtk-based систем, таких, как gnome. И любое GTK-приложение обязательно тащит за собой glib, - это данность. Нужно рассказывать про другую сторону баррикад? ;)

использующая gtk, никак не тянет за собой glib

gtk (или что угодно) может использовать glib но это не означает обратного. (в данном случае A ⇒ B, но не B ⇒ A)

И на многих таких системах mc

я возюкался с разными эмбедед железками, но не было таких куда надо было поставить mc но на ней не хватало 2Мб для glib

представляешь, есть более чистые и более практичные реализации всего того, о чём ты говоришь. И они, о ужас, под MIT лицензией, статически вкомпиливаются в код, и не тянут за собой ненужных зависимостей, просто укладываются в одно дерево с использующим их кодом, и используются по мере необходимости. Наглядный пример - stb. Например, когда мне нужна работа с изображениями - я просто использую stb_image.h, а не тащу за собой хвост зависимостей от Imlib2. Мне нужен UTF8 - я использую utf8.h из другого набора, вместо того, чтобы тащить icuuc в зависимости проекта. Да, большинству сегодня проще «на заморачиваться», и использовать то, что уже есть в дистрибутивах, находя себе оправдание вида «все так делают». Ну и пусть делают. Всегда найдутся адекватные инженеры, которые твёрдо скажут «НЕТ!»

роутеры с openwrt. [punch]

о ужас, под MIT лицензией, статически вкомпиливаются в код

эм, ну ок, не буду спрашивать нафига, но это ваше дело.

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

те кто знает испанский на уровне нэйтива проверить могли перевод сделанный нейросетью и/или поправить его

Я бы, на месте испанцев, предпочёл не проверять нейрослоп, а сделать перевод самостоятельно.

роутеры с openwrt.

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

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

навязывает свои абстракции.

иногда удобно когда кто-то вложил много сил для проработки архитектуры, по сути сэкономив твое время. Иногда нет. кмк над glib поработали очень неплохо, но никто ведь не заставляет ее использовать. Я писал свое мнение.

это понимают те, кто помнит слово «оптимизация», а не те, для кого плеер музыки весит «немножко, пару-тройку сотен мегабайт» и поднимает перед собой наперевес «интерфейс на электроне», а под капотом тыркается в «pulseaudio/pipewire», чтобы проиграть несчастный mp3stream, а еще и gstreamer тянет за собой, и (пусть будет) ffmpeg… а вдруг понадобится :) у юзера что-то тормозит? пусть сделает себе апгрейд :)

над glib поработали очень неплохо

возможно. Только я об этом никогда не узнаю, потому что мне негде его использовать, и есть чем заменить, не менее «проработанным». Поэтому я и предлагал остановить этот беспочвенный спор. Каждый останется при своём. «Таков путь».

«интерфейс на электроне»

как мы пришли от динамически линкуемого mc с довольно легкой либой к интерфейсу на электроне?

Поэтому я и предлагал остановить этот беспочвенный спор.

я же и не спорю, я просто изначально написал свое мнение, у меня нет цели призвать юзать glib2 только потому что он божественен а все кто этого не понимают будут гореть в аду.

cmake, который тоже ещё более suckless?

Он просто suck.

«всё начинается с почёсывания»… сперва ты начинаешь использовать ненужные и избыточные решения, потому что «так проще», потом к ним добавляются другие, третьи… и вот уже ты используешь плеер на электроне, потому что «тут так принято». Мне, конечно, всё равно - rust’еры доказывают преимущества своего «офигительного компилятора», «такого безопасного», а когда спросишь, почему их реализация занимает теперь не 20 килобайт, а 20 мегабайт - им и сказать нечего, кроме того, что раст - распрекрасный и безопасный. Я ничего не имею против УМЕСТНЫХ решений, которые нужны там, где они оправданы и разумны. но «плеер музыки на электроне» - для меня - это точно такой же оксюморон, как «консольное приложение, использующее glib». Просто Мигель решил упростить себе жизнь, и не ловить утечки в тогдашнем mc, а просто прилепил к нему кусок гимпа, пардон - гтк. Я там был, и точно знаю - о чём говорю. :)

Я сам цмак под хпишку ради лулзов пытался собрать. Директивы вида «надеюсь в этот раз эта зависимость точно дллка, а не статическая библиотека» - доставили неимоверно. Suckless make - 😍. После Symbian.mmp/bld.inf.

сперва ты начинаешь использовать ненужные и избыточные решения, потому что «так проще»

жизнь одна, если ждать идеального то можно не дождаться.

ну кто ж знал, что проект останется полусырым и без мейнтейнера, хотя патчеров было больше десятка - никто не взялся мейнтейнить. Видимо меня дожидались. Те, кто дождался - ну, надеюсь, им понравится «новое прочтение старого mc-4.1».

А glib2 нынче собирается meson, а он тянет python3 ….

И что? Meson и Python нужны для сборки, а не для запуска. В готовом пакете это уже собранная вещь а при установке нужны её runtime-зависимости.

Кому-то делать нечего.

После этой актуализации большие архивы перестали открываться. Но это вряд ли баг в самом MCommander. Пока не репортил.

о чем речь?

На стабильной версии пока не было времени проверить. На сборке из master зависает при попытке открыть большой tar.xz архив, зависает с постоянной загрузкой на 100% одного ядра.

У меня всегда повторяется с этим архивом: qt-everywhere-opensource-src-5.15.19.tar.xz (634 МБ, ссылка на скачивание: https://download.qt.io/archive/qt/5.15/5.15.19/single/qt-everywhere-opensource-src-5.15.19.tar.xz.mirrorlist).

Не репортил т.к. скорее всего это баг в libarchive.

Архивы, конечно же - libarchive. Какая прелесть.

А что не так с libarchive? Вашу позицию насчёт динамически подгружаемых из дистрибутива зависимостей я понимаю, но лицензия libarchive вполне позволяет её влинковать в другую программу. Или это просто лишнее согласно Вашей системе ценностей?

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

если их и фиксану то отправлю или ПР а если мое то просто фиксану.

это у меня подготовка файлов оглавления делается за O(n^2), плохо, плохо… не важно. подумаю как фиксануть. спасибо за репорт.

видимо, сборка - чего-то думает этими самыми мисонами и бидонами?! :о)

вечь вечер вчера и сегодня всё утро «добрым словом вспоминаю» тех камрадов, кто сказал мне, что «было бы неплохо сделать ‘прозрачную консоль’ с крпированием ввода обе стороны», и тех камрадов, кто сказал мне - «во freebsd всё хорошо» ;)

не икается, нет? :)

В общем, я достаточно быстро победил «прозрачную консоль» и в openbsd, и в netbsd - с приколами, конечно, но относительно быстро… а вот с фряхиной консолью я «люблюсь» уже скоро будет «полсуток» чистого времени… это какой-то лютый трэш… короче, прикрутил для фряхи отдельный буфер в 64кб, отдельно обработал PgUP/PgDN - для ringbuffer scroll, пришлось наворачивать костылинг вокруг shell prompt… в общем - «я очень люблю господина пж», просто не передать :))))

пока допиливал эту хреноту на фряхе - поймал бажок с ней же и на openbsd… так и путешествую между виртуалками - net, open, free,open,free, net… это какой-то сюр :)

// but I can already see the light at the end of the tunnel

скачал, проверю, ежли бага - постараюсь починить…

Мигель решил упростить себе жизнь, и не ловить утечки в тогдашнем mc, а просто прилепил к нему кусок гимпа, пардон - гтк

Может быть дело в gmc?

Там была целая битва. :) Сперва Мигель закрыл приём feature-request’ов с патчами, потом - вообще закрыл приём патчей до момента, пока не будут починены утечки. Ловили, наверное, пару меяцев, - не получилось. Тогда выходит Мигелюшка, и объявляет: «ну раз такое дело, парни, то с целью унификации кодовой базы - мы будем дальше использовать glib, поскольку он уже stable, и всё с ним хорошо.» Шум, гам, клочья по всем углам, чуть не до баррикадной войны дошло. Арпад берёт стабильную ветку 4.1, и начинает принимаеть feature request’ы… Идёт время, прикручивается-прикручивается glib, всё плохо, всё сыпется, ничего нормально не работает, мейнлайн уже выкатился на 4.5, Арпи выкатился на AMC-4.1.35… И вот, «не прошло и двух лет» - снова выходит Мигель и говорит «а вот теперь мы точно полностью переключили всю кодовую базу на glib», но фичи принимать не будем, пока НЕ ЗАСТАБИЛИЗИРУЕМ работу mc+glib… время идёт, Арпи присылает мне последний пре-релиз 4.1.35, говорит - «вотЪ, я всё, я устал, я ухожу, я сдаюсь», и ушел на 4.5.какую-то… свой «свежий» AMC он выкатил, если верно помню, уже поверх 4.6.какой-то версии, взял часть патчей у меня, взял часть патчей у ребят с форума, из рассылки… и потом - как-то всё затихло… Тем временем - я прикрутил свежий редактор, прикрутил кучу фичей, накрутил своих, от наших парней набрал патчей (Особо активным товарищем был Hatred, я за ним мемори-лики подтирать не успевал, хотя и он помогал, багов и ликов наловил - будь здоров!). Но, в один прекрасный день «случился» UTF8, к которому никто толком не знал - как подступиться, хотя «все хотели», и пока шла усушка-утряска, mc-MP «встал на паузу», да так из неё и не вышел… до вот этого вот релиза… и ka-BSDets фикса, который я сегодня намерен выкатить, а заодно и разорвать пуповину с «конфликтом положений» mainline mc, переименовав все бинаря, и разложив всю требуху так, как это принято делать сегодня…

А чо случилось то с криокамерой?

фффффффсйо… победил консоли *bsd, фуф… так, пиала улуна, проверяю крайний раз «гайку», проверяю, что я не поломал попутно linux (не должен! но проверить надо), проверяю отрабпортованный баг с vfs .tar.gz, коммит, тег и выливаю на гитхаб. «Это была славная охота» :)

«сломалася» :)