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

Видео - уже после 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://xn--r1a.website/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://xn--r1a.website/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 кто-нибудь пытался использовать? Я пытался)

В правительстве констатировали бегство из России 100 тысяч IT-специалистов

После начала войны с Украиной из России уехали и не вернулись 10% IT-специалистов, заявил глава Минцифры Максут Шадаев на правительственном часе в Госдуме. При этом он уверяет, что 80% из них продолжают работать на российские компании, причем делают это из «дружественных» стран.

Министр напомнил, что ведомство выступает против полного запрета на удаленную работу для таких специалистов. «Ключевая мера, которую мы сейчас предлагаем все-таки обсудить, — это не вводить жесткие ограничения, потому что это, конечно, подтолкнет их к тому, чтобы они устраивались на работу в зарубежные компании», — сказал Шадаев. Однако он поддерживает запрет на удаленку для сотрудников, которые работают над важными государственными системами. Ранее Шадаев призывал создать условия для возвращения IT-специалистов в страну, показав «на деле», что «здесь можно спокойно продолжать работать».

Подписаться | Moscow Times

#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 вышел, какой же завтра будет срачик!