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

Сегодня две истории про это.

* https://download.gnome.org/sources/gtk+/3.24/

Вышла новая версия gtk3 - https://download.gnome.org/sources/gtk+/3.24/gtk%2B-3.24.35.tar.xz - от 22 ноября.

В этот архив забыли положить meson.build из https://gitlab.gnome.org/GNOME/gtk/-/tree/gtk-3-24/gdk/wayland/cursor.

Я не знаю, что за рукожоп это делал, но файла нет, и проект без него не собирается, мне пришлось его доложить прямо в сборку, в виде патча. https://github.com/pg83/ix/blob/main/pkgs/lib/gtk/3/ix.sh#L29

Думаю, что RH собирает этот пакет через configure, пакет делает какой-то человек руками, и ему похер на сборку meson.

* Есть такой интересный проект - https://github.com/hyprwm/Hyprland #hyprland

Это такая альтернатива sway, только со свистелками и перделками.

https://github.com/hyprwm/Hyprland/releases/download/v0.18.0beta/source-v0.18.0beta.tar.gz - вот они сделали tgz руками, https://github.com/hyprwm/Hyprland/archive/refs/tags/v0.18.0beta.tar.gz - а это снепшот репозитория.

Признаться, я не понял, что там за наркомания, такое ощущение, что для ручного пакета они взяли содержимое папки src/, и доточили его напильником.

Я через их makefile собрать не сумел, поэтому взял снепшот репозитория, он собирается.

Кстати, раз уж начал про этот проект!

Я на нем могу очень хорошо продемонстрировать свой способ patchwork.

https://github.com/hyprwm/Hyprland/blob/main/src/helpers/SubsurfaceTree.hpp#L27

Зацените оператор сравнения. Он не объявлен const. Поэтому он работает в libstdc++, но не работает в clang/libc++ (например, при попытке вызвать list.erase() с такими элементами).

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

А процедурный патч - https://github.com/pg83/ix/blob/main/pkgs/bin/hyprland/unwrap/ix.sh#L42 - занимает 5 строчек кода, потому что природа патча вполне регулярна!

(Кстати, проект хороший, если хочется поучаствовать в OSS движухе - занесите им это исправление! https://github.com/pg83/ix/blob/main/pkgs/bin/hyprland/unwrap/ix.sh#L59 - там еще два патча про фикс сборки с libc++/clang, но они не такие sexy)

https://www.phoronix.com/news/RFC-eBPF-Linux-Scheduler (#ebpf #uring #future)

#ebpf едет в шедулер, а, значит, я скоро смогу попробовать запустить в него свои шаловливые ручки #ananicy

"The belief is that with eBPF support for the Linux kernel scheduler it could ease experimentation and exploration of new scheduling policies, allow for application-specific schedulers and other customizable options via the loading of custom BPF programs, and provide a non-disruptive way for changing out scheduling policies within production environments"

Ну и, совсем не удивляет, что "Engineers from both Google and Meta (Facebook) are behind this initiative"

Пост для гиков.

Если поглядеть на картинку (и тред), то маленькая иконка OpenAI указывает на то, как GPT находит баги и эксплоиты в коде (тут конкретно в коде смартконтрактов). Они (пока) простые и достаточно распространенные, но то, как GPT их описывает жутко интересно. А также он декомпилирует байткод и описывает что он делает.
Это я к чему.
Если нужно будет захватить мир путем взлома человеческой инфраструктуры - то ИИ уже готов - дайте только доступ в интернет. И готовьте свои метамаски.
https://twitter.com/gf_256/status/1598104835848798208

Мужик сказал - мужик сделал!

Запилил я gdk pixbuf #svg loader поверх #lunasvg!

В процессе, конечно, узнал много чего интересного, чем и спешу поделиться.

Короткая предыстория:

* Сперва у меня вообще не было рендера svg, потому что #rsvg перешел на Rust, а его у меня (пока?) нет.

* Потом я научился использовать довольно старую версию librsvg, которая была написана на C, и глючила, что пиздец - 1/4 иконок была отренжерена с какими-то артефактами. Это, конечно, то еще достижение, учитывая простоту формата svg.

* Потом я научился готовить для всех scalable иконок png заранее, с помощью inkscape. Примерно для 1/4 оставшихся использовался старый rsvg render, с баглом и артефактами.

* Потом я нашел замечательную #lunasvg, и перешел на нее для рендеринга png, а то, что мой процесс не находил, или были нужны какие-то особенные разрешения, использовался старый rsvg.

* (мы находимся тут) -> png рендерятся с помощью lunasvg, остатки - тоже.

https://github.com/pg83/ix/blob/main/pkgs/lib/lunasvg/gdk/io.cpp - вот код клея между lunasvg и gdk-pixbuf.

БОльшую часть кода я написал за полчаса, а потом еще часа 3 трахался за последние 5 строк кода, без которых на экране был мусор:

* Примерно полтора часа - это "нормальная" отладка - разбирательство с тем, в каком формате поверхность отдает lunasvg, в каком ожидает GdkPixbuf, и как их "поженить", разбирательство с моделью владения памятью в glib(чтобы не текло и не ездило по use-after-free), и с обработкой ошибок в ней же.

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

В какой-то момент времени я остановился, и подумал: "А какое бы безумное действие я мог бы совершить на месте авторов gtk, чтобы у меня ничего не работало"?

Единственное, что мне пришло в голову - что они, зачем-то, портят xml с svg, перед тем, как его передать мне. Ну потому что как еще объяснить факт, что pixmap data получается разная?

Sooka! Sooka! Аааа!

https://github.com/GNOME/gtk/blob/main/gtk/gdkpixbufutils.c#L249

Короче, они манглят svg во вложенный svg в виде base64 блоба. КМК, это сделано затем, чтобы указать уникальный размер для рендеринга. Да, да, в scalable vector graphics есть width, и height, чтобы им пусто было.

Я, конечно, решил, что раз эти негодяи формируют xml через printf, то парсить я его буду регулярками. https://github.com/pg83/ix/blob/main/pkgs/lib/lunasvg/gdk/io.cpp#L93 (да, да, это точно надо занести в upstream)

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

Продолжение истории про #lunasvg. #svg

Я закончил на том, что у меня часть иконок была отренжерена через lunasvg в процессе построения пакета с иконками, а часть(которая вне этого пакета) - в процессе работы приложения.

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

Причем я совершенно точно уверен, что цвета я отдал правильные, я вывел их на консоль, и сравнил с тем, что шло в сгенеренных png. Уклона в сепию в этих цветах не было.

Я бы тут хотел ткнуть вас куском кода из rsvg/cairo/gdk, который страдает такой херней, но я не сумел, там все слишком запутано.

Чего только стоят несовпадения ARGB/RGBA, где-то используется premultiplied alpha, где-то - нет, premultiplied alpha по разным формулам, все эти поверхности постоянно туда-сюда преобразуются.

Я решил просто потвикать r, g, b, a каналы в разные стороны, и посмотреть, что получится.

В процессе я выяснил:

* g, b каналы никак не использовались, ну, то есть, я мог туда записать все, что угодно.

* r канал давал изменение от цвета фона к ярко-желтому цвету. 0 - фон, 255 - ярко-желтый(нет, это не cmyk, и не прочие модели, по крайней мере, не те, что я знаю).

* alpha канал работал, как надо.

Мое лучшее предположение - что рендеринг symbolic иконки - это, собственно, отбрасывание r, g, b, и использование только alpha компоненты для блендинга между фоном и цветом для рисования.

Желтый? Хер его знает, может, для дебага, может, я вообще неверно все понял.

В итоге, решение вида "оставить только alpha канал для svg, которые загружаются как symbolic иконки", вполне себе сработало, я с лупой не нашел отличий. https://github.com/pg83/ix/blob/main/pkgs/lib/lunasvg/gdk/io.cpp#L100

Так-то это достаточно логично - а как еще наиболее дешево "оконтурить" произвольную svg?

Где это происходит в связке rsvg/gdk/cairo, я не нашел, они большие мастера прятать такое говнецо.

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

Просто писать код - скучно, это уже давно доведено до автоматизма.

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

В #ix такое ограничение - это размер ядра(интерпретация пакетов и подготовка графа) в байтах.

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

Нужно мне длинное название метода - значит, будет длинное название! https://github.com/pg83/ix/blob/main/core/package.py#L261

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

Основные источники профита:

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

* Поиск дублирующегося "смысла" (например, в какой-то момент мне довольно сильно помогло сократить размер понимание, что #realm/env - это точно такая же нода, как и любой прочий пакет, и обрабатывать ее надо тем же кодом)

Довольно долго я держал планку в 40к, при этом добавляя новые фичи, потом, полгода, держался на 50к, но вот последние месяца 2 - 3 забрался за 51, и оно никак не ужималось.

Сегодня я отыграл до 49к, бесплатно добавил новую команду "let", и очень рад этому факту!

"let" - это такой аналог "mut", который не перемещает глобальную симлинку на свежеподготовленный realm/env. Эта команда полезна, когда хочется перед переключением системы на новый root, посмотреть, чего там в нем таки лежит.

(напомню, что, по сути, мой корень - это симлинка на вот такой read only realm)

Как я это ужал?

Я отрефакторил команды mut/let/run/build в фасады к одной простой функции, которая умеет подготовить набор realm для заданной командной строки:

* let - это просто вызов этой функции

* mut - это let + несколько вызовов os.symlink()

Дальше интереснее:

* build - это интерпретация заданного command line в контексте создания нового эфемерного realm.

* run - это build, в финале которого еще запускаем одну команду в свежесозданном окружении.

https://github.com/pg83/ix/blob/main/core/cmd_realm.py#L27 - собственно, вот эти 5 функций, которые позволили мне стереть 1.5k кода!

https://github.com/scandum/rotate

Интересная подборка про разные способы "провернуть"(поменять левую и правую часть с сохранением порядка в каждой из частей) массив.

У меня, когда в таком возникает нужда, в голову всегда приходит один и тот же алгоритм, который по ссылке назвали "Triple Reversal Rotation".

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

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

{% block deps %}
A
B
C
{% endblock %}

превратится в "-I A/include -I B/include ..."

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

Например, вот тут - https://github.com/pg83/ix/blob/main/core/realm.py#L72-L73

Или вот тут, но тут сложнее заметить - https://github.com/pg83/ix/blob/main/core/package.py#L56

https://github.com/RomanHotsiy/commitgpt

"Automatically generate commit messages using ChatGPT"

Это мы используем.

https://www.opennet.ru/opennews/art.shtml?num=58249

Пишут, что нового кода в Android на Rust становится больше, а на С(и, в меньшей степени, на С++) - меньше.

Это, конечно, очень хорошо.

Думаю, вы уже знаете мою точку зрения, что, с точки зрения безопасности, современный С++(с RAII, контейнерами, и санитайзерами), на практике не сильно опаснее Rust(хотя Rust, конечно, сильно более хайповее!), но вот писать новый системный код на С - так себе идея.

Если честно, то мне, конечно, жаль, что гонку с С выиграл не С++, но и так неплохо получается.