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

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), и ничего с этим не сделать, кроме как жестко выпатчить к хуям (что я и сделал, без ссылки, там нет ничего красивого и/или интересного).

Мораль?

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