#vkquake

Извините, в последний раз, больше не буду, но разъебывать - так разъебывать.

Мне стало интересно, чем занимается программа от коллеги из idSoftware.

Я снял perf record, посмотрел perf report, и увидел:

* В аллокаторе, даже после моих патчей, она проводит 0.2% времени.

* Зато 25% времени программа проводит в https://github.com/Novum/vkQuake/blob/master/Quake/tasks.c#L129 Знающие люди сразу тут увидят наивную попытку реализовать spin wait semaphore, функция называется очень даже правильно.

Ладно, не будем придираться, обычный такой spin wait. 3000 итераций sem_trylock - ну такое, кажется, многовато.

В любом случае, опытные собаководы заявляют, что spin lock в user space - ну такое. https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723 Я на эту заметку уже кидал ссылку, но, все равно, почитайте, красивое.

Если позаменять вызов этой функции на SDL_SemWait, то программа начинает жрать существенно меньше CPU, процентов на 10 - 15, ухудшений в latency я не заметил.

Поэтому, конечно, свою версию я запатчил. https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/quake/1/vk/ix.sh#L14

UPD: по просьбам трудящихся - https://github.com/Novum/vkQuake/pull/514

#vkquake

Сперва коллега, конечно, поступил как на КДПВ - сообщил, что под винду так работать не будет(доля правды в его словах вполне есть), и закрыл тикет. https://github.com/Novum/vkQuake/pull/514

Но потом, видимо, выдохнул, и решил, что перф на дороге не валяется. Сошлись мы на том, что он сократил количество попыток trywait в 30(!!) раз. https://github.com/Novum/vkQuake/commit/5cf860d1be6d12a3f269ea8355818ab17e586390

(Я, на самом деле, не понимаю, зачем ему там динамическая выполнялка графа - все, что он разложил в этот граф, занимает 10% потребляемого CPU. Может, ему просто нравится писать динамические graph execution engine, как вот мне, или Ленарту, имеет право)

Ладно, и так сойдет.

https://www.phoronix.com/scan.php?page=news_item&px=KernelMemorySanitizer-v4 #asan

Уже писал, и напишу еще раз.

Самый большой, практически, тектонический, сдвиг в разработке софта за последние 20 лет - это внедрение address sanitizer от Google, Кости Серебряного, и его команды.

До его внедрения в pipeline тестирования мне было страшно катать прод, после - уже совсем нет.

Экспертное мнение - Rust даже рядом не стоит по масштабу улучшений. Ну, то есть, если бы не было санитайзеров, Rust был бы очень крутой штукой, а так - ну, на 20% еще меньше ошибок. Это не на порядок даже.

Собственно, отрадно видеть, как Google, вопреки вольнице кернел хакеров(почему вопреки? А почему санитайзеры гоняет google, и почему они не встроены в CI?), постепенно превращает ядро Linux из месива, в котором ты боишься обновить минорную версию ядра и/или компилятора, в нечто, что хотя бы не упадет на старте.

Будни #bootstrap

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

Недавеча увидел в этом списке exim. Это самый популярный MTA, и я подумал, что "нужно"!

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

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

Вот этот сборочный файл из arch - https://github.com/archlinux/svntogit-community/blob/packages/exim/trunk/exim.Makefile

Я попрошу отметить, что это файл из репозитория Arch.

В комментариях дали ссылку на gentoo - https://gitweb.gentoo.org/repo/gentoo.git/tree/mail-mta/exim/exim-4.96-r1.ebuild#n170

КМК, это какое-то лютое пренебрежение к пользователю.

Или я чего-то недопонял, и есть путь проще?

https://habr.com/ru/amp/post/675036/

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

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

* На lobsters/HN про это ничего нет. Я прошерстил пару раз, не нашел ничего.

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

* Сам движок всратый, ничего не умеет.

* Коллега заявил об этом прямо день в день юбилея игры, зачем такой PR Blizzard'у?

Фейк? Не фейк?

https://www.phoronix.com/scan.php?page=news_item&px=Systemd-Creator-Microsoft

Вчера стало известно, что Леннарт ушел из RH. Ну ушел и ушел, я не стал про это писать.

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

Ну, что же, пожелаем им всем удачи. Звука всем виндоводам хорошего, и скорости загрузки!

Утв. 1: время сборки и обновления source-based distro определяется временем сборки используемого браузера. Все остальное - o-малое.

Это, в целом, практический факт, и он довольно понятен:

* Браузер собирается очень долго

* Браузер зависит от кучи всего, поэтому пересобирается на любой чих

Ладно, я чуть-чуть утрирую, на самом деле, в этом списке 2 - 3 самых тяжелых конечных приложения. Чаще всего это браузер, и еще что-нибудь, в моем случае, telegram.

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

Не для того, чтобы они собирались быстрее, а для того, чтобы они собирались сильно реже.

Вот, расскажу про пример такой паразитной цепочки.

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

1) gnutls -> nettle.
2) microhttp(гнутая библиотека для разработки http client-server) -> gnutls
3) elfutils(tool) -> microhttp
4) x264/vpx(кодеки) -> elfutils(tool)
5) -> ffmpeg
6) -> telegram

Все зависимости довольно понятны, и логичны, кроме 3)

В составе elfutils идет debuginfod, которому нужно уметь ходить по http, а всем остальным, нужным мне в сборке, тулзам, из elfutils, http не нужен.

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

Кстати, браузер тоже зависел от gnutls, но эту зависимость я оторвал немного раньше, и заменил ее на openssl.

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

Реклама - наше все!

Сравните заглавную страницу проекта(W): http://www.graphicsmagick.org/

И release notes(R): https://sourceforge.net/projects/graphicsmagick/files/

W: "GraphicsMagick is the swiss army knife of image processing. Comprised of 279K physical lines (according to David A. Wheeler's SLOCCount) of source code in the base package (or 1,275K including 3rd party libraries) it provides a robust and efficient collection of tools and libraries which support reading, writing, and manipulating an image in over 89 major formats including important formats like DPX, GIF, JPEG, JPEG-2000, PNG, PDF, PNM, TIFF, and WebP."

R: "For several years now, the burden has entirely been on me (Bob Friesenhahn). I have been sheparding the project for 20 years already (and contributed to ImageMagick and GraphicsMagick combined for 26 years already). It is not reasonable to expect someone with a full time job (and expecting to retire in a few years) to do all of the work."

W: "GM participates in Google's oss-fuzz project (since February, 2018)." (типа, круто, нас фаззят!)

R: "GraphicsMagick is participating in Google's oss-fuzz project due to the contributions and assistance of Alex Gaynor. Since February 4 2018, ??? issues have been opened by oss-fuzz and ?? issues remain open." (фаззят, а issues не закрывают)

Ну и так далее.

https://github.com/Novum/vkQuake/releases/tag/1.20.3

#vkquake

"Fixed multiple parallelism bugs"

Вот жопа, хоть бы спасибо сказал.

У меня есть (короткий) список из нескольких задач, которые надо закрыть, прежде чем можно показать #stal/ix широкой общественности. #libmagic

Это задачи не про перфекционизм, а конкретные вещи, без которых "ничего работать не будет".

Как пример - дать возможность пользователю выбрать 3d драйвер из mesa. Пока у меня все заточено под мой setup из zink + radv, но там надо поддержать и более классическую схему с radeonsi, и intel, и software stack. Nouveau пока трогать не буду, подожду, пока они впилят наработки от open source nvidia.

На днях закрыл две задачи из списка - про размер курсора в gtk приложениях(он у меня был прибит гвоздями, а теперь может быть установлен через XCURSOR_SIZE), и про xdg-open.

Про xdg-open расскажу сегодня.

У вменяемого приложения под Linux есть два способа открыть какой-то внешний по отношению к себе файл:

* позвать портал через dbus.

* позвать command line тулзу xdg-open, передав ей путь к файлу или url.

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

К сожалению, in the wild я нашел только реализацию от freedesktop, и она настолько всратая, что у меня, при попытке это описать, остаются только матерные слова.

https://www.freedesktop.org/wiki/Software/xdg-utils/

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

У меня какое-то время была заглушка для xdg-open, которая просто все открывала в браузере - https://github.com/pg83/ix/blob/99291c90267d7b690bc39fca7224c0a20b76334c/pkgs/bin/xdg/open/ix.sh#L8

Браузер умеет открывать почти все, и это решало 90% моих задач.

Но, кажется, людям такое отдавать несколько стыдно, но и насилолвать свой мозг через xdg-open от freedesktop мне не хотелось.

Поэтому я решил воспользоваться знанием того, какие у меня бинарники вообще бывают в дистрибутиве, и написал вот такой вот скрипт - https://github.com/pg83/ix/blob/main/pkgs/bin/xdg/open/scripts/xdg-open

Он определяет mime type переданного файла, и пытается для каждого известного типа выбрать наиболее подходящую программу из PATH. Ну и проваливается в браузер, если ничего не найдено(тут есть "мелкая" проблемка - а что, если xdg-open позвал браузер?).

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

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

На мой взгляд, план этот потерпел фиаско. #fast_python

https://github.com/faster-cpython/ideas/blob/main/main-vs-310.rst

(Кстати, fellow kids, учитесь составлять презы - невнимательный читатель может подумать, что ускорили в 1.5 - 2 раза, а geometric mean - всего +25%)

Ускорили на четверть, хотя, по плану из https://github.com/markshannon/faster-cpython/blob/master/plan.md, каждый следующий релиз должен давать +50%, отложили релиз 3.11 еще на несколько месяцев, потому что он ведет себя нестабильно - https://www.spinics.net/lists/fedora-devel/msg302880.html

https://news.ycombinator.com/item?id=32002057

А что с удалением GIL? ХЗ, я не заметил какой-то активности про внедрение https://github.com/colesbury/nogil #nogil

Гвидо - на мыло, я так думаю.

Например, набор классных еженедельных дайджестов на разные темы: https://discu.eu/weekly/

Если лень читать HN/Lobsters/Reddit, то все сливки за неделю - там.

https://github.com/jaor/xmobar#were-using-github-under-protest

Тем временем, наткнулся на первого мамкиного съезжатора с github. #sfc #gnu #gpl #charity

Кстати, я сам, лично, выкладывал что-то под GPL, только когда был literallly голодным студентом. Ну, посудите сами, мне тут жрать нечего, а кто-то, НА ХАЛЯВУ, воспользуется моим бесценным кодом.

После того, как:

* Заработал первые деньги

* На собственной шкуре убедился, что copyleft делит весь софт на 2 плохо связанные части(я тут намеренно не указал OSS, потому что корпорации довольно охотно отдают код под permissive license, да и сами используют тоже). Произошло это примерно так - я, вдруг, понял, что я, Антон, могу использовать кусок GPL2 библиотеки base64 во внешнем проекте, но я, Антон, не могу же использовать ее внутри Я, а, значит, Столлман не за меня, а против корпораций. И это не моя война, так как я хочу иметь возможность использовать OSS софт в любом контексте. Сумасшедшие фанатики тут делают вывод, что все должно быть под GPL, я же сделал вывод, что надо делиться, и не требовать ничего взамен, чтобы не создавать проблем какому-нибудь другому Anton, где-нить совершенно в другом месте.

, я ни строчки не отдавал под copyleft лицензиями.

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

Простите за моралофажество, но это не по-христиански.

Замахнулся на святое - на ImGui.

https://github.com/ocornut/imgui

Давно хотел попробовать собрать себе что-то интересное с использованием этой библиотеки:

* пощупать вживую immediate mode gui.

* для галочки, что, вот, "и это у меня работает".

* мне кажется, что ее концепция упраления окнами весьма хорошо ложится на sway.

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

ImGui мне пока кажется весьма странным зверем - у нее какое-то бешеное количество звезд на github, в 10 раз больше, чем, скажем, у wxWidgets.

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

Но при этом, в changelog к новому релизу imgui - с десяток скриншотов https://github.com/ocornut/imgui/releases/tag/v1.88 новых приложений, которые ее используют.

Короче, какая-то совершенно непонятная мне экономика.

Еще про imgui у меня есть завиральная идея - а что, если взять wlroots, и сделать его одним из поставщиков графического контекста для imgui, как, скажем, sdl, или egl? И в цикле рисования gui просто завести по одному окну на каждое wayland-окно, и отрисовать в нем буфер приложения?

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

Да, да, я, в фоне, продолжаю думать на эту тему, никак она меня не отпускает. #cardboard

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

Вот так:

https://github.com/paperwm/PaperWM
https://github.com/cardboardwm/cardboard

Первый тормозит, и под gnome shelll, второй - заброшен.

Короче, из release notes я себе нашел приложение для тренировки - https://github.com/sgiurgiu/reddit_desktop

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

Но об этом в следующей серии.

https://www.phoronix.com/scan.php?page=article&item=linux-kernel-o3&num=9 #O3

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

Видимо, как ответ на возникушую в lkml дискуссию про сборку ядра с -O3, которую Линус быстренько прекратил https://lore.kernel.org/lkml/CA+55aFz2sNBbZyg-_i8_Ldr2e8o9dfvdSfHHuRzVtP2VMAUWPg@mail.gmail.com/

В целом, я про -O3 думаю так:

* Погромировать никто не умеет, поэтому код надо собирать так, как его чаще всего собирают. С -O2, так с -O2. По крайней мере, пока компиляторы спекулируют на UB.

* Сумасшедших, которые собирают ядро с -O3, или там с LTO, я вообще не понимаю. В нормальной нагрузке ядро занимает 3-5%(если, конечно, вы не пишете DPI для Путина). Ну сделаете вы это быстрее на 10%, и чо? Чтобы что?

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

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

Я, давеча, писал, что приложение в Linux может рассчитывать на наличие 4 шрифтов - sans, serif, #monospace, и system-ui(для отрисовки GUI).

Но, как выяснилось, не все приложения уважают эти настройки.

Например, авторы QT, почему-то, решили, что шрифт для отрисовки GUI - это "Sans Serif"(он матчится в просто "serif"), вместо "system-ui". https://github.com/qt/qtbase/blob/dev/src/gui/platform/unix/qgenericunixthemes.cpp#L67

Так же доставляет вот эта настройка - https://github.com/qt/qtbase/blob/dev/src/gui/platform/unix/qgenericunixthemes.cpp#L69

Насколько я понял, она не меняется для hidpi систем. Вот так, просто, "девятый размер шрифта хватит всем".

"// Default system font, corresponding to the value returned by 4.8 for
// XRender/FontConfig which we can now assume as default."

https://imgs.xkcd.com/comics/random_number.png

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

(отдельная интересная тема - что чтение настроек KDE есть как в QT, так и в KDE, как они этот код меняют?)

А что же делать пользователям Sway? Я так понимаю, сосать писос, что же еще!

У себя я это, конечно, починил - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/qt/6/base/ix.sh#L56

https://reviews.llvm.org/rGde4a57cb21a19179d7be830967e642b868a05a91

У libc++ из llvm всегда была проблема с излишним включением заголовков, типа <string> мог включать в себя <vector>, и кучу всего прочего - https://reviews.llvm.org/rGde4a57cb21a19179d7be830967e642b868a05a91#change-fOsgWP3mrbAP.

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

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

Ну, такое.

https://lwn.net/ml/gcc/CAGWvnym7--36T6L6XhhVhQmafR-w3g1NE1Zh9qTbjcC325Us1Q@mail.gmail.com/

В gcc собираются включить наработки #gccrs, то есть, добавят реализацию Rust.

Это будет уже третья реализация, помимо основной, и #mrustc(https://github.com/thepowersgang/mrustc).

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

Ну и факт того, что он написан на С++, не может не радовать, это всегда хорошо для #bootstrap

Будни #bootstrap, обещаный текст про сборку reddit desktop, #imgui

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

* оно требует vcpkg, причем хочет, чтобы vcpkg использовался и под Linux. А это жестейшая жесть, потому что vcpkg предполагает сборку под Windows, единственная OSS система сборки, которая там как-то работает - это cmake, и поэтому vcpkg сам для всех своих пакетов готовит файлы для cmake discovery - https://github.com/microsoft/vcpkg/tree/master/ports/bzip2, и сборку под cmake переделывает. Это привело к тому, что discovery в этом проекте без vcpkg не работает, пришлось патчить.

* по ходу сборки обнаружилось, что сломан boost - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/boost/ix.sh#L35 А чо, он же header-only, при его сборки компилябельность заголовков не проверяется.

* после того, как прошел configure, обнаружилось, что у коллеги забыты многие include. Возможно, это как раз связано с вчерашней темой про llvm14/15.

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

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

Кажется, я так процедурно(патчи регулярками над всем кодом) не издевался ни над одним пакетом - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/reddit/desktop/ix.sh#L50

Оно после этого собралось, слинковалось, но не заработало.

С сообщением, что не может загрузить в рантайме вот эту функцию - https://github.com/ocornut/imgui/blob/master/backends/imgui_impl_opengl3_loader.h#L656

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

А X11 у меня нет.

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

Ну и я реализовал эту фабрику по загрузке функций сам - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/mesa/gl/dl/glx/ix.sh#L15, благо, сама фабрика по загрузке opengl у меня уже была реализована, для эмуляции dlopen. Тут тонкое, но забавное, место - эта фабрика для opengl идет в мою фабрику по динамической загрузке символов, реализованной внутри моей реализации dlopen.

Короче, оно собралось, и показало работающий imgui gui. Думаю, я тут опять первопроходец, так как, повторю, на базе чистого wayland стоковый код работать не может.

Победа?

Какое там, картинка была заблюреной, видно, что hidpi в imgui не работал, хотя и заявлен.

Рассказ про это - в следующей серии!

https://discourse.llvm.org/t/board-meeting-minutes-may-2022/63628

Расшифровка встречи "совета директоров LLVM", не знаю, как лучше перевести.

Ничего особенно интересного, но вот, кажется, в тему #copilot:

"Relicensing next steps - assuming small patches are not covered by copyright

“Small” patches are widely considered to be non-copyrightable.
Doing an analysis to look at what value of “how many lines” impacts the number of companies and contributors.
Some projects that use CLA assume that patches with <= 10 don’t need an assignment.
LLVM Foundation license lawyer has suggested <=10 lines of code.
This is only counting lines of code added and modified, not deleted.
Kristof has built a spreadsheet that outlines every not-covered patch.
VOTE: Should we consider patches that are <= 10 lines of code to be non-copyrightable?
Approved: Chris, Kristof, Kit, Hal, Anton, Tanya, Cyndy, Tom."

Объясню, про что речь - LLVM занимается измененеим своей лицензии, и они искали отсечку длины diff, меньше которой не нужно просить разрешение у автора патча.

Совокупное мнение, согласованное с их юристами, - что до 10 строк кода - non-copyrightable work.

То есть, copyleft-атака на copylot как бы пролетает мимо.

https://lwn.net/Articles/900917/ #cve
https://comsec.ethz.ch/research/microarch/retbleed/

Еще пачка spectre-like уязвимостей, ничего интересного, кроме того, сколько стоит их исправление:

"Our performance evaluation shows that mitigating Retbleed has unfortunately turned out to be expensive: we have measured between 14% and 39% overhead with the AMD and Intel patches respectively."

Очень жду от облачных провайдеров разделение на независимые кластера, с mitigations=off, и mitigations=on, потому что зачем мне платить "за того парня с паранойей"?