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

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

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

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

Ко мне тут в личку пришли с вопросом:

"Привет!
Вот есть такой вопрос.
Я раст вообще не трогал, только "в интернете видел".
И в общем понимаю, что он даёт.
Но есть ли нормальная, сильная аргументация с позиции плюсовика, почему раст не панацея и ничего не даст в сложившейся среде?
Или мы в итоге все там будем?"

Серьезный вопрос требует серьезного ответа!

Если говорить именно про смешанные С++/Rust проекты, то:

1) interop Rust <-> C++ - поганый. Он, по сути, идет через поверхность C, ты не сможешь использовать шаблоны С++ в Rust, или proc macro из Rust в С++. Это значит, что поверхность взаимодействия нужно будет всегда сводить к С, что дорого. В С++ ты просто передашь ссылку на std::vector, а в Rust ее придется передавать сложнее, и принимать назад сложнее. Так же очень неприятно то, что нужно будет конвертировать в обе стороны динамические исключения С++ <-> типизированные ошибки Rust, это error prone процесс.

2) Из этого следует, что ты будешь часто копировать данные, если ты передаешь их между разными языками, просто чтобы они становились привычным типом в текущем языке (std::vector <-> Vec).

3) Так же из этого следует, что у тебя будут проблемы с lifetime, как в С++, так и в Rust, потому что через поверхность C они не передаются. То есть, сложно будет понять, кто владеет тем или иным объектом, и кто его и когда удаляет.

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

Если ты не можешь гарантировать сходимость процесса переписывания, то лучше и не начинать.

Имеет смысл использовать Rust там, где C поверхность взаимодействия очень тонкая, условный audio/image/video/compress кодек (на вход сжатый буфер, на выход - разжатый, владение абсолютно прозрачно, и преобразование ошибок тоже).

Или, например, реализация VM, типа WASM, там тоже очень понятная поверхность взаимодействия - байткод в буфере, и набор FFI функций для экспорта в эту VM.

#llvmweekly

https://discourse.llvm.org/t/rfc-llvm-link-llvm-dylib-should-default-to-on-on-posix-platforms/85908/60

These are again for release+assert with non-pie baseline:

            | static | dylib | slowdown
check-llvm  |  1:30s | 1:53s | 25%
check-clang |  1:11s | 1:28s | 24%

Тут написано, что тесты на clang/llvm, если брать динамически слинкованный clang, на четверть медленнее, чем со статически слинкованным clang.

В копилочку к https://www.tgoop.com/itpgchannel/2939 (два последних пункта).

https://blog.janestreet.com/a-higgs-bugson-in-the-linux-kernel/

История одного #debug, без излишних соплей, люблю такие.

Чувак для воспроизведения бага:

* запилил fuse файловую систему для быстрой генерации контента
* заиспользовал #eBPF, чтобы вывести stacktrace ядра при возникновении ошибки
* написал плагин для wireshark
* взял NFQUEUE, "userspace process for packet filtering", TIL

И все это, буквально, на двух страничках текста.

I spent way too much time scrolling through these PRs. The pattern was always the same:

- AI: “I fixed the issue!”
- Human: “Your code isn’t working and you broke other tests.”
- AI: “You’re absolutely right! Fixed it now.”
- Still not fixed.

Балдёж

If you’re worried about AI layoffs, here’s your playbook:

- Become the AI expert on your team. Don't fight the tools, master them. 
- Document everything AI can't do. Keep a running list of complex problems you solve that AI suggestions couldn't handle.
- Make it public. Share your real AI experiences on social media.
- Create the narrative. Every time you solve something AI couldn't, tweet about it. When AI helps you ship faster, share that too.
. . .
If your CEO is talking about AI layoffs, update your resume. Not because AI will replace you, but because you’re working for someone who thinks a technology that can’t understand a simple bug is ready to run their engineering org.

AI has become a part of software development, but it isn’t perfect. Humans are needed more than ever.

AI Can't Even Fix a Simple Bug — But Sure, Let's Fire Engineers
https://nmn.gl/blog/ai-scam

Спасибо подписчику за ссылку

Будни #bootstrap

Собрал под freebsd какое-то значимое количество пакетов, в том числе, графических приложений.

Был приятно удивлен:

* Под freebsd есть свой libudev, с linux compatible интерфейсами
* Под freebsd компилируются, и, наверное, работают, основные библиотеки для ввода - libinput, libevdev, libmtdev, и так далее. Мне, например, казалось, что они linux only. То есть, freebsd тут пошли по пути наименьшего сопротивления, поддерживая такой же ABI в /dev/, как и в Linux.
* Соответственно, собираются libdrm, libwayland и mesa, практически "из коробки". В целом, неудивительно.

Был просто шокирован тем, что почти все эти библиотеки имеют в себе include <linux/input.h>, то есть, изначально они были linux-only, а в freebsd есть пакет, который предоставляет этот заголовок, реализованный в соответствующих терминах freebsd.

Лично мне нравится прагматичность подхода, и отсутствие борьбы с ветряными мельницами. Есть готовый код, и давайте подстроим OS ABI так, чтобы этот код просто работал.

https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/

"Shared libraries are not a good thing in general. They add a lot of
overhead in this case, but more importantly they also add lots of
unnecessary dependencies and complexity, and almost no shared
libraries are actually version-safe, so it adds absolutely zero
upside"

Linus про динамическую линковку.

При сборке curl под freebsd стала падать библиотека libgpg-error, причем с ошибкой, которая мне показалась знакомой.

Долго вспоминал, и вспомнил - https://www.tgoop.com/itpgchannel/1665. Вот тут я чинил кросс-компиляцию этой либы, правда, не для freebsd.

Полез читать, почему не помог прошлый фикс.

Нашел прекрасное - https://github.com/gpg/libgpg-error/blob/master/configure.ac#L634

Что тут написано?

Что, если мы кросскомпилируем, то, если кросс-компилируем под Linux, то сделать магию из https://www.tgoop.com/itpgchannel/1665, а иначе сказать "ну не шмогла я". Офигенные, блин, тесты.

Починил я это весьма изящно - https://github.com/pg83/ix/blob/main/pkgs/lib/gpg/error/ix.sh#L36. Типа, сказал, что под freebsd надо сделать точно так же, как под Linux.

#llvmweekly, история одного #debug.

Довольно существенный прогресс у gcc rust codegen (это, напомню, rust, но с оптимизатором от gcc) - https://fractalfir.github.io/generated_html/cg_gcc_bootstrap.html

TL;DR - пара патчей там и тут, и все сошлось. Одна серьезная проблема - inline(always) для рекурсивных функций, и мутки с 128-битными числами.

#llvmweekly

https://llvm.org/docs/DTLTO.html
https://github.com/llvm/llvm-project/commit/3b4e79398de5
https://github.com/llvm/llvm-project/commit/6520b21ce0

Гля какая красота, LLD умеет распараллеливать часть thin lto между несколькими хостами, не только в многопоток на одном хосте!

https://medium.com/top-python-libraries/microsoft-shuts-down-python-founders-core-team-cpython-team-disbanded-0ae603862d68

"However, yesterday, CPython core developer Brett Cannon revealed on LinkedIn that three core developers from the Faster CPython team — Eric Snow, Irit Katriel, and Mark Shannon — were included in Microsoft’s recent global layoffs"

#fast_python - от начала, и до конца.

#prog #rust #article

A Newbie's First Contribution to (Rust for) Linux

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

https://fidget-spinner.github.io/posts/jit-reflections.html

Оказалось, что этот JIT медленнее, чем baseline:

"CPython 3.13’s JIT ranges from slower to the interpreter to roughly equivalent to the interpreter. Calling a spade a spade: CPython 3.13’s JIT is slow. It hurts me to say this considering I work on it, but I don’t want to sugarcoat my words here.

The argument at the time was that it was a new feature and we needed to lay the foundations and test the waters. You might think that surely, CPython 3.14’s JIT is a lot faster right? In some ways, the JIT has become faster, but only in select scenarios. The answer is again… complicated. When using a modern compiler like Clang 20 to build CPython 3.14, I often found the interpreter outperforms the JIT"

https://www.washingtonpost.com/national-security/2025/07/08/marco-rubio-ai-imposter-signal/

"A Marco Rubio impostor is using AI voice to call high-level officials
The unknown individual contacted at least five government officials, including three foreign ministers, a U.S. governor and a member of Congress, according to a State Department cable"

Ебешься каждый день!

Я такое пару раз сам наблюдал, только второй раз там была жена.