#mold #money

https://github.com/rui314/mold/releases/tag/v2.0.0

Случилось невероятное - коллега осознал ошибку, понял, что так работать не будет, и перелицензировал код под MIT!

"Mold 2.0.0 is a new major release of our high-speed linker. With this release, we've transitioned our license from AGPL to MIT, aiming to expand the user base of our linker. This was not an easy decision, as those who have been following our progress know that we've been attempting to monetize our product through an AGPL/commercial license dual-licensing scheme. Unfortunately, this approach didn't meet our expectations. The license change represents our acceptance of this reality. We don't want to persist with a strategy that didn't work well"

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

https://arxiv.org/abs/2307.12008

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

Верим?

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

Первая дыра довольно простая - у меня на разных машинках lz4(tar(git(some repo))) выдавал разный результат. По совершенно дурацкой причине - разный umask, и в tar проехали разные права доступа у некоторых файлов. И, как я и ожидал, узнал я об этом достаточно поздно, мне пришлось "переканонизировать" (пересчитать более стабильный хеш и записать его вместо старого) порядка 60 целей.

Вторая дыра чуть поинтереснее. Так получилось, что у меня случились две ноды в графе, с разными командами и зависимостями, но с одинаковым output, и с одинаковым хешом от этого output. Само по себе это было бы не страшно, потому что uid, будучи он честно рассчитанным, получился бы разный, но тут со мной сыграл злую шутку тот самый механизм, который я описывал в прошлом посте - это когда я знаю, какой конкретно будет выхлоп у ноды, то я имею ей право приписать заранее известный uid (это нужно для стабильного кеширования некоторых нод - типа, публичные сертификаты ты каким скриптом не считай, они от этого не поменяются).

И это взорвалось совершенно феерически - какие-то рандомные падения graph executor, какие-то его зависания, все это зависело от погоды на луне и от времени суток.

В конце-концов я просто побисектил (как обычно, после дня страданий и метаний, и попыток заявить, что это разрабы golang накосячили) всю свою репу, нашел коммит, в котором это начало проявляться, и там все сразу стало очевидно. Коммит не показываю, он не очень релевантен рассказу, просто "так вышло".

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

#fast_python #nogil

Чувак этот (colesbury), судя по всему, таки войдет в историю, потому что коллеги собираютс принять proposal про nogil python: https://discuss.python.org/t/a-steering-council-notice-about-pep-703-making-the-global-interpreter-lock-optional-in-cpython/30474 https://www.opennet.ru/opennews/art.shtml?num=59518

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

"We do not want to create a permanent split between with-GIL and no-GIL builds"

"We do not want another Python 3 situation, so any changes in third-party code needed to accommodate no-GIL builds should just work in with-GIL builds"

"This is not Python 4"

В какие времена живем!

https://blog.trailofbits.com/2023/07/28/the-future-of-clang-based-tooling/

Хороший обзор clang/llvm с точки зрения его применимости для разработки всякого рода tools.

С одной стороны, автор, очевидно, немного предвзят, как разработчик альтернативной реализации потрохов между clang и llvm, с другой, все написано по делу. Заявляю это как человек, однажды погрузивший свои потные ручонки в clang-format - там все очень и очень странно, и держится, буквально, на соплях.

https://overclockers.ru/blog/Razg0n_blog/show/101008/po-novomu-zakonu-razrabotchiki-nezaregistrirovannogo-otkrytogo-po-mogut-byt-privlecheny-po-uk-rf

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

Интересно, что это значит на самом деле?

Вкратце напомню, что у меня системными сервисами управляет #runit. Поэтому, когда у меня происходит обновление system #realm, происходит перезагрузка всего дерева сервисов. Ну просто потому что меняются inode путей в папке /etc/services, так как /etc - это симлинка на /ix/realm/system/etc.

ВНЕЗАПНО я понял, что это аналог "soft reboot" из systemd - https://www.opennet.ru/opennews/art.shtml?num=59512.

Даже не то чтобы аналог, а просто 1 в 1 - убивается все дерево процессов, кроме init (runit), и запускается заново.

Конечно, без извращений вида "Сохранение состояния работающего ядра при замене пользовательского окружения даёт возможность реализовать обновление некоторых сервисов в live-режиме (без остановки), организовав передачу файловых дескрипторов и слушающих сетевых сокетов для этих сервисов из старого окружения в новое" - много раз писал, и буду писать, что программам иногда нужно сбрасывать накопленный ошибочный state.

Будни #bootstrap #ladybird

Известная проблема - что, если с git/hub скачать tgz/zip/whatever, то хеш от этого файла может плавать со временем. Например, меняются алгоритмы компресии, или плывет datetime, или меняется порядок. Короче, много разных причин, много раз писал про это, не буду повторяться.

Поэтому я, например, перепаковываю таких архивы в какой-то более стабильный формат. Nix делает что-то похожее, с теми же целями.

Вот, столкнулся с очень смешным следствием такой упаковки.

https://github.com/SerenityOS/serenity/tree/78def34c5e721ccacbfa19f5eeb27405da50dc23/Base/bin

Что тут написано?

Что кто-то положил в свой репозиторий симлинку на /bin/less, внешний бинарник. И использущийся у меня способ нормализации почему-то генерировал разный нормализованный tar файл, в зависимости от того, был ли этот файл реально в системе, или нет.

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

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

https://github.com/pg83/ix/blob/main/pkgs/bin/ladybird/ix.sh#L17-L20

Скрыл это за приличным фасадом, чтобы никто не догадался, ага.

(ладно, ладно, это opt-in для таргета, в контексте которого может быть вызван такой скрипт)

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

"Alpine Linux покинул наиболее активный сопровождающий"
"После ухода psykose без сопровождения осталось около 400 пакетов"
"Судя по всему причиной ухода является эмоциональное выгорание и желание сменить деятельность, а в качестве планов упоминается лишь намерение выспаться после хронического недосыпа"

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

pg:~/ix/pkgs find . -name ix.sh | wc -l
2244
pg:~/ix/pkgs

У меня вот порядка 2000 пакетов. На самом деле, конечно, меньше, потому что часто это вариации одного и того же, но все же.

Занимает это у меня все еще порядка 15 - 20 минут в день, если не считать время на добавление новых сложных пакетов.

Будни #bootstrap

Есть такая библиотека - libidn2.

На своем сайте, https://gitlab.com/libidn/libidn2, они утверждают, что могут (и что это предпочтительно) использовать системную libunistring (про эту всратую либу надо как-нибудь написать отдельно):

"The Libidn2 library may use GNU libunistring for Unicode processing and GNU libiconv for character set conversion. It is recommended to install them before building and installing libidn2. ... When the recommended libunistring is not available, libidn2 uses internal replacement functionality which increases the size of the library. To use the internal libunistring-replacement rather than the system libunistring (even when deemed to be sufficient) you may use..."

Но вот год назад они стали линковать в себя кусок этой самой libunistring статически (вкомпиливать в libunistring.so) - https://gitlab.com/libidn/libidn2/-/commit/c691cdf09c8c172ebaa5926348b8d41f5fadca4c

Что, зачем, а главное - нахера?

https://gitlab.com/libidn/libidn2/-/issues/104

Судя по всему, у них сломался ubsan на libunistring (это еще одна вечная проблема конвенциональных пакетных менеджеров, что собрать всю приложуху с санитайзером примерно невозможно), и они решили это подкостылить у себя, потому что апстрим (как это принято у проекта #GNU) - #errogant упыри, и не хотят сделать у себя лишний каст по какой-то надуманной причине (а на самом деле, потому что это значило бы признать свою неправоту, что, конечно, невозможно) - https://lists.gnu.org/archive/html/bug-gnulib/2022-03/msg00011.html #gnulib

Мораль?

Ее, как обычно, нет.

https://www.statista.com/statistics/1245665/worldwide-permissive-copyleft-open-source-licenses/
https://www.sourcefuse.com/blog/the-importance-of-understanding-open-source-license-types/

А вот вам, например, график с распределением copyleft vs permissive кода по годам. Или вот еще похожий - https://images.prismic.io/scantist/cc9d7e97-f128-4588-bf23-b92a6af1ff87_Frame+187+%281%29.png

Первый я нашел грепом в гугле, второй - не помню уже где.

Отношение к open source как к #charity, кажется, побеждает, и это хорошо.

https://www.oilshell.org/blog/2023/08/release-0.17.0.html

Не знаю, что там с новым названием, но, помимо перехода с python на С++ (с автоматической трансляцией, напомню), проект разделили на 2 части:

"OSH runs existing shell / bash scripts, often unmodified.
YSH is the shell with tYped data, influenced by pYthon"

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

https://github.com/oilshell/oil/commits/master

Так же в пресс-релизе вскользь упомянули, что oil shell таки может обработать большую шелл-портянку:

"For example, running CPython's configure went from allocating 3.37 M objects to 2.32M objects, a decrease of 31%. Compared to our December baseline, it's a decrease of 42%"

Правда, тему перфа обошли стороной, времени там нет.

Я тут недавно встрял на обновлении телеги, вроде, на версию 4.8.3. #gir

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

А еще коллеги завязались на gobject-introspection, видимо, для опроса каких-то сервисов по dbus.

Это какая-то всратая технология от #glib/#GNOME, когда ты загружаешь .so, и она тебе рассказывает, какие функции в ней есть, и с какими аргументами их можно звать.

Проклятая динамика, в самом худшем виде, все, как я люблю.

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

У меня это, конечно, из коробки не работало, работать заставить можно, но мне уж очень не хотелось этим заниматься.

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

* для webview я нашел в сборке ветку, которая заставляет компилироваться телегу без webview - https://github.com/desktop-app/lib_webview/blob/ebb8b8b91fe357b2c397a3eb98655c585b8c856e/CMakeLists.txt#L57-L65 Так просто попасть туда нельзя, но небольшой однострочник позволяет это сделать - https://github.com/pg83/ix/blob/main/pkgs/bin/telegram/desktop/unwrap/ix.sh#L129

* С интроспекцией было сложнее. Нужно было стереть все упоминяния про вызовы и поиск соответствующих тулзов - https://github.com/pg83/ix/blob/main/pkgs/bin/telegram/desktop/unwrap/ix.sh#L113-L119, а потом заменить места реального использования на заглушки - https://github.com/pg83/ix/blob/main/pkgs/bin/telegram/desktop/unwrap/base_system_media_controls_linux.cpp https://github.com/pg83/ix/blob/main/pkgs/bin/telegram/desktop/unwrap/integration_linux.cpp

Понятное дело, что это все довольно временное решение, ситуацию с gobject introspection, так или иначе, придется решить, а за webview я еще посражаюсь.

сука