https://github.com/chardet/chardet/issues?q=is%3Aissue%20state%3Aclosed

У чувака, короче, титановые яйца - проект не поменял лицензию под давлением копилефтного сообщества, и он методично закрывает issue от троллей, которые туда регулярно набигают.

В общем, желаем ему всяческих успехов.

AI в grpc be like

have_fun: false

https://github.com/grpc/grpc/blob/4943b77a5e497a83beedc6b23b760d8193baa126/.gemini/config.yaml#L1

Вчера положил очень сложный пакет с помощью #LLM, все, как я люблю - C++, древние зависимости с древней сборкой, но половина кода уже мигрировала на Rust, и вот это вот говно надо как-то собрать.

Машина справилась за 20 минут, я бы потратил пару вечеров точно, а то и больше.

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

Сегодня ей дал список случайных пакетов, она их тоже положила. Даже не знаю, сколько это у нее заняло времени, я просто посмотрел на результат, и немного отрихтовал - https://github.com/pg83/ix/commits/main/

Процесс становится все проще и проще, потому что один из артефактов - напутствия для своих будущих инстансов через CLAUDE.md https://github.com/pg83/ix/commit/50716427872887a1c0a18cea71df615a693fd5b2.

#bootstrap

https://gist.github.com/Shishqa/986d87b1cabb88115ce460926989d8c6

Гля какой классный skill коллеги накатали!

"Легендарная философия решения проблем от PG (инструкция для ИИ-агента). Для любых зависших или неработающих команд агент применяет парадигму «ребутни нахуй и ничего не чини». Никакой диагностики, никаких исправлений — только перезагрузка"

#reboot

🎵 Пердунов не возьмут в космонавты
🎸 поп-рок

И немного нейрослопа на тему!

Примерно тогда же, 8 числа, зарядил #LLM тащить firefox в #IX.

Пыхтела она три дня, заняло это 130 итераций пересборки, но моделька справилась! Я не вмешивался, иногда просто смотрел, что она делает.

На самом деле, это только начало пути - код собрался, теперь нужно будет заняться статлинковкой получившихся артефактов в один бинарь, но это уже очень и очень круто!

Когда #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 году проще вообще не убирать за собой мусор, чем пытаться сделать это корректно.