https://www.phoronix.com/news/GNU-Binutils-SFrame #dwarf

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

Бинари получаются меньше, стек раскручивается быстрее.

Круто?

https://www.google.com/search?q=compact+unwind

Apple уже давно имеет формат для "compact unwind", он особо нигде не афишируется, но clang его умеет для mach-o. Я регулярно совершал набеги, чтобы он завелся и под elf, там делов-то - сгенерить нужную секцию, а libc++abi/llvm unwind уже давно в это умеют. Безуспешно(не потому что сложно, а потому что лень).

"Не договорились", а как же иначе.

(кстати, именно из-за этого у меня по всем замерам пару лет назад получалось, что в MacOS исключения летят раз в 5 быстрее)

Мужик сказал - мужик сделал! #mold #money

https://github.com/bluewhalesystems/sold

Пожалуйста, новый линкер от Rui - #sold!

Ну и, теперь, когда вы отправляете патч в mold, под MIT-совместимой лицензией, знайте, что, тем самым, помогаете хорошему человеку продать ваш труд!

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

В жизни не отправлю патч в mongodb/elastic, а вы?

https://3dnews.ru/1077583/pokupatelyami-pervih-kvantovih-telefonov-za-40-mln-rubley-stanut-rgd-i-gazprom

"Покупателями первых телефонов с квантовой связью, выпускаемых компанией «ИнфоТеКС» и оценённых ориентировочно в 40 млн рублей, могут стать РЖД и «Газпром». Внедрение таких устройств связи может состояться уже в следующем году и позволит существенно повысить конфиденциальность переговоров"

#analo_govnet

Решил я разобраться с падением альтернативы git от openbsd - #got http://gameoftrees.org/.

(мы его как-то обсуждали в комментариях, он у меня тогда падал, несмотря на openbsd происхождение)

Gdb, конечно, показал красивое - https://git.gameoftrees.org/gitweb/?p=got-portable.git;a=blob;f=got/got.c;h=15f993971c3f1fa3771c09ad092f2f5c3d8e6c13;hb=HEAD#l284

Падало оно вот в этой строчке кода, причем getprogname() возвращал корректный указатель на строку, а вот в fprintf() приходило уже нечто, обрезанное по 4 байтам.

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

got.c:9260:54: warning: call to undeclared 
    function 'getprogname'; ISO C99 and later
    do not support implicit function declarations 
    [-Wimplicit-function-declaration]
    fprintf(stderr, "usage: %s 
    cherrypick commit-id\n", getprogname());

Короче, компилятор не видел объявления const char* getprogname();, и посчитал что оно int getprogname(). С такой С.

Почему так произошло?

Если честно, я не разобрался на 100%. Я только понял, что это где-то проблема на стыке libbsd, кода из папочки openbsd-compat, которой нет в их репозитории, и которую, видимо, они подмешивают в момент построения релизного tgz, и моей обертки над компилятором.

Там все весьма нетривиально - libbsd пытается "досыпать" в системные заголовки дополнительных функцию с помощью include_next, и хитрой манипуляцией с путями компилятора(определенный порядок -Ixx, -isystemxxx, и так далее) - https://cgit.freedesktop.org/libbsd/tree/include/bsd/stdio.h#n32

А потом, сверху, дополнительно, делает еще и openbsd-compat из поставки got.

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

С на это похер(нет манглинга в именах символов), линкеру тоже - он линкует, что ему дали.

Я за 20 минут не разобрался, что же там сломано в порядке включения заголовков, и сделал по рабоче-крестьянски:

* сделал файл со всеми нужными прототипами - https://github.com/pg83/ix/blob/main/pkgs/bin/got/stock/ix.sh#L30

* добавил его в каждый вызов компилятора - https://github.com/pg83/ix/blob/main/pkgs/bin/got/stock/ix.sh#L57, через вызов "-include xxx.h" (есть и такое в clang/gcc)

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

В общем, падения я починил, но got у меня так и не заработал, и об этом в другой раз!

Если фото реальное, то это, конечно, офигенно.

Продолжение истории про #got.

Он у меня пока так и не заработал, потому что:

* Разработчики - большие фанаты "театра безопасности", и потому анально огородили все места, куда может залезть программа, через landlock/unveil/etc. Причем, судя по README, это "очень важная" фича, вокруг которой был сдизайнен остальной код - https://gameoftrees.org/goals.html, а, судя по changelog, примерно половина разработки - это добавление того, что забыли добавить в доступные файлы для корректной работы программы.

* Путь к ssh захардкожен - https://git.gameoftrees.org/gitweb/?p=got.git;a=blob;f=lib/dial.c;h=3325c8994f55721d8588155cdc72b95d11fd2248;hb=4cad5be9f88baeb0583b4b63a546f5815929a270#l49 в "/usr/bin/ssh", а, как вы понимаете, у разумных людей ssh там не лежит. Ну и, помимо того, что не лежит, просто позвать ssh не получится, потому что unveil.

Почему это "театр безопасности"? А много кого хакали на основе парсера ссылочного графа в git?

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

Гля че купил!

Сегодня у меня для вас анекдот про мое чувство прекрасного.

Меня лично бесят программы, которые хотят создавать временные файлы. Вообще, "временный файл" - это какой-то нонсенс, потому что захера писать эфемерные данные в персистентный файл?

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

Обычно программы пишут что-то во временные файлы или в виде хака, когда у тебя какой-то блок кода уже принимает int fd, а переписать это на нормальный интерфейс - лень, или когда какая-то программа в цепочке не умеет в pipe.

В первом случае, кстати, в современном linux можно использовать memfd_create(), довольно полезная вещь, в плане "замести мусор под кровать".

Другая проблема с временными файлами - всякие странные программы не уважают настройку TMPDIR, и пытаются напрямую писать в /tmp, причем, придумывая какие-то дикие способы разграничения доступов и "непересечения" с другими экземплярами.

Вот вам содержимое моего сессионного tmp:

./epiphany-pg-aaNPpb
./d9ca075b14fe84b587843f702e0d2466-
    {87A94AB0-E370-4cde-98D3-ACC110C5967D}
./6b047d326310867001cb39f5218a36ba-
    {87A94AB0-E370-4cde-98D3-ACC110C5967D}
./mc-pg
./mc-pg/mc-pg
./sway-ipc.10000.9709.sock
./wayland-1
./wayland-1.lock
./dbus.sock
./dbus-1
./dbus-1/services
./dbus.cfg
./ssh-XXXXXXJIAMlN
./ssh-XXXXXXJIAMlN/agent.9704

Сколько вы тут насчитали разных способов "уникализации"?

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

Кстати, немного в сторону, #TMPDIR, конечно, должна быть "сложным" путем, включающем в себя id пользователя, и session id(например, чтобы уметь эффективно очищать это барахло по окончанию сессии):

pg-> echo ${TMPDIR}
/var/tmp/10000/10953

Поэтому у меня в #stal/ix нет корневой папки /tmp.

Почему?

Потому что, по странному стечению обстоятельств, все программы, которые имеют свое сильное мнение про именование папки с временными файлами, пытаются писать в /tmp.

А у меня ее нет, зато есть /var/tmp, с разделением по сессиям.

Поэтому все такие программы ломаются, и я их все исправляю.

Чтобы этот процесс не был мучительным, я запилил небольшую библиотечку для этого - https://github.com/pg83/ix/tree/main/pkgs/lib/shim/ix

Ее применение почти автоматизировано - https://github.com/pg83/ix/blob/main/pkgs/bin/got/ix/ix.sh#L10

Прошло буквально несколько дней, и, вот, следующая версия:

https://www.phoronix.com/news/Wayland-Tearing-Control-Proto

"In the early days of Wayland one of the main philosophical driving points for this alternative to the X.Org Server was that "every frame is perfect" and would forego screen tearing among other rendering impurities. Introduced now with Wayland Protocols 1.30 though is a new staging protocol to allow screen tearing"

Ебени они там объелись, вот что.

https://maskray.me/blog/2022-11-21-relocatable-linking

Знаменитый блоггер #maskray продолжает серию постов про линкер.

На этот раз про опцию линкера "-r", которая, по сути, умеет сливать два .o файла в один, делая частичную линковку в процессе.

Не спрашивайте, зачем, если вам не нужно - то не нужно, а если нужно - то вы уже знаете.

Я-то надеялся из этой статьи узнать, что делает мутная опция gnu ld "-Ur":

"-Ur
For anything other than C++ programs, this option is equivalent to -r: it generates relocatable output--i.e., an output file that can in turn serve as input to ld. When linking C++ programs, -Ur does resolve references to constructors, unlike -r. It does not work to use -Ur on files that were themselves linked with -Ur; once the constructor table has been built, it cannot be added to. Use -Ur only for the last partial link, and -r for the others"

Вот вы понимаете, что она actually do? Я - не очень.

Мое лучшее предположение - что она включает генерацию секций .ctor(и подобных), что никто больше делать не умеет, потому что зачем???

Я так понимаю, что релевантный кусок текста от #maskray - это вот это вот:

"The linker does not create synthesized sections (.interp, .gnu.hash, .got, .plt, .comment, etc)"

Собственно, мне было бы на это пофиг, но у меня есть ровно одна программа в репозитории, которая хочет от линкера такую опцию - это https://github.com/pg83/ix/blob/main/pkgs/bin/nix/ix.sh (да, да, Nix package manager, тот самый)

В итоге, я решил, что имею полное право заменить -Ur на просто -r, https://github.com/pg83/ix/blob/main/pkgs/bld/scripts/wrapcc/kuroko/wrapcc.krk#L32, потому что какого хрена? Ну сгенерят таблицу конструкторов чуть позже, ну и ладно.

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

Какая-то совершенно феерическая тема, проект https://urho3d.io/ разделился на 2 части, https://u3d.io/

Один из разработчиков решил, что англоязычные пользователи черезчур токсичны, и решил переориентироваться на русскоязычное community - https://discourse.urho3d.io/t/the-last-english-release/7362/2

В комментария пишут, что все началось с https://github.com/urho3d/Urho3D/issues/2940 - там массово заменяли unsigned типы на signed. https://discourse.urho3d.io/t/the-last-english-release/7362/7

Я, конечно, всей душой на стороне форка, потому что "курица - не птица, а int - не тип". #unsigned

Начнем с того, что ты - пиздоглазое мудило "By the way, you are a bad programmer" - https://discourse.urho3d.io/t/the-last-english-release/7362/9

Почитайте, со ссылочками, там вкусно.

https://asahilinux.org/2022/11/november-2022-report/

Очередной status update от #asahi Linux.

Интересно почитать про пляски вокруг firmware(потому что Apple не нужно заморачиваться с кучей платформ, и они хранят firmware прямо в своем ядре!), и про power management.

Про GPU ни слова.

Вот вам сегодня анекдот на тему "у гениев свои причуды".

Я сортирую списки зависимостей не по алфавиту, не лексикографически, а по длине строки - https://github.com/pg83/ix/blob/main/pkgs/lib/web/kit/gtk/t/ix.sh#L8

Мне почему-то так проще искать, есть ли нужная зависимость, или нет. Почему? Не знаю!

Еще мне нравится смотреть, как эти строчки выстраиваются в красивую сигмоиду, по мере увеличения списка зависимостей.

Как вы теперь будете жить с этим знанием - не знаю, и знать не хочу!

❗️Путин заявил, что в предстоящие 10 лет надо обеспечить массовое внедрение искусственного интеллекта во все сферы

Несколько ссылок, с общей темой "инструменты разработки"

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

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

https://www.ixbt.com/news/2022/11/24/u-google-est-sekretnyj-proekt-kompanija-rabotaet-nad-generatorom-kotoryj-smozhet-samostojatelno-pisat-i-ispravljat-kod.html

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

Очень крутая тема, потому что обновление внешних зависимостей - это боль, но, довольно часто, это рутина по исправлению небольших сниппетов кода там и сям.

Я так понял, что изначальная цель проекта не достигнута?

https://sapling-scm.com/

Новая SCM от Facebook. Я не смотрел, потому что, насколько я понял, мякотку в виде распределенного сервера, способного хранить огромную репу, они не выложили.

Судя по качеству исполнения, это, все же, дочь программиста!

У меня тут одна зависимость потребовала новую(для меня!) библиотеку - https://github.com/HowardHinnant/date

Пока я чинил ее работоспособность в #stal/ix - https://github.com/pg83/ix/blob/main/pkgs/lib/date/ix/ix.sh (поменял пути, и добавил поддержку TZ env variable), задумался вот на какую тему.

Современные библиотеки не стесняются с тем, чтобы распарсить какие-нибудь arcane данные, доставшиеся в наследство от libc и прочих, не очень качественных, по современным стандартам, библиотек.

Ну, вот, реально - я знаю библиотеки, которые:

* парсят #terminfo database от ncurses
* парсят таймзоны
* умеют перетрахивать формат от gettext
* где-то я видел код, который напрямую работает с базой данных от libmagic, но, с ходу, не нашел
* системное хранилище сертификатов

Еще лет 5 - 7 назад это было как-то не принято - ты или готовил эти данные сам, или трахался с вызовом libc через ffi.

Я это связываю с появлением rust и go(видимо, java не смогла создать необходимое давление), где звать libc(и прочий шлак) в какой-то момент стало моветоном, люди разобрались в этом мусоре, и научились парсить его сами.

Это, конечно, хорошо, потому что тот же API в c для работы с таймзонами - это шлак, да и API ncurses - тоже.

Я тут, при очередной пересборки мира, обнаружил в dmesg красивое:

[316266.607298] clang[19065]: segfault at 0 
ip 00000000070e1d80 sp 00007efe96c97808 
error 4 in clang-15[3613000+3ad7000]
[316266.607306] Code: 09 80 38 ...

Это, конечно, очень грустно, потому что:

* если это происходит на этапе configure, то gnu #autohell кладет с прибором на это знание, и просто считает, что в системе нет какой-то фичи.

* если такое произошло во время сборки - то это особенно плохо, потому что, получается, где-то есть makefile, игнорирующий ошибки. А это, как вы сами понимаете, просто леденящий душу пиздец, потому что бывает segfault, а бывает что на сборочной ферме место закончилось.

Я заново пересобрал мир, без кеша, грепнул лог, и нашел, что так себя ведет сборка graphviz:

https://github.com/pg83/ix/blob/main/pkgs/bin/graphviz/autohell/ix.sh#L69

Такое ощущение, что там race с генерацией .c/.h файлов из grammar.y (грамматика на bison), и компилятор получает на вход неполный файл.

Ощущение такое, потому что сборка в один поток помогла.

В graphviz есть две системы сборки, одна на autohell, вторая - на cmake.

Сначала я попробовал переделать все на cmake сборку, но там напрочь сломана возможность статической линковки, потому что, в рамках одной программы, получается 2 определения функции:

https://gitlab.com/graphviz/graphviz/-/blob/main/lib/pack/ccomps.c#L671

https://gitlab.com/graphviz/graphviz/-/blob/main/lib/gvpr/actions.c#L110

Функции разные, сигнатуры - разные, имя одно.

Треш, угар, содомия, я решил попробовать полечить сборку с autohell, и набрел на решение со сборкой в один поток.

Наверное, по результатам импровизированного субботнего LSR, надо бы с этим сделать что-то системное, например, следить за ошибками в dmesg во время выполнения графа сборки.