Опубликованы результаты оценки влияния на производительность пересборки пакетов для Ubuntu с различными опциями и реализациями функций выделения памяти. Экспериментатору удалось на 90% (в 1.9 раза) повысить производительность пакета jq с инструментарием для обработки данных в формате JSON, путём обычной пересборки из того же пакета с исходным кодом, без внесения изменений в сам код. Производительность оценивалась через измерение времени выполнения типового фильтрующего запроса над данными GeoJSON, размером 500МБ.

Итоги эксперимента:

- Вариант, собранный в GCC из тех же исходных текстов с флагами по умолчанию оказался быстрее бинарного пакета Ubuntu на 2-4%.

- Пересборка в Clang 18 с уровнем оптимизации"-O3", включением оптимизации на этапе связывания ("-flto") и отключением отладочной информации ("-DNDEBUG") привела к ускорению на 20%.

- Пересборка с системой распределения памяти TCMalloc (добавление "-L/usr/lib/x86_64-linux-gnu -ltcmalloc_minimal" в LDFLAGS) привела к ускорению на 40%.

- Замена функций malloc на системы распределения памяти tcmalloc, jemalloc и mimalloc через "LD_PRELOAD=/usr/lib/x86_64-linux-gnu/lib....so" привела к увеличению производительности на 27%, 29% и 44%. При запуске с mimalloc, показавшем ускорение на 44%, выставлялась переменная окружения "MIMALLOC_LARGE_OS_PAGES=1".

- Пересборка пакета с mimalloc в LDFLAGS вместо связывания через LD_PRELOAD привела к ускорению прохождения теста на 90%. Другой тест по обработке 2.2GB JSON-данных в 13000 файлах также показал прирост производительности примерно в два раза.

Производительность Ubuntu-пакета jq удалось увеличить в 1.9 раза путём пересборки
https://www.opennet.ru/opennews/art.shtml?num=62912

Оригинальный пост
Make Ubuntu packages 90% faster by rebuilding them
https://gist.github.com/jwbee/7e8b27e298de8bbbf8abfa4c232db097

Открытка @itpgchannel и его приключениям с malloc 🌝

https://gitlab.xiph.org/xiph/ogg/-/merge_requests/11#note_57404

"A 3 year old MR, to fix a 14 year old bug, now arguing about using a 26 year old language, in a project that hasn't had a release in 5 years. Forget about it. Please don't merge this, I don't want my name associated with this project"

Open source, который мы заслужили!

(спасибо нашим радиослушателям за ссылку!)

Проблемы возникают из-за того, что подобные ИИ-индексаторы действуют агрессивно, собирают информацию в несколько потоков и не учитывают правила доступа к контенту, заданные на сайтах через файл robots.txt. Проблему усугубляет то, что разработками в области машинного обучения занимаются большое число разных компаний по всему миру, которые пытаются собирать как можно больше данных в меру своих возможностей. Каждая компания запускает свой индексатор и все вместе они создают огромную паразитную нагрузку на элементы инфраструктуры.

После начала блокировки подобного трафика, некоторые индексаторы начали притворяться типовыми браузерами для обхода фильтрации по идентификатору User Agent и использовать распределённые сети, охватывающие большое число хостов, для преодоления ограничений интенсивности обращений с одного IP. Наиболее сильно из-за активности ИИ-индексаторов страдают инфраструктуры открытых проектов, использующих собственные хостинги Git-репозиториев, форумы и Wiki, которые изначально не были рассчитаны на обработку высокой нагрузки.

Проблемы возникли у платформы совместной разработки SourceHut, развиваемой Дрю ДеВолтом (Drew DeVault), автором пользовательского окружения Sway. Дрю сетует на то, что в очередной раз вместо того, чтобы заниматься развитием платформы ему приходится тратить большую часть своего времени на разгребание неожиданно возникших проблем.
. . .
Другие проекты, обратившие внимание на проблему:

- Из-за высокой нагрузки на инфраструктуру для противостояния ИИ-индексаторам разработчики GNOME внедрили систему защиты от ботов Anubis, допускающую вход только после вычисления хэша sha256 (proof-of-work). При открытии страниц в GitLab GNOME теперь появляется характерная аниме-заставка, которая у некоторых пользователей приводит к минутной задержке загрузки страниц. За два с половиной часа тестирования только 3% запросов прошили проверку в Anubis, а 97% обращений были совершены ботами.

- В проекте Fedora из-за запросов ИИ-индексаторов наблюдаются сбои с работой платформы совместной разработки Pagure. В процессе противостояния с ИИ-ботами пришлось заблокировать множество подсетей, включая весь диапазон IP-адресов Бразилии, что привело к блокировке и некоторых пользователей.

- Сообщается о проблемах с сервисом совместной разработки Codeberg и инфраструктурой платформы Forgejo (code.forgejo.org), которые пытаются отразить поток запросов ИИ-индексаторов. 

- GitLab-сервер проекта KDE на некоторое время оказался недоступен из-за перегрузки в результате активности ИИ-индексаторов, отравлявших запросы из подсети, принадлежащей компании Alibaba.

- Из-за высокой нагрузки на сайт разработчики Inkscape начали блокировку по спискам Prodigious и планируют установить систему Anubis для защиты от ИИ-индексаторов.

- Из-за наплыва ИИ-индексаторов отмечаются сбои в работе форума проекта FreeCAD и проблемы с Wiki проекта Arch Linux.

- Разработчики открытой социальной сети Diaspora сообщили о возрастании нагрузки на форумы Discourse, Wiki и web-сайт проекта. По статистике за ноябрь и декабрь, собранной до нашествия обезличенных ботов, около 70% всего трафика пришлось на запросы от ИИ-индексаторов: 24.6% трафика сгенерировано ботом GPTBot, 17.1% - Amazonbot, 4.3% - ClaudeBot, 2.2% - meta-externalagent (для сравнения на ботов Google и Bing приходится по 0.14% трафика).

Перегрузка инфраструктуры KDE, GNOME, Fedora, Codeberg и SourceHut из-за ИИ-индексаторов
https://www.opennet.ru/opennews/art.shtml?num=62925

Cloudflare выпустила AI Labyrinth, что бы бороться с подобной активностью
https://blog.cloudflare.com/ai-labyrinth/

A list of AI agents and robots to block.
http://github.com/ai-robots-txt/ai.robots.txt

~460 тысяч адресов с которых зафиксирована активность ИИ-ботов
https://www.partagerfichier.fr/download.php?f=2025-03-17-09-22-30_botnet-set.zip

fun fact - github не жалуется на индексацию LLM-ами, а вывод из этого каждый может сделать сам!

(не надо держать свою #infra, да)

https://tinyhack.com/2022/09/16/when-you-deleted-lib-on-linux-while-still-connected-via-ssh/

pg:home# sudo sh
/home/pg/ix # rm -r /lib
rm: cannot remove '/lib': No such file or directory
/home/pg/ix #

End of story.

https://github.com/pypa/setuptools/pull/4870
https://github.com/pypa/setuptools/pull/4911

TL;DR - коллеги из Python решили потешить свое самолюбие, что "-" в setup.cfg нельзя, а можно только "_", взяли, вмержили это, а теперь откатывают, потому что сломали over 9000 пакетов!

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

"This driver is very portable and its platform-independent part can be compiled for Haiku with minor effort (but it need to implement OS-specific binding code to be actually useful)"

Вот и хорошо, что живет out of tree, а то привязали бы его к "Швабодке", и приличным людям бы ничего не досталось!

"I finally managed to make initial port NVRM kernel driver to Haiku and added initial NVRM API support to Mesa NVK Vulkan driver, so NVRM and NVK can work together. Some simple Vulkan tests are working"

Коллега еще откроет для себя #zink, и все у него будет в шоколаде. UPD - уже, https://discuss.haiku-os.org/t/haiku-nvidia-porting-nvidia-gpu-driver/16520/12

https://discourse.llvm.org/t/rfc-breaking-basic-format-strings-abi-for-performance-improvements/85431

TL;DR - хорошо им там в Rust, увидел возможность оптимизации, послал PR, и ты в шоколаде.

А в этом вашем C++ - 5 страниц текста только с объяснением идеи и случающегося ABI break, и, в результате, ты будешь тоже в чем-то коричневом (но, скорее всего, это не шоколад, ага).

Будни #bootstrap

Случился новый релиз svt-av1, принес красивое:

https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/cmake/cpuinfo.cmake?ref_type=heads#L67-68

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

* Заюзали новую либу, от pytorch, вроде, ничего страшного - https://github.com/pytorch/cpuinfo

* Завендорили, причем самым всратым в cmake способом, через FETCH_CONTENT (никогда, никогда так не делайте)

* Самая мякотка - завендорили какой-то васянский форк, https://github.com/1480c1/cpuinfo, наверное, вирус какой-то.

* Прикопали хеш от zip файла - https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/cmake/cpuinfo.cmake?ref_type=heads#L76 Никогда, никогда этого не делайте, ВСЕ известные мне хранилища исходников генерят их нестабильно. Через пару итераций очистки кеша в его gitlab этот хеш протухнет:

https://www.group-telegram.com/itpgchannel.com/916
https://www.group-telegram.com/itpgchannel.com/424
https://www.group-telegram.com/itpgchannel.com/937

Все это, конечно, вызывает некоторую фрустрацию.