Довольно техническая тема сегодня.

Я уже как-то рассказывал, как я из "грязных" входных данных делаю "чистые".

Грязный ввод - это, скажем, git checkout, или cargo vendor, или что-то в этом роде. Короче, куча файлов, которые скачиваются по сети, и, в общем, ты для них заранее ничего не можешь сказать.

Грязные данные нельзя делать вводом "чистого" алгоритма, потому что его результат - непредсказуем, невоспроизводим.

Поэтому я все такие данные кладу в один большой архив, в определенном формате, считаю его хеш, и, после этого, данные становятс "чистыми". Потому что если я заранее знаю хеш от полного git checkout/cargo vendor/etc, то, значит, я зафиксировал результат работы "грязного" кода. Если же хеш не совпал, то сборка останавливается.

И я, если честно, задолбался с форматом этого архива.

Потому что мне не захотелось велосипедить, и я решил, что у меня получится файлы после сырого git clone/cargo vendor/etc привести к такому состоянию, что tar.gz от них на разных хостах будет одинаковый.

Я прошел несколько итераций улучшений этого процесса:

* umask на разных машинах разный, поэтому после закачки надо приводить его к общему виду

* timestamp у всех файлов, очевидно, надо выставлять в одно и то же число

* gid/uid файлов сохрнанять нельзя, потому что он зависит от пользователя, от которого ты все запустил

* все rw права надо переделывать в ro, а после распаковки - снова не забыть в rw, потому что можем захотеть пропатчить результат

Но больше всего проблем мне доставили симлинки.

Симлинки для воспроизводимого сохранения в tgz - это какой-то звиздец. Потому что:

* Просто так удалить все симлинки из дерева - не вариант. Чаще всего они не нужны, но не всегда.

* А они могут вести на dangling file, и tar может выкинуть их к хуям во время компресии, если не знать про правильные ключи. А еще у тебя на одном хосте это будет dangling link, а на другом - нет.

* Права доступа к симлинкам vs файлам, на которые они указывают.

* Влияние umask при их создании. Я, кстати, так и не понял логику за этим процессом, и это стало последней каплей, когда я решил свести задачу к существующей.

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

https://github.com/pg83/ix/blob/main/pkgs/bld/stable/pack/store_links
https://github.com/pg83/ix/blob/main/pkgs/bld/stable/unpack/restore_links

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

Любители nix меня спросят, почему не взять готовый nar (https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-nar)?

Давайте я вам просто покажу код по сериализации в nar:

https://github.com/ebkalderon/libnar/blob/master/src/ser.rs#L31-L71

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

Так, я нашел время обновиться на #mesa v. 24, перейти на использование ACO вместо LLVM, для компиляции шейдеров, и даже замерил экономию в размере получающихся программ:

llvm:

pg# ls -la .../bin/imhex
157265936 Jan 1 2000 imhex

aco:

pg# ls -la .../bin/imhex
88756648 Jan 1 2000 imhex

Очень и очень немало, почти 70 мегабайт разницы, вот столько весит используемый оптимизатор из LLVM.

Программисты В С Ё, во всяком случае так считает глава NVIDIA Дженсен Хуанг.

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

Скинь тому самому 300к-сеньору

О чем я тут пишу:

https://stal-ix.github.io/

https://xn--r1a.website/itpgchannel/20
https://xn--r1a.website/itpgchannel/376
https://xn--r1a.website/itpgchannel/377
https://xn--r1a.website/itpgchannel/379

А я, тем временем, занялся автоматизацией своей home #lab.

Моя home lab - это 3 сервера, в которых примерно 200 ядер, + 3 - 4 небольших нод, которые сделаны из всякого хлама, скопившегося за несколько лет.

Понятно дело, что все это и так крутится под #stal/ix, но, до сего момента, все это выглядело так - я руками ставил OS на машину, а дальше заходил на нее через ssh, и руками вводил какие-то команды, которые что-то делали с этой машиной.

Конечно, можно было бы взять что-то готовое, но:

* нужно есть свою собачью еду.

* https://en.wikipedia.org/wiki/Content-addressable_storage - очень хорошая основа для всякого там IaC, и мне хочется сделать еще один подход к этому снаряду.

Если совсем коротко:

* Ручная наливка хоста заканчивается тем, что мы удаляем set/stalix из system #realm, и ставим туда почти то же самое, но с автоапдейтом.

* Автоапдейт занимается тем, что "приводит систему к состоянию", которое указано в каком-то заранее определенном репозитории.

Состояние - это набор пакетов, заданное состояние - это набор пакетов, который описан в какой-то конкретной версии репозитория.

https://github.com/pg83/lab - вот код, который полностью описывает состояние моей home lab.

Он состоит:

* Fork stal/IX, который я периодически сливаю с upstream.

* Одна точка входа, тот самый пакет, который содержит ссылку на auto updater, и на пакеты, которые должны стоять в системе - https://github.com/pg83/lab/tree/master/pkgs/lab https://github.com/pg83/lab/blob/master/pkgs/lab/ix.sh#L7

Я его устанавливаю на каждый хост, он ставит:

* сам auto updater. https://github.com/pg83/lab/blob/master/pkgs/lab/services/autoupdate/scripts/ix.sh - простой скрипт, который в цикле забирает новое состояние с github, и приводит систему в соответствие этому состоянию.

* пакеты, которые должны быть на каждом хосте

* и диспетчер, который ведет на список пакетов, уникальный для хоста - https://github.com/pg83/lab/blob/master/pkgs/lab/ix.sh#L6

Вот, например, список пакетов для "host1" - https://github.com/pg83/lab/blob/master/pkgs/lab/hosts/host1/ix.sh. Видно, что он крутит мой ci, и какую-то ерунду, про которую расскажу в другой раз.

Так, я на вас вывалил некоторый "framework", в рамках которого потом буду рассказывать про свой home lab.

Вот ровно так на меня смотрят наши джуны, когда я предлагаю все переписать!

https://a.exozy.me/posts/pulseaudiodb/

Текст про то, что KV база данных может быть устроена из чего угодно. В данном случае - из настроек громкости в PulseAudio.

Доставляет то, что получившийся KV поверх PulseAudio - очень медленный:

"and only takes 15.14 seconds to run for an amazing 200 reads and 200 writes"

Наверное, потому что кто-то очень любит программировать на sleep, а то как же это еще объяснить?

Раз уж я занялся автоматизацией своего home #lab, то расскажите мне за DNS.

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

А дальше мне бы хотелось, что, когда dhcp раздаст всем по IP, каждый хост "куда-то" рассказал про свой IP, в виде пары (hostname, IP), например, через broadcast, и это самое "куда-то" начало обрабатывать DNS запросы.

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

Пока я сделал по рабоче-крестьянски: привязал в dhcp IP к mac, и прописал все хосты в /etc/hosts на каждом хосте, но это как-то не очень спортивно.

https://habr.com/ru/companies/ruvds/articles/796345/

Годный текст (перевод, оригинал там же, по ссылке) про #GNOME.

Из него я узнал, что в GNOME появился аж третий терминал "по умолчанию", о как.

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

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

https://gitlab.gnome.org/sungsphinx/ptyxis

#ptyxis

Правда, автор пока не договорился с libvte про свои патчи, и носит их с собой:

https://gitlab.gnome.org/sungsphinx/ptyxis/-/tree/main/build-aux

Поэтому он не может быть собран с системной libvte, и вынужден предлагать всем попробовать свое поделие через flathub - https://gitlab.gnome.org/sungsphinx/ptyxis#installation.

Я когда-то писал про libvte, и про gnome-console, удивительно, но вот этот косяк с W_EXITCODE (https://xn--r1a.website/itpgchannel/282) люди тащат из проекта в проект.

https://discourse.llvm.org/t/user-created-branches-in-the-monorepo-are-often-misused/75544/34

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

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

https://habr.com/ru/companies/ruvds/articles/796345/

Никак меня не отпускает этот текст.

Там просто кладезь говна, изготовляемого #GNOME, и сопричастными.

Например:

"Когда они выпустили libxml 2.12.2, она была настолько поломана, что всё зависящее от неё не собиралось из-за отсутствующих заголовков. В том числе и больше четырёхсот приложений, не имеющих никакой связи с десктопным окружением GNOME, такие как Chromium, FFmpeg, VLC, Wayland, Xfce [23]. Неделю спустя была выпущена новая версия, устраняющая баг [22]."

Не понимаю, почему .2, наверное, раньше просто не заметили.

Оно было сломано с самой 2.12.0, и было сломано катастрофически.

https://github.com/pg83/ix/commits/main/pkgs/lib/xml/2/t/ix.sh
https://xn--r1a.website/itpgchannel/1473

Оцените, я с ноября прошлого года занимался тем, что накатывал каждую следующую версию libxml из ветки 2.12.X, а потом, матерясь, откатывал на 2.11.

Почти полгода они не могли починить одну сраную библиотеку после небольшого рефакторинга.

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

Треш, угар, содомия.

Появление React ребята из Facebook часто объясняют примерно вот так:

В далеком 2013 году в Facebook Chat часто появлялись фантомные сообщения: уведомление приходило, иконка загоралась, а самого сообщения не было.

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

У меня всегда были вопросы к этому объяснению. А вчера Adam Wolff причастный к разработке добавил деталей:

Да, React, был действительно создан для решения проблемы фантомных уведомлений, но эту проблему он в результате не решил, потому что проблема на самом деле была в кривых настройках DNS где-то в Индии, и когда DNS починили проблема ушла.

https://twitter.com/dmwlff/status/1762885255030259854?s=20

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

Конечно, если все делать плохо, то будет плохо, а если плохо не делать, а делать только хорошо - то все будет исключительно хорошо.

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

Вышли 6-ые кеды.

У меня их нет, и пока не будет (#kparts), а вот то, что они объявили #wayland сеанс основным, очень и очень много значит.

Это значит, что внедрение wayland сейчас станет лавинообразным, и, через год-два, будет не 15% wayland, а 15% X11. #future

Надеюсь, не откатят это, как когда-то сделали SDL.