Продолжение темы https://t.me/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://t.me/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://t.me/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 #gorn

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

#homelab #lab #gorn

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

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

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

#distbuild

https://github.com/pg83/molot

#gorn

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

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

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

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

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

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

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

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

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

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