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 во время выполнения графа сборки.

https://github.com/luajit-remake/luajit-remake

А вот еще один подход к lua jit, поверх llvm, в полтора раза быстрее, чем luajit(кстати, в свое время luajit считался вполне себе state of the art jit).

Пока только lua 5.1, и без GC(поэтому статус бенчмарков не очень понятен).

Очень, очень интересный проект, хотя код лично мне показался несколько overengineered.

Продолжаю свой quest for #terminal.

#zutty

Напомню, что пока использую #foot, но и к нему у меня есть претензии(автор череcчур переусложнил логику инкрементальной перерисовки, и она у него иногда глючит).

Вот, новые кандидаты:

* https://github.com/tomscii/zutty - по коду (нормальный такой С++) хороший, качественный, терминал, но жестко прибит к X. "жестко" - надо переделать ввод, и настройку opengl контекста, все остальное делается поверх opengl. Модель рендеринга примитивная, без изъебов и шейдеров, как я уже пару раз описывал, и это очень хорошо! IMHO для переделки этого на SDL нужно 2 - 3 вечера. К сожалению, непонятно, примет ли автор такиеисправления, потому что он ну очень любит X, а просто так время было бы жалко тратить.

* https://github.com/91861/wayst - wayland + opengl, кодовая база на C, что заметно, потому что терминал не прошел мой стандартный тест:

-> cat some.big.tar.gz
...
[warning] Unknown escape sequence: (-40)
[warning] Unknown escape sequence: ␂ (2)
[warning] Unknown DCS: HH␖␒h␐j␍␊[40m␈q'␔i
␘"n[40m␆%_;␛K#F@␈
=e.Eϝ%[40m␐j?␜һ0␒(
ƽH␟ev␎mcf␓[40m␎␔GO␐pW␈
#Bq␚*x␎␓␛t␋␂i␅<zT[␈D(kx.,Z␎Lv^
ʤ_V sqb␡␋␒wI]lc]b'<?̮␜,␗ gKq␌
r4@EwqE␆pY߻V␚]␍␊~Z^␌?چRZpw')ҋ;8
V^K<{.y␍z·`G␄␃i>RTD:,,eAY␂c3n,̑[40m
␑␌MG,S␃2z`";=Yu`3␋x6␟F=1uL
[40m␋MiR␆TjL[40m␓x␍␊Ag␁␘.␃FN-ʪ
;Kc٥#0|4␖s.[40m␉1'U;<␏sb␑:Fh␙]␌e
␐D␛_ӿ[40m␍␊_ÿݟ[40m␡
[warning] Unknown escape sequence: (-62)
[warning] DECBI/DECFI not implemented
[warning] Unknown escape sequence:  (-99)
[warning] Unknown escape sequence:  (-85)
[warning] Unknown escape sequence: (-51)
[warning] Unknown escape sequence:  (-102)
[warning] Unknown escape sequence: , (44)
[warning] Unknown escape sequence: (-24)
[warning] Unknown escape sequence: (-55)
[warning] Unknown escape sequence:  (-70)
[warning] Unknown escape sequence: (-36)
[warning] Unknown escape sequence: K (75)
[warning] Unknown escape sequence:  (-9)
[warning] Unknown escape sequence:  (-124)
[warning] Unknown escape sequence: (-12)
[warning] Unknown escape sequence: (-46)
Segmentation fault

Да и какие-то странные артефакты рендеринга, как будто автор захотел быть святее папы римского freetype, и навернул там что-то типа (глючного и косого!) clear type.

Короче, какая-то пионерская поделка, а, на первый взгляд, выглядело хорошо!

У меня вчера, внезапно, пропал wifi на ноутбуке.

Ну вот так, посреди закачки, взял и пропал.

Рестарт не помог, кроме того замечательного факта, что в dmesg(после рестарта) не было никакого упоминания слов intel, iw*, etc.

Устройства не было, интерфейса тоже.

Я собрал ведро с диагностикой, добавил дополнительных драйверов, перезагрузился раз 10, в том числе, в live cd от федоры(в нем тоже не работало), и, в какой-то момент обнаружил, что wifi заработал.

Мне кажется, что произошло это в тот момент, когда я вынул type-c кабель питания, и на его место воткнул внешний жесткий диск с федорой. До этого, диск с федорой я втыкал во второй слот type-c.

Гипотеза заключается в том, что контроллер зарядки(а он, напомню, продолжает работать даже после отключения ноутбука по питанию) пришел в какое-то очень странное состояние, "ломавшее" что-то на шине.

В пользу этой гипотезы есть еще тот факт, что с контроллером зарядки у меня явно что-то не так последние пару месяцев, потому что бывает следующее:

* огонек зарядки светится, а зарядка не идет, ноутбук выключается по питанию

* контроллер вообще не видит зарядное устройство, зарядка не идет, пока не перевоткнешь шнур

Это все звучит довольно диковато, но я больше не понимаю, как объяснить тот факт, что wifi выключился, когда я включил ноут в зарядку, и починился, когда я его из зарядки вынул, и включил в этот порт какое-то другое устройство.

Зато 2 часа бессмысленного и беспощадного(потому что ничего не понял) #debug, за время которого я узнал кучу бесполезных знаний про сеть в Linux, и про устройства своего ноутбука!

* например, у меня есть кнопка принудительного(аппаратного) отключения тачпада, Fn-F9, сяомишники знатно потешаются над этим фактом в разных там форумах, чуть ли не первый вопрос новичку, не нажал ли он эту кнопку случайно.

* в первый раз в жизни запустил команду "ip a", увидел интерфейс sit0, и разобрался, что это такое(спойлер - вам это не нужно).

Ну и так далее.

Недавно рассказывал, что соорудил рендеринг #svg иконок в png, через #inkscape.

Все же, мне этот процесс кажется не очень технологичным:

* Inkscape - overkill по зависимостям
* И, хотя я и сделал, что от пакета с иконками зависит только финальный #realm, все равно, inkscape пересобирается довольно часто, и приводит к пересборке иконок.
* Еще он срет в консоль сообщениями про то, что, мол, не может найти display.

Поэтому я решил найти что-то попроще!

Сначала гугл мне посоветовал https://github.com/cppfw/svgren

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

* Он распилил проект на очень много маленьких зависимостей, которые надо опакетить.

* Так-то оно, может, и неплохо, но он к ним запилил свою систему сборки, с классным названием prorab - https://github.com/cppfw/svgren/blob/master/makefile, и с не менее классным определением библиотек в системе, с чем я уже развлекаться не захотел.

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

Вторым вариантом гугл мне предложил https://github.com/sammycage/lunasvg, на ней я и остановился.

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

"Из коробки" мне не понравилось только сглаживание, поэтому я наладил такой вот процесс https://github.com/pg83/ix/blob/main/pkgs/bld/iconker/lunasvg/iconker.py:

* Рендерим иконку в большом разрешении
* Ресайзим через Imagemagic's convert во все нужные разрешения

Заодно оно стало быстрее работать, потому что рендеринг, все же, медленнее, чем resize.

Хорошая, годная, библиотека, подумываю написать поверх нее pixman loader, вместо librsvg-шного.

https://connortumbleson.com/2022/11/28/open-source-saying-no/

Тут вот очередной зумер рассказывает про какую-то проблему open source.

Дело тут, конечно, не в open source, он рассказывает про проблемы любого bloated софта. Хоть open source, хоть корпоративного, хоть какого.

Я писал, и буду писать, что эта проблема решается тем, что некоторый софт надо считать законченным. Вот, реально:

* библиотека замораживает свой код
* принимает только багфиксы
* никаких новых фич

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

Желающие переходят на новую библиотеку, или не переходят.

Проблема тут в следующем:

* Человек, словивший хайп в OSS один раз, вряд ли сумеет его словить во второй раз, поэтому все новое тащат в первое удачное и популярное решение, раздувая его до невозможности.

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

Поэтому, кстати, в Rust/Go проблема с этим стоит гораздо слабее, если стоит вовсе, потому что распилить библиотеку на части, и притащить новую зависимость - очень просто.

Вот бы в С++ кто-то этим озаботился - сделал бы нормальную std2, выкинув оттуда все наслоения, типа iostream, регулярок, локалей, и прочего шлака. Мечты, мечты.

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

Сегодня две истории про это.

* https://download.gnome.org/sources/gtk+/3.24/

Вышла новая версия gtk3 - https://download.gnome.org/sources/gtk+/3.24/gtk%2B-3.24.35.tar.xz - от 22 ноября.

В этот архив забыли положить meson.build из https://gitlab.gnome.org/GNOME/gtk/-/tree/gtk-3-24/gdk/wayland/cursor.

Я не знаю, что за рукожоп это делал, но файла нет, и проект без него не собирается, мне пришлось его доложить прямо в сборку, в виде патча. https://github.com/pg83/ix/blob/main/pkgs/lib/gtk/3/ix.sh#L29

Думаю, что RH собирает этот пакет через configure, пакет делает какой-то человек руками, и ему похер на сборку meson.

* Есть такой интересный проект - https://github.com/hyprwm/Hyprland #hyprland

Это такая альтернатива sway, только со свистелками и перделками.

https://github.com/hyprwm/Hyprland/releases/download/v0.18.0beta/source-v0.18.0beta.tar.gz - вот они сделали tgz руками, https://github.com/hyprwm/Hyprland/archive/refs/tags/v0.18.0beta.tar.gz - а это снепшот репозитория.

Признаться, я не понял, что там за наркомания, такое ощущение, что для ручного пакета они взяли содержимое папки src/, и доточили его напильником.

Я через их makefile собрать не сумел, поэтому взял снепшот репозитория, он собирается.

Кстати, раз уж начал про этот проект!

Я на нем могу очень хорошо продемонстрировать свой способ patchwork.

https://github.com/hyprwm/Hyprland/blob/main/src/helpers/SubsurfaceTree.hpp#L27

Зацените оператор сравнения. Он не объявлен const. Поэтому он работает в libstdc++, но не работает в clang/libc++ (например, при попытке вызвать list.erase() с такими элементами).

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

А процедурный патч - https://github.com/pg83/ix/blob/main/pkgs/bin/hyprland/unwrap/ix.sh#L42 - занимает 5 строчек кода, потому что природа патча вполне регулярна!

(Кстати, проект хороший, если хочется поучаствовать в OSS движухе - занесите им это исправление! https://github.com/pg83/ix/blob/main/pkgs/bin/hyprland/unwrap/ix.sh#L59 - там еще два патча про фикс сборки с libc++/clang, но они не такие sexy)

https://www.phoronix.com/news/RFC-eBPF-Linux-Scheduler (#ebpf #uring #future)

#ebpf едет в шедулер, а, значит, я скоро смогу попробовать запустить в него свои шаловливые ручки #ananicy

"The belief is that with eBPF support for the Linux kernel scheduler it could ease experimentation and exploration of new scheduling policies, allow for application-specific schedulers and other customizable options via the loading of custom BPF programs, and provide a non-disruptive way for changing out scheduling policies within production environments"

Ну и, совсем не удивляет, что "Engineers from both Google and Meta (Facebook) are behind this initiative"

Пост для гиков.

Если поглядеть на картинку (и тред), то маленькая иконка OpenAI указывает на то, как GPT находит баги и эксплоиты в коде (тут конкретно в коде смартконтрактов). Они (пока) простые и достаточно распространенные, но то, как GPT их описывает жутко интересно. А также он декомпилирует байткод и описывает что он делает.
Это я к чему.
Если нужно будет захватить мир путем взлома человеческой инфраструктуры - то ИИ уже готов - дайте только доступ в интернет. И готовьте свои метамаски.
https://twitter.com/gf_256/status/1598104835848798208

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

Запилил я gdk pixbuf #svg loader поверх #lunasvg!

В процессе, конечно, узнал много чего интересного, чем и спешу поделиться.

Короткая предыстория:

* Сперва у меня вообще не было рендера svg, потому что #rsvg перешел на Rust, а его у меня (пока?) нет.

* Потом я научился использовать довольно старую версию librsvg, которая была написана на C, и глючила, что пиздец - 1/4 иконок была отренжерена с какими-то артефактами. Это, конечно, то еще достижение, учитывая простоту формата svg.

* Потом я научился готовить для всех scalable иконок png заранее, с помощью inkscape. Примерно для 1/4 оставшихся использовался старый rsvg render, с баглом и артефактами.

* Потом я нашел замечательную #lunasvg, и перешел на нее для рендеринга png, а то, что мой процесс не находил, или были нужны какие-то особенные разрешения, использовался старый rsvg.

* (мы находимся тут) -> png рендерятся с помощью lunasvg, остатки - тоже.

https://github.com/pg83/ix/blob/main/pkgs/lib/lunasvg/gdk/io.cpp - вот код клея между lunasvg и gdk-pixbuf.

БОльшую часть кода я написал за полчаса, а потом еще часа 3 трахался за последние 5 строк кода, без которых на экране был мусор:

* Примерно полтора часа - это "нормальная" отладка - разбирательство с тем, в каком формате поверхность отдает lunasvg, в каком ожидает GdkPixbuf, и как их "поженить", разбирательство с моделью владения памятью в glib(чтобы не текло и не ездило по use-after-free), и с обработкой ошибок в ней же.

* А вторые полтора часа - это какая-то совершенно безумная ебала, когда, на первый взгляд, я делаю все правильно, при этом, знаю, что command line часть lunasvg родила корректный png, но, если отрендерить его в динамике моим кодом, то на экране - мусор.

В какой-то момент времени я остановился, и подумал: "А какое бы безумное действие я мог бы совершить на месте авторов gtk, чтобы у меня ничего не работало"?

Единственное, что мне пришло в голову - что они, зачем-то, портят xml с svg, перед тем, как его передать мне. Ну потому что как еще объяснить факт, что pixmap data получается разная?

Sooka! Sooka! Аааа!

https://github.com/GNOME/gtk/blob/main/gtk/gdkpixbufutils.c#L249

Короче, они манглят svg во вложенный svg в виде base64 блоба. КМК, это сделано затем, чтобы указать уникальный размер для рендеринга. Да, да, в scalable vector graphics есть width, и height, чтобы им пусто было.

Я, конечно, решил, что раз эти негодяи формируют xml через printf, то парсить я его буду регулярками. https://github.com/pg83/ix/blob/main/pkgs/lib/lunasvg/gdk/io.cpp#L93 (да, да, это точно надо занести в upstream)

После этого почти(в следующей серии!) все заработало, иконки выглядят очень хорошо, всяко лучше, чем в бажной и глючной старой librsvg.