Когда #LLM начинает отлынивать от работы, например, говорит, что код слишком сложный, вместо того, чтобы запустить gdb, иногда очень хорошо помогает начать следующую фразу с "ты че пес ...".

Полагаю, я там у них уже в short list на экстерминатус.

Переписал реактор на io_uring, ну как переписал, не я конечно, а #LLM, я сам нихера в нем не понимаю. Заодно запилил новую долбилку (в цвете! прямо как будто на almost blazingly fast писал!!), а то wrk начал затыкаться.

На самом деле, этот результат еще лучше, потому что тогда я тестировал тоже на 8 ядрах, но сетевые реакторы отъедали еще примерно 4, а тут всего 8 ядер на серверную часть.

#std

вот я уже с #LLM говорю за жизнь, такие дела

Продолжение темы https://xn--r1a.website/itpgchannel/3135

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

"В пакетном менеджере Nix, применяемом в дистрибутиве NixOS, выявлена уязвимость (CVE-2026-39860), которой присвоен критический уровень опасности (9 из 10). Уязвимость даёт возможность перезаписать любой файл в системе, насколько позволяют права доступа фонового процесса Nix, который в NixOS и многопользовательских установках выполняется с правами root. Проблема вызвана некорректным устранением уязвимости CVE-2024-27297 в 2024 году. Эксплуатация осуществляется через подмену символической ссылкой каталога внутри изолированного сборочного окружения, в который записывался результат сборки. Уязвимость устранена в обновлениях nix 2.34.5, 2.33.4, 2.32.7, 2.31.4, 2.30.4, 2.29.3 и 2.28.6"

Просто скопирую кусок предыдущего своего поста, он все так же актуален:

Я, когда дизайнил это место в #IX (https://xn--r1a.website/itpgchannel/179, тогда это еще называлось #mix, до ребрендинга, #security), смотрел на то, как это сделано в nix и guix. Мне это место с демоном показалось довольно тонким, и я решил, что имеющейся у меня изоляции не хватит на то, чтобы гарантировать безопасность.

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

Фактически, любой вызов ix build у меня содержит вызов su -s /bin/sh ix -- executor ..., для непосредственного применения построенного графа к системе (в других терминах, конечно, потому что у меня нет классических способов поменять пользователя, #suid).

Натурально, можешь стать пользователем ix - можешь менять систему.

Поэтому такой проблемы у меня нет, и быть не может.

pg@:~/any cat ./examples/fictional.any
#!/usr/bin/env any
магия: сложи 2 и 2, потом умножь на 10
скажи результат
pg@:~/any ./any ./examples/fictional.any
40

pg@:~/any cat ./examples/lisp.any
#!/usr/bin/env any
(define x 7)
(define y 3)
(display (* (+ x y) (- x y)))
(newline)
pg@:~/any ./any ./examples/lisp.any
40

pg@:~/any cat ./examples/ruby.any
#!/usr/bin/env any
name = "Мир"
puts "Привет, #{name}!"
puts 3.times.map { |i| i * i }.inspect
pg@:~/any ./any ./examples/ruby.any
Привет, Мир!
[0, 1, 4]

pg@:~/any cat ./examples/emo.any
#!/usr/bin/env any
🫙 = 100
🍎 = 37
🧮 = 🫙 - 🍎
покажи 🧮
pg@:~/any ./any ./examples/emo.any
63

Запилил короче универсальный интерпретатор, https://github.com/pg83/any - он может исполнить код на любом языке программирования, даже вымышленном!

(with a twist, конечно)

#math #meme

(thanks @random_rust_dev)

Несколько раз уже писал, что, в современном состоянии, LLM не добавляют к твоим скилам, а мультиплицируют их.

Я вот переберу с #LLM 5 - 6 разных решений задачи, и выберу наиболее "подходящее".

Поэтому когда какой-то нуб решает натравить на произвольный код нейронку, получается вот как в этом треде: https://discourse.llvm.org/t/concerns-about-influx-of-ai-generated-bug-fixes/90381

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

Коллеги берут случайные тикеты, или варнинги стат-анализаторов, просят бота написать фикс и, не глядя, несут этот AI slop прямиком в апстрим LLVM.

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

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

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

#llvmweekly

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

Почитал тут "победную реляцию" от разработчиков 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)