#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, потому что ваш код стал значить что-то немного более другое, чем он значил вчера

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

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

А вот как великие доебываются до стайлгайда на code review - https://www.phoronix.com/news/Linus-Comments-Bcachefs-6.6 #bcachefs #Kent

"А теперь ты приходишь и говоришь: Дон Корлеоне, мне нужна справедливость. Но ты не просишь с уважением, не предлагаешь дружбу, даже не думаешь обратиться ко мне — крёстный. Нет, ты приходишь ко мне в дом в день свадьбы моей дочери и просишь убивать за деньги"

"I need to know that you understand that if you actually want this upstream, you need to work with upstream.

That very much means *NOT* continuing this "I'll just do it my way". You need to show that you can work with others, that you can work within the framework of upstream, and that not every single thread you get into becomes an argument"

В целом, я не очень уважаю мейнтейнеров open source софта за их #errogant поведение, но тут сложно не согласиться с Линусом, и выглядит это все странно.

Тут вот lobste.rs принес ссылку на очередной мини-шедевр от Гугла.

https://github.com/google/minijail

Это, знаете ли, ровно та контейнеризация, которая нужна для системы сборки - не делает ничего лишнего, и потому работает полностью rootless, без #suid бинарников и прочей нечести.

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

Маленькая, компактная, шик, блеск, красота. И, кстати, тоже из ChromiumOS

Интересно, сколько у Гугла еще таких полезных мелочей, в их огромных закромах? Я как-то, ради интереса, пробовал пролистать их org на github, там просто залежи полезного кода. Но вот как там искать то, что нужно здесь и сейчас - совершенно непонятно.

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

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

Вот, например, есть такой проект - https://github.com/Genivia/ugrep

Хороший, быстрый, современный grep (наверное, мне пофиг, я сам не использую)

И, вообще говоря, когда я его тащил к себе, то еще удивился, что вот, мол, новый проект, а сборка у него на gnu autohell. Ну не может же быть такого в 21 веке?

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

Чувак настолько любит (я не знаю, какие тут еще могут быть эмоции) gnu autohell, да и M4, что накостылял своих костыльных макросов для поиска внешних библиотек, https://github.com/Genivia/ugrep/tree/master/m4

Которые, ничего не стесняясь, лезут в систему - https://github.com/Genivia/ugrep/blob/master/m4/ax_check_bzlib.m4#L67

Это не копипаста, это реально его самодел - https://github.com/Genivia/ugrep/blob/master/m4/ax_check_bzlib.m4#L32

Я, честно говоря, такое вижу в первый раз в жизни.