Вытащу из комментариев.

https://crates.io/crates/fake-static

Баг в компиляторе Rust(висит с 15 года), позволяющий, без применения unsafe, произвольно менять lifetime.

Рекомендуется не использовать в проде! В целом, я всем тоже советую не использовать SEGFAULT в проде, да.

https://daniel.haxx.se/blog/2022/12/06/faster-base64-in-curl/

Тут вот автор curl решил похвастаться, как он ускорил свою же реализацию base64, в xy раз(даже не процентов!).

С точки зрения perf инженегра, это все, конечно, очень слабо:

* Нужно было не велосипедить, а соревноваться со state of the art, хотя бы https://github.com/lemire/fastbase64, или turbo base64.

* Соревновался он с линейным поиском символа в массиве 64 символов - "const char *p = strchr(base64, *s);"

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

Ну и, в любом случае, нужно было сделать зависимость от быстрой внешней либы для тех, кому надо, и оставить сколь угодно медленный случай для всех остальных, потому что где curl, а где base64.

Мы тут с коллегами выясняли, зачем вдруг antlr стал зависеть от abseil.

Раскопали красивое.

https://github.com/antlr/antlr4/pull/3694/commits/41beb8fe3540114943cb4ee93dafcc170f143c61

"[C++] Introduce synchronization and container abstractions"

А вот так выглядит "container abstraction":

#if ANTLR4CPP_USING_ABSEIL
#include "absl/container/flat_hash_map.h"
#else
#include <unordered_map>
#endif

Я не шучу.

Лучшее предположение - что Гугл занес в antlr, чтобы они, зачем-то, начали использовать велосипед от Гугла, вместо общепринятого класса.

Потому что этот леденящий душу пиздец из макросов я не понимаю как еще объяснить.

В контексте разработческих окружений.

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

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

Что у нас тут интересного?

* Автор пытается делать релоцируемые на fs проекты, вместо content based address. "Пакеты размещаются в отдельном каталоге ~/.tea и не привязываются к абсолютным путям (могут быть перемещены)" Это интересно, но прямо реально сложно, и я пока не нашел у него механизмов, отвечающих за то, чтобы это делать "просто".

* Мякотка, описание сборочного скрипта. https://github.com/teaxyz/pantry.core/blob/main/projects/deno.land/package.yml#L22 - вот это выглядит так себе. Я как-то рассказывал, во что я погружал свою сборку. В yaml я ее тоже погружал, это несложно, потому что большинство того, что я использую - это списки и конкатенация списков. Выглядело это примерно так, как в tea, по ссылке. Проблема с inline shell скриптами, они, на мой вкус, что в yaml, что в языке nix, выглядят херово.

* Довольно богатая метаинформация, например, он знает, что deno умеет интерпретировать javascript/typescript - https://github.com/teaxyz/pantry.core/blob/main/projects/deno.land/package.yml#L11 Это интересно, хотя, с ходу, непонятно, что он с этим делает.

https://www.phoronix.com/news/Linux-6.2-funsigned-char

Интересная (узким специалистам) новость, ядро Linux переходит на сборку с char == unsigned char по умолчанию.

Есть три возможных состояния:

* Везде signed
* Везде unsigned
* На разных платформах по разному

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

Наша монорепа фиксирует везде signed char, это nop на x86_64, и смена дефолта для linux-aarch64 (сюрприз, сюрприз, но там char unsigned по умолчанию).

В целом, я считаю, что unsigned по умолчанию лучше, просто потому что unsigned - это понятный тип, а signed - непонятное нечто. В нашей вселенной не бывает отрицательных чисел так-то! Но, если ты не контролируешь всю кодовую базу(например, тащишь код извне в contrib/), то unsigned char весьма сложно, если вообще не невозможно, пофорсить.

Пожелаем удачи ядру Линуса, особенно вспоминая его способ бороться с багами - https://en.wikipedia.org/wiki/Linus%27s_law

(TL;DR - падать и коркаться будет на наших компах)

Ну и, конечно, с заголовками, которые потребляет userspace, придется быть аккуратнее.

**: про один такой забавный случай - в следующей серии!

Пост для комментариев (а вдруг). В первый раз вижу такой интересный пост, который имеет ссылку на комментарии в оригинальном канале.

Продолжаю писать и улучшать документацию.

https://github.com/pg83/ix/blob/main/docs/KERNEL.md

Вот, буквы про сборку ядра. Пока на русском, лучше, чем ничего! Кстати, проект (с радостью!) примет помощь в переводе текстов!

Ну, за эйчаров. И всех, кто пытается давать тесты соискателям.

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

"Я прогнал его через тест, который мы обычно выдаем собеседуемым. Там ничего военного, обычная задачка на понимание принципов ООП и Питона.

Эта сволочь написала его почти идеально. Причем не так, как это бы сделал джуниор, а с пониманием тонкостей и очень компактно. Я сам, когда придумал этот тест и прошел его, был более многословен.
Была там и пара моментов, к которым можно было придраться, но эта сволочь исправила их после первой же моей просьбы, причем я сформулировал претензии только общими словами. В общем, такого кандидата я бы взял на работу не задумываясь. Что наводит на размышления. Скорее всего, придется придумывать другие тесты"

Спасибо, Саша.

Обещанное про signed char vs. char vs. unsigned char

Есть такая программа - ragel. Она довольно известна узкому кругу коллег, используется для компиляции регулярок в state machine для целевого языка.

И есть в ней такой файлик - https://github.com/mikkelee/ragel/blob/ragel-6/ragel/common.cpp#L28, а в нем - перечисление всех целочисленных типов на машине, с диапазонами их значений.

Причем, что важно, char идет раньше unsigned char!

Я не буду давать ссылку на место конкретного использования, но оно используется так:

* Строим конечный автомат.
* Находим в этой табличке тип, который вместит весь наш state, и используем этот тип в кодогенерации.

linux-aarch64 - char == unsigned char, на linux-x86_64 char == signed char. char в этой табличке стоит раньше всех.

Поэтому ragel, скомпилированный для host == aarch64, берет в качестве базового типа char, а на x86_64 - unsigned char!

Таким образом, сгенерированный файл зависит не от target системы, а от host системы, для которой был скомпилирован ragel.

От этого ломается воспроизводимость, и лезут всякие subtle баги и предупреждения компилятора.

А, ну и еще, автор ragel сошел с ума, и для разработки седьмого рагеля запилил свой язык программирования - http://www.colm.net/open-source/colm/!

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

Я тут понял, что мне в системе больше симпатичны бинарники на Go, нежели на Python.

Это довольно долго было каким-то "подспудным" ощущением, но я решительно с ним разобрался!

TL;DR - меня напрягает модель работы с внешними библиотеками (особенно с гуевыми) как с фабриками.

У питона нет стадии линковки, поэтому ему нужно знать отображение имени функции на указатель этой функции в runtime. И, так как заранее неизвестно, какие функции будет дергать скрипт, приходится тащить за собой все.

И, когда ты линкуешь статически слинкованный бинарь с питоном и всеми нужными модулями, ты в этот бинарь тянешь literally все символы из gtk/qt, wayland, opengl, драйвера видеокарты, и так далее.

Компилируемая программа со стадией линковки выкинула бы к херам 3/4 всех доступных символов, и оставила бы только нужное.

Второе соображение - даже такие бинарники тащат за собой кучу .py файлов, и это создает кучу бардака в системе. Их тоже можно положить в этот же бинарь, и не таскать с собой, но такое решение выглядит странновато для true питонистов, вопросов же не оберешься.

Отладили с коллегой процедуру установки и сборки ядра.

Видео - уже после boot в систему, в момент пересборки всего мира, из свежеустановленного stalix.

А ведь это мог быть ты, %username%!

Воскресный #rant.

Увидел в потоке обновлений программу под названием codelite https://codelite.org/, и решил собрать ее.

Оченно удивился, когда обнаружил, что ее tgz занимает порядка 100 мегабайт.

Быстрые раскопки показали:

pg-> find . -type f -name '*.a'
./sdk/curl/lib/libcurl.a
./sdk/libssh/lib/libssh.dll.a
./sdk/libssh/lib/osx/libcrypto.a
./sdk/libssh/lib/osx/libssh.a
./sdk/libssh/lib32/libssh.dll.a
pg-> find . -type f -name '*.dylib'
./sdk/hunspell/lib/osx/libhunspell-1.3.0.dylib
./sdk/lldb/osx/lib/liblldb.10.0.0svn.dylib
pg-> find . -type f -name '*.dll'
./Runtime/msys-1.0.dll
./Runtime/pthreadGC2.dll
./sdk/curl/lib/libcurl-4.dll
./sdk/libssh/lib/libssh.dll
./sdk/libssh/lib/libzlib.dll
./sdk/libssh/lib32/libssh.dll
./sdk/libssh/lib32/libzlib.dll
pg-> find . -type f -name '*.exe'
./CxxParser/sed.exe
./Runtime/File2Hex.exe
./Runtime/mkdir.exe
./Runtime/patch.exe
./Runtime/rm.exe
./codelitephp/bin/bison.exe
./sdk/astyle/bin/AStyle.exe
./sdk/clang/lib/clang-format-64.exe
./sdk/clang/lib/clang-format.exe
./universal-ctags/win32/codelite-ctags.exe

Я, конечно, перед сборкой все это говно подчистил, потому что нефиг тянуть за собой всякое:

https://github.com/pg83/ix/blob/main/pkgs/bin/codelite/ix.sh#L30

После такого аккуратного strip оно при установке начало выдавать ошибку, что, мол, не может скопировать какой-то файл на положенное ему место.

Я, почуяв недоброе, пошел смотреть, что происходит:

https://github.com/eranif/codelite/blob/master/universal-ctags/CMakeLists.txt#L11

И, да, этот господин, ничтоже сумняшеся, прикопал какой-то бинарник прямо в репу, и копировал его в host систему. А я его удалил, и обломал всю малину/

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

А почему бы не прикопать сразу готовый бинарник codelite, и не тратить время на сборку, нуачо?

#bs #vendor

https://www.phoronix.com/news/Meson-1.0-RC1

Вот, пожалуйста, #meson хвастается поддержкой Rust.

Писал, и буду писать, что так делать не надо, и надо иметь мета-package manager, типа nix/guix/ix.

Основной массив аргументации тут - https://t.me/itpgchannel/252

Классного текста про IT сегодня не будет, потому что я писал классную доку про IX package manager - https://github.com/pg83/ix/blob/main/docs/IX.md!

Ну и продолжал улучшать и углублять документацию по stal/IX, https://github.com/pg83/ix/tree/main/docs.

Инсталлятор, помимо меня, смогло осилить уже два человека, даже со сборкой ядра на реальном железе, и поддержкой 3D на встройке от Intel, чего я сам никогда до этого не делал!

Продолжение темы про "героическое изобретение всем известных контейнеров в C" - https://www.phoronix.com/news/Linux-6.2-Modules

Программы на С, в среднем, медленнее, чем программы на C++/Rust, потому что там сложно использовать контейнеры, отличные от связанного списка и массива фиксированной длины.

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

Все эти связанные списки в С, все эти *get_property* в GTK программах, которые написаны в стиле

if (strcmp() == 0) {return ...}
if (strcmp() == 0) {return ...}

Я прекрасно понимаю, почему написано именно так - потому что легко добавить еще один элемент, и не надо беспокоиться за память. Но когда пропертей становится больше 100?

Ну и да - по ссылке - замена прохода по связанному списку с таким вот strcmp() на дерево, с огромным ускорением в 1000х раз!

Проблема в том, что, пока выпилили 1 список, в ядро впилили еще 100. Такими темпами, конечно, работы хватит навсегда.

https://www.kommersant.ru/doc/5721073

Давненько не было ссылок на мою любимую тему про инфраструктурные площадки. #provider #yeswecan

"Как сообщает Fox News, новый глава Twitter полностью распустил консультативную группу по безопасности, которая модерировала спорный контент и состояла из почти 100 экспертов по правам человека"

"С самого начала многомиллиардной сделки по приобретению Twitter господин Маск заявлял: он намерен наконец дать ее пользователям возможность «свободно говорить в рамках закона», а не подвергаться излишней цензуре"

Инфраструктура должна жить по четким внешним правилам, и подвергаться внешнему аудиту, а не сотней sjw-активистов.

UPD: Маск тут будет ничуть не лучше, чем предыдущие, только с уклоном в другую сторону. https://t.me/hn_best_comments/15495

https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608387.html

В gcc вмержили gccrs (rust frontend).

Выглядит это всrustо, потому что я никогда не видел, чтобы такой сырой продукт вмерживали бы в mainline gcc.

Ну, то есть, по мощщи эта поделка пока не дотягивает даже до #mrustc, который в состоянии бутстрепнуть современный компилятор Rust.

gccrs, насколько я понимаю, не умеет даже такого (Я не прав? Поправьте!)

Короче, какое-то странное, наверное, политическое, решение.

Пятничный вечерний #rant.

Есть такая библиотека, #glibc, ее авторы известны тем, что они хотят сделать все "лучше", чем все остальные. Проблема в том, что, чаще всего, их решения оказываются просто "по другому", а потом - "блядь, кто, и нахуя, это все придумал".

Есть такая функция - #pthread_cancel ().

* Не используйте ее, нигде и никогда. Ее поведение максимально плохо определено, и, в реальной жизни, введет вас в какой-нить deadlock. Потому что тестов на этот участок кода вы все равно не напишите.

* По стандарту, все, что она должна сделать - это вызвать специально зарегистрированные cleanup handlers, и завершить тред. Но коллеги из glibc решили, что им этого мало! И запилили следующую фичу - они вызывают stack unwinder, чтобы уничтожить локальные объекты на стеке в этом треде.

Как это сделано?

* Загружаем в runtime unwinder из gcc. Нет, это не обязательно тот же самый unwinder, который используется всей остальной программой, он может быть статически влинкован. https://codebrowser.dev/glibc/glibc/nptl/pthread_cancel.c.html#99

* Бросаем неизвестное науке исключение. https://codebrowser.dev/glibc/glibc/nptl/unwind.c.html#130 Вопрос для знатоков - как это исключение взаимодействует с исключениями C++? А с catch (...) ?

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

Собственно, если ваша программа несет с собой свой unwind runtime, ожидайте произвольное падение в результате взаимодействия с glibc/pthread_cancel.

https://www.pypy.org/posts/2022/12/jit-bug-finding-smt-fuzzing.html

Интересный текст про использование #Z3 для проверок корректности проведенных оптимизаций в pypy jit. Текст довольно насыщенный, без соплей, без вводных про traces(довольно краеугольный камень в современных jit для динамических языков), и про ssa.

TL;DR - нашли довольно прилично багов.

Вообще, про pypy могу сказать, что код там довольно странный. Он, видимо, действительно умный, с хорошим таким академическим нюшком (в статье так и пишут - что, вот, мой студент запилил такую-то и такую-то фичи), но, с инженерной точки зрения, он так себе - какая-то неудобоваримая лапша. Впрочем, моя оценка, в основном, базируется на коде вокруг FFI (а на чем же еще, я же пытался все это барахло статичесмки слинковать).