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

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

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

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

Удивительно, но я, кажется, сделал.

За выходные закрыл 2 последних задачи, без которых отдать #stal/ix кому-то было просто невозможно:

* Возможность указывать графический стек, отличный от RADV + ZINK. Теперь у меня поддержаны различные комбинации графических стеков для AMD, Intel, ну и софтверный стек для всех остальных.

Немного в сторону - llvmpipe прямо хорош, он насытил все 16 ядер моего ноутбука, и выдал вполне приличные RPS в Q3 на 4к экране.

Сделано это с помощью указания флага —mesa=radv для #realm, в котором стоят программы пользователя.

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

* И, собственно, вторая задача - возможность указать глобальные флаги на #realm.

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

Про новый разбор командной строки я напишу отдельно, КМК, получилось довольно занятно. Теперь можно за один запуск поменять все #realm-ы произвольным образом(добавить/удалить * realm/package/global_flag/package_flag).

Теперь только написать документацию, и заняться сайтом.

#plugins

У меня сейчас не собрано ни одного KDE-шного приложения(за исключением пары библиотек, ранее нужных телеге), потому что я очень не хочу иметь дело с их KParts и KIO Slaves. Про KIO Slaves(кстати, их еще не переименовали? последний раз я в их исходник заглядывал лет 15 назад) в другой раз, сегодна про #KParts.

Что такое KParts?

https://api.kde.org/frameworks/kparts/html/index.html

Если совсем просто, то каждый виджет, отнаследованный от QWidget, имеет конструктор KWidget(QWidget* parent).

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

* А дальше у всех разработчиков происходит какое-то умопомрачение. Как только у разработчика появляется сколько-нибудь полезная фабрика, он обязательно хочет ее сделать подгружаемой с диска, через dlopen.

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

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

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

Если говорить конкретно про KParts, как вот про такую плагинную фабрику по загрузке виджетов, то:

* Я не понимаю, чем для среднего приложения KParts::load("terminal", parent) лучше, чем new KonsoleWidget(parent). Нет, никто, в своем уме, не будет реализовывать другую консоль для KDE, в том числе, потому что у виджетов QT есть интроспекция в сигналах и в слотах, и хрен ты узнаешь, к каким из них подсоединился тот или иной пользователь KParts::load("terminal"). Чем хуже - понимаю, это неявная зависимость, ее надо прописывать в пакетном менеджере, вместо сборочного скрипта.

* Есть point про всякого рода просмотрщики файлов, которые из себя представляют shell для KParts. Я на это отвечу, что:

1) Просмотр jpeg и просмотр pdf сильно отличаются, и тем более, сильно отличаются от просмотра там 3ds. Обвязка/GUI в этом shell должна быть сильно разной для разных типов файлов, а если shell предназначем для каких-то конкретных типов файлов, то тогда уже нет смысла в KParts, надо просто слинковаться с нужными библиотеками для просмотра pdf/djvu/svg.

2) Загружать и выполнять произвольный код в свою программу - ну такое. У тебя какой-то third party KPart будет ездить по памяти, а ты этим shell, после просмотра файла и проезда по памяти, пойдешь браузить WEB, как это было в Konqueror(глюкалово страшное, после просмотра samba share его лучше было перезагрузить). Лучше я открою отдельное приложение через dbus/xdg-open, которое спокойно унесет проехавшуюся память за собой в могилу.

3) Если уж так хочется shell, то сделай из своего процесса wayland compositor, и открывай себе просмотрщики в отдельных процессах, показывая их GUI у себя в shell.

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

#stal/ix

Вынес документацию в отдельный тип таргета, по аналогии с bin, lib.

Почему?

К - Консистентность.

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

Если же требовать установку документации всегда, то это довольно сильно увеличивает высоту графа, потому что один pandoc чего стоит(https://pandoc.org/installing.html#compiling-from-source TL;DR; - Haskell). Ну и лишних циклов прибавляет.

Поэтому я решил, что:

1) Для документации и man уже давно есть web. На самом деле, я так-то особо и не вспомню, когда пытался прочесть что-то локально. Кстати, если не знали - прикольная штука - https://tldr.sh/, вот бы для man кто-нить такое запилил.

2) Если "очень надо", то всегда можно установить пакет с —kind=doc, и наслаждаться жизнью.

Ну и, будучи последовательным сумасшедшим, если kind==doc не указан, то я принудительно документацию удаляю, потому что К. https://git.sr.ht/~pg/ix/tree/main/item/pkgs/die/std/postinstall.sh#L89

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

https://github.com/carbon-language/carbon-lang #carbon

Carbon, новый язык от Google(хотя они это, кажется, не афишируют, но их фирменный стайлгайд и сборка на Bazel выдают их с потрохами).

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

Элегантная комбинация синтаксиса от Rust(включая совершенно уебищную модель generic'ов**) + memory safety C++, то есть, кажется, это язык, на котором лично я программировать не буду.

Кажется, это пока больше декларация о намерениях, потому что реального кода самого языка в репозитории довольно мало(https://github.com/carbon-language/carbon-lang/tree/trunk/toolchain).

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

**: да, я считаю, что современные веяния, когда надо явно указывать, какие интерфейсы реализует класс - это очень так себе, duck typing шаблонов в C++ мне кажется куда как более здравым решением. У меня тут есть такое соображение - "клеить" статически типизируемые языки мега-удобно с помощью duck typed прокладки, типа, С + Python, или вот С++ + templates.

Собрал первую программу на #go, сразу с cgo.

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/emptty/ix.sh

Выглядит, вроде, неплохо.

Go я честно #bootstrap, начиная с версии 1.4, которая последняя на С, и кончая версией 1.18.

Скажу, что авторы Go, конечно, по гугловым меркам, упыри - у них слишком много "ценного мнения" на единицу кода.

Одна игра с GOROOT_BOOTSTRAP/GOROOT_FINAL чего стоит, ну и официально рекомендованный сопосб установки свежескомпилированного тулчейна доставляет:

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/go/4/ix.sh#L35

Доставили игры с линкером от Go:

* Он так и не смог научиться понимать мою структуру директорий с библиотеками, пришлось сделать так, что он всегда использует external linker - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/go/18/c/ix.sh#L21

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

Ну и эпичнейший баг с cgo - https://github.com/golang/go/issues/40415 - оно не работает, когда clang делает разноцветный выхлоп:

"The cgo tool doesn't really do string analysis of error messages. It just uses the file name and line number. But it does look for the literal string ": error:". It looks like -fdiagnostics-color is messing that up, because color codes are written out after the first colon."

"Не, мы не парсим выхлоп компилятора. Ну, ладно, парсим, на полшишечки, но это не считается", пишет нам некто ianlancetaylor.

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/go/18/c/ix.sh#L17

Вендоринг для Go я пока даже не начинал делать, а это значит, что нужно уже учиться в системе сборки помечать ноды как use_net/pure/impure, и чтобы сборка pure нод не могла зависеть от impure нод.

* компилятор Go от переписывания с С на Go замедлился раза в 2, если не больше, живите с этим знанием :D

* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/go/18/t/ix.sh#L37 - go ищет сертификаты по каким-то захардкоженным путям, прищлось это исправить.

* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/go/18/t/ix.sh#L42 - вот тут какая-то очень странная упячка, go, при сборке, почему-то очень хотел записать новый runtime.a по путям, по которым лежит предыдущая версия go. В интеренете на эту тему мутно - у кого-то тоже случалось, почему - непонятно. Я просто копирую исходный тулчейн во временную папку.

Кстати, кажется, вполне можно воспринимать #carbon именно вот с этой точки зрения, что, наконец-то, какая-то компания взяла, и решила запилить С++ 2.0 на основе clang, все, как я и заказывал.

(а всратый синтаксис от Rust - дань моде и попытка хайпануть)

#cplpl_doomed

Опять я мастер предсказывать уже произошедшие события!

https://www.reddit.com/r/programming/comments/w2thvo/carbon_an_experimental_c_successor_language/

Утащу комментарий с reddit:

"To give some context, in February of 2020 there was a crucial vote in the C++ standard committee about breaking ABI compatibility in favor of performance, mostly pushed by Google employees.
The vote failed. Consequently, many Googlers have stopped participating in the standardization of C++, resigned from their official roles in the committee, and development of clang has considerably slowed down.
Now, they've revealed that they've been working on a successor language to C++. This is really something that should be taken seriously."

Листал https://github.com/avelino/awesome-go, https://github.com/uhub/awesome-go - смотрел, есть ли тут что-нибудь полезное, что я раньше не мог положить в #stal/ix.

https://github.com/hashicorp/go-plugin:

"Plugins are Go interface implementations. This makes writing and consuming plugins feel very natural. To a plugin author: you just implement an interface as if it were going to run in the same process. For a plugin user: you just use and call functions on an interface as if it were in the same process. This plugin system handles the communication in between"

"Cross-language support. Plugins can be written (and consumed) by almost every major language. This library supports serving plugins via gRPC. gRPC-based plugins enable plugins to be written in any language"

"Protocol Versioning"

"Host upgrade while a plugin is running"

"Plugins can't crash your host process"

"Plugins are very easy to install"

"Plugins can be relatively secure: The plugin only has access to the interfaces and args given to it, not to the entire memory space of the process"

https://github.com/hashicorp/go-plugin#architecture
https://github.com/hashicorp/go-plugin#what-about-shared-libraries

https://github.com/xxxserxxx/gotop

"Extensions have proven problematic; go plugins are not usable in real-world cases, and the solution I had running for a while was hacky, at best. Consequently, extensions have been moved into the main code base for now"

В этом смысле экосистема Go - бальзам на мое израненное сердце.

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

Я окончательно зашкварился на go накодил закоммитил первые 10 строк на Go - https://github.com/tvrzna/emptty/pull/71

Дело в том, что emptty(очень достойный login manager, не скажешь, что на Go) не поддерживал хешированные пароли в /etc/passwd, а только схему с /etc/shadow, на которую мне все лень перейти.

Кстати, в чем отличие моих PR just for lulz, и PR по делу - все четко, быстро, понятно. Видно, что автор не стремится донести свою "важную точку зрения по любому вопросу", все исключительно по существу. Даже помог иcправить ошибку, в том же PR(а так можно было?)

Что я ощутил от разработки на #go? #обмазаться_шоколадом

Spread the word!

https://github.com/carbon-language/carbon-lang/issues/1519

https://github.com/python/cpython/blob/main/Lib/tempfile.py#L206

Например, код, проверяющий доступность для записи во временную папку для python.

Продолжал эксперименты с #imgui

Выяснил, что оно фигачит 60rps даже в моменты, когда это не требуется от слова совсем - https://github.com/ocornut/imgui/pull/5116

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

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

Нет в жизни счастья :(

https://github.com/carbon-language/carbon-lang/issues/1519#issuecomment-1192285832

"We think we've made it pretty low-overhead to grab Carbon and start building all the same. And no one else should need to interface with us at this point, it is much much too early. So for now, it seems reasonable to just focus on what works well for the team. Does that make sense?"

UPD: тут вот меня спрашивают - зачем писать, если все равно ничего не поменяется?

Как говорит моя любимая Шульман, "только сопротивление дает субъектность".

Я напишу, что не согласен, ты полайкаешь, или тоже напишешь - глядишь(с вероятностью 5%) что-то и поменяется.

А не напишешь - точно ничего не поменяется.