Пересобрал. Удивительно, но оно даже работает.

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

Вот, например, набор патчей, связанных с ranges - https://github.com/pg83/ix/blob/main/pkgs/bin/telegram/desktop/unwrap/ix.sh#L122-L139

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

Наверняка функция, на которую я заменил ranges::contains, компилируется в 100500 раз быстрее, но кому это важно?

https://www.phoronix.com/news/wlroots-Tearing-Control-Merged
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3871?s=09

Я так понимаю, это дает нам объяснение того, почему Hyprland прогнулся под атакой #ddv.

Потому что от Hyprland есть какое-то количество PR в wlroots. И, вот, например, PR по ссылке выше - висел себе 10 месяцев, а тут взял и смержился.

Совпадение?

Вышел python 3.12

Думаю, самая крутая его фишка - это https://docs.python.org/3.12/howto/perf_profiling.html#perf-profiling

Одной строкой - интеграция с perf record/report.

Да, да, в python появился нормальный профайлер!

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

https://www.cppstories.com/2023/monadic-optional-ops-cpp23

Текст про расширения std::optional в c++23.

Чувак, на голубом глазу, считает, что пример из https://www.cppstories.com/2023/monadic-optional-ops-cpp23/#the-c23-way-monadic-extensions лучше читается, чем пример из https://www.cppstories.com/2023/monadic-optional-ops-cpp23/#traditional-approach-with-ifelse-and-optional-c20

Первый пример, конечно, более компактен, но проще читается код по второй ссылке, потому что он:

* немного более рыхлый
* не требует держать в голове дополнительной семантики для своего понимания
* явный control flow

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

https://cstheory.stackexchange.com/questions/53343/recent-advances-in-computer-science-since-2010

Коллега задается вопросом, а что интересного случилось в CS с 2010 года?

А ничего интересного не случилось, инкрементальные улучшения там и тут.

CS, как и многие другие науки, "закончилась", в том смысле, что человеческими мозгами там уже ничего серьезно не накопать. Для како-то существенного прогресса, наверное, нужен более мощный думатель, неважно, алгоритмический, или в виде аппаратного апгрейда человеков.

https://www.bitecode.dev/p/python-312-what-didnt-make-the-headlines#%C2%A7the-performance-let-down

Тут вот коллега пишет, что python 3.12 не быстрее 3.11 на 5%, а довольно значимо медленнее (для теста использовался https://github.com/python/pyperformance).

"You'll notice that 14 tests run faster, but 79 run slower"

Да и даже по wall time всего теста там видно замедление.

Эх, где те (недавние) времена, когда нам обещали 50%-ое ускорение на каждый мажорный релиз?

#fast_python

https://www.phoronix.com/news/Glibc-LD-Nasty-Root-Bug

"We successfully exploited this vulnerability and obtained full root privileges on the default installations of Fedora 37 and 38, Ubuntu 22.04 and 23.04, Debian 12 and 13; other distributions are probably also vulnerable and exploitable (one notable exception is Alpine Linux, which uses musl libc, not the glibc)"

#stal/ix, по понятным причинам, данной уязвимости не подвержен.

Астрологи уже в IT

Programmer memes

У нас уже 6 зеркал, и есть дока, как запилить свое!

https://github.com/stal-ix/stal-ix.github.io/blob/main/MIRROR.md

Одно из зеркал - http://ix.samokhvalov.xyz/ - мое.

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

Под это дело я запилил runit юнит для #stal/IX:

# ix mut system bin/ix/mirror \
    --port=8080 \
    --user=mirror \
    --wd=/home/mirror
# mkdir /home/mirror
# chown mirror /home/mirror

Не могу не похвастаться тем, как этот юнит устроен, конкретно - программная его генерация:

https://github.com/pg83/ix/blob/main/pkgs/bin/ix/mirror/unwrap/ix.sh

Прямо классно, как я его собрал из маленьких запчастей. Особенно доставляет, что я забыл, как в Go делается парсинг command line (бывает, когда в голове с 5 языков на постоянной основе), и просто сгенерил программу, в которую зашиты настройки из вызова ix mut выше:

https://github.com/pg83/ix/blob/main/pkgs/bin/ix/mirror/serve/serve.go#L6-L7

(я не уверен, что эта простая программа не сможет прочесть что-нибудь не то, но у меня кроме кеша там вообще ничего нет, поэтому пофиг)

https://github.com/pg83/ix/blob/main/pkgs/bin/ix/mirror/serve/ix.sh#L5

Можно было бы вообще inline, без sed, но так проще, потому что не надо думать про escaping.

(do not do this, kids, at home)

#mirror

#rant

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

Вот, и 3.12 версия - не исключение.

Система сборки стала игнорировать *disabled* модули в Setup.* - https://github.com/python/cpython/blob/main/Modules/Setup#L19-L21

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

Как я когда-то уже шутил, мне кажется, что авторы некоторых OSS проектов зарабатывают деньги на том, что готовят желающим сборки без всех этих извращений с динамическими #plugins.

Иначе я это объяснить не могу.

Ладно, конечно могу - всем просто похер на этот механизм, вот он и ломается, почем зря.

К счастью, мой враппер над компилятором давно, и с легкостью, справляется с такой засадой (он просто собирает .a из тех же .o, вместо .so) - https://github.com/pg83/ix/blob/main/pkgs/lib/python/3/12/ix.sh#L19

Еще они украли к себе в исходники какую-то более хорошую модную автоматически верифицируемую реализацию хеш-функций (https://github.com/python/cpython/tree/main/Modules/_hacl), а вот addincl не сделали, пришлось сделать самому - https://github.com/pg83/ix/blob/main/pkgs/lib/python/3/12/ix.sh#L14

Снова похвастаюсь своими сборочными файлами - https://github.com/pg83/ix/blob/main/pkgs/lib/python/3/12/ix.sh

Мне кажется, вот этот вот способ описания каждой следующей версии продукта как маленькое инкрементальное изменение сборки предыдущей версии - это очень удобно, #изящно, и отражает ход мыслей. О как.

Все же, нет сборочной системы хуже, чем gnu #autohell.

(давние читатели, наверное, заметили, что я держу две системы сборки в "самых худших" - cmake, и gnu autohell, а вот кто из них хуже - это уже дело ситуативное)

У нее есть такой хитрый режим сборки, когда в одну папку можно положить несколько отдельных проектов на autohell, написать один общий configure, и оно будет как-то пытаться все это собрать.

Прямо очень условное устройство таких проектов:

# cat configure
...
sh A/configure
sh B/configure
sh libC/configure
...

Так собираются gcc, gdb, и, вот, gettext - https://github.com/autotools-mirror/gettext.

Иногда мне нужно декомпозировать сборку таких проектов, например, в случае gettext - чтобы отдельно собирать инструментарий gettext, и отдельно - libintl.

Так как такая схема сборки косая и кривая, разработчикам, которые ее используют, приходится жестить:

* разработчики gettext/tools захотели напрямую заиспользовать исходничек из соседнего проекта - https://github.com/autotools-mirror/gettext/blob/master/gettext-tools/src/Makefile.am#L295. Ну и просто добавили его в свой Makefile!

Казалось бы, что может пойти не так?

Все шло совершенно так, пока кто-то не захотел в этот вот localealias.c добавить include на генерируемый в процессе сборки файл (вот исходник для файла - https://github.com/autotools-mirror/gettext/blob/master/gettext-runtime/intl/libgnuintl.in.h,как он по цепочке попадает в localealias.c - неважно)

Понятное дело, что теперь сборка всего проекта получила race, и теперь он не может быть собран параллельно, нужно в определенном порядке позвать configure и make в этой общей структуре проектов, чтобы эти неучтенные зависимости были готовы, когда реально нужны.

Можно ли это как-то починить (если считать, что эта зависимость там реально нужна)? Без перехода на более хорошую систему сборки, или глубокого рефакторинга сборочных файлов старой - сомневаюсь.

Я это починил так:

* https://github.com/pg83/ix/blob/main/pkgs/bin/gettext/unwrap/ix.sh#L34 - занулил плохой файл

* добавил зависимость от libintl (где есть нужный объектный код) в сборку gettext/tools - https://github.com/pg83/ix/blob/main/pkgs/bin/gettext/unwrap/ix.sh#L11

Мораль? Как обычно, ее нет.

Ну не прошло и двух лет, как коллеги озаботились проблемой воспроизводимости сборки Python - https://sethmlarson.dev/security-developer-in-residence-weekly-report-13

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

Я уже как-то писал (https://xn--r1a.website/itpgchannel/776), и напишу еще раз - при всех прочих равных я стараюсь брать автоматически сгенеренный tgz из системы контроля версий (ну или напрямую git clone), нежели чем tar.xz, "сваренный" каким-то человеком из хрен знает каких исходников. Большое поле для злоупотреблений, или для человеческих ошибок.

#maskray, #llvmweekly

Очередной зажигательный текст от нашего коллеги - https://reviews.llvm.org/rG904b3f66f59e

TL;DR - новая эвристика в алгоритме, который пытается наиболее оптимальным образом (видимо, с точки зрения заданного perf/call graph) распределить код функций по бинарнику.

Говорят, более хорошо учли instruction cache, и все такое.

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

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

Ну а как сделать что-то такое "быстро", с ходу совсем не очевидно.

Пишут, что ажно +1% перфа, по сравнению с предыдущим алгоритмом.

Забавная статья, под названием "Is Guix full-source bootstrap a lie?"

https://simon.tournier.info/posts/2023-10-01-bootstrapping.html

Наши постоянные слушатели помнят, что мне очень интересна эта тема (#bootstrap) - "как из ничего получить что-то", и я уже пару раз писал про то, как Guix трепетно относится к этой задаче (Nix - в целом, наплевательски, они больше запариваются по воспроизводимости (что похоже, но не совсем то же самое), ну а мой #ix - где-то посредине)

Поэтому, конечно, я не смог пройти мимо этого текста, потирая свои потные ручонки в предвкушении жареного!

Но чуда не произошло, а автор статьи - просто мастер кликбейтных заголовков:

No, it is not a lie! Guix blog post told me: « today, you get a package graph of more than 22,000 nodes rooted in a 357-byte program »

В целом, довольно вторичный текст, по сравнению с тем, что я уже кидал на тему, но вот пара интересных цифр там есть:

Summarizing what we get
In all that story, which binary do we have to trust?

First, we must trust bootstrap-seeds. That’s nice because it is small enough for auditing the binary seeds. That’s already very excellent!

That’s said, although the package graph is rooted in bootstrap-seeds, second we also must trust the driver. It means: 1.3MiB for tar, 1.3MiB for bash, 0.7MiB for mkdir and 0.844MiB for xz. Last, 14MiB for uncompressed static Guile binary. Result, it is a bit less that 20MiB.

Что тут написано? Что, "на самом деле", часть цепочки от 300 байт на ассемблере до 20 мегабайт бинарей, с которыми собирается вся остальная система, есть участок, который был пройден руками, и авторы guix про него "мамой клянутся", что там все честно.

20мб - это уже очень хороший результат, лучше сделать довольно сложно.