Прекрасный пост про статическую линковку, from Hacker News. https://gavinhoward.com/2021/10/static-linking-considered-harmful-considered-harmful/

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

#gavin

И перепалка разработчиков #glib и musl(про статическую линковку), https://bugzilla.gnome.org/show_bug.cgi?id=768215#c16 . #GNOME

"UNIX is simple and coherent..." - Dennis Ritchie
"GNU's Not UNIX" - Richard Stallman

———
https://woodrush.github.io/blog/posts/2022-01-16-neural-networks-in-pure-lisp.html

Статья, конечно, не про нейронные сети, а про то, как сделать float, имея на руках структуру данных в 1 бит.

———
Full disclosure - я очень не люблю gstreamer. Его пилили какие-то сумасшедшие, которые решили, что граф обработки multimedia может свалиться в runtime, а не в момент его конструирования. Графы там сложные, падают почем зря. Ну и 15 лет назад библиотека была настолько нестабильна, что я чуть не поседел, пытаясь ей воспользоваться.

https://gstreamer.freedesktop.org/features/

Graph-based structure allows arbitrary pipeline construction

И произвольные падения в runtime. Потому что надо не arbitrary, а только те, что имеют смысл в runtime.

Based on GLib 2.0 object model for object-oriented design and inheritance

Хуже объектной модели #glib не бывает вообще ничего. Магия на препроцессоре, которая приводит к генерации исходников похлеще, чем в С++, шаг влево - вправо - расстрел на месте. Про 10 уровней indirection и про то, что все в куче - я вообще молчу(а потом удивляются, почему программы на GTK жрут памяти больше и работают медленнее, чем QT)

Compact core library of less than 500KB, about 65 K lines of code

pg@fedora:~/mix/store/vVPM7CFLUYaHJm8iL-lib-gstreamer-19/lib du
376  ./pkgconfig
97116  .

100 мегабайт, и сюда не входит mpeg/libav/ogg/etc

Multi-threaded pipelines are trivial and transparent to construct

Нет.

Clean, simple and stable API for both plugin and application developers

Знаете, кому и кобыла - невеста. Возможно, коллеги не видели clean and simple API.

Короче, если есть выбор - берите ffmpeg. К сожалению, WebKit использует gstreamer, поэтому пришлось повозиться.

———
https://www.da.vidbuchanan.co.uk/blog/webos-wampage.html

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

Взлом WebOS через кеш байткода в V8. long story short - имплантируем в кеш байткода проезд по памяти, и, благодаря этому, забираемся в потроха браузера.

Я давно откладывал эту тему, но вот вышла эта новость, и, видимо, пора:

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

"Отмечается, что для полноценной работы приложений на базе SDL в Wayland требуется наличие библиотеки #libdecor для декорирования окон на стороне клиента."

libdecor - это леденящий душу пиздец.

Очень хорошо со стеком #glib /gtk я познакомился под НГ, когда собирал себе браузер Epiphany, на основе WebKitGTK(*).

* Он написан на диалекте С от GNU. Это очень странная объектная система, которая позволяет конструировать классы на лету, и несщадно тормозит, потому что минимум 2 уровня косвенности.

* Он жрет много памяти. Потому что любой объект в куче, там нет оптимизации любой нормальной VM, позволяющей создавать большинство объектов на стеке.

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

* Он косой и кривой - я заметил, что браузер всегда мерцает(1 кадр - белый фон, второй - реальная картинка(видос записывать лень)). Бугага, зато девелоперы пишут победные статьи - https://blogs.igalia.com/carlosgc/2017/02/10/accelerated-compositing-in-webkitgtk-2-14-4/. Ремарка - плохие девелоперы у Igalia, не у WebKit.

В процессе исследования это проблемы я пришел к следующему интересному выводу: динамической линковкой в мире OSS решают две проблемы:

* Кто-то с кем-то не договорился. #fontconfig
* Круговые зависимости.

Сегодня про первую проблему :) #GNOME #SSD

Вот такой феерический тред - https://gitlab.gnome.org/GNOME/mutter/-/issues/217. Обязательно его прочитайте! Краткое содержание - все упрашивают разработчиков Gnome добавить поддержку server side decorations, а они отказываются, мотивируя тем:

* Что могут(Wayland не требует поддержки SSD).

* Что их собственный композитор не зависит и не должен зависеть от GTK. Дебилы, у меня нет других слов.

И, тем самым, не-GTK приложения должны в себя влинковывать GTK, чтобы не выглядеть в Gnome чужеродно. Чувствуете логику, да? То есть, не 1 гномовский композитор должен зависеть от их платформенной библиотеки, а каждое приложение на QT должно зависеть от чужой платформенной библиотеки.

Короче, TL;DR - они не договорились, и появилась библиотека libdecor, которая должна в runtime загрузить в себя плагин, который загрузит GTK в QT приложение, запустит в отдельном event loop GTK, и будет отрисовывать клиенсткие декорации.

Я думаю, последствия такого леденящего душу пиздеца очевидны - надежность и так ненадежного кода падает в разы, потребление памяти растет, сложность растет, у клиентов все глючит, потому что библиотека не может найти сраный плагин(это вообще такая особенность плагинов в мире OSS), и потому что определение того, под каким DE мы запущены, глючит.

И вот, теперь безвинные приложения на SDL будут загружать это УГ, и рисовать им декорации.

Я после этого треда очень сильно поменял свое отношение к этим упырям из Gnome, они реально негодяи. Считают, что GTK - это платформенный тулкит, и все должны под него подстраиваться. С его-то проблемами.

* Почему WebKIT? Мне показалось, что его проще всего собрать, потому что меньше мудохаться с вендорингом. Я ошибался, но это уже другая история.

Обещал про динамическую линковку в OSS. #GNOME

Есть такая библиотека - #glib. И в ней типа есть возможность использовать tls. Ну, была раньше. Потом поддержку tls вынесли в отдельную либу - https://gitlab.gnome.org/GNOME/glib-networking, видимо, по лицензионным соображениям(раньше же openssl и GPL были несовместимы), но это же OSS, поэтому glib продолжает делать вид, что умеет в tls.

При попытке использования tls glib пытается загрузить glib networking, и сыпется, если это невозможно. Отделили, да.

Поэтому всякий там код, который хочет использовать tls, проверяет наличие этого загружаемого модуля во время компиляции:

Checking if "GIO has real TLS support" with
 dependencies glib-2.0, gmodule-2.0,
 gobject-2.0, gio-2.0 runs: NO (1)

Реально, вдумайтесь в происходящий цирк.

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

К счастью, libc от проекта gnu очень хорошо умеет жить с кольцевыми зависимостями(UPD: а до последнего времени был пиздец о n^3 - https://habr.com/ru/post/451208):

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

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

Выскажу такую мысль - примерно треть проблем, которые можно увидеть на разных форумах про Linux(ладно, я на LOR смотрел) - это проблемы разбиения приложения на плагины. Неработающий звук - 100% посреди цепочки какой-нить pipewire не может найти плагин с alsa. Неработающее ускорение видео в браузере - 100% Mesa не может найти плагин для какого-нить vdpau. И так далее.

Обычно причины этому следующие:

* Пути не стандартизованы. Драйвер от nvidia может положить интерфейс для ускорения декодирования не туда, где его ожидает увидеть mesa.

* Не прописана зависимость, плагина просто нет на FS

* Плагин сломан(не хватает каких-то символов), не загружается.

Тестов на это все нет, и не будет.

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

В одном там рабочем чате с коллегами зашла речь, кто как смотрит порно. Мне пришлось признаться, что я для этого использую рабочий macbook, потому что в моем браузере все еще не работает поддержка видео. Собственно, у меня там 3 заметных проблемы:

1) Поддержка видео. Как починю, обязательно напишу про эту эпичную историю.
2) Про кривые иконки из-за старой librsvg я уже писал, надо или как-то затащить Rust, или научить это оффлоадить в inkscape. Я склоняюсь ко второму пути.
3) И сегодняшняя история - поддержка PDF!

Epiphany, как и многие, поддерживает PDF через PDF.JS. Но оно почему-то не работает. Конечно, как обычно, дело в динамическом связывании - код, которому нужен код читалки, не может его найти в runtime. И в данном случае дело не в статической линковке, а в чем-то еще(что-то с ресурсной системой glib, я не разобрался пока).

Чинить это займет время, а pdf-ки читать надо уже сейчас.

Я решил вечерочком собрать себе читалку - Evince. Думал, плевое дело, простая программа, все зависимости уже в репе, 5 минут, не больше. Ага, конечно.

* В программе есть плагины. Читатели у меня уже прошаренные, поэтому я просто скажу, что загрузка плагинов там по второму типу #plugins Плагины много времени не заняли, все же, это основная фишка дистрибутива.

* После загрузки программы я увидел надпись "unsupported mime type application/octet-stream", и тут я понял, что это надолго.

Не буду утомлять скучными подробностями #debug, но:

* glib неявно зависит от базы данных для определения mime types. Неявно - значит, все делает вид, что работает, до поры до времени, примерно как TLS в той же #glib.

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

* Самое страшное - сборка этих данных зависит от docbook xml, а это моя дикая боль. Я напишу об этом отдельно, но надо понимать, что там очень сложная динамическая линковка данных поверх XML, все это сдобрено perl, с легким налетом GNU. Я это затащить могу, но очень не хочу, и пока просто обходил стороной. А тут жесткая зависимость сборки.

Короче, я решил, что вместо всей этой херни я вкорячу старую-добрую libmagic, из пакета file https://www.darwinsys.com/file/. Хороший, древний, проверенный код, без изъебов.

revision 1.1
date: 1987/08/23 19:51:05;  author: ian;  state: Exp;
Initial revision

Код чуть младше меня.

Замечания по ходу процесса:

* Пришлось сделать thread-safe обертку над api libmagic: https://github.com/pg83/mix/blob/main/pkgs/lib/mimetype/mix.sh

* Как оно используется: https://github.com/pg83/mix/blob/main/pkgs/lib/glib/01.diff (блин, а код без аллокаций на C писать вполне норм!) Я бы хотел тут остановиться, и сказать, что оно заработало like a charm, но нет

* glib сначала пытается определить тип по расширению, в #libmagic этого нет. Я это обошел тем, что всегда определяю по данным. NVMe все стерпит.

* Без нужных ему данных glib определяет длину буфера для autodetect в 0. Ну, починил.

* Названия mime types в библиотеках немного расходятся. К счастью, авторы Evince это предусмотрели, и добавить нужный mime type было несложно.

Короче, все заработало, а бонусом я выяснил, что в диалоге открытия файлов в GTK не работали иконки, потому что им нужен mimetype. А я и не замечал.

Почему freedesktop не взяли эту либу за основу, я не понимаю. Ведь в OSS так много свободных рук.

#dbus #systemd

https://www.phoronix.com/news/Ubuntu-23.10-Dbus-Broker-Plan

dbus-broker - это замена dbus-daemon, но:

* linux-only
* https://github.com/bus1/dbus-broker/blob/main/meson.build#L76 довольно безальтернативно зависит от libsystemd, без нее глючит в плане запуска процессов
* зависит от каких-то велосипедных библиотек для С - https://github.com/c-util, https://github.com/bus1/dbus-broker/blob/main/meson.build#L24 Факт того, что уже есть безальтернативная зависимость от #glib, никого не волнует - это не +-1, это +1 велосипедная либа

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

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

Мораль? Да какая мораль, все равно нас всех скоро заменит AI, пусть кожаные порезвятся напоследок.

#bootstrap #glib #rant

У меня в моем инструментарии по статической линковке всего и вся есть такой микроинструмент для сборки программ (типа интерпретаторов python, sbcl, и так далее), которые хотят невозбранно делать dlsym() на любой символ из своего же бинарника.

Все такие программы добавляют флаг линковки -Wl,—export-dynamic, чтобы все символы были доступны через dlsym.

Я перехватываю этот флаг, и запускаю скрипт, который достанет все символы из линкующихся объектных файлов, и добавит их в мою фабрику, заменяющую dlopen/dlsym:

https://github.com/stal-ix/ix/blob/main/pkgs/bld/wrapcc/kuroko/wrapcc.krk#L120-L121
https://github.com/stal-ix/ix/blob/main/pkgs/bld/wrapcc/dynlink/dynlink.py

У этого процесса есть один недостаток - линкер не может выкинуть ни один символ, потому что как? Все они могут быть загружены через dlsym позже, в runtime.

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

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

Но вот сейчас у меня сломалась сборка какого-то goшного бинаря, с очень странным сообщением об ошибке:

github.com/gotk3/gotk3/gdk: 
    invalid flag in pkg-config 
    --cflags: -Wl,--export-dynamic

И вот тут у меня "щелкнуло"!

Я обновлял glib, и эти долбоебы добавили этот флажок линкера в экспортируемые cflags!

В транке они уже откатили, даю ссылку на коммит с откатом, там сразу видно, что было, и что стало - https://github.com/GNOME/glib/commit/6e29fbec2dbc513e81252d0a83ab1e860c80c002

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

Я тут недавно встрял на обновлении телеги, вроде, на версию 4.8.3. #gir

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

А еще коллеги завязались на gobject-introspection, видимо, для опроса каких-то сервисов по dbus.

Это какая-то всратая технология от #glib/#GNOME, когда ты загружаешь .so, и она тебе рассказывает, какие функции в ней есть, и с какими аргументами их можно звать.

Проклятая динамика, в самом худшем виде, все, как я люблю.

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

У меня это, конечно, из коробки не работало, работать заставить можно, но мне уж очень не хотелось этим заниматься.

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

* для webview я нашел в сборке ветку, которая заставляет компилироваться телегу без webview - https://github.com/desktop-app/lib_webview/blob/ebb8b8b91fe357b2c397a3eb98655c585b8c856e/CMakeLists.txt#L57-L65 Так просто попасть туда нельзя, но небольшой однострочник позволяет это сделать - https://github.com/pg83/ix/blob/main/pkgs/bin/telegram/desktop/unwrap/ix.sh#L129

* С интроспекцией было сложнее. Нужно было стереть все упоминяния про вызовы и поиск соответствующих тулзов - https://github.com/pg83/ix/blob/main/pkgs/bin/telegram/desktop/unwrap/ix.sh#L113-L119, а потом заменить места реального использования на заглушки - https://github.com/pg83/ix/blob/main/pkgs/bin/telegram/desktop/unwrap/base_system_media_controls_linux.cpp https://github.com/pg83/ix/blob/main/pkgs/bin/telegram/desktop/unwrap/integration_linux.cpp

Понятное дело, что это все довольно временное решение, ситуацию с gobject introspection, так или иначе, придется решить, а за webview я еще посражаюсь.