Обсуждение к https://www.tgoop.com/itpgchannel/3139

https://medium.com/@M0rtyMerr/рекрутеры-паразиты-отказ-на-свою-же-должность-в-it-11e255d25b82

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

Добровольцам было предложено:

* Проверить наличие открытой позиции под их стек в текущей компании
* Изменить ФИО, телефон и почту в резюме
* Удалить из резюме текущее место работы. То есть, вернуть его к виду, с которым когда-то приняли на работу
* Оставить отклик в свою же компанию"

"Итоги эксперимента
* 19 добровольцев из VK, 2ГИС, Авито, Т-Банк, Сбер и менее известных компаний завершили эксперимент
* 6 получило явный отказ
* 9 были проигнорированы (прошло больше 2 недель)
* Всего четверо получили приглашение на собеседование и дошли до обсуждения зарплаты"

Вдова Филипа Дика справедливо жалуется на проблемы с YouTube. Отличная иллюстрация к тому, как херово работают ИИ. От этого самого слова, да.

https://www.scientificamerican.com/article/new-proof-dramatically-compresses-space-needed-for-computation/

https://arxiv.org/abs/2502.17779

"We show that for all functions t(n)≥n, every multitape Turing machine running in time t can be simulated in space only O((tlogt)**0.5). This is a substantial improvement over Hopcroft, Paul, and Valiant's simulation of time t in O(t/logt) space from 50 years ago [FOCS 1975, JACM 1977]"

"For nearly 50 years theorists believed that if solving a problem takes t steps, it should also need roughly t bits of memory—the 0s and 1s that a machine uses to record information. (Technically, that equation was t/log(t), but for the numbers involved log(t) is typically negligibly small.)"

"But in a surprising finding described this week at the ACM Symposium on Theory of Computing in Prague, Massachusetts Institute of Technology computer scientist Ryan Williams found that any problem solvable in time t needs only about √t bits of memory: a 100-step computation could be compressed and solved with something on the order of 10 bits"

Будни #bootstrap, #ix

pg:home# ./ix build bin/b64 --target=freebsd-x86_64
...
pg:home# readelf -a .../bin/base64 | grep OS/ABI
  OS/ABI: UNIX - FreeBSD

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

"Проблема вызвана тем, что при применении опции "-R" ("--chroot") для запуска команд в chroot-окружении с выбранным пользователем корневым каталогом, файл /etc/nsswitch.conf загружался в контексте нового корневого каталога, а не системного каталога. Так как пользователь может использовать в качестве корневого каталога для chroot собственный каталог, он может разместить в нём файл конфигурации nsswitch.conf. Контролируя загружаемый подсистемой NSS (Name Service Switch) файл /etc/nsswitch.conf, пользователь может добавить в него настройки, приводящие к вызову дополнительных обработчиков. Подобные обработчики загружаются NSS в форме разделяемых библиотек, которые также можно разместить в подконтрольном пользователю каталоге. Подставив свою библиотеку пользователь может добиться выполнения из неё кода с правами root, так как обработка NSS производится до сброса привилегий"

Все, как я люблю - #plugins + #suid == бабах!

Помяните мое слово, вот эта вот вакханалия, с 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-битными числами.