Краткий курс по программированию⁠⁠

Programmer memes

https://www.opennet.ru/opennews/art.shtml?num=59666 #fork

Продолжение истории с #hashicorp.

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

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

Из интересного - форком будет заниматься >= 14 разрабов fulltime, а в hashicorp всего 5.

Сеньор проводит вводный инструктаж новому сотруднику

Programmer memes

Сумел стереть еще 1.5кб кода, но, правда, до 50кб так и не "ужал".

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

https://github.com/pg83/ix/commit/9899433a4e9c0003764aff563b1d3213a45d213b
https://github.com/pg83/ix/commit/c8b112fc9406e35802f688906f7c4faa40247c47

Благодаря этому упрощению теперь возможно использовать шаблоны описания сборки пакетов на любом языке, а не только на ранее захардкоженных sh/python.

Не то чтобы я ожидал шквал пакетов на JS, но, тем не менее.

Опять лежит 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 можно ожидать?