Решил посмотреть, что там в стане врага у конкурентов, у них все тоже неплохо - есть как минимум одна популярная библиотека для разработки композиторов - https://github.com/Smithay Там, конечно, не весь стек на Rust, но, тем не менее.

И, вот, интересный scrollable (https://xn--r1a.website/itpgchannel/1437) tiling compositor на его основе - https://github.com/YaLTeR/niri Посмотреть я его пока не посмотрел, но выглядит неплохо.

https://github.com/CuarzoSoftware/Louvre/blob/main/LICENSE

Слона-то я и не заметил.

Бибилиотека под GPLv3, а, значит, использовать ее никто не будет.

А если у библиотеки нет пользовательской базы, то в ней нет багфиксов и развития.

Есть, конечно, небольшое количество устоявшихся библиотек под #GPL, но они погоды не далают.

Забавно, я все еще думал, что такое бывает только в интернете, пока не нашел у себя в логах CI:

libc++abi: terminating due to uncaught exception of type std::__1::system_error: thread constructor failed: Resource temporarily unavailable
libc++abi: terminating due to uncaught exception of type std::__1::system_error: thread constructor failed: Resource temporarily unavailable
libc++abi: terminating due to uncaught exception of type std::__1::system_error: thread constructor failed: Resource temporarily unavailable

Теперь думаю, как чинить.

Потому что, понятное дело, libc++/musl такой патч не возьмут.

Вообще, конечно, надо бы устроить рубрику "смешное в сборочных логах", вот сегодняшний улов:

ld.lld: error: undefined symbol: thiswillneverbedefinedIhope

https://github.com/ocornut/imgui/releases/tag/v1.90

Люблю рассматривать релизы #imgui, потому что там всегда есть список новых приложений, которые его используют.

Это вообще какая-то совершенно потрясающая вещь - в списке каждый раз 10 - 20 новых приложений, это примерно столько же, сколько во всем Gnome core.

Судя по всему, на imgui очень легко писать сложные gui, нужные для тулинга, и которые нужно написать быстро, а завтра - выкинуть. И в этом процессе нет места вылизыванию blur на уголках окон по 100500 раз.

Короче, промышленный инструмент, а не вот эти ваши изыски над css.

Мне очень импонирует идея gui как очень тонкой прослойки над системным 3D API, потому что все классические gui типа qt/gtk, которые интегрировали 3d постфактум, сделали это плохо, неполно, и поэтому ты не знаешь, какая часть сцены у тебя отрендерится в 3d, и что приведет к тому, что случится 100500 копирований какого-нибудь буффера из/в память видеокарты.

К сожалению, в Linux 3d драйвера - это .so в userspace, вместо того, чтобы быть каким-нибудь dbus daemon, который бы умел кешировать и компилировать шейдерные программы, что не очень изящно ложится в мою модель статической линковки (бинари довольно заметно распухают, это не то чтобы сильно важно, но как-то "неаккуратно").

Поэтому я, конечно, очень жду, когда gui можно будет компилировать в что-то типа #WASM #WASI, и чтобы 3d драйвера жили исключительно в одном бинаре с WebAssembly VM, о как. Это, если что, не влажная фантазия, у вас прямо сейчас так работает webgl в браузере!

За последние несколько дней вышло:

* 3 минорных версии libheif
* 2 минорных версии libde265
* 2 минорных версии libaom

Это жжж неспроста, они там явно что-то судорожно чинят!

https://glandium.org/blog/?p=4346

Классный рассказ про то, как git вытеснял hg в Mozilla.

Из него я узнал, что однажды зеркало mozilla в github этот самый github немного сломало - https://bugzilla.mozilla.org/show_bug.cgi?id=943132#c8

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

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

(разумеется, она пижже, чем git, потому что умеет в монорепу, и умеет в упрощенный flow, типа svn commit, без иызысков с индексом и прочими усложнениями от git)

Есть такая утилита - neofetch, обычно ее используют, когда делают скриншот с каким-нибудь особенно всратым образом настроенным sway, или там waybar - https://www.reddit.com/r/unixporn/

Я решил попробовать ее альтернативу, под названием https://github.com/fastfetch-cli/fastfetch

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

Но вот глаз зацепился за то, что, в качестве terminal emulator она мне писала "mc".

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

Мама дорогая...

https://github.com/fastfetch-cli/fastfetch/blob/dev/src/detection/terminalshell/terminalshell_linux.c#L134-L146
https://github.com/fastfetch-cli/fastfetch/blob/dev/src/detection/terminalshell/terminalshell_linux.c#L153-L170

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

Так как "mc" у него не был прописан в этих списках, то он на нем останавливался, и поднимал лапки.

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

Какие-то простые штуки, типа "session leader", "владелец теминала, в который я сейчас пишу", наткнулись на то, что авторы тех или иных оболочек вообще не понимают, как устроены process group, sessions, и так далее, в unix, и делают какие-то совершенно странные штуки (типа, создают сессию, когда она совершенно не нужна по логике вещей). Впрочем, я тоже в этом плохо разбираюсь, да и сами авторы этого кода в Linux (unix) тоже.

Норм работает тема "а вот у какого процесса вверх по дереву есть открытый fd в wayland/x11 socket", но это было уже слишком сложно, и я передумал это дело патчить.

Просто добавил "mc" в список исключений, и оно "заработало".

https://github.com/pg83/ix/blob/main/pkgs/bin/fastfetch/ix.sh#L25

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

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

Тут вот проект opensuse ищет новый логотип.

Я бы им, конечно, предложил сабж (pepe clown)

Мне вот интересно, как в Arch проезжают новые версии софта?

Вот есть такая https://archlinux.org/packages/core/x86_64/libxml2/

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

Но, при этом, если собрать .so, то она обратно совместима. Потому что все нужные символы остались, просто лежат в других файлах.

Получается, Arch тащит к себе код, с которым можно динамически слинковаться, а вот пересобраться уже не получится?

Как так?

https://www.forrestthewoods.com/blog/dependencies-belong-in-version-control/

Тут вот коллега пишет, что надо, мол, clang.exe класть прямо в VCS, и расписывает, как было бы много профитов у такого решения.

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

И вся эта красота разваливается, когда нужно проапдейтить zlib.

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

В репозиторий нужно класть якоря - ссылки на метапакетные системы, типа flake.nix, ix.h, и так далее, чтобы они готовили контролируемое и воспроизводимое окружение, в котором бы ты запускал свою сборку, которая должна быть максимально простой, без configure в 10к строк.

И действительно, зачем кешировать зависимости в git (или другой vcs), когда тебе их, в один момент, привезут на хост ровно в том виде, в котором ты их ожидаешь?

- Когда я встречу свою любовь?
- Погоди пару минут, кластер Кубера навернется...