У пограничного расстройства личности девять диагностических критериев. Для диагноза достаточно пяти. Если посчитать все возможные сочетания, получится 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(), удивлён, что большинство программистов обращаются с ней как с чёрным ящиком. Этот пост призван немного исправить ситуацию, и в нём рассказано, что именно происходит под капотом. Также рассмотрим одну из возможных реализаций этой функции.

Если вы или ваша команда уже используете LLM или планируете интегрировать их в проект, то наверняка у вас возникал вопрос, как лучше и красивее написать такой интерфейс, который мог бы общаться с разными моделями. И на такой вопрос уже есть ответ.

Теперь можно сэкономить время разработки и управлять нейросетями в одном месте. Поможет в этом простой инструмент LiteLLM, про который далее и пойдет речь.

Вторая часть серии статей по Docker. Разбираем все способы хранения данных в Docker: тома, bind mount и tmpfs — чем отличаются, как использовать, а также драйверы хранения, бэкап томов и работа с Compose.

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

Новый промпт не всегда решает проблему: важно управлять тем, какая информация попадает к модели перед каждым следующим шагом. Это и называют контекстной инженерией.

Разбираемся, чем она отличается от промпт-инжиниринга, RAG и MCP, почему агент начинает ошибаться и какие приёмы помогают собрать контекст так, чтобы модель не путалась в длинных сценариях.

Нейро сети для самых маленьких

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

Это первая статья из небольшого цикла, посвящённого сетям для AI/ML-кластеров и HPC.

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

Конкретно в этой статье мы разберёмся, что представляет из себя нейросеть, как она работает, как происходит её обучение, а самое главное, почему для неё нужны сотни дорогущих GPU-карточек и какая-то особенная сеть.

Рефрен сегодняшней истории: в нейросетях нет никакой магии — это просто множество простых операций над числами, которые выполняются на компьютерах со специальными чипами.
Магии нет ни в том, как они работают, ни в той инфраструктуре, на которой они запускаются.

Каждый электронщик, работающий (или отдыхающий) с цифровыми микросхемами рано или поздно обязательно сталкивается с протоколом JTAG. Значительное количество материалов о данном протоколе содержит три раздела:
1) Обширный экскурс в историю и рассказ о том, как стенд с летающими щупами и рентгеновская установка легко могут быть заменены отладчиком на 2-3 порядка дешевле их.
2) Достаточно сжатое описание протокола JTAG (с картинкой его конечного автомата).
3) Рассказ о том, что фирменный отладчик, а также программное обеспечение компании <COMPANY NAME> позволят почти без усилий протестировать почти любое устройство почти любой сложности и конфигурации.

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

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

Такие платы называют HDI (англ. High Density Interconnect) — это печатные платы с высокой плотностью межсоединений.

Цель нашей статьи — показать, что соблюдая простые рекомендации и имея представление о "популярных" ошибках, можно заметно сэкономить время, а также получить надежные и соответствующие функциональным характеристикам HDI-платы, поставленные в срок, с минимальным риском дефектов и по оптимальной стоимости.