Опять лежит gitlab от freedesktop - https://gist.github.com/pg83/de5cc5e61cd5bbd05ac7e6959136fd89

И я, конечно, воспользуюсь этим, чтобы призвать всех владельцев open source софта делать RO зеркала на github.

https://github.com/serde-rs/serde/pull/2590 #blob

Из serde таки удалили бинарный блоб. Это, конечно, хорошо. Потому что скорость сборки - скоростью сборки, но она не должна достигаться таким вот хаком.

Меня больше, чем вся эта история с бинарным блобом, заинтересовала вот эта вот папочка - https://github.com/serde-rs/serde/tree/bfcd44704f847ac5a9f3072e102e803b5ebbef31/precompiled/proc-macro2 (ее уже нет в транке, потому что выпилили всю precompiled/ историю).

Я вот как в этом вот анекдоте:

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

Нутром чую, что в этой папочке лежит реализация proc_macro, которая не требует загрузки .so в rustc, а работает через subprocess. Ну или я тогда не понимаю смысл этого precompiled binary - что там лежало-то?

Раскопки приводят к https://github.com/dtolnay/watt (от того же автора):

"Watt is a runtime for executing Rust procedural macros compiled as WebAssembly"

Короче, в конце тоннеля забрезжил свет, возможно, у меня получится прикрутить эту штуку к Rust, чтобы она использовалась вместо реализации по умолчанию, и не требовала загрузки свежесобранной .so в rustc. То, что там #wasm - это дело десятое, главное, что в виде отдельного бинаря.

#bootstrap

https://go.dev/blog/rebuild

Заметка от Russ Cox (все же помнят, что я большой его фанат?), про воспроизводимость сборок тулчейна go.

Ничего особо интересного, потюнили процесс там и тут. Правда, есть небольшой подлог - задачу воспроизводимости сборки усилили требованием воспроизводимости, имея только исходники самого тулчейна (то есть, как-то пришлось убирать зависимости от C compiler, в cgo).

Так-то, что в #IX, что, уверен, в #guix (насчет nix не знаю, они не очень запариваются #bootstrap), сборки и так были воспроизводимы.

Фактически, сделали простую задачу чуть более интересной. Ну и хрен с ними, дело-то хорошее.

#rant #bootstrap

А вот вам, например, выдержка из сборки qemu.

https://github.com/qemu/qemu/blob/master/ui/meson.build#L172

Тут написано, что для сборки qemu нужен meson subproject, без фолбека на системный вариант. Ну вот так получилось, что это скрипт от авторов же qemu, и они его решили так заисполдьзовать (хотя бОльшая часть зависимостей у них делается через git submodules).

А в это subproject написано, что этот проект можно скачать только из git - https://github.com/qemu/qemu/blob/master/subprojects/keycodemapdb.wrap

Вот, реально, только из git, без фолбека на локальную копию в репозитории. Если бы она была, то лежала бы в папочке keycodemapdb вот тут - https://github.com/qemu/qemu/tree/master/subprojects

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

Что у этих школьников сборка намертво прибита к хождению по сети через git (начиная с версии 8.1.0), и ничего с этим не сделать, кроме как жестко выпатчить к хуям (что я и сделал, без ссылки, там нет ничего красивого и/или интересного).

Мораль?

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

https://www.phoronix.com/news/Linux-6.6-Illicit-NVIDIA-Change

Разработчики ядра опять пытаются анально огородиться от бинарного блоба под названием "nvidia driver".

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

Почему?

Мой первый тезис - Nvidia не нарушает #GPL. Я бы мог тут рассказать про это с упором на сам текст лицензии, но #ianal, и все мое объяснение будет в пустую, потому что мы сойдемся на том, что не договорились про определения. Вместо этого я укажу на два простых факта:

* Nvidia - компания, которая стоит сколько, триллион долларов? Если бы хоть один адвокат или там FSF видели перспективы этого дела в суде, оно бы уже состоялось. Отсюда я делаю вывод, что у подобного дела заранее нет перспектив. Почему? Ну, очевидно, две причины:
- выберите свою любимую теорию заговора по вкусу
- NVidia не нарушает GPL!

* Бинарный блоб от Nvidia, по сути, ничем не отличается от любой другой firmware. Вот, реально, куча драйверов, помимо блоба от Nvidia, занимаются тем, что выполняют команды ядра on behalf of этого самого проприетарного firmware. Они зовут GPL символы только в путь.

Второй тезис - дело совсем не в нарушении GPL. У разработчиков бомбит от того, что NVidia не следует рекомендованным принципам разработки ядра, когда драйвера должны быть in tree, и рефакториться при изменении интерфейсов вместе со всеми драйверами. Я тут не готов дискутировать, хорошо это, или плохо, NVidia - в своем праве.

Из этого следует очень интересный вывод, ради которого я и затеял этот текст.

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

Это тонкий момент, но надо уметь разделять текст лицензии, где написано, как можно использовать код и блобы, собранные на его основе, и вот эти вот макросы - GPL_ONLY_SYMBOLS(), и так далее.

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

В GPL лицензии написано только, что, если вы распространяете слинкованный артефакт, то вы его должны распространять, соблюдая определенные требования.

Nvidia ядро не распространяет, конечная линковка происходит на стороне у пользователя, финальный результат ее он не распространяет.

ЕЩЕ РАЗ!

Когда разработчики ядра пытаются препятствовать использовани юраспространяемого им кода на условиях лицензии GPL - это они нарушают GPL, а не NVidia!

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

https://www.opennet.ru/opennews/art.shtml?num=59683 #CVE

"Спорные отчёты направлены анонимно через сервис информирования об уязвимостях NVD. Мотив публикации не ясен, вероятно кто-то решил продемонстрировать отсутствие должного аудита при приёме отчётов об уязвимостях, возможность использования CVE как механизма для дискредитации проектов или привлечь внимание к исправлению в коде потенциально опасных проблем без анализа их влияния на безопасность"

Мое отношение к CVE, и к продавцам страха вы и так знаете оченеь хорошо, а если нет - грепните блог по слову "CVE".

Например:

https://xn--r1a.website/itpgchannel/401
https://xn--r1a.website/itpgchannel/600

Искал способ сделать так, чтобы sway читал какое-то множество настроек до того, как начинал загружать пользовательский конфиг. Например, чтобы запилить нескучный wallpaper с логотипом.

Ничего похожего не нашел, потому что все include из конфига надо делать явно.

Но вот наткнулся в исходниках на забавный блок кода, который должен делать ровно то, что я хотел - https://github.com/swaywm/sway/blob/master/sway/config.c#L501

К сожалению, он уже очень давно висит закомментированным, с комментарием TODO: security, чего бы это не значило.

Задачка на #bootstrap:

pg# strace 2>&1 | wc -l
2
pg# strace strace 2>&1 | wc -l
24
pg# strace strace strace 2>&1 | wc -l
696
pg# strace strace strace strace 2>&1 | wc -l
24551
pg# strace strace strace strace strace 2>&1 | wc -l
921491

По какой закономерности растет это число, и почему?

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

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

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

Я понимаю, что делают большие дистрибутивы, типа gentoo - у них есть свои зеркала.

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

Меня так и тянет сделать fallback на distfiles от gentoo, но насколько это ОК?

А если я сделаю fallback на какой-нибудь из бесчисленных зеркал distfiles, например, ну, чтобы не ходить далеко, https://mirror.yandex.ru/gentoo-distfiles/ ?

Какой QoS можно ожидать?

Хорошо иметь много пользователей!

Потому что у них что-то не работает, и это заставляет нас делать системы лучше и лучше.

Вот, например, мои пользователи часто жаловались на негерметичность первоначальной стадии #bootstrap - если в систему были установлены те или иные библиотеки, то системы сборки часто их находили в системе, вместо моих. С моментальной ошибкой сборки, потому что они несовместимы по ABI.

Я достаточно неплохо выкосил это в autohell скриптах - https://github.com/pg83/ix/blob/main/pkgs/die/c/autohell.sh#L38-L46

Недавно выкосил в #meson, через обертку над clang, которая убирает /usr из search path - https://github.com/pg83/ix/blob/main/pkgs/bld/wrapcc/kuroko/wrapcc.krk#L118

Вот, настала очередь #cmake. Он принудительно добавляет эти пути в пути для поиска библиотек вот тут - https://github.com/Kitware/CMake/blob/master/Modules/Platform/UnixPaths.cmake#L33

Сначала я изящно занулял этот файл при установке cmake, но потом нашел более "изящное" решение. Этот файл имеет include guard, чтобы не включаться повторно - https://github.com/Kitware/CMake/blob/master/Modules/Platform/UnixPaths.cmake#L10

Ну я и обманул cmake, чтобы он думал, что уже включил этот файл - https://github.com/pg83/ix/blob/main/pkgs/die/c/cmake.sh#L66-L67

А зачем там UNIX=1, спросит дотошный читатель?

Ну потому что выставить в cmake флаг про то, что мы собираем под unix, конечно, лучше всего именно в файле, который настраивает юниксовые пути поиска библиотек - https://github.com/Kitware/CMake/blob/master/Modules/Platform/UnixPaths.cmake#L18

(Что?? Да!!)

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

Причиной остановки всех 14 заводов Toyota в Японии стал недостаток места на диске базы данных, сообщил автоконцерн на своем сайте.

Совет от дядюшки ПЖ.

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

Почему?

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

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

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

Выработайте в себе здоровый скептицизм, вот.