Я как-то писал, что одно из самых больших удовольствий, которое доставляет наш род занятий, это "соединить несоединимое" - https://xn--r1a.website/itpgchannel/1000.

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

У меня есть три текста на эту тему, я их решил объединить в цикл, и назвал его "История о трех херОборах" #herobora. #gold

История первая, или "альтернативный patch".

Недавно рассказывал про то, как интересно у меня сломался #GNU patch, при сборке keepassxc - https://xn--r1a.website/itpgchannel/1692

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

В общем-то, у нас есть следующие альтернативы:

* gnu patch (он сломан)

* оригинальный patch от Larry Wall (https://en.wikipedia.org/wiki/Patch_(Unix)), от которого пошли все остальные патчи

* git apply patch (про эту команду я ничего не знаю, и даже не смотрел, что у нее под капотом)

Я решил, что, а давайте соберем patch от Larry Wall, и попробуем заиспользовать его!

Какой вариант этого кода взять? patch от Larry Wall раскидан примерно по всем *BSD системам, с какими-то доработками, улучшениями, ухудшениями, немного разной сборкой, и так далее.

Тащить его из FreeBSD мне не захотелось, потому что он идет вместе со всей монорепкой FreeBSD, поэтому я решил стащить его из https://github.com/apple-oss-distributions/patch_cmds/tree/main/patch

В целом, хорошая альтернатива, тем более, macOS - один из немногих сертифицированных UNIX.

Понятное дело, что он никогда не собирался под Linux, его исходники были заточены на Darwin (и ранее на FreeBSD).

Возникло 2 проблемы:

* Как собрать исходник с наименьшими правками

* Как не переписывать родную сборочную систему - https://github.com/apple-oss-distributions/patch_cmds/blob/main/patch/Makefile - это Makefile, но довольно необычный Makefile, если кому интересно - читайте про то, как собирается *BSD мир.

Собственно, для решения первой задачи я соорудил первую херОбору из списка - linux libc + https://libbsd.freedesktop.org/wiki/ (набор библиотек, которые делают Linux немного более похожим на BSD) + некоторе количество доработок напильником поверх (https://github.com/pg83/ix/blob/main/pkgs/bin/patch/darwin/unwrap/ix.sh#L26-L36). Удивительно, но, в сумме, это позволило собрать darwin patch.

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

Традиционно, для сборки BSD систем используется утилита make, которая похожа на gnu make, но не совсем gnu make. Их, конечно, тоже можно насобирать по разным репозиториям с BSD системами (NetBSD, OpenBSD), и так далее, но можно взять готовый https://www.crufty.net/help/sjg/bmake.html, который основан на коде из NetBSD

"As noted above; bmake is derived from NetBSD's make(1), its goal is to be a portable version of same, so new features are added via imports of NetBSD's make (I'm one of the contributors to NetBSD). Thus bmake is kept in sync with NetBSD's make."

И так же используется во FreeBSD:

"FreeBSD 10.0 and later also use bmake (I'm a FreeBSD committer as well)."

bmake - это полдела.

Нужно еще где-то найти .mk файлы - https://github.com/apple-oss-distributions/patch_cmds/blob/main/patch/Makefile#L13 , собственно, в них и содержится вся мякотка сборки.

Как вы уже поняли, в какждой BSD системе есть свои mk файлы, они похожи, но все равно, разные. С bmake идут mk файлы от NetBSD, и они нам не подходят - https://www.crufty.net/help/sjg/mk-files.htm

Беглый взгляд на Makefile показал, что в patch используются либо цельнотянутые из FreeBSD mk файлы, либо очень близкие к ним. Родных для Darwin я так и не нашел.

В этот момент я соорудил вторую херОбору (на сегодня):

* bmake

* https://github.com/pg83/ix/blob/main/pkgs/bin/pmake/mk/ix.sh - скачал всю монорепу FreeBSD, и потырил из нее mk файлы

* pmake - wrapper, который объединяет первые два пункта в одну команду - https://github.com/pg83/ix/blob/main/pkgs/bin/pmake/script/ix.sh

(продолжаю https://xn--r1a.website/itpgchannel/1730)

Собственно, с помощью этой херОборы я вполне успешно собрал darwin patch.

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

Настойчивый читатель спросит, а нафига все это нужно, если результат уже был получен?

* Это интересно!

* Мне всегда казалось, что миру не хватает "FreeBSD с content addressable package manager", если вы понимаете, о чем я (#ix). Вот, теперь я могу поэкспериментировать и в эту сторону тоже.

И, с учетом того, что я уже не влез в размер одного поста в телеге, продолжение цикла историй о трех херОборах - в следующих сериях!

https://news.ycombinator.com/item?id=39593647
https://www.opennet.ru/opennews/art.shtml?num=60721

Меня тут спрашивают, почему я не пишу про эти две истории.

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

Я считаю, что можно делать clean room reimplementation. https://en.wikipedia.org/wiki/Clean_room_design

Если ты так сделал (вот, как делают, например, разработчики драйверов для #asahi (ладно, заявляют, что делают, я свечку не держал)), то ты молодец, и к тебе нельзя прикопаться.

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

Ну, то есть, если ты купил видеокарту nvidia, скачал себе CUDA, согласился с EULA, в которой написано, что нельзя декомпилировать результат, то все, ты не можешь это использовать для производства конкурирующего продукта. Тебя за руку никто не тянул, мог не соглашаться, и не использовать тогда этот hard & soft. А если согласился и нарушил договор, то все, результат труда "испорчен".

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

N+1 опубликовали результат своего исследования про open source.

Я там тоже немного посветил ебалом - https://research.nplus1.ru/

"Основная цель нашего исследования — узнать, кто и зачем сегодня занимается опенсорсом в России, а также выяснить, с какими трудностями они сталкиваются. Мы стремились получить целостный взгляд на состояние российского опенсорса: в исследовании отражены как технические аспекты, так и личное отношение экспертов к актуальным темам"

Надо бы собраться, и найти полную запись моих ответов на вопросы от N+1.

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

https://www.opennet.ru/opennews/art.shtml?num=60736 - пишут, что в новой freebsd появились новые-кленовые строковые (семейство str*, mem*) функции, оптимизированные вручную, для ассемблера x86_64. #perf

Со ссылкой на https://freebsdfoundation.org/blog/a-sneak-peek-simd-enhanced-string-functions-for-amd64/, но там написано только про пререлиз 15.0, а про 14.0 и 13.3 не написано, собственно, я пока их код не нашел, и не смотрел.

Раньше:

* Ты мог использовать LGPL вариант из glibc, без возможности статической линковки.

* Ты мог использовать всратые заглушки от musl (TBD - написать про пару программ, которые у меня проводили 30% CPU time в memcpy от musl)

* Ты мог использовать подход Google, это когда они написали кучу вариантов memcpy, с разными размерами блоков, в надежде, что LTO/PGO выберет нужный вариант и без всякого ассемблера. https://xn--r1a.website/itpgchannel/1113 https://xn--r1a.website/itpgchannel/54 Увы, не все имеют ресурсы, чтобы собирать весь код с LTO/PGO.

* Ты мог использовать asmlib от Agner Fog, со всеми вытекающими. Например, этот сумрачный гений не умеет в систему контроля версий, и вообще, в версионирование своих артефактов. Вот url к asmlib, любой версии, не очень удобно для CI - https://www.agner.org/optimize/asmlib.zip Как хотите, так и ебитесь с этим. Ну и еще они под GPL, со всеми вытекающими.

Собственно, я использовал вариант от Agner Fog, потому что у меня все собирается из исходников, а бинарные артефакты я не распространяю.

Но, если новость - правда, то это просто какое-то счастье, потому что все пользователи musl получат нормальную (по скорости, и по лицензии) альтернативу заглушкам из musl.

Продолжая одну из любимых моих тем, что "инфраструктурная площадка bla bla bla" (#provider https://xn--r1a.website/itpgchannel/86):

https://www.epicgames.com/site/en-US/news/apple-terminated-epic-s-developer-account

Меня тут спрашивают, почему я не пишу про llvm/clang18, хотя он вышел 3 дня назад - https://github.com/llvm/llvm-project/releases

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

В целом, с точки зрения сборки, все хорошо, почти ничего не пришлось править в проектах, но:

* Сломан busybox

ping: bad address 'ya.ru'
pg# ping ya.ru

gdb/strace говорят, что в функцию bind() передается мусор, поэтому мы просто не можем разрезолвить это имя

* epiphany просто падает на старте, с segmentation fault, в каком-то совершенно нормальном месте.

* вишенка на торте - падает компилятор: https://gist.github.com/pg83/e138892353aed9d76b47f85109a1ea05 Давненько такого не было.

В общем, откатился назад, на 17 версию, жду фиксов.

Продолжаем цикл заметок "История трех херобор" - https://xn--r1a.website/itpgchannel/1730 #herobora

История вторая - "avahi, она же mDNS".

Ресь тут пойдет про https://xn--r1a.website/itpgchannel/1709

Я решил остановиться на https://en.wikipedia.org/wiki/Bonjour_(software) для настройки имен хостов в своей локальной сети.

Под macOS это все работает из коробки, под Linux есть две известные реализации:

* https://avahi.org/

* запчасть systemd https://wiki.archlinux.org/title/systemd-resolved

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

Вот, например, феерический тред про Avahi - https://github.com/avahi/avahi/issues/117

Речь там про то, что в Avahi есть race, и оно иногда начинает барахлить, и, вместо {{hostname}}.local генерировать какие-то всратые имена типа {{hostname}}-1.local, и так по возрастающей.

Баг висит с 17 года, разработчики его подтверждают, но пофиксить не могут.

Я наткнулся на этот баг уже после того, как поднял сам Avahi, и поднял дополнительную штуку, которая реализует гейт из dns в avahi: https://wiki.alpinelinux.org/wiki/MDNS

https://github.com/LouisBrunner/avahi2dns (простая прокся, отвечающая по dns протоколу, и ходящая за резолвингом в Avahi, через d-bus)

Это нужно для non-glibc систем, потому что для интеграции с dns Avahi предоставляет nss плюгин (https://en.wikipedia.org/wiki/Name_Service_Switch), который, очевидно, не работает с musl, и, тем более, не работает в статически слинкованном окружении.

В общем, я расстроился, и пошел пилить херобору!

Я взял https://github.com/apple-oss-distributions/mDNSResponder от Apple. Да, да, это ровно тот же самый код, который работает у вас на macOS.

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

Я разобрался с тем, как в него запушить свой hostname. Это оказалось не очень просто, потому что наружу mdnsresponder отдает только API для публикации в mDNS сервисов, а не hostname, пришлось придумать, как запаблишить фейковый сервис, чтобы пророс hostname.

Мне пришлось запилить gate из dns мира в mdns - https://github.com/pg83/mdns2dns Это такой прокси, который отвечает по протоколу DNS, но, under the hood, запускает command line тулзу из поставки mDNSResponder - https://github.com/pg83/mdns2dns/blob/main/query.go#L56, парсирует ее output, и оборачивает в ответ DNS сервера.

Над этим у меня работает локальный кеширующий dns - dnsmasq, который занимается кешированием, и тем, что все запросы вида X.local отправляет в мою херобору, а остальные - куда-то еще.

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

Ну и, если убрать вот этот мой mdns2dns, то, так-то, это антикостыльное решение, в отличие от Avahi/SystemD:

* Потому что работает тот же код, что и у всех остальных клиентов Bonjour.

* Это ровно тот же код, который работает, например, в вашем принтере, если он умеет в ZeroConf. Да, да, Apple не занимается благотворительностью, а этот SDK в open source нужен производителям устройств.

#xfs #perf

https://blog.allegro.tech/2024/03/kafka-performance-analysis.html

Вот, например, почему xfs - все еще лучшая FS под Linux.

Вышел, но сломал вендоринг зависимостей.

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

Хеши едут, сборка ломается.

Пришлось откатить вендоринг на go 1.21, а сборку оставить на go 1.22.

Теперь нужно придумывать какой-то "ползучий" процесс обновления архивов и их перехеширования.

Грусть, тоска, ну вот зачем было ломать то, что хорошо работало?

https://github.com/python/cpython/pull/116338

А вот это прямо бомба - #nogil в транке Python.

И чувак, который это таки сделал, войдет в историю (https://xn--r1a.website/itpgchannel/1241)

Потрясающее упорство, надо сказать.

Смотрите, что Google пишет про #carbon:

https://security.googleblog.com/2024/03/secure-by-design-googles-perspective-on.html

"We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees that include temporal safety"

"A large-scale rewrite of all existing C++ code into a different, memory-safe language appears very difficult and will likely remain impractical"

В фоне продолжаю заниматься своей home #lab.

Там уже 3 ноды, автоматическая наливка с 0, нормальная сеть между всеми узлами (2.5gb), IaC для выкладки (конечно же, на основе #ix), сервисы сами рассказывают про себя через mdns, и вообще, красота.

Коллеги, а порекомендуйте нормальную очередь задач для распределенного кластера?

Я это вижу примерно так - etcd + какая-то встраиваемая библиотека, которая реализует скучные вещи, типа очередей поверх etcd, какой-нить простой work stealing алгоритм шедулинга, эфемерные ноды для каждого хоста, разгребающего очередь, для того, чтобы задачи с упавших нод прозрачно возвращались в общую очередь, и прочий crud.

Вот, например, как https://github.com/lytics/metafora, только живое, и чтобы звезд побольше?