И, закрывая тему #wayland на сегодня, скажу, что меня дико бесит способ распространения их протоколов.

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

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

d.lld: error: duplicate symbol: zwp_linux_dmabuf_v1_interface
>>> defined at wayland-linux-dmabuf-unstable-v1-protocol.c
>>> wayland-linux-dmabuf-unstable-v1-protocol.c.o:(zwp_linux_dmabuf_v1_interface) in archive /ix/store/vG3f4y9IuqH0uqOa-lib-qt-6-wayland/./plugins/wayland-graphics-integration-server/libqt-wayland-compositor-linux-dmabuf-unstable-v1.a
>>> defined at linux-dmabuf-unstable-v1-protocol.c:76 (/ix/build/dKHxjGBeXc36a9Nv/obj/src/egl/wayland/wayland-drm/linux-dmabuf-unstable-v1-protocol.c:76)
>>> meson-generated_.._wayland_wayland-drm_linux-dmabuf-unstable-v1-protocol.c.o:(.rodata.zwp_linux_dmabuf_v1_interface+0x0) in archive /ix/store/dKHxjGBeXc36a9Nv-lib-mesa/lib/libEGL.a

ld.lld: error: duplicate symbol: zwp_linux_buffer_params_v1_interface
>>> defined at wayland-linux-dmabuf-unstable-v1-protocol.c
>>> wayland-linux-dmabuf-unstable-v1-protocol.c.o:(zwp_linux_buffer_params_v1_interface) in archive /ix/store/vG3f4y9IuqH0uqOa-lib-qt-6-wayland/./plugins/wayland-graphics-integration-server/libqt-wayland-compositor-linux-dmabuf-unstable-v1.a
>>> defined at linux-dmabuf-unstable-v1-protocol.c:94 (/ix/build/dKHxjGBeXc36a9Nv/obj/src/egl/wayland/wayland-drm/linux-dmabuf-unstable-v1-protocol.c:94)
>>> meson-generated_.._wayland_wayland-drm_linux-dmabuf-unstable-v1-protocol.c.o:(.rodata.zwp_linux_buffer_params_v1_interface+0x0) in archive /ix/store/dKHxjGBeXc36a9Nv-lib-mesa/lib/libEGL.a
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)

Я, честно говоря, подзадолбался ходить по библиотекам, и переименовывать там эти символы - https://github.com/pg83/ix/blob/main/pkgs/lib/wpe/fdo/ix.sh#L18. В .so их, понятное дело, просто скрывают.

https://bluewhalesystems.blogspot.com/2022/11/mold-linker-may-not-switch-to-source.html

Подоспел ответ от Rui.

IANAL, но, КМК, он еще меньше lawyer, чем я, судя по придуманной им схеме.

"That is, we claim that the output from the linker is a derivative work of the linker. That's a bold claim but not entirely nonsense since the linker copies some code from itself to the an output. Therefore, there's room to claim that the linker's output is a derivative work of the linker, and since the linker is AGPL, the license propagates"

1) Ну даже он сумеет показать, что verbatim слинкованный бинарь идет под AGPL, и что? Это же не будет иметь отношения к исходникам.

2) Ну не будут распространять бинари, слинкованные mold. Разрабы, которым приходится линковать chromium, будут это делать, а CI продолжит варить бинари в прод через lld.

Короче, он там чем-то явно упоролся.

#llvmweekly

https://uob-hpc.github.io/rtb/

А вот классный сайт, где можно посмотреть на скорость сборки кода разными версиями clang и gcc, во времени, ну и всякие другие (несколько менее полезные) метрики.

https://discourse.llvm.org/t/rtb-tracking-compile-time-and-compiler-sizes-for-llvm-and-gcc/66461 - анонс.

TL;DR - там давно уже ничего не происходит, ни в gcc, ни в clang.

Илон Маск выдвинул сотрудникам Twitter ультиматум: усердно работать или уволиться — Washington Post

У меня, на самом деле, довольно неоднозначное отношение к этому заявлению.

С одной стороны, кто платит, тот и заказывает музыку.

С другой:

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

* КМК, его действия идут вразрез с моими личными интересами, а потому он негодяй, редиска, и ходить к нему на работу - не надо. Возможность full femote - это благо, доставшееся от периода короновируса, с хера он хочет это отменить?

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

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

То самое ощущение, когда ты закончил собирать новый мир с llvm, а тебе прилетели sqlite + cmake, от которых весь мир эффективно зависит...

https://daniel.haxx.se/blog/2022/11/17/considering-c99-for-curl/

Тут вот Даня написал ужасный старперский текст, почему curl не будет использовать c99, и останется на c89.

Весь тект можно не читать, достаточно одного абзаца этой воды:

"So sure, there are lots of cool things we could use. But do we need them?

For several of the features above, we already have decent and functional replacements. Several of the features don’t matter. The rest risk becoming distractions"

Классический "X не нужен". Ну так-то и с89 тебе не нужен, строго говоря, пиши на K&R, или на ассемблере.

Я бы, на его месте, написал бы: "Идите в жопу, мне 60 51, на чем хочу, на том и пишу, а чего добился ты, аноним?"

Борцов с large IT прибыло: #money

https://github.com/ReimuNotMoe/ydotool#more-talks

"Independent software developers in China, like us, have 10 times more life pressure than Marak, the author of faker.js. Since ydotool has the opportunity to benefit large IT companies who won't pay a penny to us, we've changed the license to AGPLv3. These large IT companies are the main cause of life pressure here, such as the "996" working hours.

Marak's fate will repeat on all open source developers eventually (of course we aren't talking about those who were born in billionare families) if we just keep fighting with each other and do nothing to improve the situation. If you make open source software as well, don't hesitate to ask for donations if you actually want them.

Also make sure you understand all the terms of AGPLv3 before using this software"

Я не понимаю, что происходит в головах у этих людей.

"У меня есть хобби, мне оно нравится, а еще чтобы деньги за него платили"

Ну, в жизни так редко бывает.

https://maskray.me/blog/2022-11-13-odr-violation-detection

Текст от #maskray, про то, как разные фреймворки реализуют поиск ODR violation.

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

Но я вот не знал, как это делает asan runtime, красивое.

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"

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