#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/

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

"ix run" (или любая другая метапоисковая система), конечно, сильно меняет подход к разработке. #ix_run #dev_shell

Свой go-шный portal я собираю, например, вот так - https://github.com/pg83/portal/blob/main/build.sh

ix run set/dev/go -- go build

"Где-то там" строится временный #realm, со всем нужным окружением, в котором запускается свежесобранный go build на мой проект. Оверхед - доли секунды.

Хочется cgo, и зависимость от какий-то C-шной библиотеки?

ix run set/dev/go --cgo lib/gtk/3 -- go build ...

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

Анонс курса про Rust в вышке, например

Анонс курса раста в следующем году. Распространяйте среди первокурсников, чтобы все выбирали нас!

Тут вот Данила "наше все" #Lemire запилил бенчмарк https://lemire.me/blog/2023/03/03/float-parsing-benchmark-regular-visual-studio-clangcl-and-linux-gcc/

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

Под винду сравнил VS/std vs. VS/fastfloat vs. clang/fastfloat, ну и добавил, для пикантности, сравнение с gcc/wsl/???.

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

Из его сравнения можно сделать однозначный вывод, что MSVC сосет (как компилятор), ну и... все.

Не бенчмаркайте так, как это сделал Лемир!

Меня тут спрашивают, зачем я решил запилить свой портал.

Рассказываю.

Недавно писал про то, что, при обновлении #mesa до 23 ветки, у меня сломался #zink opengl driver для связки epiphany + ее WebKitWebProcess (это отдельный процесс для рендеринга(и не только)).

Тогда я решил это тем, что собрал epiphany + WebKitProc(blabla) в софтверном режиме.

Но это, конечно, было очень медленно, и нужно было решить проблему более лучше.

Как можно в #mesa выбрать opengl driver для приложения?

* Поправить всратый xml с конфигами - настройками - хаками для приложений, которые не работают с дефолтными настройками. https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/00-mesa-defaults.conf Да, там strcmp() по имени приложения, так себе решение, я решил этот способ оставить на самый крайний случай.

* Второй способ - вмешаться в загрузчик драйверов в egl, и как-то override его решение. Я так и хотел сделать, но, к сожалению, zink прикручен к mesa через жопу. Он хочет не только драйвер, но чтобы при загрузке приложения была выставлена опция, котороая говорит, что надо использовать именно zink. Почему? Потому что, вместо того, чтобы протащить какие-то настройки через фабрику с драйверами, им оказалось проще в 5 местах кода сделать проверку на == "zink". Особенно "вредное" место - https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/egl/main/eglapi.c#L695

Что тут написано? Тут написано, что zink - не настоящий драйвер, он в своем коде использует запчасти из opengl software renderer, и ему надо инициализироваться сложнее, чем позвать функцию инициализации из драйвера.

Сразу видно руку мастера, а точнее, программиста на 300000кк/сек, которому после него хоть трава не расти.

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

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

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

Почти, но не совсем.

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

И тут я, конечно, вспомнил про то, что epiphany умеет работать во flatpak/snap, а значит, умеет использовать порталы, а значит, умеет вызывать внешние программы для просмотра файлов через портал. Дальше мой портал открывает приложение для просмотра в чистом окружении, в котором нет испорченной переменной среды MESA_LOADER_DRIVER_OVERRIDE.

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

Ну а дальше дело было за малым.

#xiaomi

Кстати, купил я новый book pro, на Новый Год.

Поставил, конечно, #stal/ix, не с первого раза, потому что первая попытка окирпичила ноут (я полагаю, что эти долбоебы положили какие-то запчасти от загрузчика не во flash, а на раздел на диске, потому что все шло хорошо, пока я не удалил раздел с виндой).

Экран классный, процессор быстрый, греется меньше, чем прошлая модель.

Не без linux глюков, какие-то проблемы с ACPI, не всегда уходит в сон.

Купил ноут на алишечке, поэтому он без русских букв на клавиатуре.

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

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

В продолжении темы регулярных рестартов.

У меня завис unbound. Ну завис и завис, где-то в select/poll/etc, не отвечал на запросы и сам ничего не делал.

Можно, конечно, побороться с ветряными мельницами, заслать совершенно ничего не говорящий stack trace (потому что без символов) в upstream, и ждать у моря погоды.

Я сделал ровно то, что предлагал в цитируемом посте - начал регулярно уменьшать энтропию системы, регулярно рестартуя unbound - https://github.com/pg83/ix/blob/main/pkgs/bin/unbound/runit/ix.sh#L8, с помощью /bin/timeout 300.

Раз в 5 минут, вполне достаточно, чтобы dns cache был полезен.

Подвожу черту в своем микроисследовании USB-C to HDMI тракта для поддержки 4k120HZ.

У меня нет ни одного готового, из коробки, решения (это когда вам сразу продают USB-C to HDMI кабель, в который встроен какой-то преобразователь), которое бы давало устойчивое изображение 4k120hz на всех трех моих подопытных устройствах. В целом, это понятно, потому что нужно, чтобы сошлись звезды, и производитель не пожадничал на сразу двух устройствах - преобразователе сигнала, и на самом кабеле. А в noname кабелях вообще невозможно узнать, из чего они сделаны.

Есть кабель, который работает на 2 из 3 устройствах, и на этом все.

Ultimate решение - это купить отдельно преобразователь USB-C DP в HDMI, и отдельно - хороший hdmi кабель, в палец толщиной и в металлической оплетке.

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

https://www.ozon.ru/product/perehodnik-video-kabel-j5create-usb-c-to-hdmi-2-1-8k-adapter-seryy-chernyy-jca157-849800092/?utm_medium=organic&utm_referrer=https%3A%2F%2Fyandex.ru%2Fproducts%2Fsearch%3Ftext%3DJCA157&utm_source=yandex_serp_products&sh=ZtlDTV-YKA

https://www.phoronix.com/news/Qt-Wayland-Compositor-Restart

Фига, QT-шные приложения теперь будут переживать гибель композитора. Ну теперь Wayland-то точно готов для десктопа!

С точки зрения backend разработчика - вполне очевидное решение, пересоединиться и пересоздать все буфера. Можно было бы и буфера не пересоздавать, если бы сделать это изменение на уровне libwayland, потому что тот факт, что буфер зависит от указателя на wayland контекст - это просто артефакт управления ресурсами, а так-то в ядреном буфере никакого знания про wayland соединения и в помине нет.

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

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

Так же можно было бы иметь демон, владеющий буферами и соединениями, но "wayland - это же не демон, а протокол, my ass".

Как говорится, доверяй, но проверяй!

Я тут, случайно, в выводе pstree увидел красивое:

flock---unbound 

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

flock---timeout---unbound

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

Посмотрел логи - да, действительно, мой вызов timeout не возымел эффекта. Как будто его и не было.

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

https://git.busybox.net/busybox/tree/coreutils/timeout.c#n101

Что там написано?

Там написано, что команда timeout в качестве child запускает код, который демонизируется, и, далее следит за временем выполнения основного процесса, а потом основной процесс делает exec на нужную команду.

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

А этого внука прибивает мой процесс, следящий за тем, чтобы в системе не было бесхозных процессов.

Починил я это тем, что добавил в цепочку subreaper, https://unix.stackexchange.com/questions/250153/what-is-a-subreaper-process https://github.com/stal-ix/ix/blob/main/pkgs/bin/unbound/runit/ix.sh#L9

Зачем timeout устроен так сложно?

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

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

Дебажил тут один скрипт, который под python2 (да, есть еще легаси в русских селеньях) работал нормально, а под третьим питоном зависал на попытке вывести в stdout кучу (примерно 15 гигабайт) бинарных нулей.

Строчка, приводящая к такой забавной ошибке:

print(six.binary_type(some_func()["id"]))

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

Сломанный скрипт - часть рантайма большой production системы, которую починят, но не "прямо сейчас".

А мне же надо "прямо щас", ну и я испорчен взаимодействием с open source, поэтому я сделал в своем скрипте вот так:

cp $(which mega_script) ./ 
sed -e 's|six.binary_type||' \
    -i mega_script
export PATH=${PWD}:${PATH}

Моя джоба побежала. В будни, когда коллеги обновят сервис, я это уберу, конечно.

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

Мораль?

Мне интересно, сделал бы я так два года назад, еще до активного взаимодействия с open source, или, все же, нет. Не знаю.

Борьба с говнокодом

Programmer memes

Можно ли быть святее папы римского?

Сборки llvm, который можно скачать с их релизной страницы, bootstrapped.

Что это значит?

Что они в процессе сборки собирают новую версию host c++ компилятором, а потом уже им собирают релизную версию нового llvm.

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

Так же они, в процессе, собирают себе libc++, и, скорее всего, какие-то рантаймы.

Но, например, они не собирают себе libc, и прочие zlib/ncurses, от которых будет зависеть этот компилятор.

По ссылке https://github.com/pg83/ix/blob/main/pkgs/bin/clang/16/bootstrapped/ix.sh компилятор, не просто bootstrapped, а еще и все зависимости которого собраны им самим же (конечно, логически, физически это невозможно).

Так что, ответ на поставленный вопрос - да, можно!