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

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2723r0.html

Интересный proposal про zero-initialize по умолчанию в C++. #cppcom

TL;DR - оптимизации за последние лет 20 научились справляться с этим, и теперь zero initialize ничего не стоит, а иногда делает код даже быстрее. Удивительный факт, но вот коллеги пишут, что zero-initialize для регистров способен разбивать ложные цепочки данных, и, тем самым, улучшать код с точки зрения out of order execution.

Примут ли его?

Я сомневаюсь, что замшелые деды из стандарта пойдут на такое радикальное изменение.

https://www.nmattia.com/posts/2022-12-18-lockfile-trick-package-npm-project-with-nix.html - вот, теперь я понял, как устроен мой VFS в Nix!

Очевидно, мне мое решение нравится больше, но тоже хорошо.

Вангую, что за такими вот "погружениями" будущее мета-пакетных менеджеров!

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

Кажется, намечается новый водораздел между gcc и llvm.

Если вы хотите иметь solid codebase, поддерживающую небольшое число архитектур и языков, то вам в llvm. А если никому не известный язык на древней платформе - то в gcc!

Я, кстати, почти не стебусь - проект llvm очень щепетильно относится к новым архитектурам(за исключением, пожалуй что, #loongson, но там, наверное, политика, или занесли), а вот gcc сейчас - кладбище платформ и реализаций языков(gccgo кто-нибудь пытался использовать? Я пытался)

#bootstrap, #ix

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

Пример использования:

# ix mut system bin/dropbear/runit --seed="dead beef"

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

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

Собственно, решение этой задачи разбилось на 2 части:

* Немношк перепилить утилиту генерации ключей, чтобы она шла не в /dev/random, а в заранее подготовленный файл - https://github.com/pg83/ix/blob/main/pkgs/bin/dropbear/runit/keygen/ix.sh#L7

* Подложить генератору хостовых ключей этот файл, и сгенерить эти ключи. Таким образом, мы получаем "чистый" пакет, который зависит только от своего параметра seed - https://github.com/pg83/ix/blob/main/pkgs/bin/dropbear/runit/hostkeys/ix.sh#L14

Таким образом, мы имеем как бы "случайный" набор ключей, который является чистой функцией от seed. Задача пользователся системы при настройке машины указать этот самый seed, чтобы он был уникальным (это может сделать инсталлятор прозрачно для пользователя).

В процессе у меня получился интересный артефакт - "пакет с подготовленной энтропией". Вот так я прошу, чтобы он был доступен в момент подготовки ключей - https://github.com/pg83/ix/blob/main/pkgs/bin/dropbear/runit/hostkeys/ix.sh#L4, а вот так выглядит его реализация - https://github.com/pg83/ix/blob/main/pkgs/aux/entropy/ix.sh https://github.com/pg83/ix/blob/main/pkgs/aux/entropy/ix.sh#L10 - вот тут вся мякотка, передаем seed в openssl.

pg-> ./ix build aux/entropy 
  --entropy_seed="dead beef" 
  --entropy_size=100
READY /ix/store/7aP.../touch
pg-> ls -ls /ix/store/7aP.../share/entropy
     100 ... /ix/store/7aP.../share/entropy

Артефакт, на самом деле, довольно полезный, потому что в момент установки системы есть довольно много процессов, которые требуют сгенерить уникальный идентификатор хоста, например, /etc/machine-id, который используется в dbus.

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

Кстати, обнаружил красивое, пока читал исходники - https://github.com/mkj/dropbear/blob/master/dbrandom.c#L270

Тут вот написано, как нормальные люди собирают себе изначальную энтропию для работы.

(тем, кто пытался пенять мне на файлик https://github.com/catboost/catboost/blob/master/util/random/entropy.cpp#L40 должно стать стыдно - все так делают!)

#llvmweekly

https://reviews.llvm.org/rGc86a878e8995

"[RISCV] Add Syntacore SCR1 CPU model"

Syntacore - IMHO хороший пример российского IP бизнеса. Вон, в LLVM коммитят, и risc-v проц на гитхаб выкладывают https://github.com/syntacore/scr1.

Это вам не попил бабла на "российский проц", который потом даже в виде IP никому нафиг не сдался, не то, что в железе.

Кстати, вы уверены, что понимаете, что такое "рандомная последовательность нулей и единиц"?

Статистика, например, вообще обходит стороной этот вопрос!

https://en.wikipedia.org/wiki/Random_variable

"However, the interpretation of probability is philosophically complicated, and even in specific cases is not always straightforward. The purely mathematical analysis of random variables is independent of such interpretational difficulties, and can be based upon a rigorous axiomatic setup"

https://en.wikipedia.org/wiki/Random_sequence

"Axiomatic probability theory deliberately avoids a definition of a random sequence"

КМК, интуитивное представление о том, что такое random, написано вот тут - https://en.wikipedia.org/wiki/Impossibility_of_a_gambling_system. И вот тут - https://en.wikipedia.org/wiki/Kolmogorov_complexity#Kolmogorov_randomness + https://en.wikipedia.org/wiki/Algorithmically_random_sequence

Первое - это про то, что важные статистические свойства должны держаться для "нормально выбранной случайной подпоследовательности", а вторая - что настоящий random() не может быть сгенерен на универсальной машине Тюринга фиксированного размера.

Как они связаны, я не знаю, наверное, как-то должны быть.

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

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

Все делают IT прогнозы на 23 год, а я чем хуже?

Вот, делаю!

ЕБЖ, в 23 году выйдет как минимум 1 JS "фремворк" (скорее всего, для управления состоянием), которым "все, абсолютно все" захотят воспользоваться, и переписать на него весь свой код!

https://github.com/ihhub/fheroes2/wiki/Change-Log

Батюшки, fheroes2 (это такой локальный мем с opennet.ru) 1.0.0 вышел, какой же завтра будет срачик!

Не могу не поделиться украденной ссылкой из комментариев - https://www.mccme.ru/free-books/dubna/vau-random-2ed.pdf

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

Автор текста, Успенский, кстати, очень крутой был чувак - https://ru.wikipedia.org/wiki/%D0%A3%D1%81%D0%BF%D0%B5%D0%BD%D1%81%D0%BA%D0%B8%D0%B9,_%D0%92%D0%BB%D0%B0%D0%B4%D0%B8%D0%BC%D0%B8%D1%80_%D0%90%D0%BD%D0%B4%D1%80%D0%B5%D0%B5%D0%B2%D0%B8%D1%87

Вел у меня матлогику, я (впервые) от него услышал фразу "пустое множество пахнет фиалками" :)

(Я правильно назвал 2 из 4 критериев, которые описаны в этом тексте. Это, конечно, не может не радовать!)

https://www.npopov.com/2022/12/20/This-year-in-LLVM-2022.html

Что-то вроде годового self assessment одного из разрабов LLVM.

Мне показалась интересной первая история, про типизированные указатели в LLVM IR.

TL;DR - Раньше с указателем был связан тип, а сейчас не связан.

Казалось бы - данных больше, они богаче, можно больше получить профита?

Но мир жесток, и, несмотря на то, что информации было больше, работать с ней было сильно сложнее (как-то трансформировать и передавать между разными optimization passes), поэтому, в итоге, более простая модель оказалась предпочтительнее.

Меньше потенциальных возможностей, зато профит можно молотить быстрее, и суммарно получается лучше.

https://www.phoronix.com/news/Qt-6.5-Beta-Released

Вышла бета qt 6.5, я стараюсь смотреть на новые релизы пораньше, потому что каждый новый релиз QT приносит мне какую-то новую боль (очень уж у них там большие затейники сборку пишут).

"Qt Grpc is the third new module that provides QtGrpc and QtProtobuf. With QtGrpc it enables communication with gRPC services and QtProtobuf for dealing with protobuf .proto-specifications"

Тут не исправить уже ничего, Господь, жги!

Купил себе планшет.

В последний раз попытка использовать планшет у меня с треском провалилась в конце 19 года. Я тогда купил себе только что вышедший и очень навороченный samsung galaxy s6 amoled, стоил он тогда, ну, скажем, 80к. Может, больше, но точно не меньше.

Характеристики можно посмотреть, например, тут - https://www.samsung.com/ru/tablets/galaxy-tab-s/galaxy-tab-s6-10-5-inch-gray-128gb-lte-sm-t865nzaaser/

Неделю назад мне пришел новенький https://aliexpress.ru/item/1005004733001677.html?sku_id=12000030865279571&spm=.search_results.3.28784aa6tLpBgu

Если вы посмотрите на характеристики, то, если посмотреть с лупой, можно заметить разницу в частоте обновления экрана, и, кажется, это все.

Ну, то есть, аналог bleeding edge из 19 года сейчас является совершенным commodity, и стоит в 4 раза дешевле.

Про что этот пост?

Этот пост про то, что, через 30 - 40 лет (ЕБЖ, конечно), никто вам не нальет чашку кофе в ресторане, сколько бы у вас не было денег, просто потому, что, а зачем что-то делать, если можно вообще ничего не делать, и жить на ББД?

Давненько не было новостей про #ksmbd.

https://www.opennet.ru/opennews/art.shtml?num=58377 - сразу несколько CVE в этой поделке.

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

https://www.openwall.com/lists/oss-security/2022/12/21/6

Оч. смешная бага в парсере procfs. Все ломается, когда в имени процесса есть пробел.

Как-то уже писал, повторюсь. Я принципиально оставил в разрешенных путях для корня IX, и для имен #realm'ов только a-zA-Z0-9_, потому что как ты не экранируй, все равно какой-то инструмент на других символах сломается.

А про взаимодействие ядра и userspace - там везде, конечно, нужен машинно-генерируемый json, без ручных printf.

Я себе клятвенно пообещал, что у меня, в моей личной OS, будет только один syscall, принимающий json, и возвращающий json, все остальное будет мультиплексироваться полями этого json.