#mesa, свет моей жизни, искры на кончиках пальцев. Грех мой, любовь моя. Me-sa.

Для ее сборки была разработана ныне очень популярная система сборки - #meson, и, на самом деле, это очень печально, потому что разработчики Mesa слишком хорошо знают meson, и пользуются любыми всратыми ее фичами.

Фактичеси, Mesa состоит из 2 частей - загрузчика плагинов, который поверх интерфейса плагина реализует всякие там state tracker типа opengl, vulkan, и, собственно, плагинов.

Так как авторы Mesa слишком хорошо знают meson, то сборка Mesa выглядит примерно так:

* собирается K объектных файлов
* из них собирается N архивов, причем, что важно, есть пересечения - один и тот же .o может попасть в несколько архивов
* из этих K + N артефактов собирается M конечных .so. Тоже с произвольным пересечением по .a/.o файлам!

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

Пока это все собирается в .so, со скрытыми символами, это не представляет собой проблемы, кроме увеличения объема конечного кода и времени компиляции(потому что некоторые исходники таки переcобираются по нескольку раз).

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

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

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

Это нужно, чтобы поднять зависимость от драйверов до конечных программ, а все промежуточные библиотеки должны зависеть только от loader. Это важное требование, если мы не хотим пересобирать все дерево библиотек, нужных для сборки конечных GUI программ, для каждого набора драйверов, и, фактически, для нормального бинарного кеша сборки.

Я подходил к задаче распила раз 5:

* попилить по .o конечный артефакт руками. Ломается о комбинаторный взрыв различных способов собрать драйвера.
* сделать так, чтобы все собиралось в несколько полностью независимых .a файлов - все упиралось в дефекты сборочный системы meson и сособенности сборочных файлов mesa - тут я пытался руками править сборочные скрипты mesa(не масштабируется на апдейты), и саму meson(тут я был ближе всего к победе, но не срослось)

Короче, пока я эту проблему решил так:

* написал generic процедуру вычитания одного .a из другого. По именам .o файлов это сделать нельзя, по причинам что я уже описал выше, поэтому все делается посимвольно. https://github.com/pg83/mix/blob/main/pkgs/lib/mesa/t/sep/substr.py

* последовательным вычитанием привел в порядок загрузчик и библиотеку с драйверами. https://github.com/pg83/mix/blob/main/pkgs/lib/mesa/t/sep/mix.sh#L29

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

В догонку предыдущему посту про #mesa.

Забыл рассказать, что мне пришлось хачить сборочную систему mesa, потому что собрать loader с пустым списком драйверов оно не умело. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/mesa/t/nodrv/mix.sh

И действительно, кому в своем уме это может понадобиться?

(кстати, я негодую, что никто не оценил эпиграф к предыдущей записи, он классный)

———
https://www.phoronix.com/scan.php?page=article&item=apple-m1-linux-perf&num=1

Первые бенчмарки Asahi Linux, в сравнении с MacOS. Я бы сказал, что там нет ничего удивительного.

1) Linux пишут жадные капиталисты для датацентров

2) MacOS - в ожидании, что там что-то выполняется редко, но метко, и важнее отзывчивость.

3) В Asahi нет управления питанием, то есть, оно шпарит всегда на максимум.

Поэтому на CPU-bound задачах Asahi несколько лучше, что хорошо заметно на моем любимом примере компиляции. Думаю, что Mac Mini M1 с Asahi на борту - это самое cost effective решение для CI сейчас.

———
LLVM weekly

Вышел clang/llvm 14! Я уже перешел на него в Mix. Впрочем, я перешел сразу на rc1, у clang хорошие тесты.

https://reviews.llvm.org/rG827575a7f853 - libc от LLVM наращивает мускулы. Она будет непригодна для bootstrap, потому что написана на C++, но вот для сборки основного дистрибутива - будет очень интересно.

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

Писать интерфейсы на C/GTK - это пиздец как сложно, там получаются просто тонны и километры boilerplate кода. Я, если честно, совершенно не понимаю людей, которые в 21 веке пишут GUI на C.

Вот, вместо того, чтобы перейти на C++/Rust, был запилен специальный язык для разработки на GTK.

Как и все от проекта #GNOME - всратое говно.

скорее бы уже

Ну и чтобы вы не думали, что автономные робаты это только Терминаторы и Дроны-убийцы...
Двойное назначение никто не отменял.

"А по вечерам я работаю в клубе".

https://www.cnews.ru/news/line/2022-03-24_bazalt_spo_predlozhila

Все же знают, почему и Альт, и Астра - упыри, не надо лишний раз рассказывать, да? #altlinux

#linux - это embedded. #scheduler

Что такое embedded? Это когда вам дают какой-то заранее собранный и преднастроенный программно-аппаратный комплекс, который выполняет какую-то функцию, и вы его используете, как черный ящик.

Я хочу аргументировать, что все известные и выстрелившие использования ядра Linux - это embedded.

КМК, единственное сомнение в этом утверждении может вызвать использование Linux в датацентрах. Но, если посмотреть на это под правильным углом, то линукс в датацентрах - это тоже глубокий embedded, потому что:

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

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

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

Можно было бы привести в пример Android, как пример "открытой" системы, но и там:

* Прошивку вылизывает вендор

* Приложения сильно ограничены VM sandbox, которая делает много магии, чтобы они все вместе работали "плавно"

Поэтому "Linux на десктопе" - это оксюморон, он последние лет 10 точится совсем в другом напрявлении. Linux - давно не "OS общего назначения".

Правда, тут стоит отметить еще следующие факты:

* macOS - это что-то типа Android по своим свойствам, потому что Apple тюнит свою OS под ограниченный набор устройств, и очень сильно ограничивает приложения

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

Поэтому, по большому счету, у нас осталось всего полторы OS общего назначения, да и те сдают позиции.

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

https://lwn.net/Articles/889025/#Comments
https://www.opennet.ru/opennews/art.shtml?num=56902

Вышел новый #gnome GNOME. Много недовольных.

Кто-то недоволен тем, что убрали градиенты на кнопках(я из них) - https://blog.brixit.nl/the-end-of-the-nice-gtk-button/ . Лично мне кажется, что политика "все кликабельное имеет градиент" - это очень классно, и упрощает работу с GUI.

Кто-то - процессами разработки. https://informatique-libre.be/swilmet/articles/gnome-gedit-dev-feedback.pdf

Я, как обычно, недоволен пиздежом.

"В число приложений, рекомендуемых для включения по умолчанию в установки GNOME, добавлено два новых приложения - текстовый редактор Text Editor и эмулятор терминала Console. Данные приложения используют GTK 4"

UPD: то, что console использует gtk4 - ошибка перевода новости с https://release.gnome.org/42/

Полез собрать эти чудеса, потому что в живую не видел приложений на gtk4 + libadwaita.

gnome-text-editor собирается из тега, который не прошел CI тесты. https://gitlab.gnome.org/GNOME/gnome-text-editor/-/tags

gnome-console, судя по скриншоту, собрался вообще с gtk3. Я таки попробовал собрать его с gtk4, но:

* #libvte, которая нужна для console, собирается с gtk4 только в транке, тега и релиза про это еще не было вовсе

* сам код console не рассчитан на gtk4

Ну и, куда же без этого, наткнулся на очередной errogance от разрабов GNOME: https://gitlab.gnome.org/GNOME/vte/-/issues/72

Чуваки, как обычно, форсят свою повестку - "API Linux определяет glibc"(по ссылке офигенный комментарий от автора musl, Ричарда Фелкера, про это), "мы не поддерживаем musl", etc. Технически дело в том, чтобы не использовать 1 нестандартный макрос из #glibc, все musl-based дистрибутивы патчат это место - https://git.alpinelinux.org/aports/tree/community/vte3/fix-W_EXITCODE.patch.

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

Мое мнение о разрабах GNOME падают все ниже и ниже плинтуса. Половина из них - #errogant(я тут не могу написать предлагаемый перевод "высокомерный" для этого слова, потому что IMHO значение немного другое) мудаки, имеющие свою нетехническую повестку(реально это воспринимается именно так - "мы тут знаем что API Linux - это glibc, и не дадим вам про это забывать, минорной проблемой, которую просто откажемся чинить, потому что можем").

https://lobste.rs/s/zlanqi/end_nice_gtk_button#c_usyuo5

gnome-text-editor, кстати, ничо так, чистенько, опрятненько, ничего лишнего.

Поддержку перехода на libadwaita(и "1 theme to rule them all"), кстати, я поддерживаю. Жалко только, что libadwaita пока - так себе закос под macOS, надо лучше.

История одного бутстрапа.

Решил я себе собрать какой-нить не-tiling wm. Выбор пал на wayfire, потому что картинки в интернете красивые. Похоже на compiz, если вы понимаете, о чем я.

https://github.com/WayfireWM/wayfire/blob/master/src/api/wayfire/plugin.hpp#L187 #plugins - первая проблема. Все плагины имеют одинаковую точку входа. И, к сожалению, в данном конкретном случае не получается модифицировать определение этого макроса, потому что его могут вызывать так - https://github.com/WayfireWM/wayfire/blob/master/plugins/single_plugins/autostart.cpp#L55 (нет законченного С токена, к которому можно привязаться).

Поэтому я испробовал новую для себя технику - переименование символов в готовых артефактах. В объектных файлах. https://github.com/pg83/mix/blob/main/pkgs/bin/wayfire/mix.sh#L51 В этом цикле мы пользуемся тем, что имя плагина совпадает с именем .cpp файла.

Потом по получившимся .o файлам строим структуры данных для моего "динамического" загрузчика - https://github.com/pg83/mix/blob/main/pkgs/bin/wayfire/mix.sh#L62

Ну и перелинковываем программу вместе с плагинами - https://github.com/pg83/mix/blob/main/pkgs/bin/wayfire/mix.sh#L71 Тут можно отметить вызов cc без -I/-L/-l, потому что моя система готовит враппер для компилятора со всеми нужными агрументами.

Казалось бы, все?

Нет, при старте программа начала кидаться исключением из какого-то глобального конструктора: https://github.com/WayfireWM/wayfire/blob/master/plugins/wobbly/wobbly.cpp#L152 У чувака таким странным образом сделан разбор аргументов командной строки. Плагин загружается уже после обработки конфига, и это как-то работает.

Ну, если уж начинать жестить - то зачем останаливаться? Я написал ленивый класс для обработки параметров конфига - https://github.com/pg83/mix/blob/main/pkgs/bin/wayfire/opts.h

Все тут же заработало? Какое там.

В логах и в strace это выглядит так - мы читаем конфиг, а дальше ничего не происходит. Потратил на это пару часов, чтобы выяснить, что автор этого кода конкретно сошел с ума - он пересекает множество запрошенных плагинов с множеством реальных файлов в папке с плагинами, чтобы отфильтровать несуществующие. Без записи об этом в лог, просто кидая на пол. https://github.com/WayfireWM/wayfire/blob/master/src/output/plugin-loader.cpp#L200 - в транке логгирование уже есть. Нормальные люди просто пытаются открыть файл по запросу, и пишут ошибку, если не получилось.

После фикса все завелось и заработало. Если найду, в комментариях будет скриншот, все же любят скриншоты! Заодно доказываю сомневающимся, что у меня есть работающая телега!

just random thoughts:

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

* У автора плагиноз головного мозга. Все сделано через плагин. Даже загрузка конфига через плагин. Кольцевая зависимость? Ничего страшного - передадим имя плагина для загрузки конфига через command line!

* Примерно половина кода проекта - поддержка перечитывания конфигурации при изменении файла с конфигом. Ну, ладно, треть. Хотя умные люди давно все придумали - общение с dbus в основном event loop.

* Для wayfire нужно было собрать https://github.com/g-truc/glm Эти упыри не только не стали делать install таргет для своей либы, но и убрали .pc файл для discover этой библиотеки, репозитариям приходится это делать вручную - https://github.com/archlinux/svntogit-community/tree/packages/glm/trunk https://github.com/archlinux/svntogit-community/blob/packages/glm/trunk/PKGBUILD#L30 Надо бы ворваться к ним в тикет, но пока нет. UPD: вломиться не получится, тикет отменили - https://github.com/g-truc/glm/issues/947

>Ну, если уж начинать жестить - то зачем останаливаться?

fun fact - я, когда страдаю "пожестить в коде", всегда вспоминаю вот эту вот сценку из Футурамы - https://www.youtube.com/watch?v=JdH3jo-A2Uw

Во внутреннем монологе это звучит как "пора обмазаться шоколадом" 😁

#обмазаться_шоколадом

llvm weekly

https://discourse.llvm.org/t/rfc-lifting-include-cleaner-missing-unused-include-detection-out-of-clangd/61228

Рефакторинг кода по очистке заголовков из clangd в отдельный инструмент. Пишут, что работает немного не так, как линтер из clang-tidy.

———
#mesa

У меня тут случилось странное - "вдруг" перестали работать приложения на Vulkan, а на OpenGL продолжали работать, хотя у меня #zink в качестве реализации OpenGL.

Я сначала подумал, что у меня сломалась видюха, от постоянного перенагрева, но потом запустил bisect.

Очень удобно, когда состояние всей системы привязано к hash коммита в репозитории, и сборочные артефакты лежат в content addressable cache - bisect я запустил на неделю назад, заняло это полчаса времени(так долго, потому что нужно вручную перезапустить WM и запустить тест).

Оказалось, что дело в минорном обновлении Mesa, с 21.3.7 на 21.3.8. https://docs.mesa3d.org/relnotes/21.3.8.html

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

Это к давнему спору о том, можно ли доверять апстриму и всей технологии #semver. Нет, нельзя.

———
https://www.phoronix.com/scan.php?page=news_item&px=Vulkan-On-Direct3D-12-Dzn-Merge

Еще новостей про Mesa. На этот раз от Collabora + Microsoft. Реализация Vulkan поверх Direct3D, для WSL. Само по себе мне это не очень интересно, но вот то, что MS последнее время серьезно коммитит в Mesa - факт.

https://www.collabora.com/news-and-blog/blog/2022/03/23/how-to-write-vulkan-driver-in-2022/ - текст от Collabora про разработку драйвера Vulkan.

———
https://old.reddit.com/r/linux/comments/thsrcp/this_was_the_first_step_in_the_interview_process/

Классный текст про собеседования в Canonical. TL;DR - они там совсем упоролись, как будто к ним очередь стоит. Ну или они нанимают для вида.

Починил таки кольцевую зависимость #harfbuzz - freetype.

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

https://git.sr.ht/~pg/mix/commit/338a5028686dd448442f796faac6bff0d0c10e75

———
В каждом увлечении есть свой священный грааль. #nvidia

(кстати, если не смотрели "Monty Python and the Holy Grail" - обязательно посмотрите)

Для меня это - статическая сборка libGL.so от Nvidia в свои программы, собранные с musl.

Если рассказать про эту задачу широкими мазками:

* https://github.com/endrazine/wcc

"WCC is a collection of compilation tools to perform binary black magic on the GNU/Linux and other POSIX platforms."

С помощью wcc можно превратить libGL.so в релоцируемую libGL.o. Вообще, сходите по ссылке, и почитайте, что умеет wcc, это действительно похоже на черную магию.

Как работает восстановление relocations, например, через таблицу plt, я не очень понимаю. Это, получается, нужно найти такие адреса, по которым записано число, совпадающее с расстоянием в этом .so от этого адреса до таблицы plt? И чтобы при дизассемблировании это оказалась jmp инструкция? Ох.

Но просто так слинковать ее в программу не получится, потому что из нее торчат вызовы в glibc.

* Переименовать все входящие в libGL.o символы, применив к ним какой-то префикс, например, gnu_.

* Далее написать кучу boilerplate кода, который бы делал примерно следующее:

GNUFILE* gnu_fopen(const char* p, const char* m) {
    FILE* f = fopen(p, m);
    GNUFILE* gf;
    // construct GNUFILE* from FILE*
    return gf;
}

Короче, реализовать все нужные символы из glibc поверх musl, сохранив layout структур из glibc.

После этого все это добро можно слинковать в один большой бинарь, все, как я люблю.

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

В следующей серии рассказ про мою скромную коллекцию бинарных хаков, с помощью которых я постепенно приближаюсь к решению этой задачи - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bld/scripts/librarian.

https://lwn.net/Articles/889444/

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

------
https://wiki.musl-libc.org/alternatives.html

Список альтернатив mainstream software, от авторов musl(что само по себе символично). Я довольно много из этого списка использую для bootstrap, потому что оно все сильно проще в сборке.

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

Хочется иметь софт, который ты понимаешь, как работает.

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

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

В продолжении темы минимализма:

"БД пакетного менеджера RPM перенесены из каталога /var/lib/rpm в /usr/lib/sysimage/rpm с заменой /var/lib/rpm на символическую ссылку. Подобное размещение уже применяется в сборках на базе rpm-ostree и в дистрибутивах SUSE/openSUSE. В качестве причины переноса называется неразделимость БД RPM с содержимым раздела /usr, в котором фактически находятся RPM-пакеты (например, размещение в разных разделах усложняет управление снапшотами ФС и откат изменений, а в случае переноса /usr теряется информация о связи с установленными пакетами)."

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

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

Такая кривая и косая статическая линковка поверх динамической, со всеми недостатками этих подходов.

#evince #gold

Я, когда собирал evince, узнал, что в последние годы случился какой-то разумный конкурент для poppler - mupdf. Это еще один open source pdf renderer.

Это довольно удивительно, потому что xpdf/poppler сообщество пишет последние лет 30. Это не суперсложная, но довольно муторная задача. Особенно учитывая, чего adobe наворотила в pdf(там и js, и хождение по сети, да вообще все).

Библиотека называется mupdf, просмотрщик - zathura.

zathura примечательна тем, что у нее плагины живут out of tree, поэтому мои обычные техники статической линковки тут не годились.

Я вышел из положения так. Собрал zathura 1 раз, оставил от сборки только заголовки. С этими заголовками собрал кучу .a файлов, для каждого плагина. После этого собрал zathura во второй раз, имея все собранные плагины под рукой.

https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/zathura - вот тут можно посмотреть на все таргеты для сборки.

Конечно, дело не обошлось без треша, куда уж там.

* mupdf имеет встроенный просмотрщик, помимо библиотеки. Он использует opengl + freeglut. Какое же было мое удивление, когда я увидел в консоли вот такое:

https://github.com/swaywm/wlroots/issues/1799

Великий и ужасный(нет) Simon Ser, конечно же, послал страждущего нахуй.

Я посмотрел, что там дальше случилось в репозитории freeglut:

https://github.com/FreeGLUTProject/freeglut/issues/72

Чувак с бородой, называющий себя "I'm a hacker", ничего сделать не смог, и вообще, сказал, что вертел он этот наш Wayland, и ему на остаток жизни и X11 хватит.

Короче, c 19 года как не работало, так и не работает. Я, может, даже и взялся бы починить freeglut, но нести это в "I am a hacker" не очень хочется, он явно не заинтересован.

Зато он заинтересован в том, чтобы написать еще один freeglut - точно такой же, но только в 1 файле, потому что нормальных систем сборок в мире нет. https://github.com/jtsiomb/miniglut

* Как вы понимаете, я сразу же вбил в google "evince mudpf".

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

https://mail.gnome.org/archives/evince-list/2016-October/msg00007.html

Ну, конечно, зачем им там нужен конкурент там выстраданному poppler, поэтому, most definitely, нахуй mupdf в evince не нужен. #GNOME, чего с них взять.

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

Потом это уже нафиг никому не нужно.

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

Как, кстати, однажды произошло с проектом #GNU, потому что они считали, что пишут THE libc #glibc, и THE compiler #gcc. Про то, что они вот только недавно разрешили не подписывать бумажное CLA для разработчиков, я тут пару раз писал.

Вывод - в проекты нужно приходить на ранней стадии, и если вам интересно попилить какой-нить дистр, приходите ко мне, а не в arch/nix/fedora!

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

This site can’t be reached
gitlab.gnome.org refused to connect.
Try:

Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_REFUSED

Совпадение?

https://www.phoronix.com/scan.php?page=news_item&px=FreeType-2.12-Released

#freetype #fontconfig

У меня, короче, бамболейло.

Эти сумасшедшие добавили во freetype поддержку векторных шрифтов в формате svg.

Я, конечно, считаю, что это леденящий душу пиздец:

* Явное нарушение всех релевантных принципов дизайна - что за одну сущность должна отвечать одна библиотека. Нужно было для поддержки таких шрифтов сделать новую библиотеку - как google сделали с woff2. Цветной клипарт - это НЕ шрифт!

* Формально у нас получается неразрешимый цикл по зависимостям, потому что svg -> freetype, freetype -> svg теперь. Конечно, эту зависимость замели под ковер, с помощью https://en.wikipedia.org/wiki/Dependency_injection - типа, в библиотеку нужно передать хук, который умеет что-то сделать с распаршенным svg(я только не вчитался, вернуть outline, или осуществить полный рендеринг).

* Надо бы, конечно, посмотреть, что будет со всем этим говном, если в svg шрифта засунуть текст со ссылкой на этот же шрифт.

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

Банальное нежелание нормально отрефачить код приводит вот к таким кадаврам, если мы хотим наслаждаться полноцветной какашечкой на наших экранах.

Ну и тот факт, что единственный работающий embedded растеризатор svg написан на Rust, доставляет. Я это, конечно, вертел на причинном месте, я там вставлю вызов по RPC в Inkscape(самый лучший растеризатор svg из доступных, но не в виде библиотеки), собственно, как и хотел сделать для качественного рендеринга иконок.

Я тут допиливал свою поддержку sudo, которая, как вы помните, сделана поверх ssh #system0

Добавлял туда поддержку входа по ключу(это когда у пользователя есть запароленный приватный ключ, и в root его пускает по публичному ключу, прописанному в authorized_keys).

Сломал голову, почему добавление в /etc/dropbear/authorized_keys (а я использую dropbear для серверной части, и openssh для клиента(потому что dropbear не поддерживает все нужные форматы ключей)) не решает мою проблему. Логи, потом strace - ну не читает демон /etc/dropbear/*, и все тут.

https://github.com/mkj/dropbear/blob/master/svr-authpubkey.c#L448 - вот код, этот файл он и читает.

В интернете написано, что читает /etc/dropbear. Кому верить?

Короче, в интернете пишут про dropbear в openwrt, где он широко используется, и там разработчики просто добавили поддержку нового пути - https://github.com/openwrt/openwrt/blob/openwrt-21.02/package/network/services/dropbear/patches/100-pubkey_path.patch , а стоковый не умеет, такие дела.

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

Вот мой патч на 3 строчки кода. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/sud/server/mix.sh#L12

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

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

Примеры:

* https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/lua/t/mix.sh#L21 - поддержка статически собранных с lua модулей

* https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/mesa/mix.sh#L36 - поддержка в экспортируемом API от #mesa полного opengl, вместо glesv2.

Последнее, кстати, очень интересная тема сама по себе.

Mesa умеет в полный opengl, но его полная реализация завязана на X, и экспортируется вместе с кодом поддержки X сервера. Если собирать только под Wayland, без поддержки X, эта либа просто не имеет шансов собраться, хотя внутри Mesa и имеет все необходимые запчасти для opengl.

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

Как это работает, рассказывать не буду, интересно - загляните внутрь, в Mesa это место довольно интересно устроено(как один и тот же внутренний код умееет притворяться для клиентов и glesv2, и opengl).

Вот код в mesa, который собирает glx - либу, которая неразрывно связывает opengl, и X11 - https://github.com/mesa3d/mesa/tree/main/src/glx

https://hi-tech.mail.ru/news/57350-pervyy-noutbuk-na-baykal-m-raskryta-cena/

Ноутбуки, которые мы заслужили.

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

У меня такое ощущение, что HN, да и его собрат lobste.rs, как-то за последнее время сильно деградировали(ну или я сильно поумнел, но это врядли). Если раньше там можно было найти каку-то интересную тему хотя бы раз в день, то теперь даже не раз в неделю.

Мне так только кажется?

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

https://lobste.rs/s/wxqcul/project_with_single_11_000_line_code_file

Тут вот собирают список проектов, написанных в 1 файле, большого размера. Рассказать им про bsconfig, чтоли? :D

———
#mesa

В продоложение темы разных personalities для opengl.

Вся эта конструкция, которую я описал в прошлом посте про mesa, на самом деле, выглядит и ведет себя очень странно. In the wild довольно много кода, который линкуется с glesv2, но в runtime ищет libGL.so, и экспортирует из нее к себе символы, и даже вызывает это.

Фактически, это приводит к тому, что программа видит символ с одним и тем же именем, но с разной семантикой.

Что это значит, и как работает, я пока не понял.

———
Парочка анекдотов про сборку.

Пара вводных: lib_deps: [X, Y] - список библиотек, от которых зависит данный таргет, и они ведут себя транзитивно. bld_libs: [X, Y] - список библиотек, которые нужны только для сборки данного таргета, то есть, ведут себя нетранзитивно.

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

Поэтому, когда, однажды я сделал вот такую замену: lib_deps: [A, B] + bld_libs: [C] -> lib_deps [A] + bld_libs [B, C], и у меня ничего не пересобралось, я занервничал.

А потом понял, что так и должно было быть, потому что актулаьный набор библиотек для сборки таргета [A, B, C] не изменился.

И второй.

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

Например, факт, что cmake зависит от libcurl, меня совсем не радует.

На днях тут обнаружил красивое - #libvte (это библиотека-виджет эмулятора терминала) зависит от gnutls - https://github.com/GNOME/vte/blob/master/meson.build#L588

Причем, если собрать ее без gnutls, то gnome-console/vte начинает на старте предупреждать, что все соединения от ее имени будут идти через несекурный канал.

Я, конечно, выпал в осадок, разбираться пока не стал.

https://developers.google.com/open-source/gsoc/faq#are_participants_from_ukraine_russia_or_belarus_allowed_to_participate_in_gsoc_2022

А действительно, зачем проводить GSoC на территории стран, в которые нельзя заплатить?

———
#quake

Я тут, для проверки работоспособности opengl и vulkan решил собрать себе quake2. Все шло очень хорошо, пока не пошло совсем наперекосяк.

Очень грубо, клиент quake загружает в себя 2 .so(на самом деле, больше, но для понимания сути рассказа это неважно), каждая из которых устроена примерно так:

client.so = 1.o + 2.o
game.so = 2.o + 3.o

При этом, fun fact - 1.o и 3.o содержат в себе некоторую функцию, с одинаковым именем, которая реально зовется в 2.o, и должна иметь разную семантику в client.so, и в game.so

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

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

В конце-концов, я нашел решение, симулировав поведение hidden symbols с помощью objcopy. Конкретно - добавляем к каждому экспортируему символу уникальный для архива префикс - скажем, client_ для client.a, и game_ для game.a, после чего их можно безопасно влинковать в одну и ту же программу.

https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/quake/2/yamagi/mix.sh#L34

+ немного магии в моем псевдо-динамеческом загрузчике по переадресации вызовов:

https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/quake/2/yamagi/mix.sh#L36

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

Думаю, до меня статический бинарник для quake2 не изготовлял никто, потому что это гениальное решение можно проследить еще в исходниках от id software.

Кстати, раз уж начал про quake.

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

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

llvmweekly

https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/61377

lifetimes для C++. Кажется, на этот раз все серьезно. Не очень только понимаю, как это работает без изменения ABI, по идее, lifetimes же должны манглиться вместе с остальными свойствами типов.

Надеюсь, предложение пройдет, и, надеюсь, это даст толчок для развития С++ 2.0, на базе clang, и без старперов из комитета.

https://nullprogram.com/blog/2018/05/27/

Сказ про то, почему динамически слинковаться с библиотекой может быть дороже, чем позвать функцию через dlopen. Для тех, кто не знает, что такое got и plt, может быть интересно.

Могу добавить, что в хорошо оптимизированной программе got и plt вполне могут быть видны на приборах, занимая несколько процентов перфа.