#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 я еще посражаюсь.

сука

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

А вот, например, коллеги, занимающиеся разработкой открытых драйверов для NVidia, затащили свой драйвер #NVK в #mesa, и рассматривают дальнейшую реализацию opengl через #zink.

Это хорошо и правильно - реализовывать старые API в виде надстроек над новыми, более мощными, API.

https://github.com/facebook/zstd/issues/3717

Тут вот коллега поднимает бучу по поводу лицензии ZSTD.

Вся мякотка заключается в том, что используется двойное лицензирование, но, вместо того, чтобы написать BSD OR GPL, там написано BSD AND GPL. Как говорится, есть нюанс.

Коллега предлагает исправить текст на OR, но, КМК, он не очень понимает, что он предлагает на самом деле (или, наоборот, очень хорошо понимает, why not). Потому что facebook не может просто взять и заменить текст на OR, для этого нужно получить согласие от всех контрибуторов в zstd, а это, конечно, ад и израиль.

https://kipp.ly/jits-impls/

Вот, например, хороший текст, откуда я узнал, что GraalVM https://www.graalvm.org/ - это не только очередная блажь от оракла, но что-то действительно интересное, и, даже, может быть, полезное.

Идея про "погрузить С в LLVM bitcode для интерпретации и JIT в JVM для более простого interop" - это прямо хорошо.

https://gist.github.com/pg83/aabbfa4e0850f3616857d9acaaf841c8

А вот вам еще одна всратая ошибка сборки, из-за криворуких атворов #cmake.

Что тут произошло?

Я в каждую папку с готовыми артефактами кладу файлик touch, как символ того, что эта папка готова.

А авторы #cmake решили, что они будут искать бинари не только в папках CMAKE_PREFIX_PATH/bin, а еще и в самих CMAKE_PREFIX_PATH. И вот сборка webkitgtk нашла такой файлик в качестве команды touch - https://github.com/WebKit/WebKit/blob/main/Source/JavaScriptCore/CMakeLists.txt#L159

Знаете, вот это вот ощущение, когда одни криворукие программисты начинают воркэраундить код для других криворуких программистов (одни не сумели осилить передать правильный PREFIX, другие не рабобрались, и стали искать везде)?

Вот это вот оно, да.