Вторая часть марлезонского балета!

#abi

Потому что однажды создатели С++ добавили в него https://en.wikipedia.org/wiki/Turing_tarpit под названием "шаблоны".

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

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

И в этот момент ловушка для языка захлопнулась!

Потому что если комитет по стандартизации С++ добавит в язык нормальное (*) метапрограммирование, то все время, инвестированное в это говно под названием "шаблоны", разом обесценится у очень большого числа людей. А оно кому-то надо? А что после этого будут делать уважаемые люди из комитета С++?

(пишу я это вполне осознано, как человек, когда-то спавший со стандартом под подушкой, и думавший, что он щас все сделает на этом сраном pattern matching под названием "частичная специализация")

Замкнутый круг.

Я вообще никому и никогда не советую начинать новые проекты на С++.

Лично я начинаю с Python, если неважен perf. В последнее время чаще смотрю на Go, и, думаю, однажды Go мне полностью Python заменит. Что бы я взял, если бы нужно было запилить что-то perf critical, в новой кодовой базе? Мне не нравится Rust, но, скорее всего, это был бы он.

(*) Что такое нормальное метапрограммирование? Это, по сути, доступ к AST (или, хотя бы, к потоку токенов) средствами самого языка, либо внешним кодогенератором:

* https://terralang.org/
* https://github.com/python/cpython/blob/main/Lib/collections/__init__.py#L439 - ядро изготовления namedtuple в python (да, кодогенерация + eval)
* lisp/scheme/etc
* в Rust норм

#gold #blob #supply

https://github.com/serde-rs/serde/issues/2538 этот тред, конечно, пополнит мою золотую коллекцию.

Разработчики serde (насколько я знаю, самая популярная библиотека сериализации для Rust), решили, что им "очень нада" ускорить сборку своего поделия, и положили предсобранную либу в свой репозиторий.

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

В тред набижали старшие и более опытные товарищи, и напихали хуев этим малолетним долбоебам объяснили, что так делать "не нада".

https://github.com/serde-rs/serde/issues/2538#issuecomment-1676139711
https://github.com/serde-rs/serde/issues/2538#issuecomment-1676355050

Вот, наверное, наиболее корректные сообщения с объяснением возникающих проблем при попытке воспроизвести сборку.

(От Jakub Jirutka, наверное, можно особо не объяснять, кто это?)

UPD: там, конечно, ЖЫР:

* Набижали SJW со своими "community deserves more" (я, как последовательный правый, считаю, что сообщество заслуживает только того, что написано в лицензии) https://github.com/serde-rs/serde/issues/2538#issuecomment-1684526456

* Или вот автор форка этой либы, который пишет, что сам не хочет его поддерживать, и есть ли на это волонтеры. https://github.com/serde-rs/serde/issues/2538#issuecomment-1684531496

* А кто-то предлагает скинуться по 10 баксов автору либы, чтобы он сделал эту фичу opt-out - https://github.com/serde-rs/serde/issues/2538#issuecomment-1684607407

Будни #bootstrap

Я, как вы уже заметили, люблю собирать запчасти для #stal/ix с разными там выподвыпердами.

Например, базовые программы у меня собраны со стандартным аллокатором из musl (потому что там важнее размер бинаря, а не скорость аллокации), и с netbsd curses вместо ncurses. Тоже из-за экономии размера, ну и потому, что там terminfo database вкомпилена в либу, а не валяется в виде 100500 файлов на диске, как у ncurses. Так же из них выпилены gnu gettext, потому что нефиг.

Выглядит это так - https://github.com/pg83/ix/blob/main/pkgs/set/system/0/ix.sh#L4 Фактически, собираю поддерево проектов с особым набором флагов, которые переключают те или иные умолчания.

Вот, нашел на просторах интернета hardened malloc - https://github.com/GrapheneOS/hardened_malloc, и решил, что мне обязательно нужно собрать с ним единственную программу, которая у меня в системе занимается privilege escalation - sshd (https://xn--r1a.website/itpgchannel/291).

Не то чтобы я очень боялся, что ее взломают, но зумеры и хипстеры же падки на такие заявления - "security enhanced base system, with hardened malloc" etc etc и прочий bullshit.

https://github.com/pg83/ix/blob/main/pkgs/bin/sud/ix.sh#L7 - вот, буквально одна строчка изменений, помимо того, чтобы положить саму либу в репозитоий.

Fun fact:

В процессе линковки "усиленного" dropbear выяснилось, что кто-то у кого-то потырил исходники:

ld.lld: error: duplicate symbol: chacha_keysetup
>>> defined in ./libssh.a(chacha.o)
>>> defined in .../libhardened_malloc.a(chacha.o)

ld.lld: error: duplicate symbol: chacha_ivsetup
>>> defined in ./libssh.a(chacha.o)
>>> defined in .../libhardened_malloc.a(chacha.o)
ld.lld: error: duplicate symbol: chacha_keysetup
>>> defined in ./libssh.a(chacha.o)
>>> defined in .../libhardened_malloc.a(chacha.o)

ld.lld: error: duplicate symbol: chacha_ivsetup
>>> defined in ./libssh.a(chacha.o)
>>> defined in .../libhardened_malloc.a(chacha.o)
ld.lld: error: duplicate symbol: chacha_keysetup
>>> defined in ./libssh.a(chacha.o)
>>> defined in .../libhardened_malloc.a(chacha.o)

Обычно такое скрывают с помощью всякого рода hidden символов, но это не работает в случае статической линковки.

И к важным новостям: https://www.phoronix.com/news/KDE-Plasma-6-Double-Click

"KDE Plasma 6 Default Behavior Is Now Double-Click For Opening Files/Folders"

У телеги brain split на несколько независимых сегментов, интересно, к чему это?

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

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.