Все потоки

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

Если запустить множество таких случайных систем и позволить им мутировать и взаимодействовать друг с другом, возникнут ли в итоге “жизнеподобные”, самовоспроизводящиеся программы? Новая статья Блеза Агуэра-и-Аркаса и его соавторов показывает, что ответ, по-видимому, положительный. Это поднимает интересный вопрос: не является ли вычисление аттрактором в пространстве соответствующих динамических процессов? Если это так, последствия могут быть весьма существенными для нашего понимания происхождения жизни и того, насколько широко она распространена во Вселенной.

Блез Агуэра-и-Аркас получил степень бакалавра физики в Принстонском университете. В настоящее время он занимает должность вице-президента по инженерным разработкам в Google, руководит командой Cerebra и входит в команду Paradigms of Intelligence. Он автор книг Ubi Sunt и Who Are We Now?, а также готовящейся к выходу книги What Is Intelligence?

Вступление

ведущий (Шон Кэрролл): Всем привет и добро пожаловать в подкаст Mindscape. Сегодня у нас ситуация из разряда “есть хорошая новость и плохая”. Плохая новость в том, что в этом выпуске будет нецензурная лексика. Не потому, что мы вдруг решили особенно грубо выражаться или ругаться, а потому, что будем обсуждать компьютерные симуляции, написанные и запущенные на языке под названием Brainfuck. Прошу прощения у тех, кого может задеть такое название, но это вполне реальный язык программирования, и он действительно называется Brainfuck. Поэтому слово Brainfuck нам сегодня придется повторять снова и снова. Собственно, поэтому я произношу его уже сейчас - чтобы вы успели привыкнуть и знали, чего ожидать.

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

Часто задаюсь таким вопросами:

• что будет с моими активами через 5 лет, если взять квартиру в ипотеку?

• стану ли я богаче или же беднее от этого?

• смогу ли я выплатить вообще с текущими доходами и расходами всю ипотеку?

• а если не смогу, в какой момент получу кассовый разрыв?

Ипотечные калькуляторы считают только платёж, а в Excel нужно знать тонну формул для учета всех нюансов расчетов во времени, да и наглядность в эксель сильно хромает.

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

• снимать квартиру и параллельно гасить ипотеку

• или взять жильё на миллион дороже, сразу заехать и отправлять сэкономленную аренду в досрочное погашение.

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

Считать стоимость использования DeepSeek становится всё менее просто. Токены DeepSeek не одинаково полезны стоят сильно по-разному. В пиковые часы цена в два раза дороже.

Сначала пиковые часы были каждый день с 01:00 до 04:00 и с 06:00 до 10:00 UTC. Желающие экономить научились переводить UTC в MSK. Позже выходные дни стали непиковыми целиком. “Экономисты” выучили, когда начинается суббота по UTC. И когда заканчивается воскресенье.

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

Мне давно было любопытно разобраться, как в RTB (Real Time Bidding — аукционная закупка рекламы в реальном времени) устроена хайлоад часть. Задача выглядит сложной: от площадок идет поток запросов на покупку рекламы (бид-реквестов), на стороне рекламного движка есть каталог рекламных объектов (кампаний и баннеров в них) со своими таргетингами, и на каждый входящий запрос надо успеть найти подходящие объекты, посчитать ставку и ответить. На весь обмен с биржей дается порядка ста миллисекунд, и в них должно поместиться все сразу — сеть в обе стороны, разбор запроса, подбор объекта, расчет ставки, сборка ответа. То есть на сам подбор остается еще меньше времени.

А еще такая система должна быть подвижной в обе стороны по нагрузке. Трафик у поставщиков не постоянен, он гуляет и в течение суток, и от поставщика к поставщику, так что держать максимальный конфиг под пиковую нагрузку круглосуточно нет смысла. Значит нужна возможность добавлять и убирать мощности, понимая при этом, сколько пропускной способности дает каждая добавленная единица. Спроектировать такое — интересная инженерная работа. Ну это я, как продакт работающий в этой сфере, так считаю :-)

В каждой компании где я работал с рекламными движками (DSP – Demand Side Platform) были свои кастомные решения, свое легаси – не везде можно найти обоснование каждому решению, поэтому мне всегда было интересно, как это устроено у других. Так что я решил разобраться, какие вообще бывают решения — чтобы лучше понимать возможности и ограничения, с которыми имеют дело мои разработчики. Это важно, потому что от выбора хранилища напрямую зависит сколько трафика мы физически способны обработать не отъехав, и что случится (а точнее что мы можем быстро сделать), если завтра нужно будет попросить у поставщика (в рекламе он называется SSP - Supply Side Platform) вдвое больше.

В предыдущей статье я писал про [5 вещей, которые не следует делать в LibGDX].

Поэтому логично продолжить тему и поговорить о вещах, которые, наоборот, стоит использовать при разработке 2D-игры на LibGDX.

Сразу оговорюсь: это не статья про архитектуру, паттерны проектирования, ECS, оптимизацию кода или правильную организацию проекта.

Здесь всё гораздо проще.

Я хочу поговорить о нескольких технических инструментах, которые способны относительно небольшими усилиями заметно улучшить визуальное восприятие игры:

С помощью AI сегодня каждый может навайбкодить приложение за считанные часы. Но чтобы превратить его в рабочий PoC, нужно решить ряд архитектурных, инженерных и организационных задач. Именно они занимают гораздо больше времени и требуют уже других навыков.

В статье разберём типовую архитектуру современного AI PoC на примере моего пет-проекта и ответим на вопрос: если AI умеет писать код, зачем все еще нужен инженер?

В этой части нашего техно-триллера решил поговорить про календари, почту и адресные книги. Здесь, как и в мессенджерах, прямо сейчас активно разбивают Vendor Lock-in через стандартизацию открытых протоколов и антимономопольные суды. И одновременно, на наших глазах формируется новый узел вендор-лока, и стартует новая борьба, теперь за контекст для корпоративного ИИ. В 2026 году Big Tech начинает продавать бизнесу уже не просто почту и календари, а социальный и когнитивный граф, который мгновенно испаряется при любой попытке миграции. Сможет ли связка открытых протоколов JMAP + Matrix (MSC4496) обеспечить бизнесу владение собственным семантическим контекстом?

Стандартная статья это типо «я использовал ии и навайбкодил сайт за 2 дня»

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

Вот на тему стыка человек — ии я хотел бы и подумать.

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

Почему одинаковые данные могут давать разные p-value? На простом примере с монетой разбираю, как правило остановки меняет частотный вывод, а затем связываю это с подглядыванием в A/B-тесты и повторными проверками значимости. Заодно становится понятнее, что именно ломается при peeking и почему проблема не в самом просмотре данных, а в том, как промежуточные результаты влияют на решение остановить эксперимент.

Всем привет! Этой весной я искал работу, и в какой-то момент пришел к тому, что на сами отклики у меня уходит минут тридцать, а весь остальной вечер я трачу на то, чтобы просто обойти площадки и посмотреть, не появилось ли чего нового. То есть я не работу искал, я вкладки открывал.

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

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

Далее две части. Сначала про рынок и про то, что видно из базы, когда вакансии можно посчитать. Потом техническая кухня: что ломалось, что я чинил и какие места, по-моему, полезно знать заранее. Я разработчик, но парсинг, нормализация данных, Postgres, эмбеддинги и инфраструктура были для меня новыми, так что граблей набралось прилично.

И сразу заранее: все цифры ниже про мою базу, а не про рынок целиком. Спорить с ними можно и даже нужно :-)

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

Знать принцип 80/20 в такой ситуации недостаточно. Сложность начинается в тот момент, когда нужно применить его к реальной бизнес-задаче: определить, какие действия действительно сильнее других влияют на результат, сформулировать их конкретно и договориться, на чём стоит сосредоточиться.

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

В России 2026 года нейросетями пользуется каждый четвёртый житель — это примерно 35 миллионов человек, что выше среднемирового показателя. При этом 58% активных пользователей обращаются к ИИ минимум раз в неделю. Но вот парадокс: чем больше моделей появляется, тем сложнее выбрать «ту самую».

В 2026 появилось множество новых нейросетей и ИИ-моделей: GPT-5, Claude Fable, DeepSeek, GLM, Qwen, и интернет уже не ограничен исключительно ChatGPT от OpenAI. Некоторые из них уже создали фурор своими способностями и мощностью интеллекта, некоторые стали популярными за счёт интегрированности и доступности, третьи — за счёт бесплатности и безлимитного общения. Мы поговорим и о глобальных флагманах, и о менее известных нейросетях, и о российских нейросетях.

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

На разработку ушло 16 выходных дней и примерно 250$

Решил я значит разработать свое приложение, начитавшись материалов про ИИ и вайбкодинг, захотелось попробовать самому. Так как я являюсь UX/UI дизайнером, который занимается разработкой дизайна для приложений, я поставил себе несколько целей, которые должны были закрыться в процессе разработки аппы...

Однажды заказчик, которому я разворачивал офисную телефонию спросил меня: "А можно нашим сотрудникам поставить на телефоны SIP клиенты, чтобы их разговоры с клиентами проходили через офис, попадали в CRM и записывались?"

Мысль заказчика понятна: Почему бы просто не поставить софтфон на мобильник и не настроить его на свой сервер?

Но есть несколько причин, почему это работает откровенно плохо.

Я пытался сделать NPC более реалистичными. Получился местами несмешной анекдот, а местами — психологический триллер. Я издевался над NPC, они издевались надо мной. Я запрещал им «думать о белой обезьяне», они меня газлайтили и давили моралью. Если готовы к большому тексту — добро пожаловать.

Иногда мне нужно быстро проверить свой VPS: посмотреть нагрузку, глянуть логи или перезапустить сервис. Каждый раз открывать ноутбук и подключаться по SSH ради пары команд было неудобно, поэтому я решил сделать Telegram‑бота. Сначала думал, что всё будет довольно просто: Telegram → SSH → сервер. Но по ходу разработки выяснилось, что само SSH‑подключение — как раз самая простая часть. В статье расскажу, с какими проблемами я столкнулся и как в итоге их решил.

Возвращаюсь со своим еженедельным дайджестом для мобильных разработчиков. В этом выпуске адаптация приложений под iPhone Duo и Shared Transition как требования дизайнеров, прозрачный Яндекс.Навигатор и нативная разработка в Shopify, фронтенд без готового бэкенда, путь к Chaos As A Service, ошибка после оформления подписки, которая приводит к оттоку и многое другое. Заходите!

По всей территории Аппалачей и «Ржавого пояса» в США, в том числе в Питтсбурге, бывшие промышленные площадки превращаются в новые жилые районы, исследовательские центры и технологические кластеры. Однако на протяжении десятилетий в этих местах происходили и другие процессы преобразования.

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

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

Я микробиолог, и этой темой я заинтересовался благодаря браунфилду, который находится практически у меня на заднем дворе. Моя лаборатория в Университете Карнеги — Меллона расположена всего в 3 километрах от Hazelwood Green, бывшей промышленной территории площадью 72 гектара на берегу реки Мононгахила в Питтсбурге.

Более ста лет здесь находились сталелитейные предприятия, в том числе Jones & Laughlin Steel Co. На пике производства на этой площадке работали тысячи человек, и она внесла свой вклад в репутацию Питтсбурга как Стального города.

Промышленная история Питтсбурга оставила после себя и химическое наследие. Как и на многих других бывших промышленных территориях, почва Hazelwood Green была загрязнена нефтяными углеводородами, тяжёлыми металлами и другими веществами, из‑за чего территория была классифицирована как браунфилд. Среди загрязнителей присутствовали бензол, толуол, этилбензол и ксилол — группа соединений нефтяного происхождения, известная под общим названием BTEX. Эти вещества могут быть токсичными для человека и других организмов, а некоторые из них являются известными канцерогенами.

В прошлой статье я представил свою библиотеку для парсинга JSON. Краткое содержание - мы используем новые инструменты стандарта С++26 (в основном, рефлексию) для автоматической генерации оптимизированных парсеров для конкретных JSON, что позволило нам обогнать simdjson в несколько раз.

Здесь мы рассмотрим, как можно генерировать целевые структуры для объектов JSON напрямую из JSON схем при помощи других трюков из стандарта 26.

Это эссе я задумал сразу после выхода книги Элиезера Юдковского и Нейта Соареса «If Anyone Builds It, Everyone Dies». Потом книгу неожиданно перевели, и мне казалось, что пост уже потерял изрядную долю актуальности для русскоязычной аудитории.

За то время как переводили книгу LLM начали решать задачи Эрдёша. Затем вышла Mythos 5, из-за которой даже разразился политический скандал, но я всё равно считал, что пока мы находимся в состоянии, когда размышления о скором конце света представляют собой скорее развлечение, сродни чтению художественного романа. Потом наступило лето.

В июле рой агентов сам спланировал и провёл атаку на сервера Hugging Face, а вскоре начали появляться расследования о других диких сообществах LLM-агентов. Не успели толком разобраться, что именно произошло, как OpenAI заявила, что её агенты решили одну из задач тысячелетия, связанную с уравнениями Навье - Стокса. Я понял, что уже мне самому нужен этот текст - хотя бы как имитация разумной деятельности в тот момент, когда мир вот-вот опрокинется в бездну (или вершину) сингулярности.