В этой новости прекрасно все, поэтому я просто оставлю ее тут:

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

На самом деле (tm), особо ничего неожиданного в этом нет, потому что Python сначала победил в качестве языка для анализа всяческих данных, потом победил Jupyter Notebook, а потом Екселю не осталось ничего, как признать поражение, и сделать вот ровно то же самое.

#maskray #rant

https://maskray.me/blog/2021-11-07-init-ctors-init-array

А вот еще один классный текст от знаменитого блоггера MaskRay!

Он про устройство секций, в которых лежат указатели на функции, которые нужно вызвать до main. Так что, если вам казалось, что там есть какая-то магия, то почитайте, ничего магического там нет.

Наткнулся я на этот текст по рабочей необходимости.

Старая версия CUDA (<= 10), которую все еще иногда приходится использовать, содержит в себе секции .ctors, но не содержит .init_array. А используемый нами линкер пару лет назад перестал поддерживать секцию .ctors. Ну и нам приходилось поддерживать патчи на линкер, чтобы он умел в .ctors, а не только в .init_array.

При переходе на новую версию линкера мне надоело накладывать эти патчи, и я, пользуясь этой заметкой, бинарно переделал библиотеки от nvidia, переместив конструкторы из .ctors в .init_array.

Примерно вот такой командой:

objcopy --rename-section .ctors=.init_array file

Что нам говорит этот вызов?

Что формат .ctors и .init_array ничем не отличаются, это одна и та же секция, просто ее назвали иначе.

Чем же кому-то не угодила секция .ctors, почему в новых стандартах пришлось заводить .init_array, который, по сути, ничем не отличается, и зачем нужно было убирать поддержку .ctors, история (и MaskRay) умалчивают:

"Under the hood, on ELF platforms, the initialization functions or constructors are implemented in two schemes. The legacy one uses .init/.ctors while the new one uses .init_array"

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

#asahi

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

У коллег, судя по всему, прямо прорыв в поддержке 3D.

Интересно, конечно, что у них с питаловом, то есть, сколько жрет GPU с этим drm driver.

Напомню, что это были основные проблемы с open source nvidia driver, что, без изпользования подписанного nvidia firmware, все работало не самым оптимальным образом.

Но, вообще, конечно, это очень и очень круто. Надо будет как-нибудь попробовать там запустить #stal/ix. Прямо сейчас мне мешает только тот факт, что drm driver написан на Rust.

Совершенно случайно пришлось заглянуть в код subj.

Слушайте, мне иногда кажется, что у некоторых программистов, когда они кодят, в голове происходит что-то типа https://www.youtube.com/watch?v=NVwAOiKbOqI

Потому что я вот не знаю, чем можно объяснить вот такое:

https://github.com/intel/hyperscan/blob/master/src/rose/rose_build_convert.cpp#L564

shared_ptr<NGHolder> h_new = make_shared<NGHolder>();
if (!h_new) {
    assert(0);
    throw std::bad_alloc();
}

В этом отрывке прекрасно все:

* new/make_shared может вернуть nullptr? А в 21 веке?
* разное поведение в дебаге и в релизе - assert vs. runtime error (кстати, немного в сторону - то, как в Rust обрабатываются переполнения - это треш, угар, содомия)
* этот bad_alloc не содержит line info, поэтому человек, решивший такое раздебажить, может поседеть

Короче, это совершенно redundant блок кода, который современный компилятор может вообще убрать нафиг. И вообще, это как использовать 3 презерватива, если вы понимаете, о чем я.

И это не единственная такая штука - там все, все выделение ресурсов обмазано вот такой вот проверкой. https://github.com/intel/hyperscan/blob/master/src/nfa/goughcompile.cpp#L210, всего несколько десятков таких однотипных проверок.

Будни #bootstrap, пятничный #rant

Отвязывать сборку от окружения - сложно (особенно без контейнеризации/виртуализации).

Недавно я узнал, что cmake и meson, в момент configure, могут дергать вот такую вот команду:

# clang -print-search-dirs
programs: = ...:.../clang-16/bin: \
    /usr/lib/gcc/.../x86_64-linux-gnu/bin
libraries: = .../clang-16/lib/clang/16: \
    /usr/lib/gcc/x86_64-linux-gnu/9: \
    /usr/lib/gcc/.../lib64: \
    /lib/x86_64-linux-gnu: \
    /lib/../lib64: \
    /usr/lib/x86_64-linux-gnu: \
    /usr/lib/../lib64: \
    /lib: \
    /usr/lib

И использовать найденные пути для поиска библиотек!

А потом, передавать в линкер /usr/lib/libxml2.a, вместо -lxml2. К чему это приводит, вы можете придумать и сами, от банальных ошибок в линковке, до падений в runtime, из-за разных ABI.

Какой в этом поиске физический смысл - я не понимаю.

Система сборки должна запустить pkg-config (или cmake, если метаинформация про установочные пути живет в базе данных от cmake), и узнать у него про пути к библиотекам, а не заниматься вот такого рода самодеятельностью.

Я не стал выяснять, что там воркэраундили эти сумасшедшие, а просто налепил workaround на workaround - https://github.com/pg83/ix/blob/main/pkgs/bld/wrapcc/kuroko/wrapcc.krk#L118-L119 Теперь и cmake, и meson, не видят этих путей для поиска, и меньше лезут в систему.

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

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 при этом.