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, другие не рабобрались, и стали искать везде)?

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

Полгода назад запилил свой великолепный CI скрипт, https://github.com/pg83/ix/commits/main/pkgs/die/scripts/ci.

По сути, он почти не менялся, кроме того, что я вынес внешний цикл в #runit, ну а так он работал себе и работал.

Но вот недавно я добавил туда ровно одну строку, которая призвана собирать все то же самое, но другим выполнителем графа - https://github.com/pg83/ix/blob/main/pkgs/die/scripts/ci#L8.

Напомню, у меня их два - один на go, он ставится в систему, и служит для оркестрации выполнения для #stalix, а второй написан на питоне, и служит для #bootstrap, ну и на macOS можно чего-нить пособирать. Так, простенький выполнитель, встроенный прямо в движок построения этого графа.

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

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

Интересно, сколько я его теперь смогу не трогать?

https://ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%BA%D0%BE%D0%BD_%D0%9B%D0%B8%D0%BD%D1%83%D1%81%D0%B0

Вот есть 3 популярные в open source системы сборки - cmake, meson, #autohell.

И во всех трех есть определенные проблемы с #cross-компиляцией:

* В #cmake ее просто нет. Много раз писал и буду писать, что она у него совершенно фейковая, для отчета горе-программистов, которые ее делали, перед начальством.

* GNU #autohell содержит зачатки кросс-компиляции (умеет искать host compiler, например), но дальше ты сам по себе - фактически, нужно руками писать все сборочные правила для host сборок, без всякой на то помощи. Искать host библиотеки через pkg-config? Боже упаси, это же просто космос!

* meson наиболее продвинут в этом отношении, но и в нем есть свои проблемы. Например, очень странный способ указывать host/target тулзы, через материализованный файл, с не очень понятным синтаксисом.

При этом, ни одна из этих систем не является cross-native (#cross_native)!

(я сам изобрел этот термин, не ищите)

Что это значит?

Это значит, что кросс-компиляция туда добавлена постфактум, и не является родной. То есть, по умолчанию, предполагается, что ты можешь запустить любую свежесобранную тулзу, а чтобы было "не так", разработчики конкретной сборки должны знать, что бывает кросс-компиляция, и специально для этого присесть (повторю, meson в этом помогает, autohell не мешает, cmake мешает активно).

При чем тут закон Линуса?

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

Как я предлагаю поступать с кросс-компиляцией в open source?

Я советую:

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

* Или разбивать свои проекты на библиотеки и программы в разные проекты на github (или в разные папочки одного проекта, но с возможностью собрать по отдельности все составляющие части), и сопрягать их мета-сборкой, типа nix/ix/guix.

#security #CVE

Меня тут спрашивают, почему я не пишу про всякие интересные уязвимости в CPU, типа

https://www.opennet.ru/opennews/art.shtml?num=59571
https://comsec.ethz.ch/research/microarch/inception/

Я не знаю.

Это было интересно в первый раз (а все помнят название первой уязвимости такого класса? Я вот уже забыл).

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

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

Когда их сложно найти, и легко починить, то почет и уважение тем, кто их ищет, почет и уважение тем, кто их фиксит, все довольны, все получили свою 5+, и всем пофиг, что ущерб не нанесен, потому что in the wild оно не эксплуатировалось.

А вот когда починить реально дорого, прямо очень дорого, то люди ВНЕЗАПНО вспоминают, что умеют считать деньги, и просто игнорируют всю эту шелуху и весь этот абсурдный театр безопасности.

Про идеальный код.

У меня есть друг, он однажды сказал такую фразу, поменявшую мои представления о коде, и о программировании.

"Представь себе", сказал Ден (его зовут Ден, да), "что ты импотент". "У тебя есть два пути - всю жизнь жаловаться на это и страдать, а можно привязать карандашик, и таки впендюрить" (цитата дословная).

Не то чтобы это сразу во мне что-то поменяло, но я это запомнил, и потом много лет занимался тем, что, по капле, выдавливал из себя свое (часто неуместное!) "чувство прекрасного", которое сильно мешало жить программировать, и делать сложные и интересные штуки.

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

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

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