Еврей жалуется раввину на плохие жилищные условия.
- Ты возьми козу и посели ее в комнате.
- Да что ты говоришь? Куда же козу-то еще?.. И так там шагнуть негде.
- Приведи козу
- Ну, хорошо.
Привел козу. Через несколько дней приходит к раввину:
- Что ты мне насоветовал!.. Тут и без козы житья не было!.. А теперь вообще кошмар!..
- Теперь убери козу
Увел козу. Скоро приходит и говорит:
- Спасибо! Так хорошо жить стало! Так спокойно! Так просторно!

Почитал тут "победную реляцию" от разработчиков curl про асинхронный резолв DNS: https://eissing.org/icing/posts/curl-dns-threads/

TL;DR - это просто какой-то лютый пиздец.

Коллеги на серьезных щах хвалятся тем, что наконец-то прикрутили thread pool для вызовов getaddrinfo().

Оказывается, до этого момента curl буквально рожал новый POSIX-тред на КАЖДЫЙ сетевой чих, если вы, не дай бог, не собрали его с c-ares! Вы знали? Я не знал!

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

Но бомбит в этой истории даже не столько от curl, сколько от того, в каком убогом состоянии исторически находится системный резолвинг DNS, по крайней мере, в мире С и его деривативов. В go все очень хорошо, про Rust я не в курсе.

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

UPD: https://xn--r1a.website/itpgchannel/3397 - как-то писал про #pthread_cancel на getaddrinfo, от авторства тех же коллег.

Вышел релиз OpenSSL 4.0.0.

Прочитал https://github.com/openssl/openssl/releases/tag/openssl-4.0.0, и заорал в голосину.

TL;DR - они наконец-то признали, что так и не осилили корректную работу своего OPENSSL_cleanup(), который годами ломал программы самым всратым образом.

Суть проблемы очень простая - раньше они вешали очистку своих глобальных ресурсов на atexit().

И всё было "хорошо", пока вы не начинали использовать их говнище в многопотоке или, не дай бог, грузить и выгружать .so в рантайме #plugins. При выходе из программы cleanup радостно лез освобождать уже убитые кэши декодеров или контексты, и программа падала с segfault (например, https://github.com/openssl/openssl/issues/22939, или https://gitlab.gnome.org/GNOME/glib-networking/-/merge_requests/254).

И знаете, что они в итоге сделали?

Они просто отключили вызов atexit() по умолчанию!

Что?! Да! Чтобы программа не падала при попытке освободить ресурсы, они решили их тупо не освобождать, официально заявив https://openssl-library.org/post/2026-03-10-remove-atexit/?utm_source=atom_feed, что "failing to free it is not strictly speaking a memory leak". Мол, операционная система прибьет процесс и сама память очистит, а если ваш Valgrind теперь сходит с ума - идите и пишите suppressions, это ваши проблемы.

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

Сварщиком

Интересно конечно, что бы сделала цивиллизация, обладающая "настоящим наблюдателем", столкнувшись с философским зомби.

#LLM явно дают буст развитию моей #lab #homelab.

Взял и наклодил себе очередь задач - https://github.com/pg83/gorn

#distbuld

ну красота же?

#homelab #lab

фанклуб подогнал!

(это все про https://github.com/pg83/gorn/blob/master/throw.go #panic)

Ссука, никто не выкупил "gorn плавит код, из которого куется stal/ix". Оркестратор, который будет выполнять граф #IX поверх gorn, будет называться, конечно, molot!

#distbuild

https://github.com/pg83/molot

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

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

Оно, э, взяло и заработало с первого раза, и теперь я вышел на новый уровень своего CI - не локальный запуск на одном сервере, а честная распределенная сборка, с честным хранением всех артефактов в minio.

Мне тут, знаете, пеняют, что мой блог стал блогом про #LLM.

А что делать, если я сюда пишу, в основном, про свои технологические процессы? Вот занимался #bootstrap #stal/#ix, и 5 лет писал про это. Недавно написал, что эта задача, в целом, завершена https://xn--r1a.website/itpgchannel/3998 - сейчас #ix у меня обновляется бОльшей частью в автоматическом режиме. Понятное дело, что про bootstrap в блоге стало сильно меньше.

Сейчас много занимаюсь старыми долгами про #homelab - пишу про нее.

И, так как я решил, что руками сам ни строчки кода в жизни больше не напишу, потому что это неэффективно, во всех моих работах есть и будут есть отсылки к #LLM.

Это не какое-то локальное увлечение вайбкодингом, а то, что тут теперь будет всегда.

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

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

https://www.ixbt.com/news/2026/04/19/proryv-v-kompiljatorah-optimizacija-delenija-uskorila-processory-apple-i-intel-pochti-vdvoe.html

TL;DR - ускорили деление на константу в 2 раза.

https://arxiv.org/html/2604.07902v1

UPD: в комментариях пишут, что не на все константы, а лишь на некоторые, так что важность, конечно, не такая, как кажется из заголовка.

(предложка)

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

Шапито с ntfs продолжается.

https://www.phoronix.com/news/GNU-Coreutils-9.11

TL;DR - в свежем GNU Coreutils 9.11 ВНЕЗАПНО ускорили cat аж в 15 раз, а wc - в 4.5 раза!

Двадцать лет дiды сидели на жопе ровно, с важным видом заявляя: "мы лучше всех, а больше и нет ничего, и что вы с этим сделаете?".

Но стоило на горизонте замаячить конкуренту в лице uutils, который начал отжимать аудиторию и хвастаться бенчмарками, как у дедушек моментально нашлось время прикрутить zero-copy I/O и векторные оптимизации.

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

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

TL;DR - луддиты наступают, перепись проектов, отказавшихся от приема PR от LLM.