Сколько на самом деле стоит путь пакета через ядро Linux, и сколько из этой стоимости снимают io_uring, AF_XDP и DPDK? Собрал библиотеку, в которой один и тот же цикл отправки и приёма работает поверх семи разных путей, и прогнал её на двух очень разных стендах: на домашнем десктопе с двумя 10-гигабитными портами сетевой карты Intel 82599, соединёнными AOC-кабелем, и на паре инстансов AWS c6in.4xlarge.

Всем привет!

Почти каждый, кто работал с Git больше пары недель, хоть раз сталкивался с одной и той же путаницей: почему git add — это не сохранение, зачем нужен какой‑то отдельный индекс, если есть коммит, откуда вообще берутся конфликты при мерже, если мы просто оба поправили один файл. И почему иногда git status показывает файл как изменённый, хотя вы точно ничего не трогали.

Если вы так же знакомы с этими проблемами, а также с другими проблемами при работе с Git — эта статья для вас.

В этой статье cначала покажем, как Git на самом деле хранит файлы и их изменения, что такое индекс и почему он существует отдельно от рабочей директории и коммитов. Далее — как устроены ветки на уровне данных, а не только как указатель текущей линии разработки. После этого разберём, как Git определяет, какие именно строки поменялись, и как из этого механизма следует слияние т.е merge и, самое главное, конфликты при слиянии.

Изучив модель, пройдёмся по основным командам работы с файлами: add, rm, mv, restore, diff, log, stash, работу с .gitignore и с большими файлами.

А в конце мы вам покажем, как это всё применяется на практике.

Сгенерированная картинка для привлечения внимания. Промпт: «Продемонстрируй, что всё новое — это хорошо забытое старое» (нет)

За последний год инструментов для агентной разработки стало столько, что в них легко потеряться: одни обещают сохранять контекст между сессиями, другие — «понимать» всю кодовую базу целиком, третьи — память, планирование и автономность в одном флаконе. На GitHub каждую неделю появляются репозитории с внушительным (и не всегда честно заработанным) числом звёзд, которые обещают всё и сразу, а на поверку оказываются README-проектами; другие честно работают на демо-репозитории и падают с OOM при первой же встрече с реальным энтерпрайз-проектом — и так далее, список можно продолжать долго.

Осенью прошлого года я пользовался связкой Claude + RooCode + семантический поиск на Ollama, и это был мой основной рабочий инструмент — ровно до того момента, как связка перестала работать (об этом чуть ниже). Я решил полностью пересесть на Claude Code и начал искать замену семантическому индексу, но так её и не нашёл: альтернативы для меня просто не работали — на монолите в 3,5M+ строк они либо индексировались часами, либо требовали отдать код в облако (и заплатить немалую сумму за эмбеддинги!!!), либо поддерживали Ruby, мягко говоря, номинально. В итоге я принял непростое для себя решение сделать собственный инструмент — начав с форка простого движка семантического поиска на Ollama + Qdrant — и, что характерно, сделал: полностью локальный, чтобы ни код, ни его производные (индекс, эмбеддинги, граф вызовов) никуда не уезжали. На сегодняшний день на него ушло больше полугода (и, честно признаюсь, не одна сотня чашек чая).

Скиллы превращают обычного ИИ-агента в узкопрофильного спеца: он ищет инфу в интернете, работает с файлами, пишет код, анализирует данные, запускает задачи в сторонних сервисах.

В этой подборке я собрал 50 самых популярных скиллов для ИИ-агентов - вместе они набрали 9 млн звезд на GitHub и 22 млн установок.

Используйте бесплатно.

Для каждого скилла указал, что он умеет, где пригодится и команду для быстрой установки.

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

MCP-сервер - это по переходник между ИИ и внешним сервисом. Например, один MCP читает файлы на ПК, другой - программирует, третий - ищет инфу в интернете. 

То есть ИИ в основном отвечает на вопросы, анализирует и генерит картинки, а через MCP он может еще подключаться к Figma, Google Drive, базе данных, браузеру, почте и тысячам других сервисов.

В этой подборке я собрал 100 самых популярных MCP-серверов - вместе они набрали ⭐3.1 млн звезд на GitHub.

У пограничного расстройства личности девять диагностических критериев. Для диагноза достаточно пяти. Если посчитать все возможные сочетания, получится 256 комбинаций. Два человека с одним диагнозом могут совпасть друг с другом всего по одному критерию (Leichsenring et al., 2024).

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

В 2019 году Всемирная организация здравоохранения сделала то, о чём исследователи личности спорили больше сорока лет. В одиннадцатом пересмотре Международной классификации болезней (МКБ-11) она упразднила все классические типы расстройств личности. Вместо них появилась единая дименсиональная шкала тяжести — лёгкая, умеренная, тяжёлая — и пять черт-квалификаторов. Это гораздо ближе к тому, как устроены реальность и сложность человеческой психики (WHO, 2024; Tyrer et al., 2019).

Из всей старой таксономии в особом положении осталось только пограничное расстройство личности. В МКБ-11 для него сохранили специальный квалификатор borderline pattern.

Почему система, устремлённая к непрерывным шкалам, сделала исключение именно для него? Что это за сбой психики, который клиницисты отказались выпускать из поля зрения?

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

Всем привет. Добро пожаловать на подкаст Mindscape. Я ваш ведущий Шон Кэрролл. Сегодня у нас специальный сольный выпуск Mindscape. Иногда мы делаем такие выпуски, когда одновременно с подкастом у меня выходит новая книга. Кажется, это всего второй такой случай. В прошлый раз мы делали нечто подобное в связи с выходом «Нечто глубоко скрытое» (Something Deeply Hidden), моей книги о квантовой механике. Новая книга, которая выходит 20 сентября 2022 года, называется «Самые большие идеи во Вселенной. Том 1: Пространство, время и движение» (The Biggest Ideas in the Universe, Volume One: Space, Time, and Motion). Разумеется, она основана на серии видеороликов, которые я выпускал на YouTube в самом начале пандемии, в 2020 году. И эта книга в некотором смысле представляет собой отход от привычного формата - как для меня самого, так и для книг по физике вообще. Обычно, когда я пишу научно-популярные книги, я стараюсь обосновать какую-то точку зрения, которая может оказаться верной, а может и нет. Я пытаюсь убедить читателя, что существует хороший способ размышлять о той или иной проблеме - будь то стрела времени, натурализм или многомировая интерпретация квантовой механики. На этот же раз моя задача исключительно педагогическая: мы будем говорить о том, что я называю большими идеями, то есть об идеях, которые, по сути, останутся с нами навсегда.

Это идеи, которые, как мы считаем, играют важную и корректную роль в описании мира, по крайней мере в определенной области применимости. Речь идет именно о физических идеях. Конечно, существуют большие идеи и за пределами физики, но у меня нет достаточной компетенции, чтобы рассказывать о них, поэтому в названии книги слово «физика» как бы подразумевается. Главное здесь в том, что я не собираюсь заниматься спекуляциями. В книге нет рассуждений о самых далеких следствиях квантовой механики, о мультивселенной, дополнительных измерениях, частицах темной материи или чем-то подобном. Речь идет о том, что мы действительно знаем и что уже надежно установлено. В первом томе мы занимаемся классической физикой. Но классическая физика позволяет продвинуться очень далеко. Она ведет нас не только через Ньютона и Галилея, но и вплоть до Эйнштейна. Поэтому мы рассматриваем специальную теорию относительности, общую теорию относительности и черные дыры. Еще одна особенность этой книги заключается в том, что в ней есть уравнения. Существует множество книг, которые пытаются объяснять основы физики с разной степенью глубины и увлекательности. Но книг, занимающих промежуточное положение между обычным научпопом и учебниками, не так много. Научно-популярная книга обычно старается обходиться почти исключительно словами, аналогиями, метафорами и, возможно, несколькими схемами, чтобы объяснить вам происходящее. Учебник же предполагает, что вы буквально годами будете изучать физику и в конечном счете попытаетесь стать профессиональным физиком.

Двадцать лет назад убрать мусорный бак из кадра — это была целая история, требующая виртуозно владеть фотошопом. Чем дальше шло развитие «умных» инструментов, тем проще решалась эта задача, но поведение всё же не было до конца предсказуемым.

И вот мы пришли к полноценному ИИ, который нам этот бак уберёт одним щелчком, не обязательно даже его полностью выделять. Так и хочется сказать: «Будущее!» А потом заметить, что заодно перерисовался бордюр в другом конце кадра. Который вообще не надо было трогать.

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

Разговор пойдёт по нарастающей. Сначала пройдёмся по методам ретуши. Потом погрузимся в то, как диффузионка вообще работает с картинкой — целиком, от промпта до пикселей. Потом — как из такой генерации сделали редактор. Дальше — что модель несёт с собой из обучения, что ломается на стыке с фотографическим рабочим процессом, что до сих пор быстрее делать по-старому. И под конец — вопрос про то, чему теперь вообще верить, мы его затронем по касательной.

Предупреждаю сразу: примерно две трети текста — это про ограничения. Про достоинства вам и без меня расскажут в любом рекламном ролике, а вот про то, где именно эта штука спотыкается, обычно молчат.

LLM галлюцинирует, впрочем, все видели, как это выглядит. Модель уверенно, связно, с правильной интонацией и терминологией сообщает то, чего нет. Инженеры считают это багом, который чинят и  вот-вот починят.

Не починят. Это не техническая ошибка, а неотъемлемое свойство языка, которое машина сделала видимым.

У меня был iPhone и ноутбук на Windows, а хранилище Obsidian лежало в iCloud. Работаешь себе, всё нормально, и в какой-то момент заметка, которую ты правил, превращается в 10 копий с номерами в именах. Что-то потыкал, вроде исправилось. Несколько дней тишина, потом то же самое. А когда я наконец заглянул в служебную папку, там лежали сотни копий одного файла workspace.json: он размножался активнее всего, просто на глаза не попадался.

Кончилось тем, что я перешёл на технику Apple целиком. Я и так к этому шёл, но история с копиями решение заметно ускорила.

Из этого опыта я вынес мысль, вокруг которой построена вся статья. У синхронизации Obsidian нет одного правильного способа: то, что отлично работает у одного человека, у другого разваливается за неделю. Дальше разберу все рабочие варианты, покажу, от чего зависит выбор, и расскажу, что изменилось этим летом. Перемен хватило, чтобы популярные русскоязычные инструкции перестали работать.

Пошагово собираем собственный AI-контур на VPS c зарубежным IP: подключаем ChatGPT и Claude через OmniRoute, объединяем модели в LiteLLM и настраиваем Codex, Qwen Code и VS Code для работы без VPN.

В прошлой статье (Непослушный using ) я разобрал, как using вмешивается в поиск имён и почему его поведение часто расходится с тем, что от него ждет программист, и на этом ветку статей про поиск имен (name lookup) можно временно закрыть.

Using'и попортят вам в проектах еще немало крови, но в целом их проблемы известны и легко ловятся, а теперь давайте поговорим обauto и выводе типов в шаблонах, который регулярно удивляет даже опытных программистов на C++, когда речь идёт о распаде типов (type decay) и неявных ловушках при работе с ним. Представьте, что у нас есть несколько переменных, которые выглядят разными: const int&, просто int, const int и int&&.

По наивной интуиции можно подумать, что компилятор должен относиться к ним по‑разному: и где‑то ссылка, где‑то константность, где‑то rvalue, но это будет работать только до тех пор, пока мы не используем auto или шаблон.

Потихоньку дописываю книгу, в целом каркас уже сложился и большая часть материала уже собрана и обработана в черновике, если вам интересно, что получилось, то главы выложены на гитхабе в русском и английском вариантах или тут, если вам больше нравится в виде статей, а то, что ещё дописывается уже больше шлифовка, чем поиск нужной формы. Оглавление и ссылки будут под катом.

Как часто вы слышали: «Не доверяй компилятору, пиши вручную»? Похоже, эту идеологию пора сдавать в архив.

Автор специально собрал примеры, в которых «умный» код современного C++ либо проигрывает наивному, либо не даёт выигрыша, но при этом ухудшает читаемость и мешает оптимизатору. Тут и легендарный Q_rsqrt, и бит-хаки для подсчёта единичек, и вездесущие const&, и даже опасные фокусы с фильтрацией диапазонов. Всё с воспроизводимыми бенчмарками на Clang 21 и Ryzen 9. Если вы готовы пересмотреть багаж старых привычек – просим под кат.

Если вы когда-нибудь собирали проекты на C++, то практически наверняка получали ошибку от линковщика формата:

/usr/bin/ld: /tmp/ccYa2eaO.o: в функции «foo()»: foo.cpp:(.text+0x0): повторное определение «foo()»; /tmp/ccKEs5I7.o:main.cpp:(.text+0x0): здесь первое определение collect2: error: ld returned 1 exit status

Опытным C++ разработчикам эта проблема известна как ODR (One Definition Rule). Но корень этой ошибки выходит далеко за рамки «используй inline в .hpp» и «не определяй ничего в .hpp».

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

Заголовок конечно очень похож на классический ИИ SEO слоп, но не спешите закрывать. Анализ вцелом я делал для себя и не претендую на истину в последней инстанции. Просто делюсь вдруг кому окажется полезным.

OpenRouter — самый крупный и известный в мире агрегатор нейросетей. C 26 июля стал пытаться блокировать пользователей из России. В целом, с учетом простоты регистрации и возможностью оплаты криптовалютой — это не такая большая проблема. Но только вот пользование сервисом из 3 букв может добавлять определенные задержки к ping‑у. А если на агрегатор завязано достаточно много сервисов, то сервис из 3 букв должен работать как часы. Эту проблему можно решить именно так, но откровенно говоря ценность OpenRouter как агрегатора в данном случае сводится практически в нулю, поэтому я решил поискать альтернативу — кто уже озаботился решением этого вопроса, попутно получив и другие полезные плюшки, вроде использования российских моделей если в агентах светит 152 ФЗ (строго для этих запросов) и более простой оплаты без переводов на зарубежную карточку.

Для тех, кому лень читать, краткий итог ниже:

Приветствую всех, кто хочет делать свой код быстрым и оптимальным. В этой статье мы расссмотрим один из способов, как можно просто и легко оптимизировать программу на C++ при работе со структурами/классами, почти не меняя код.

Promise, setTimeout и async/await часто работают совсем не в том порядке, которого ждёшь по коду, а тяжёлая синхронная функция способна заморозить весь интерфейс. Разберём модель цикла событий, которая объясняет эти эффекты и помогает понимать, где возникают блокировки, гонки запросов и лишние задержки.

Представьте: вы пишете парсер, который обходит сотни миллионов URL. Каждую новую ссылку нужно проверить — посещали ли мы её раньше? Заводить гигабайтный хеш-набор для хранения всех адресов — расточительно и медленно.

Но существует вероятностная структура данных, которая способна ответить на вопрос «видели ли мы этот URL?», занимая при этом в десятки раз меньше памяти, чем полное множество строк. Плата за такое — мизерная возможность ложноположительного срабатывания, где алгоритм заявит что URL есть, хотя на самом деле он новый. Зато на вопрос «не видели?» она не ошибётся никогда.

Это и есть Фильтр Блума, созданный Бёртоном Блумом аж в 1970 году. Более полсотни лет этому алгоритму! В принципе, никогда не помешает освежить знания и вспомнить, как писать реально оптимизированное ПО.

Программисты, работающие с языком C, несомненно, узнают стандартную функцию malloc(). Это главный аллокатор памяти в языке, который тесно связан со всем известными ошибками сегментирования. Функция malloc() – именно то средство, при помощи которого программы приобретают память во время выполнения. Зачастую она также превращается в основной инструмент создания объектов и управления ими. Учитывая такой центральный статус malloc(), удивлён, что большинство программистов обращаются с ней как с чёрным ящиком. Этот пост призван немного исправить ситуацию, и в нём рассказано, что именно происходит под капотом. Также рассмотрим одну из возможных реализаций этой функции.