Запилил "системные сервисы бедного человека".

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

За 5 минут запилил простую штуку:

ix mut system etc/services/0
  --srv_command="/bin/sleep 1000"

Думаю, идея понятна - это шаблон сервиса, который запускает в runit произвольный command line - https://github.com/pg83/ix/blob/main/pkgs/etc/services/runit/script/ix.sh#L10

Дальше задача клиента - занять порт, сбросить привилегии, и так далее.

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

Перепиливание одного runit скрипта выгоялит как-то так - https://github.com/pg83/ix/commit/3e4a843b6bdadc25add66f93a9a02a891b26e48f

Тут мне, кстати, очень удачно помогло то, что я не стал токенизировать флаги по пробелам, а только по запятым, которых не бывает в command line:

etc/services/runit(...,srv_command=chrt -f 10 \
    sndiod -dd -f rsnd/{{alsa_device or 'default'}})

Про первый хак (в хорошем смысле этого слова).

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

Более современная версия это шляпы - https://www.sites.google.com/site/sredaprogrammirovaniakumir/ispolnitel-robot

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

Задача была с подвохом, потому что:

* Переменных не было. Был, условно говоря, getcolor(), setcolor(), move(left,...)

* На тот момент мы умели в цикл, и в ветвление, но в ветвление мы не умели в "else" clause.

Поэтому все наши программы были устроены примерно так:

for (i = 0; i < 10; ++i) {
    if (get() == 0) {set(1)}
    if (get() == 1) {set(0)}
    moveright();
}

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

Так вот, хак, который пришел мне в голову - выйти за пределы белого и черного цветов:

for (i = 0; i < 10; ++i) {
    if (get() == 0) {set('синий')}
    moveright();
}

for (i = 0; i < 10; ++i) {
    if (get() == 1) {set(0)}
    moveleft();
}

for (i = 0; i < 10; ++i) {
    if (get() == 'синий') {set(1)}
    moveright();
}

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

https://www.hillelwayne.com/post/np-hard/

Текст про мои любимые #sat солверы. #Z3 (для связности)

Интересная мысль, которую я раньше не думал:

"Of course life isn’t that easy and randomly generated SAT problems tend to be intractable.4 But a lot of industrial problems map to the subset of SAT problems that are tractable (why this is is an open question), meaning you can some pretty big gains from making fast SAT solvers."

Хороший же вопрос - почему, несмотря на то, что средняя задача для SAT быстро не решается, многие практические задачи решаются быстро?

Оказывается, инкапсуляция - это вот это вот, а не то что вы там себе думали!

Как я и говорил, случился релиз, и даже +1 patch - https://github.com/transmission/transmission/releases/tag/4.0.1

Я сразу не написал про это, потому что у меня, почему-то, падал gtk port.

Наконец, разобрался, рассказываю.

Там, по всему коду, появились вот такие вот глобальные объекты - https://github.com/transmission/transmission/blob/main/gtk/DetailsDialog.cc#L2008

Они стали предметом initialization order fiasco, потому что, в случае использования динамических библиотек, порядок выполнения конструкторов более определен, чем в случае статической линковки (например, можно гарантировать, что статические объекты зависимой .so будут сконструированы раньше, чем объекты программы).

Запилил следующее преобразование всех исходников - https://github.com/stal-ix/ix/blob/main/pkgs/bin/transmission/gtk/unwrap/ix.sh#L67

Оно все такие глобальные объекты заменяет на синглтон Майерса. И перенаправляет все вызовы в него, с помощью препроцессора - https://github.com/stal-ix/ix/blob/main/pkgs/bin/transmission/gtk/unwrap/ix.sh#L68

Вроде, работает!

Xочет кто-нибудь это запушить в upstream? Почет, слава, вот это вот все.

#gavin, будни #bootstrap

Коллега сошел с ума, и запилил зависимость bc install script от bc, что, конечно, доставляет - https://github.com/gavinhoward/bc/issues/63

https://github.com/gavinhoward/bc/blob/master/scripts/safe-install.sh#L28

Я эту проблему решил, собрав bc 2 раза - один раз для host, и тогда мы можем пользоваться свежесобранным bc - https://github.com/pg83/ix/blob/main/pkgs/bld/bc/ix.sh#L8, и второй раз для target, где мы просто делаем зависимость на предыдущий target - https://github.com/pg83/ix/blob/main/pkgs/bin/bc/gavin/ix.sh#L9

Ну, такое.

Правда, такой финт ушами приходится делать вообще для всех скриптовых языков (perl - https://github.com/pg83/ix/blob/main/pkgs/bin/perl/ix.sh#L11, python, ruby), которым вынь да положь свой рабочий интерпретатор во время сборки.

А чем bc хуже?..

Не сошел с ума, а просто ошибся! https://github.com/gavinhoward/bc/issues/63#issuecomment-1443908686

(кстати, напомню тем, кто к нам недавно присоединился, что мы тут любим сумасшедших, они делают все самое интересное)

https://www.phoronix.com/news/Mesa-Zink-DB-Descriptor-Mode
https://www.phoronix.com/news/Mesa-RADV-Cyberpunk-2077-RT

Несколько новостей про #mesa, в том числе, вышла новая мажорная ее версия, 23 - https://www.opennet.ru/opennews/art.shtml?num=58705

И я решил, что больше ждать не могу, надо обновляться. Обновиться я не мог целый год, потому что в 22.1 сломали настройку контекса в #zink + radv, так, что у меня по разному в разных релизах отваливались куски браузера #epiphany.

В итоге, я обновился, но #webkit использует канву без 3d ускорения, все остальные приложения работают "как надо".

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

Так же я попробовал, например, собрать весь мир с radv + zink, а браузер и webkitproc c radeonsi, но оно тоже, почему-то, не полетело.

https://research.swtch.com/telemetry-opt-in

shit storm победил, и телеметрия будет opt-in

https://www.kitware.com/import-cmake-c20-modules/

А вот, например, текст от Kitware, про поддержку модулей в cmake.

Про то, как они пропихивали динамические зависимости в разные там ninja/clang/gcc.

Если честно, когда я прочел про то, что они запилили свой форк ninja в 2015 году, для поддержки модулей в fortran, и смогли его смержить в upstream только недавно, после появления модулей в C++, я заплакал кровавыми слезами, и дальше читать не стал.

#cmake

https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1437382934 #harfbuzz

Потрындел с matthiasclasen и behdad про эту circular dep.

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

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

#mesa #rant

https://gitlab.freedesktop.org/mesa/mesa/-/issues/6578#note_1795307

В #mesa совершенно аховая обработка ошибок. Можно сказать, что ее там нет совсем, потому что есть несколько мест, где строки меняют на коды ошибок, и наоборот.

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

Дело еще осложняется тем, что падает worker в webkit, которых всегда запускается строго больше 1, это число не конфигурируется, и падает оно прямо на старте. То есть, нельзя получить устоявшуюся конфигурацию процессов, приаттачиться к нужному, и подебажить.

Такое ощущение, что в #mesa, что в #webkit, славно потрудились над job security, ага. Отлаживать это невозможно от слова совсем.

#bootstrap

У меня, знаете ли, часто зудит мысль, что clang + musl - не самая популярная связка компилятора и libc. А один умный человек мне однажды сказал, что наиболее безглючный код - это тот, который позвали наибольшим возможным числом способов, желательно, в gdb.

Код под Linux чаще всего собирается с gcc + glibc, а под mac, где используется clang, собирается другой набор программ, и с другой libc.

Поэтому, когда я вижу вот такое, с новым выпуском clang:

.../parameter/array.h:85:23: warning: 
    object backing the pointer 
    will be destroyed at the end 
    of the full-expression 
    [-Wdangling-gsl]
        gchar * str = g_strdup(os.str().c_str());
                      ^~~~~~~~~~~~~~~~~~~~~~~~~~
.../include/glib-2.0/glib/gstrfuncs.h:212:51: 
    note: expanded from macro 'g_strdup'
    const char *const __str = _G_STR_NONNULL (___str);
                                                  ^~~
.../include/glib-2.0/glib/gstrfuncs.h:157:29: 
    note: expanded from macro '_G_STR_NONNULL'
#define _G_STR_NONNULL(x) ((x) + !(x))

То я начинаю сильно нервничать на тему "а как это вообще работает", и думать, как сделать так, чтобы я от этого не страдал.

https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gstrfuncs.h#L207 - вот тут написано, буквально, следующее - "для константных строк в gcc применим какую-то всратую оптимизацию, без нормально определенной семантики, и которая будет ломаться от gcc к gcc, потому что это не С, и на этот код примерно всем насрать". А когда clang решит, что достаточно хорошо поддержал эту никому не известную упячку из gcc, будем в нем ломаться вдвойне.

Я, от греха подальше, раздефайнил эти оптимизации к херам - https://github.com/pg83/ix/commit/b38e152954363020588192f88c70b47b410c2257

Это, так сказать, был пассивный #hardening.

А есть еще и активный.

Например, по тем же соображениям, я "отменил" UB при переполнении целых чисел, ну и strict aliasing заодно. https://github.com/pg83/ix/blob/main/pkgs/lib/build/opt/safe/ix.sh

Ну потому что clang смотрит на код не совсем так, и, наверняка, проэксплуатирует UB, незаметный при сборке с gcc.

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

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

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

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

Для этого начал пилить свой xdg portal - https://github.com/pg83/portal

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

* https://github.com/godbus/dbus/blob/master/_examples/server.go#L12 - куски xml, которые напрямую пишутся в wire protocol, для интроспекции. (Во flathub xdg portal оно еще и конкатенацией строится, да).

* Нет общего дерева сервисов, ну или я что-то сильно не понял. Казалось бы, сервис - это путь объекта в какой-то иерархичной модели + интерфейс, которй он реализует. Но нет, сервис уникально идентифицирует (service_name, path, interface), то есть, иерархий объектов произвольно много. Я не понимаю, как это объяснить, кроме как пресловутого "не договорились" - кто-то хотел путь в виде A.B.C, а кто-то - A/B/C, сделали оба варианта.

* Великолепное решение проблемы долгих ответов в асинхронной модели. https://flatpak.github.io/xdg-desktop-portal/#idm9 TL;DR - клиент присылает уникальный endpoint, по которому клиент поднимает микросервис с одной ручкой, которую должен дернуть хендлер оригинального запроса в сервере. Леденящий душу пиздец, чо.

Красивое про #sat

https://ahelwer.ca/post/2018-02-13-z3-firewall/

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