Вечерний #rant, про Google и GRPC.

#ball_lick

Про Google (и про MANGA вообще, или как там щас их принято обзывать) достаточно часто говорят, что они нанимают лучших из лучших, а потом заставляют их парсить JSON-ы.

С одной стороны, благодаря такой политике мы имеем v8, и лучший из доступных web совместимый браузер, с другой - это приводит к тому, что какую-нить GRPC для open source пишут 20 выпускников MIT (почему? потому что можно!).

И, чтобы не сойти с ума от этого безблагодатного занятия:

* Они переинженирили GRPC, что пиздец, разобраться в нем без шильдика "MIT" решительно невозможно. Причем, на мой взгляд, совешенно на пустом месте, просто потому, что делать нехрен.

* Каждую простую проблему воспринимают как способ устроить "бурю в стакане":

https://github.com/grpc/grpc/issues/31885#issuecomment-1579222845

"The issue with the absl deadlock checker is a known one when NDEBUG is not defined (i.e. when the shared object library is built in debug mode), but all of our prebuilt released artifacts define NDEBUG, so I would expect this not to be problem unless building from source with debugging turned on. We have a longer term plan to resolve this issue, but it requires an architectural change and since it should only affect people building their own artifacts from scratch, it is not our highest priority"

Реально, на трехстроочный патч (кстати, когда за них уже проделали сложный debug), они говорят "Мы в курсе, но, так как нам нехера делать, то мы, вместо того, чтобы взять ваши 3 строчки, запланируем архитектурный рефакторинг на пару лет, а то нам нечем будет оплачивать ипотеку. Ну и проблемы негров шерифа не волнуют" (вольный перевод мой).

Любой нормальный инженер (ладно, это https://ru.wikipedia.org/wiki/%D0%9D%D0%B8_%D0%BE%D0%B4%D0%B8%D0%BD_%D0%B8%D1%81%D1%82%D0%B8%D0%BD%D0%BD%D1%8B%D0%B9_%D1%88%D0%BE%D1%82%D0%BB%D0%B0%D0%BD%D0%B4%D0%B5%D1%86, не любой) знает, что проблему нада сначала замитигировать, потом завести тикет в JIRA, на более правильную починку, который можно сделать "когда-то", и не держать на event.Wait() кучу народа.

Одной строкой.

https://bugzilla.mozilla.org/show_bug.cgi?id=1833315

Интересное расследование бага в мобильном процессоре Samsung - https://bugzilla.mozilla.org/show_bug.cgi?id=1833315

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

Альтернативный компилятор для Go, на основе LLVM.

Я пока не смог его собрать, потому что его сборка - это тихий ужас, пытающийся собрать завендоренные запчасти с помощью аццкого Makefile - https://github.com/tinygo-org/tinygo/blob/release/Makefile. Этот кошмар пытается собрать llvm, довольно странным образом (оно собирает бинари, а потом выковыривает из сборки получившиеся .a файлы), потом запчасти tinygo с помощью go build, а потом как-то слинковать это в один бинарь.

Треш, угар, содомия.

https://dmitryfrank.com/articles/rust_module_system_encourages_bad_practices

Небольшая заметка про отличия модульной системы Rust и Go.

Мне, однозначно, система Go нравится больше, хотя бы за четкое разбиение пакетов по директориям.

Собирать несколько модулей/пакетов/библиотек из одной директории придумали сумасшедшие, ценящие внешнюю красоту больше красоты внутреннего логического устройства, не надо так.

https://reviews.llvm.org/rGa6213088812f

Какой-то странный движ вокруг #llvm #libc.

Ее допиливают под GPU target platform, вот, коммит, в котором запилили malloc/free.

С одной стороны, проехаться на растущей популярности этой платформы - норм, но как бы это не заслонило ту конечную цель, на которую надеялся я - стать THE libc для Linux.

https://www.opennet.ru/opennews/art.shtml?num=59297 #uring

Google отключает io_uring на Андроиде, ChromeOS, и, наверное, где-то еще. Пишут, что дырявое решето - 60% всех багов и выплат за поиск багов.

В целом, это все логично и понятно:

* io_uring пилят для перфа, видимо, на безопастность обращают внимание в последнюю очередь.
* нафиг этот io_uring не сдался на вашем телефоне и ноутбуке, вряд ли вы заметите выигрыш от него.

Но, конечно, это очень печально, потому что мне io_uring виделся как будущее ввода-вывода в Linux, да и вообще, я надеялся, что все сисколлы, рано или поздно, можно будет асинхронно батчить пачками.

https://github.com/harfbuzz/harfbuzz/pull/4131

#harfbuzz #fontconfig #wasm

"This adds a wasm shaper that when called (default, when built), loads a WebAssembly program from the Wasm table of the font and calls its bool shape(font*,buffer*) function to shape the buffer"

Я, с одной стороны, всячески пропагандирую "открытые" системы, типа "там, где передаешь строку, сразу передай user defined dict", или "если требуется процедурное действие, не формализуй его, а позови пользовательский run.sh", но, с другой стороны, понимание, что загрузчик шрифта может позвать произвольный WASM, даже и в песочнице, меня напрягает.

Мысль о том, что интерпретатор wasm будет влинкован в каждую программу, энтузиазма тоже не вызывает. Вот если бы шрифты рендерились отдельным процессом, например, через dbus, было бы гораздо более хорошо.

Это "умение", конечно, сильно облегчило жизнь, в случае, когда авторы не удосуживаются готовить разумные tgz с релизами, так, чтобы они содержали все исходники.

Иногда новый способ экономит мне довольно много исулий по ручному скачиванию всех сабмодулей, например, вот - https://github.com/pg83/ix/commit/e187e1e719050f3bb8cb95c7ac1fddd40f7f19e6

В связи с этим, у меня вопрос задачка на bootstrap - какой командой можно наиболее эффективно скачать срез git репы (репа + бранч/таг + sha коммита в нем), со всеми сабмодулями, рекурсивно, без скачивания лишней истории (можно вообще без истории)?

У меня есть какая-то примерная команда, но, мне кажется, она не очень эффективна.

https://lwn.net/SubscriberLink/934692/5046d466490d9220/

Автор bcachefs, #Kent, хочет, в очередной раз, заапстримить ее.

Не очень понимаю, какую пользовательскую задачу она решает, которую бы не решали уже существующие FS.

Поэтому я не понимаю, какую поддержку получит эта FS в индустрии, и почему не станет уделом маргиналов.

Особенно мне доставил пассаж про

Rust is something that he has been evangelizing about to "anyone who will listen"; he thinks "writing code in C, when we finally have a better option available, is madness". He loves to write code, but not to debug it; writing in Rust "just means a lot less time debugging". He intends to slowly rewrite bcachefs in Rust, which will be a ten-plus-year project, but the use of Rust in bcachefs has already started. Some of the user-space tools have been rewritten in Rust and someone is looking at moving some of that work into the kernel.

"10 человеко-лет", говорит, "положу на переписывание под Rust".

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

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

Не стал писать про эту новость в момент ее появления, хотел дождаться результатов расследования.

https://gmplib.org/list-archives/gmp-devel/2023-June/006162.html

Какой-то чувак положил своим CI сервера проекта GNU gmp. CI этот живет в github, и проверяет сборку ffmpeg для сотни платформ. Проект gmp, широкими мазками, забанили все сети MS на своем сервере.

MS/github считают, что так можно, и проекту gmp нужно заиметь более лучшее железо.

Авторы gmp считают, что MS - контора пидарасов невозможно обслужить 8 гиг пожатого трафика за несколько часов, и отказались убирать блокировку. Не обошлось без левацких заявлений - https://gmplib.org/list-archives/gmp-devel/2023-June/006164.html:

"Note that this abusive traffic is still ongoing, but it is subsiding as I keep adding more and more Microsoft subnets to the firewall rules. I have much better things to do than defend a public service web server against corporate abuse!

What would you advise me to do, should I contact a US lawyer and have them send a cease and desist letter?"

Я, конечно, считаю, что:

* не надо хостить свою инфру, много раз про это уже писал #gitlab

* всегда нужно иметь зеркало на github, для бекапа, ну и чтобы обслуживали это те, кто хорошо умеет это делать.

GNU gmp (наверняка по глупым политическим причинам) такого зеркала не имеет.

https://github.com/faster-cpython/ideas/blob/main/3.13/README.md
https://github.com/faster-cpython/ideas/blob/main/3.12/README.md

#fast_python

Закончил читать два фундаментальных (если считать ссылки) текста про грядущие оптимизации python.

Если раньше я выражал здоровый скептицизм про эти планы, то теперь готов заявить сдержанный оптимизм - планы звучат достаточно "сложно", чтобы быть интересными, а не просто "ну мы как-то все ускорим в 100500 раз".

Oh, fun fact - Гвидо, похоже, отодвинули от процесса - https://github.com/faster-cpython/ideas/commits/main

Совпадение? Хм...

https://blog.rust-lang.org/2023/06/20/introducing-leadership-council.html

Тут вот пишут, что распустили Core Team, и завели новый.

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

#wasm #bootstrap

После написания того текста я решил, что мне катастрофически не хватает какого-то решения для поддержки WebAssembly - как для сборки в него, так и выполнения.

Потому что раз всем нужно, то и мне тоже нужно!

Вот, теперь все есть:

pg# cat qw.c 
int f(int a, int b) {
    return a + b;
}
pg# /ix/store/.../bin/clang \
    --target=wasm32 \
    -nostdlib \
    -Wl,--no-entry \
    -Wl,--export-all \
    -O2 \
    -o qw.wasm \
    ./qw.c 
pg# /ix/store/.../bin/iwasm \
    --repl ./qw.wasm 
webassembly> f 1 2
0x3:i32
webassembly> 

Я завел интерпретатор из https://github.com/bytecodealliance/wasm-micro-runtime, llvm jit из него же, тулчейны из https://github.com/WebAssembly/binaryen, https://github.com/WebAssembly/wabt, ну а clang давно уже умеет в wasm.

На самом деле, я немножко мухлюю, потому что надо еще собрать wasm libc (поверх WASI - https://github.com/WebAssembly/wasi-libc), но, в целом, уже все работает, причем без всяких там rust и emscripten.

https://ohadravid.github.io/posts/2023-03-rusty-python/

Неожиданно годный текст про оптимизацию питона через переписывание кода на Rust.

Неожиданно - потому что заголовок совершенно кликбейтный, "python", "rust", "в 100 раз", короче, все, как я люблю. Да и задача, мягко говоря, выбрана странно - чуваки написали кусок пайплайна 3d рендера на python, причем кусок, который непосредственно обрабатывал геометрию. А потом героически оптимизировали этот кусок, хотя ответ, кажется, всем очевиден - не надо обрабатывать геометрию на python.

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

Довольно подробно расписано использование биндингов из Rust в Python + NumPy.

Короче, хороший вводный текст, если абстрагироваться от хайпа и от решаемой задачи.

https://lwn.net/Articles/935592/

RH закрывает доступ к исходникам, из которых собирает RHEL. По подписке они продолжают быть доступны, все честно.

В комментариях срач, коллеги никак не могут договориться, кто же больше паразитирует на open source:

* RH, переупаковывая и продавая чужой труд
* Alma/Rocky линуксы, пересобирающие RHEL из исходников, ранее доступных всем
* Oracle ...

Я, конечно, считаю, что никто не паразиты, все в рамках того, что ВЫ САМИ разрешили им сделать с вашим кодом. Не хотите - ну возьмите другую лицензию на свой код, но им тогда никто не будет пользоваться, и все.