https://suricrasia.online/blog/turning-a-keyboard-into/

Отличный текст, с картинками, про то, как запилить свое виртуальное input устройство, например, мышь. Теперь от попытки запилить kinetic scrolling меня останавливает только своя лень. Ну и понимание, что, без связки с композитором, оно может работать всрато.

А я, кстати, рассказывал, как лет 10 назад запилил кастомный драйвер для synaptic touchpad? Меня здорово раздражала его "дубовость", но я посмотрел в его исходники, и понял, что ковыряться в этом не хочу. А еще раздражала необходимость перезагружать X при каждом изменении поведения.

Поэтому я запилил псевдо "драйвер" для X, который пытался присоединиться к определенному named pipe, и просто читал оттуда команды (в виде json rpc). А настоящий драйвер я запилил на питоне, он просто читал сырые события, парсируя какаую-то модную на тот момент утилиту для чтения сырых событий, и отправлял команды в другую сторону этого named pipe.

Понятное дело, что цикл Edit - Compile - Run стал в 100 раз быстрее, и нужного мне эффекта я добился довольно быстро.

А как смешно себя вела мышка, если вместо реальных координат отсылать координаты легкого тела, вращающегося вокруг более тяжелого тела, привязанного к реальным координатам, по законам Ньютона (проще говоря, передавать координаты Луны, как если бы Земля следовала за курсором мыши), ммм...

С++ #rant #gold

Мне сегодня в очередной раз сказали, что, мол, я люблю С++.

Это ложь, пиздежь, и провокация.

Давайте я вам расскажу краткий экскурс в развитие языков программирования, с авторским объяснением "что, как, зачем".

Тезис номер один. На ассемблере невозможно написать компилятор Rust. Вот вы хоть усритесь, хоть соберите 10^6 программистов с самыми таланливыми менеджерами. Не напишите, просто потому, что сложность компилятора Rust - просто гигантская, такую кодину, даже если ее суметь разработать по спецификации, будет невозможно отладить.

Из этого тезиса я делаю простой вывод - развитие идет маленькими шагами.

После ассемблера было неизбежным появление С и Алгол-подобных языков, типа Pascal. Pascal (в редакции с указателями) и С - это близнецы-братья. Их отличает то, что их можно довольно просто закодить на ассемблере, и они будут сносно работать.

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

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

Дальше у нас есть развилка - на C можно запилить:

* Интерпретатор с рантаймом (refcount или gc, это неважно), что-то типа lisp, python, perl, и так далее. Это прикольно для непосредственной разработки на этих языках, но, с точки зрения продолжения цепочки, это dead end, потому что ну не пилят промышленные языки на интерпретаторах с runtime.

* А дальше интереснее - на C можно запилить еще более крутой компилируемый язык, похожий на С, но с более строгой моделью compile time проверок (и гарантий), которая позволяет делать меньше ошибок, а, значит, строить еще более и более сложные программы и системы.

Я говорю про C++ и про RAII.

(RAII, кстати, на мой взгляд, решает 80% ошибок управления памятью С, еще 15% фиксит санитайзер и valgrind, и 5% остаются на borrow checker)

Собственно, в конце 90-ых, начале двухтысячных, у меня было не особо много выбора.

Я пробовал Pascal, C, какие-то интерпретаторы. Интерпретация на тот момент была неюзабельной, потому что машины были очень слабые.

А на Pascal и C невозможно (ладно, запретительно дорого) строить большие программы, без постоянной боязни выстрелить себе в ногу (проездом или утечкой).

Поэтому я тогда выбрал С++.

Это был sweet point в языкостроении - компилятор еще не был перегружен тоннами наслоений, довольно простой язык, RAII давал писать гораздо более сложные и надежные программы, при этом, он был нативно-компилируемый.

Ну и, как полагается, С++ открыл дорогу к еще более сложным системам - Java, JS/V8/Node, Swift, два компилятора Rust написаны на С++, и я удивлен, что исходный зачем-то пилили на ML. Zig начинал с С++. Короче, по сути, вся плеяда современных языков выросла из этой приоткрытой двери. И я не говорю про language design, я говорю про простую и тупую вещь - на С++ можно было писать эффективные большие и сложные программы так, чтобы они почти не падали.

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

Я довольно хорошо знаю С++, но очень не люблю.

Почему?

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

#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.