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, потому что зачем мне платить "за того парня с паранойей"?

https://blog.rust-lang.org/2022/07/12/changes-in-the-core-team.html

"Ashley Williams will be stepping down from the Core Team and other roles. "

https://github.com/libsixel/libsixel

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

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

По ссылке:

* SDL в терминале
* qemu в терминале, со всеми вытекающими
* X11 в терминале, со всеми вытекающими

Надо сказать, что sixel output в gnuplot - мегаудобно.

Все же, мне нравится клепать системы сборки.

У меня есть некоторое количество библиотек, которые не имеют смысла за пределом #stal/ix.

Например, https://github.com/pg83/ix/tree/main/pkgs/lib/shim/gnu

Ничего особенного, просто пара функций, которых нет в musl, но которые сторонний софт иногда хочет.

(хотя, например, когда я писал вот это вот - https://github.com/pg83/ix/blob/main/pkgs/lib/shim/gnu/string.h, то я определнно ощущал себя #обмазаться_шоколадом)

Собиралось это предельно тупо - файлы материализовывались на диске, потом я вручную вызывал для них команды компиляции, линковки, и устанавливал в систему - https://github.com/pg83/ix/blob/e50237c6130b4a68fae9b44633af198e8ef816a7/pkgs/lib/shim/gnu/ix.sh

Когда у меня таких библиотечек стало 10 штук, пришло время это дело порефакторить, и я написал дня них общий шаблон - https://github.com/pg83/ix/blob/main/pkgs/die/inline/common.sh

Он, точно так же, материализует файлы на диске, и вызвает команды компиляции, только делает это немного более общО(собирает все подходящие файлы в директории, и копирует все .h файлы в ${out}/include/, библиотеки в ${out}/lib/, программы - в ${out}/bin/).

Конечный сборочный файл выглядит как-то так - https://github.com/pg83/ix/blob/main/pkgs/lib/shim/gnu/ix.sh

Вот почему, что бы я не делал со сборкой, там, все равно, появлются PEERDIR() + SRCS()???

https://github.com/libgit2/libgit2/releases/tag/v1.5.0

Вышла новая версия libgit2.

Коллеги затеяли большое дело - начали разработку внутри libgit2 непосредственно клиента к git.

Пишут, что хотят использовать тесты от git, ну и как пример, но мы-то понимаем!

Дело хорошее, git написан очень плохо, libgit2 - хорошо неплохо.

UPD:

pg-> ...MHVE-bin-git-2/bin/git2_cli 
usage: git2 [--help] [--version] <command> [<args>...]

Забавно, видимо, команду переименовали из git2 в git2_cli, чтобы было поменьше коннотаций про конкуренцию.

#bootstrap #bootstrap_science

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

Сейчас поясню на пальцах.

Допустим, вы, в процедуре bootstrap, собираете clang + coreutils, которые, потом, используются для сборки всего остального. Но для их сборки вам нужны промежуточные инструменты A, B, C.

Вы собрали себе нужный набор пакетов, сделали #ix gc, после чего A, B, C были удалены, так как они никому не нужны для работы.

А теперь, представьте себе, что какой-то конечный, user visible код случайно по сборке стал напрямую зависеть от A(или от B, или от C) Тогда, при попытке собрать этот таргет, нам придется воссоздать A, а значит, пройти всю цепочку bootstrap целиком.

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

Я пробовал найти такое множество пакетов пару раз, но оно получалось вкривь и вкось.

До тех пор, пока я не переделал цепочку bootstrap, как в предыдущем посте, на который я ответил.

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

Понятно же, почему это правило порождает необходимый и достаточный набор инструментов?

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

Вот, я перечислил все такие инструменты в 1 таргете - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bld/ix.sh

Это очень удобно, потому что теперь, чтобы прикопать эти инструменты, мне достаточно завести #realm с этим таргетом(realm задает множество корней для gc).

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

А, тем временем, кодовая база #stal/ix:

pg-> (find . -type f -name '*.sh' 
    | while read l; do cat ${l}; done) | wc -l
34391
pg-> (find . -type f -name '*.py' 
    | while read l; do cat ${l}; done) | wc -l
2967
pg-> find . -type f -name '*.sh' | wc -l
1617

35000 строк кода, 1500 пакетов.

Немало.

https://medium.com/@mproberts/a-discussion-about-the-breaking-of-the-internet-3d4d2a83aa4d #npm

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

А правда, что trademark дает такие серьезные права на это слово? То есть, я не могу на github завести репозиторий с названием yandex/google/whatever? А может, например, владелец trademark запретить употреблять это слово вообще, или в каком-то контексте?

Мои пакеты, в каком-то смысле, программно-генерируемые.

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

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

Например, у меня так сделан task scheduling в системе.

Cron? Не, не слышали.

Вот такой программно-генерируемые сервис - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sched/scripts/ix.sh

Он ожидает на вход параметр delay, и дальше использует его для генерации своего исходника:

* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sched/scripts/ix.sh#L4 - у сервиса будет уникальная папка для запуска его через runit

* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sched/scripts/ix.sh#L10 - спим столько, сколько указано в delay

* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sched/scripts/ix.sh#L12 - после чего выполняем все скрипты, лежащие в папке /etc/sched.d/{{delay}}

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

Это значит, что любой клиент, который хочет, чтобы какой-то его скрипт выполнялся раз в delay секунд, он:

* Делает зависимость от этого сервиса, с параметром delay= - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sched/staleprocs/ix.sh#L4

* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sched/staleprocs/ix.sh#L8 - в папочку /etc/sche.d/{{delay}} материализует запускаемый скрипт

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/set/system/0/unwrap/ix.sh#L17 - дльше мы просто устанавливаем в систему пакеты с указанием этого самого конкретного delay, и дело сделано.

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

Почему не cron? Посекундно сложно, конфигурационный файл плохо composable из запчастей.

Собственно, у меня на таком "кроне" работает, например, очистка системной /ix/trash/(про нее я рассказывал отдельно), и убиение stale процессов. И вместо постоянно висящего ntpd - регулярное хождение в ntp https://git.sr.ht/~pg/ix/tree/main/item/pkgs/set/system/0/unwrap/ix.sh#L23.

#ebpf #uring

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.20-User-Space-Block-Drv

Какую хорошую новость я пропустил. FB/RH тащат в ядро user space block device через io_uring.

"IO_uring User-Space Block Driver Coming For Linux 5.20"

https://www.technologyreview.com/2022/07/14/1055894/us-military-sofware-linux-kernel-open-source/

https://lwn.net/Articles/901254/

Пока все стебутся над китайским социальным рейтингом, DARPA, "тихо и незаметно", собирается следить за тем, кто как себя ведет в open source community:

"To do this, the researchers will use tools such as sentiment analysis to analyze the social interactions within open-source communities such as the Linux kernel mailing list, which should help identify who is being positive or constructive and who is being negative and destructive"

Интересно, что система сделает с известным своей несдержанностью Линусом.

(меня-то, понятно, и за километр к ядру не подпустят теперь)

#imgui, #wayland, #sdl, #hidpi #gold

Так, третья, заключительная, часть рассказа про "собрать какое-нибудь приложение c imgui".

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

Скриншот мне делать лень, поэтому просто представьте себе, что картинка была rendered в буфер 100x100, который был растянут на экран 200x200.

Кстати, ровно та же проблема у меня наблюдалась с #dosbox.

Суммарно на решение это проблемы я потратил часов 10, фактически, все прошлые выходные. Зачем? Ну, потому что интересен процесс, а не результат. И потому что, предполагается, что владелец дистрибутива способен такие проблемы пользователей решать, я так думаю.

Я, пожалуй, не буду вдаваться в детали процесса, это слишком долго, я просто расскажу, как устроен hidpi в wayland, к чему это привело в модели sdl, и что я с этим сделал.

* В wayland у каждого буфера, в том числе on screen, есть, кроме обычных WxH(+ формат, но нам это не интересно), еще параметр scale. На мой взгляд, назван он неверно, и это долго меня сбивало с толку.

* Когда композитор отрисовыает буфер приложения в экранный буффер, он масштабирует буфер приложения в отношение scale этих двух буферов. Ну, то есть, если screen->scale == 2, app->scale == 1, то буфер от приложения будет увеличен в 2 раза.

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

Давайте на примерах:

* screen == 200x200x2, app == 100x100x1. Увеличим app buffer в 2 раза, отобразим получившуюся картинку 200x200 as is. Так, фактически, работают старые приложения, которые не hidpi-aware.

* screen == 200x200x2, app == 100x100x2. Мы получим, что приложение заняло верхнюю левую четверть отведенного ей экрана.

* screen == 200x200x2, app == 200x200x2. Четкая, pixel perfect, картинка.

Что еще важно понимать?

Если композитор имеет размер буфера для приложения 200x200, и screen scale 2, то он, в качестве желаемых размерностей пошлет приложению 100x100, чтобы non-hidpi-aware приложения как-то работали. hidpi aware приложения, для того, чтобы рассчитать размер буфера для отрисовки, должны эту величину умножить на переданный scale.

А дальше все тулкиты изголяются, кто во что горазд.

Например, что делает SDL:

* Он hidpi aware, поэтому он выделяет буфер размера w * scale, h * scale. То есть, цепочка: композитор имеет буфер 200x200x2, он передает в SDL 100x100x2, SDL выделяет буфер для рисования 200x200x2. https://github.com/libsdl-org/SDL/blob/main/src/video/wayland/SDL_waylandwindow.c#L1901-L1905

* Далее SDL делает что-то странное. Он говорит, что всю отрисовку теперь мы будем делать в неких point, point у нас 100x100, каждый point физически отображается в 2 пикселя. https://discourse.libsdl.org/t/high-dpi-mode/34411

* ImGui берет размерности экрана в этих point, 100x100, делает gl viewport 100x100 над буфером 200x200, и рисует в свое удовольствие заблюренный контент.

То есть, как будто hidpi aware приложение само готовит контент низкого разрешения.

Я пробовал починить это разными способами, лучше всего сработал такой - https://git.sr.ht/~pg/ix/commit/fab9a5086801ea5e41d1e454f6c3a26abe9a06ed#pkgs/bin/reddit/desktop/hidpi/imgui_impl_sdl.cpp:

* В коде ImGui умножить размеры, передаваемые SDL, на scale.

* Получится так, что мы создадим viewport 200x200 над буфером 200x200, и отрисовка будет pixel perfect.

Почему я не могу расценивать это как финальное решение:

* Потому что, кроме gui, SDL возвращает масштабированными события от мыши, и получается, когда я их умножаю на scale, я теряю точность(мышка двигается по 2 пикселя по вертикали и гризонтали). Я не смог это заметить глазами на retina display, но как-то неаккуратно. http://forums.libsdl.org/viewtopic.php?p=43373

На мой взгляд, тут баг в SDL, что, когда приложение говорит, что оно hidpi aware, то надо ему возвращать настоящие пиксели, а не points.

Что мне делать с моим патчем в ImGui, я пока не понимаю.

BTW, должен сказать, что, после моего фикса, hidpi support в imgui кажется очень классным, потому что все размеры во float, и привязаны к размеру шрифта.

#imgui #insane

Решил закрепить успех, и собрать что-нить еще с imgui.

Выбор пал на https://github.com/WerWolv/ImHex, потому что много звезд, и оно использует glfw, а не SDL, для создания контекста.

Что в процессе сборки узнала девочка Антон:

* Автор проекта - сумасшедший. В целом, в этом ничего плохого нет, но вот https://github.com/WerWolv/ImHex/releases/tag/v1.19.2 "Upgraded codebase to C++23" - это немного за гранью. Я пока не нашел связку компилятор + c++ lib, с которой бы это завелось, поэтому я откатился на прошлый релиз.

* glfw + imgui, с точки зрения hidpi, работают гораздо корректнее. Плясать с бубном пока не пришлось.

* Оказывается, в с++ теперь есть вот такое, а я не знал:

view_hex_editor.cpp:202:69: 
    error: no member named 
    'boyer_moore_horspool_searcher' 
    in namespace 'std'
    return std::search(haystackBegin, 
        haystackEnd,
    std::boyer_moore_horspool_searcher(
        needleBegin, needleEnd));

Ну, как, в с++ есть, а в libc++ только-только завезли. https://reviews.llvm.org/D121074

* Пришлось сделать вот такое:

s|std::abs(index)|(index > 0 ? index : -index)|

потому что не во всех стандартных библиотеках есть std::abs для int128_t, дээээ.

#ix

При сборке пакетов регулярно нужно смотреть, какие опции предлагает тот или иной пакет, ну, типа, ./configure —help.

Я сделал для себя мегаудобную штуку - теперь настройки сборки можно смотреть, не скачивая вручную исходники, а просто указав —help в ix:

...
# pg-> ./ix build bin/stunnel --help
...
  --disable-libtool-lock  
    avoid locking (might break 
    parallel builds)
  --disable-largefile     
    omit support for large files
  --disable-ipv6          
    disable IPv6 support
  --disable-fips          
    disable OpenSSL FIPS support
  --disable-systemd       
    disable systemd socket 
    activation support
  --disable-libwrap       
    disable TCP wrappers support
...

Что самое прикольное, сам ix про это вообще ничего не знает, help - это просто очередной флажок, который попадает в шаблонизатор, и каждый конкретный шаблон реализует эту логику каким-то своим способом.

Например, в meson для этого достаточно вывести на экран meson_options.txt - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/die/meson.sh#L44:

{% if help %}
cat meson_options.txt
exit 1
{% else %}

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

https://lwn.net/Articles/901699/

Красивое.

Какое-то CVE в Go, или в библиотеках, и список на сотню security апдейтов в go-шных пакетах.

Статическая сборка, все дела.

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