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

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 вполне могут быть видны на приборах, занимая несколько процентов перфа.

Будни #bootstrap

Я как-то писал про процедуру generic #bootstrap, когда мы пересобираем весь мешок инструментов предыдущей версией. Как я тогда отмечал, эта процедура довольно fragile к изменениям входных данных. Но я таки сумел ее заиспользовать, и упростить всю цепочку.

У меня, как и раньше, цепочка сборки первого инструментария описана руками, жесткими зависимостями, потому что fragile.

Но вот инструменты второго поколения я пересобираю с помощью такой автоматически построенной цепочки. Напомню, что у меня нотация a/b(c=d) означает зависимость от пакета a/b, собранного с флагами c == d. И есть особо выделенный флаг std_box - это ссылка на пакет инструментов, с помощью которого нужно собирать искомое. Флаги наследуются на все поддерево библиотек, поэтому с помощью std_box= пересоберется все поддерево.

https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bld/make/mix.sh#L4 - собираем make "второго поколения", указав std_box, и сказав, что в этом make не нужна поддержка i18n от gnu. Давно хотел это сделать, но раньше это было сложно, потому что один и тот же сборочный файл использовался и для сборки инструмента, и как user-facing пакет. А теперь это бесплатно.

Кстати, intl_ver работает очень просто - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/intl/mix.sh#L4 - это dispatch по имени флажка в конкретную реализацию. Так же я умею собирать пакеты с разными openssl, curses, whatever. В любой комбинации флажков.

https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bld/mold/mix.sh#L4 - или вот более интересный пример. Собираем mold "второго поколения", и заодно указываем, что в качестве openssl для mold взять мою велосипедную реализацию - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/openssl/md/mix.sh, которая оборачивает libmd в openssl-совместимый интерфейс. Сделано это для того, чтобы не тащить в это поддерево openssl, и perl, соответственно.

А user-facing пакеты собираются уже с помощью "второго поколения" инструментов.

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

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

Кажется, у меня вырисовываются интересные перспективы :D

https://github.com/NVIDIA/libglvnd

Узнал о существовании вот такой библиотеки. Это такой loader для opengl реализаций, чтобы их можно было свитчить на лету, видимо, чтобы разные приложения можно было запускать на разных карточках(встроенной и дискретной, например).

Масла в огонь подливает факт, что по аргументам некоторых функций из glx(привязка контекста opengl к X11) невозможно узнать, в какой драйвер делать реальный вызов.

Поэтому там есть пертредная map, отображающуя созданные контексты на загруженную .so с драйвером.

А еще есть libepoxy, https://github.com/anholt/libepoxy, которая, видимо, загружает libglvnd тоже через dlopen, и наводит свой лоск и хаки уже поверх нее.

Как это все работает, я думаю, не понимает никто.

Судя по форумам, работает оно через раз, и херово.

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

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

Nevertheless, мне надоело постоянно вводить

echo 255 > $(find /sys | grep backl 
    | grep amd | grep /brigh)

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

Выбор пал на https://github.com/haikarainen/light. Все шло хорошо, до того момента, когда я запустил это инженерное чудо в первый раз.

Программа просто вышла, не реагируя ни на -h, ни на -v.

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

Чтение исходников показало, что автор совершил детскую ошибку - писал в log, не установив loglevel во что-то разумное.

https://github.com/haikarainen/light/blob/master/src/light.c#L494 - зацените, сколько полезной работы мы уже сделали до того момента, как решили распарсить command line.

Ладно, это место я починил, но не тут-то было.

Программа начала выходить с какой-то очень странной ошибкой, что не смогла создать каталог в папочке ~/.config. Причем под strace программа прекрасно выполнялась, я такое в первый раз в жизни видел.

Короче, эта шняга выставляла set group id on exec, https://github.com/haikarainen/light/blob/master/src/Makefile.am#L8, и чо это значит, я не знаю, и знать не хочу. Подозреваю, что gid/egid этого процесса был не очень подходящий, чтобы писать в мою папочку.

Некоторые запчасти Unix, конечно, лучше не знать.

Я строю #system0 без systemd, но я считаю, что для десктопа нужна общая шина.

Соображения мои такие:

* Доступ нужно регулировать к функциям, а не к файлам. Поэтому концепция Unix пользователей и групп тут не очень ложится. Потому что для выполнения функции может понадобиться доступ к другим функциям(и файлам соответственно).

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

Поэтому я считаю, что dbus и polkit - здравые, по своей сути, идеи.

Но, как обычно, реализация у них всратая.

Я даже молчу, что у dbus настройки через xml, и ни с чем не совместимый и уникальный wire формат. Хотя и считаю правильным, чтобы там был \n-delimited json, чтобы сервисы можно было делать в виде скриптов на любом языке, и на любой чих(*). Для dbus запилить сервис это то еще удовольствие.

Я про то, что, хотя dbus и определяет wire format, но он не определяет стандартные интерфейсы.

Поэтому что ConnMann, что iwd, что NetworkManager - они не реализуют стандартный интерфейс по настройке сети, они реализуют свои, уникальные, интерфейсы.

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

Есть такой набор стандартов от XDG, классная штука. Но они, например, предлагают использовать https://linux.die.net/man/1/xdg-open для того, чтобы открывать файлы и урлы на простмотр.

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

Интересно, GNOME и KDE сумели договориться про общие интерфейсы в этом месте? А про global menu? :)

Кстати, тот факт, что каждый sway пишет себе свой swaymsg, вместо того, чтобы использовать общую шину, это тоже камешек в огород десктопному Linux.

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

*: Именно поэтому протокол должен быть простой, чтобы скрипт мог его реализовать через pipe + jq.

Кстати, рабочим названием mix всегда было pizdOS, или pizDOS, кому как больше нравится :D

https://www.phoronix.com/scan.php?page=news_item&px=Mesa-Kopper-Merged

"Zink with Kopper now provides native Vulkan windowing system integration (WSI), proper Vulkan swapchain handling"

"This moves Zink closer to being able to run with a Wayland compositor and other features previously only dreamed about for this generic but performant OpenGL implementation for running on Vulkan drivers. Mike Blumenkrantz continues working on Zink/Mesa thanks to employment from Valve" (Все #хорошее в графическом стеке Linux делают корпорации!) #zink #mesa

Интересно, а как у меня так получается уже гонять весь opengl stack через связку wayland + zink + vulkan? В том числе, и композитор.

Ну и непонятно, зачем этот самый WSI нужен. EGL вполне справляется с настройкой контекста, и, кроме слова GL, там от opengl нет ничего особо.

Тут вот пишут, что профессия художника уже закончилась. Интересно, когда придут за IT? 5 лет? 10?