Я, кстати, тогда не рассказал, что попросил господ из Химеры запилить busybox-style binary из bsdutils, раз уж они занялись его перехреначиванием под meson, но господа тогда отказались, мотивируя это тем, что "не нужно". Не нужно - так не нужно, я эту тему отложил.

Но, вот, на январских решил этот гештальт закрыть.

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

В целом, мой процесс описан тут - https://github.com/pg83/ix/blob/main/pkgs/bin/bsdutils/box/ix.sh#L10, я немного прокомментирую:

* В пакете достаточно регулярная структура исходников - по папке на каждую тулзу. Я прохожу по всем папкам верхнего уровня, и готовлю libfunc.a из всех *.o, соответствующих эой тулзе. https://github.com/pg83/ix/blob/main/pkgs/bin/bsdutils/box/ix.sh#L15 Важно - в каждом таком .a есть функция main()!

* После чего я добавляю префикс вида "${tool_name}_" ко всем символам в этой libfunc.a - https://github.com/pg83/ix/blob/main/pkgs/bin/bsdutils/box/ix.sh#L16 (это уже мой инструментарий для бинарного патчинга). Важно - main() в, скажем, sed, начинает называться int sed_main(). После этого все эти .a файлы можно слинковать в один бинарь.

* После чего я генерирую настоящий int main(), который устроен примерно так:

...
if (strcmp(argv[0], "sed") == 0) {
    return sed_main(argc, argv);
}
...

(вот, кстати, тут сишечка "сияет", потому что используется ровно для того, для чего ее придумали!)

Наверное, тут стоит отметить, что мое решение не до конца аккуратно, потому что вызываемый sed_main() может иметь сигнатуру не int sed_main(), а void sed_main(), и/или не принимать все argc/argv/envp, но:

- Я глазами убедился, что в коде void не бывает, а если бы был, нужно было бы еще занулить RAX перед вызовом sed_main() (попробуйте себя в этом убедить!)

- Передача лишних аргументов тоже не должна привести к проблемам в данном конкретном случае. Попробуйте себя убедить и в этом!

* Линкуем всю конструкцию в монобинарь - https://github.com/pg83/ix/blob/main/pkgs/bin/bsdutils/box/ix.sh#L57

В целом, такую процедуру можно провести с любым набором конечных артефактов, только надо понимать, что, в случае C, это "почти" безопасно, а вот в С++, если есть много глобальных переменных с нетривиальными конструкторами, можно "попасть".

Получившийся бинарник работает just as planned, из интересного - он чутка меньше, чем такой же монобинарь для coreutils.

bsdbox - 2M, coreutils - 2.4M

Тесты на perf какого-нибудь развесистого configure скрипта пока не проводил, гештальт закрыт.

Запустил таки configure с bsdutils, вместо coreutils.

Результата не дождался, потому что словил oom в sed!

[837157.716471] oom-kill:
    constraint=CONSTRAINT_NONE,
    nodemask=(null),
    cpuset=/,mems_allowed=0,
    global_oom,task_memcg=/,
    task=sed,pid=7540,uid=1000
[837157.716492] Out of memory: 
    Killed process 7540 (sed) 
    total-vm:6018196kB, anon-rss:5584024kB, 
    file-rss:0kB, shmem-rss:0kB, 
    UID:1000 pgtables:11820kB 
    oom_score_adj:0

В целом, неудивительно, учитывая changelog!

https://github.com/dcantrell/bsdutils/releases/tag/v13.1

"Freshly imported from FreeBSD 13.1 and patched. Also add the sed(1) command. Enjoy"

У телеги очень интересно разные changelog в приложении, и на github:

"Telegram Desktop was updated to version 4.5.3

— Bug fixes and other minor improvements

Full version history is available here:
https://desktop.telegram.org/changelog"

https://github.com/telegramdesktop/tdesktop/releases/tag/v4.5.3

"Attempt to fix incoming video in calls from mobile apps"

В github всегда интереснее!

https://lobste.rs/s/pza2fr/sqld_is_server_mode_for_libsql

Анонс sqld, сервера баз данных, построенных поверх libsql(которая сама по себе довольно забавный форк sqlite, вызванный тем, что всех подзаебало, как оунеры sqlite ее развивают(а, точнее, не принимают внешний код от слова совсем)).

В анонсе ничего интересного нет, кроме того, что я из-за него вспомнил, что хотел написать следующее:

Никогда, никогда не используйте встраиваемые базы данных (*)! Вот вообще никогда!

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

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

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

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

Как правильно?

Ну вот так и правильно - запускать вместе с приложением вот такой вот sqld, и ходить к нему через сокет.

*: "на самом деле" (tm), есть один случай, когда встроенный sql - OK. Это случай, когда вы решили использовать sql как структурированный формат для save/load. Не как базу данных, к которой в процессе работы идут постоянные запросы, а при старте приложения прочитали файл в память, поработали с ним, в конце записали целиком заново.

Увожаемые, а дайте совет про лучшие практики CI на github?

Сейчас у меня есть процесс, который на каждый коммит умеет сказать OK/FAIL.

Самое простое, что мне приходит в голову - двигать какую-то метку "stable" в последний зеленый коммит, или мержить все изменения по последний зеленый в какую-то ветку "stable".

А как вообще принято?

https://sourcehut.org/blog/2023-01-09-gomodulemirror/

Продолжение истории про ddos от Google.

Решение Дрю, конечно, спорное, потому что принципы - принципами, но вот go-шные проекты у него хостить будет сложнее.

https://quick-lint-js.com/blog/cpp-vs-rust-build-times/

Текст про сравнение скорости сборки Rust vs. C++.

От кучи подобных текстов отличает монументальность подхода - коллега переписал 17 тыщ строк с С++ на Rust, для корректности сравнения.

Измеряется вообще ВСЕ - инкрементальные vs полные сборки, различные трюки для ускорения сборки как С++, так и для Rust, в том числе, (за это отдельный респект и уважуха) - попытка собрать тулчейны с #BOLT.

Короче, автор явно одержим скоростью, почитайте.

Выводы? Все сложно!

Коллеги принесли красивое.

Обсуждали внутренний патч во flakes8, вида

-VALID_CODE_PREFIX = re.compile(
    "^[A-Z]{1,3}[0-9]
    {0,3}$", re.ASCII)
+VALID_CODE_PREFIX = re.compile(
    "^[A-Z]{1,3}[0-9]
    {0,4}$", re.ASCII)

Ну, типа, не хватает ширины какого-то поля, давайте, мол, увеличим на 1.

Конечно, возник вопрос - почему так в upstream, и можно ли это будет смержить в него.

https://github.com/PyCQA/flake8/pull/1782#issuecomment-1377346615
https://github.com/PyCQA/flake8/issues/1777

TL;DR - начнем с того, что ты пиздоглазое мудило "what part of "this is not changing" do you not understand?"

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

А, ну и вишенка на торте - договориться не могут проекты(pylint и flake8) из одной организации.

Вот в коммерческой организации пришел бы старший разраб в трекер, навалял бы обеим "высоким договаривающимся сторонам" люлей, и дело бы пошло, без всяких "тонких душевных организаций", и прочих ЧСВ.

https://seclists.org/oss-sec/2023/q1/13

Просто оставлю это здесь.

На самом деле, из текста я не понял, где именно не случается нужная проверка. Я вот, например, при скачке исходников тоже не проверяю сертификаты, потому что важнО несовпадение чексуммы(SHA), которая получена по надежному каналу.

Если при скачке репозитория версий и зависимостей - то это, конечно, хорошо.

Вчера разбирались с коллегой, почему у него странно работает ssh на машину с установленным #stal/ix.

Если совсем коротко, то это выглядело так:

# ssh host env
...
A=B
...
# ssh host
> env
...
A=C
...

Ну, то есть, натурально, сильно разный environment при запуске команды в batch режиме ssh, и такой же команды в интерактивном режиме.

Дело свелось вот к этой функции - https://github.com/mkj/dropbear/blob/master/dbutil.c#L371

Совсем коротко - для интерактивного режима оно запукает shell в login mode, и тогда shell читает содержимое /etc/profile, и далее все, как положено, а для запуска batch команды запускает шел в неинтерактивном режиме, через -c. Ну и этот shell, конечно, наследует env от parent process, и не зачитывает на старте /etc/profile.

Я тут не очень понимаю, как правильно (и кто это "правильно" вообще определяет).

Мне лично кажется, что и во втором случае нужно запускать login shell, но не в интерактивном режиме!

Я это у себя зачинил так - https://github.com/pg83/ix/blob/main/pkgs/bin/dropbear/ix.sh#L7 https://github.com/mkj/dropbear/blob/master/dbutil.c#L388 - вот тут заменяем -c на -cl, указывая, что надо зачитать env из /etc/profile.

Вот теперь думаю, надо ли с этим стучаться в dropbear upstream, или меня там сразу нахер пошлют?

Мне кажется, надо бы апнуть этот замечательный пост, в котором я объяснял, зачем я затеял свой дистрибутив Linux.

Если коротко - то меня бесят многие вещи, сделанные в Unix/Linux, и самый простой способ их починить - это иметь контроль над всем окружением!

Вот, если говорить про предыдущий пост, где я написал про "странность" поведения ssh daemon в интерактивном vs. batch режиме.

На самом деле, эта странность очень просто объясняется - она вызвана путаницей между login shell, и interactive shell!

К сожалению, эти режимы довольно часто соседствуют, поэтому есть соблазн в настроечные файлы для login shell запихнуть свои настройки для interactive shell.

Но это в корне неверно!

Login shell, это, если очень грубо, первый shell в цепочке для вашего пользователя. Обычно его стартует какой-нибудь display manager, типа mingetty, agetty, emptty, greetd, sddm, да тысячи их. ssh, putty, telnet, mosh, и так далее - это тоже штука, которая spawn первую shell в цепочке!

Interactive shell - это то, куда вы вбиваете команды с клавиатуры.

Это, конечно, довольно разные штуки.

(Кстати, немного в сторону - если у вас бывают случаи, когда в PATH повторяются одни и те же элементы - это значит, что вы не понимаете разницу между этими сущностями, и у вас иногда два раза срабатывает конструкция добавления чего-то к PATH, потому что лежит не в том файле)

Проблема тут еще усугубляется тем, что разные shell читают разные startup файлы, в зависимости от режима.

Например, bash читает /etc/profile как и в interactive, так и в login mode. А большинство других shell так не делают!

Короче, тут явно видны треш, угар, и содомия, наслоение привычек, непонимания, и так далее. Оцените, например, только /etc/environment - https://superuser.com/questions/664169/what-is-the-difference-between-etc-environment-and-etc-profile - это упячка, родившаяся из того, что иногда надо сделать "login", но без "shell", а переменные откуда-то надо взять!

Поэтому, конечно, я тут намерен сделать все "правильно" (*), а не воспроизвести хак, к которому все привыкли!

Почему?

Потому что, если бы меня устраивал этот хак, я бы поставил Fedora! А мне нужно better!

(*) Правильно - конечно, ssh и прочие должны запускать первый shell в login mode. Еще лучше - для каждого shell пользователь должен разобраться, в какие файлы ему класть interactive настройки (типа completion), а куда - login.

https://xn--r1a.website/PAAMAYIM_NEKUDOTAYIM/30

Не могу не утащить из комментариев!

Продолжается замечательная история про #gil в Питоне.

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

https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional/22606

Я настроен довольно пессимистично, потому что люди прекрасно понимают, что это сильно фрагментирует экосистему. Условно говоря, будешь ты приходить к автору third party модуля с просьбой починить в нем баг в многопотоке(или починить регрессию в однопотоке), а он будет посылать нахер, с "не использовали многопоток, и неча начинать". В итоге, все разделится по признаку "можно в многопоток/нельзя", и это не очень.

https://www.opennet.ru/opennews/art.shtml?num=58472

Пишут, что в Chromium можно в Rust.

Новость, конечно, не очень приятная!

Я люблю, когда на Rust переписывают какую-то кодину на C, но вот сочетание Rust + C++ мне не очень ОК. Потому что С++ достаточно безопасен, настолько, что проблемы от взаимодействия 2 языков перевешивают профит. Про такую попытку Гугла использовать Rust в С++ кодовой базе я уже писал - #cras.

"Для упрощения интеграции кода на Rust с существующим кодом на C++ и обхода связанных с интеграцией рисков и ограничений, в настоящее время решено ограничиться однонаправленным взаимодействием - обращением из С++ к Rust (т.е. код на Rust может лишь вызываться из кода C++ через функции API, но не смешиваться с кодом на C++), что также даст возможность держать под контролем дерево зависимостей. Вторым ограничением является поддержка только сторонних библиотек, поставляемых в форме отдельных компонентов, не привязанных к Chromium и имеющих API, ориентированный на выполнение конкретных задач"

Пока мне кажется, что это такой эксперимент, и что эти правила позволяют затащить какой-то кодек на Rust, или вот librsvg. Вполне возможно, что этим все и ограничится, как двумя файликами "для галочки" в #cras.

И еще такой вопрос - а что с #carbon?

Кажется, что Rust тут пытается откушать как раз нишу #carbon, и это довольно странно. Carbon все?

https://www.opennet.ru/opennews/art.shtml?num=58465 #sfc

Слуште, я, когда прочитал текст этой новости, полез в календарь, и проверил, какое сегодня число. Но потом увидел, что, в списке подписантов, есть известные левые упыри под названием #sfc, и все встало на свои места.

Интересно, много ли народу съехало с github, после их прошлой инициативы?

Такие IT новости нам по душе! Хотя я бы, конечно, ожидал бы такого от blizzard!