Все потоки

Почему нельзя просто взять и сделать отечественный процессор побольше?

Разработчики “Герои 3” как-то поделились лором: события игры вообще-то происходят в далеком будущем, а вся эта магия и расы - просто забытые технологии.

Я сидел, ковырял на коленке умную лампу и вдруг поймал себя на мысли: для меня-то эта магия давно наступила. Как кусок крепко сплющенного песка управляет сетями, серверами и вообще нашей жизнью?

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

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

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

Размер кристалла нельзя раздувать просто так, тут сразу несколько причин.

Экономика и банальная пыль.

Блины на заводах не бывают идеально чистыми. Из одного блина выходит 500 мелких кристаллов, случайная пылинка запорет два-три. Брак копеечный. Но если резать огромные куски, их на блине поместится штук десять. Одна пылинка — минус 10% партии. А если их с десяток, весь блин летит в помойку. Себестоимость такого гиганта просто улетит в космос.

Синдром утюга.

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

Скорость света.

Тут мы тупо бьемся о фундаментальную физику. Чем больше кристалл, тем дольше сигнал идет от одного края до другого. В огромном процессоре ток просто не успеет пробежать это расстояние за один такт.

Ладно, если делать один кирпич бессмысленно, почему не воткнуть в материнку два обычных процессора?

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

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

Я подумал: блин, для наших процессоров это же идеальный путь!

А потом уткнулся в реальность. Чиплеты круто работают, когда ты можешь печатать их мелкими. А у нас заводы вроде “Микрона” уперлись в 65–90 нанометров. Тайваньская TSMC, которая печатала сложную мелочь, маршрут закрыла из-за санкций.

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

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

Дебаж 🐞с ноги 🦶

Клиент не платит: пошаговый алгоритм от претензии до суда

Продолжаем серию постов о договорах и финансах.

Что делать? Действуем по шагам. Холодная голова и чёткий план.

Профилактика - лучшее лекарство от долгов

Самый дешёвый способ вернуть деньги - не дать долгу возникнуть.

Способ оплаты - предоплата. Это правило на 100% избавит вас от неоплаты вашей работы.

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

Из рабочего опыта - гораздо больше компаний и ИП не платят по своим долгам.

До начала работы добавьте в договор или оферту:

⦁ Предоплату (аванс). Минимально 50-70% от суммы. Это отсекает несерьёзных клиентов и покрывает ваши базовые затраты.

⦁ Неустойку (пени) за каждый день просрочки (0,1–0,5% в день).

⦁ Штраф за отказ от подписания акта - если в течение 3-5 рабочих дней нет мотивированной претензии, работа считается принятой.

⦁ Подсудность по вашему адресу, чтобы бегать в суд не к клиенту, а рядом с домом/офисом.

Если вы работаете «на доверии» и без документов - первый шаг уже пропущен. Но не всё потеряно.

Дружеское напоминание (через 3-5 дней после просрочки)

Клиент мог просто забыть. Не сжигайте мосты. Позвоните и напишите в мессенджер (и заскриньте переписку):

- «Иван Иванович, обращаю внимание, что по договору №123 от [дата] наступил срок оплаты. Прошу оплатить до [дата]. Спасибо».

Цель: зафиксировать факт просрочки и дать шанс без конфликта.

Претензия - самый важный шаг

Без неё суд не примет иск (или оставит без движения). Для арбитражного суда соблюдение претензионного порядка обязательно (ч. 5 ст. 4 АПК РФ). Для суда общей юрисдикции - не всегда, но лучше перестраховаться.

Что указать в претензии:

⦁ Кто должник (ФИО, ИНН, адрес).

⦁ Основание долга (договор, акт, переписка).

⦁ Сумма основного долга и расчёт неустойки/процентов.

⦁ Срок добровольной оплаты (например, 10 дней).

⦁ Юридическое обоснование ваших требований.

Как отправить: по ЭДО или заказным письмом с уведомлением и дублировать на e-mail/мессенджер. Главное чтобы осталось доказательство отправки.

Что даёт претензия:

⦁ Иногда клиенты платят именно на этом этапе - видят, что вы настроены серьёзно.

⦁ Если не заплатят у вас есть доказательство соблюдения досудебного порядка.

Оцениваем ситуацию и перспективу судебного спора с помощью юриста

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

Упрощенное производство или судебный приказ - зависит от вида спора, размера исковых требований, бесспорности спора, подсудности.

Исковое производство (есть спор):

Подаёте иск в районный суд (если клиент - физлицо) или арбитражный суд (если клиент - юрлицо или ИП).

К иску обязательно приложить:

⦁ доказательства соблюдения претензионного порядка;

⦁ доказательства выполнения работы (акты, переписка, односторонний акт);

⦁ расчёт долга и неустойки.

После суда - приставы или банкротство

Получили исполнительный лист? Направляйте в ФССП или сразу в банк должника (если знаете, что счёт один и нем есть деньги).

Если должник - физлицо и вы знаете его место работы, то исполнительный лист можно направить работодателю.

Если у клиента ничего нет - есть процедура банкротства, но это уже тема отдельного поста.

Главный вывод

Суд - это не страшно. Страшно ждать, когда долг станет «просроченным по исковой давности» (3 года - и всё, деньги не вернуть никогда).

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

А теперь вопрос к вам: сталкивались ли с неоплатой? Как действовали? Получилось ли вернуть деньги? Делитесь опытом в комментариях 👇

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

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

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

Сейчас идёт набор в партнёрку, а уже 9 июня начнётся обучение. За несколько дней команда Хабра расскажет, как устроена аудитория площадки, какие рекламные решения работают под разные задачи и как подбирать форматы под запрос бренда.

В программе:

— разбор 10+ рекламных форматов Хабра;
— кейсы компаний из разных сегментов: «Норникель», «Самолёт», LaVivion, VIVO, «СМ-Клиника», «Гемотест», «Островок» и других;
— обучение по работе с брифом, аудиторией и подбором форматов;
— сертификат эксперта по Хабру для агентства и участников обучения.

После обучения агентство получает статус партнёра. А вместе с ним — возможность получать агентское вознаграждение от 10% до 30%, бесплатные блоги на Хабре, рост партнёрского уровня и доступ к совместным ивентам, обмену лидами и мероприятиям Хабра.

Подать заявку можно до 3 июня. Следующий набор — не раньше октября.

→ Оставить заявку на партнёрскую программу Хабра

Утечки данных в ритейле: онлайн-торговля вышла на первый план

Экспертно-аналитический центр InfoWatch опубликовал исследование «Утечки информации в сфере торговли, 2021-2025 гг.». В отчете специалисты ЭАЦ InfoWatch приводят статистику по инцидентам в мировом и российском ритейле за пять лет.

По итогам исследования:

• в мировой торговле зарегистрировано почти 5000 утечек данных, в России — 711 инцидентов;

• чаще всего утекают ПДн покупателей — более 11 млрд записей в мире и 610 млн в России;

• более половины инцидентов в России — это маркетплейсы и интернет-магазины.

Подробности на сайте InfoWatch.

РБПО по ГОСТ Р 56939—2024: вебинар №16 из 30 – Использование инструментов композиционного анализа

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.16. – "Использование инструментов композиционного анализа". На YouTube. Слайды.

Цели 16-го процесса по ГОСТ Р 56939—2024:

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

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

✔️ Alibaba добавила анализ видео в систему синхронного перевода Qwen3.5-LiveTranslate

Китайский техногигант представил мультимодальную модель синхронного перевода Qwen3.5-LiveTranslate на базе архитектуры Qwen3.5-Omni. Система понимает текст на 60 языках и генерирует речь на 29.

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

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

Демоверсия доступна на платформе Qwen Omni. Релиз API в облаке Alibaba Cloud ожидается в ближайшее время.

https://qwen.ai/blog?id=qwen3.5-livetranslate

«Моложе с каждым годом: Как дожить до 100 лет бодрым, здоровым и счастливым» Крис Кроули, Генри Лодж

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

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

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

Поэтому писать буду мягонько и осторожненько. Ничего не советуя и не настаивая. Если вам в данный момент тема здоровье не интересна – смело пропускайте. Перечитаете позже.

Итак, книга. Она прям классная книга – про то, как подготовиться к пенсионному возрасту. Рассматривается три аспекта – здоровье тела, здоровье мозга, отношения с людьми (как часть здоровья и тела, и мозга).

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

Мне книжка очень понравилась. Написана интересно, с юмором, множеством примеров. И главное – очень конкретная. И цель у книги и её материала вполне конкретная, и рекомендации – тоже.

С моими наблюдениями многое совпало. С опытом пока нет – рано ещё. Но примеров людей, которые с выходом на пенсию резко «сдают» - масса. Думаю, в вашем окружении – тоже. Мы видим результат и знаем, каков был процесс.

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

Из Книжного стека.

Linux, Docker, Kubernetes и мониторинг: 10 открытых уроков для системных администраторов

Системное администрирование давно не ограничивается «поднять сервер и настроить доступы». Сегодня инфраструктура живёт в контейнерах, кластерах, пайплайнах, распределённых системах и мониторинге, который должен подсказать о проблеме раньше, чем её заметят пользователи.

В этом посте делимся подборкой бесплатных уроков для тех, кто работает с Linux, инфраструктурой, контейнеризацией, Kubernetes, SRE‑практиками и безопасностью. На них можно познакомиться с преподавателями курсов, протестировать формат обучения и задать вопросы экспертам.

Если хотите закрыть базу по Linux и автоматизации

• 18 июня, 20:00. «Основы Bash: пишем простые скрипты для автоматизации в Linux».
  _{Для тех, кто хочет перестать делать рутинные операции руками и начать автоматизировать админские задачи через простые, понятные Bash‑скрипты.}

• 4 июня, 20:00. «Продвинутый Bash».
  _{Следующий шаг после базовых скриптов: больше контроля, аккуратнее работа с окружением, меньше хрупких одноразовых команд.}

• 22 июня, 20:00. «Память в Linux. Cache, swap, dirty pages».
  _{Практичная тема для тех, кто сталкивался с ситуацией «память вроде есть, но сервер ведёт себя странно».}

Для всех, кто хочет подтянуть основы Linux, рекомендуем подготовительный курс (сейчас всего за символические 10 руб)

Если работаете с контейнерами и Kubernetes

• 2 июня, 20:00. «Введение в Docker: контейнеризация приложений в Linux».
  _{Базовый вход в контейнеризацию: что происходит с приложением внутри контейнера, зачем нужен Docker и как он встраивается в повседневную инфраструктурную практику.}

• 28 мая, 20:00. «Безопасность K8s: основные концепции и частые проблемы».
  _{На уроке разберем базовые концепции безопасности K8s и ошибки, которые регулярно всплывают в реальных кластерах.}

• 18 июня, 20:00. «Kubernetes под прицелом: почему ваш кластер может взломать даже стажер и как этого избежать».
  _{Более прикладной взгляд на безопасность Kubernetes: где кластеры обычно оставляют открытыми, какие настройки создают риск и что стоит проверить в первую очередь.}

Если отвечаете за стабильность систем

• 1 июня, 20:00. «Мониторинг распределенных систем».
  _{На уроке поговорим о подходах к наблюдаемости распределённых систем и о том, как быстрее понимать, где именно началась деградация.}

• 16 июня, 20:00. «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе».
  _{Для тех, кто хочет перейти от тушения пожаров к управляемому процессу: как реагировать на инциденты, разбирать причины и снижать вероятность повторения сбоев.}

• 3 июня, 20:00. «Internal Developer Platform: self‑service‑инфраструктура за один вечер».
  _{Как организовать инфраструктуру так, чтобы разработчики могли получать нужные ресурсы быстрее, а инфраструктурная команда не превращалась в ручной сервис‑деск.}

Если зона ответственности включает защиту инфраструктуры

• 16 июня, 20:00. «IDS/IPS как часть эшелонированной защиты инфраструктуры».
  _{На уроке разберем, как такие системы вписываются в инфраструктурную безопасность и где от них действительно есть польза.}

Больше открытых уроков по ИТ-инфраструктуре, разработке и не только смотрите в календаре открытых уроков OTUS.

ROI по внедрению AI

Как понять, что AI вообще сработает в вашем кейсе, в вашем бизнесе? Нужно считать ROI (Return on Investment) до начала внедрения.

Например, есть задача, которая занимает ~4 часа у сотрудника, сотрудник получает ~100 000 руб., его 4 часа стоят ~2500 руб. 

Сотрудник делает задачу раз в неделю. Расход ~10 000 руб. в месяц или ~120 000 руб. в год на эту задачу.

Чтобы автоматизировать эту задачу, например, надо 20 часов AI Dev средней стоимостью 3000 руб. в час. ~60 000 руб. 

Тут, если вы опытный руководитель ИТ, то надо умножить этот прогноз на число Pi, тогда будет 180 000 руб.

Получается, вы вкладываете 180k и получаете 120k, ~66% доходности. Не самая высокая, но приемлемая величина, если таких задач будет много, то вы преуспеете.

Больше по теме тут.

Продакт-менеджмент в 2026 году: почему рынку уже недостаточно «человека с идеями»

20 мая в Центре «Пуск» МФТИ прошла открытая встреча «Карьера в управлении продуктами в 2026-м: что важно знать».

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

Что еще обсуждали на встрече:

— Продакт-менеджер сегодня может работать в разных ролях. Технический продакт говорит с разработкой на одном языке и понимает архитектуру продукта. Индустриальный продакт опирается на экспертизу в конкретной сфере — например, в медицине, образовании, финтехе, логистике или B2B. Менеджер продукта по росту (Growth PM) работает с воронкой, метриками и экспериментами.

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

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

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

Сегодня продолжим этот разговор на Дне открытых дверей онлайн-магистратуры МФТИ «Управление ИТ-продуктами».

На эфире выступят академический директор программы Елена Тупикова и выпускники магистратуры — Екатерина Киселева и Дмитрий Пелик. Обсудим, как устроена программа, какие навыки развивают студенты, как проходят проекты с индустриальными партнерами и как поступить в 2026 году.

Когда: 21 мая, 18:00 по Мск. Где: онлайн. Регистрация: https://t.me/mipt_events_bot?start=c1777546389600-ds

Запись будет доступна тем, кто зарегистрировался.

ROI по внедрению AI

Как понять, что AI вообще сработает в вашем кейсе, в вашем бизнесе? Нужно считать ROI (Return on Investment) до начала внедрения.

Например, есть задача, которая занимает ~4 часа у сотрудника, сотрудник получает ~100 000 руб., его 4 часа стоят ~2500 руб. 

Сотрудник делает задачу раз в неделю. Расход ~10 000 руб. в месяц или ~120 000 руб. в год на эту задачу.

Чтобы автоматизировать эту задачу, например, надо 20 часов AI Dev средней стоимостью 3000 руб. в час. ~60 000 руб. 

Тут, если вы опытный руководитель ИТ, то надо умножить этот прогноз на число Pi 🙂 тогда будет 180 000 руб.

Получается, вы вкладываете 180k и получаете 120k, ~66% доходности. Не самая высокая, но приемлемая величина, если таких задач будет много, то вы преуспеете.

Больше по теме тут.

7 историй про профессиональный путь в IT 

Собрали истории студентов и экспертов Практикума: о том, как они меняли профессию, пробивались в бигтех, учились после работы и проваливали (а затем успешно проходили) собеседования. Полезно всем, кто в начале своего профессионального пути или только рассматривает переход в IT.

1. От джуна до тимлида за 5 лет — история роста и секреты продуктивности

Автор: Денис, тимлид в компании MedControl и старший код-ревьюер в Практикуме.

Он рассказывает, как развивался в разработке, перековал себя из программиста в руководителя и выстроил рутину, чтобы всё успевать. Сменить профессию Денис решил в 36 лет, поэтому статья может быть интересна тем, кто думает начать новую карьерную главу в зрелом возрасте. 

2. Как я пришёл в аналитику, устроился в бигтех и понял, что только на рабочих задачах у меня не получится расти

Автор: Сергей, аналитик данных в Озоне и студент онлайн-магистратуры НИЯУ МИФИ и Практикума на программе «Специалист по работе с данными и ИИ».

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

3. «Приходила уставшая, ставила таймер на два часа и училась»: как я стала DevOps-инженером

Автор: Настя, DevOps-инженер и выпускница курса «DevOps для эксплуатации и разработки». 

До того, как стать DevOps-инженером, она работала системным администратором, а ещё немного раньше — училась в IT-вузе. В статье она рассказывает, как прошла этот путь, что именно изучала и с какими сложностями встретилась.

4. Путь айтишника: как преодолевать все изменения на рынке и оставаться востребованным

Автор: Алексей, разработчик и предприниматель с 25-летним опытом в IT, программный директор и ведущий эксперт направления веб-разработки в Практикуме. 

В этом материале он рассказывает об уроках, которые извлёк на своём долгом пути, и делится советами, которые могут пригодиться новичкам.

5. Из актрисы в бизнес-аналитика: как я выбирала новую профессию, училась и искала работу 

Автор: Лена, бизнес-аналитик в телеком-компании, выпускница курса по бизнес-анализу в Яндекс Практикуме, а в прошлом — актриса и преподавательница английского.

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

6. Не бойтесь, просто ходите: как пройти первые собеседования, если ты QA-инженер без опыта

Автор: Кристина, QA-инженер в госкомпании и экс-ревьюер курса «Инженер по тестированию» в Практикуме. 

За все время в профессии она прошла 10 собеседований, по итогам которых получила 3 офера. В этом материале Кристина рассказывает, к чему готовиться и почему главная задача новичка — не выучить ответы, а победить волнение. 

7. Много спрашиваю и откладываю встречи на последний момент: мой опыт прохождения собеседований

Автор: Ярослав, бэкенд-разработчик в компании «Синимекс» и ревьюер на курсе «Java-разработчик» в Практикуме. 

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

ИИ не должен управлять исполнением. Заметки о детерминированном FSM-рантайме для агентов

Большинство рантаймов для ИИ-агентов сейчас работают по одному простому паттерну: LLM -> вызов инструмента -> рантайм выполняет сайд-эффект.

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

В процессе подготовки части наших внутренних агентов к деплою, мы пришли к необходимости полностью разделить процессы «рассуждения» (reasoning) и право на исполнение (execution authority).

Мы написали nano-vm — детерминированный FSM-рантайм (конечный автомат), в котором:

• модель лишь предлагает действия;

• рантайм жестко контролирует переходы состояний и сайд-эффекты.

Рантайм принудительно обеспечивает:

• конечные графы исполнения;

• строгий порядок шагов, зафиксированный при компиляции (compile-time ordering);

• capability-gating для инструментов (жестко изолированные доступы);

• границы идемпотентности и защиту от replay-атак;

• append-only историю аудита.

Одно из архитектурных решений, которое оказалось критически важным: слой политик намеренно сделан менее выразительным, чем Python.

Мы полностью отказались от eval-подобного исполнения и ограничили политики небольшим детерминированным подмножеством AST:

• только простые операторы;

• никаких циклов;

• никаких системных вызовов.

Это ограничение радикально упростило аудит и исключило целые классы рантайм-поведения, которые мы не хотели видеть в финансовых воркфлоу.

Sabotage Mode и семантика отказов

Чтобы протестировать семантику отказов, мы добавили в демо-стенд «Sabotage Mode» с несколькими векторами атак:

• неавторизованная инъекция инструментов (tool injection);

• попытки повторного выполнения (replay-атаки);

• подделка хешей (hash corruption);

• пропуск шагов пайплайна (skipped transitions).

С точки зрения эксплуатации самым полезным свойством пока оказались именно детерминированные границы повторного воспроизведения вокруг сайд-эффектов.

Нам также пришлось решать крайне неудобную compliance-проблему: как сохранить неизменяемые цепочки аудита (immutable audit chains) и при этом выполнить требования 152-ФЗ / GDPR об уничтожении данных. Наш текущий подход заменяет ссылки в хранилище на маркеры-надгробия (tombstones), полностью сохраняя криптографическую непрерывность хешей и ссылочную целостность графа.

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

• Core runtime: github.com/Ale007XD/nano_vm

• MCP layer: github.com/Ale007XD/nano-vm-mcp

• Live Sabotage Demo: demo.bannerbot.ru:8843

В Японии появились киоски с роботами-парикмахерами, которые с помощью 3D-сканирования анализирует форму головы, качество волос и выбирают стиль, который подходит клиенту. Робот использует машинку и удаляет волосы с точностью до миллиметра, а стрижка стоит 60 йен за сеанс (около 30 рублей).

Открытый проект ai engineering from scratch (онлайн версия) позволяет получить навыки базового разработчика нейросетей с полным набором необходимых знаний и навыков:

• более 400 уроков: от математики до архитектуры нейросетей, их создания, обучения, настройки, написания промптов и еще кучи всего.

• вся теория интерактивна, много примеров кода.

• в курсах десятки практических задач, чтобы закрепить навыки.

OpenAI показала редкий для ИИ результат: внутренняя модель самостоятельно нашла контрпример к известной задаче из дискретной геометрии, которую Пал Эрдёш сформулировал ещё в 1946 году.

Суть задачи простая: есть n точек на плоскости. Нужно понять, сколько пар точек могут находиться ровно на расстоянии 1 друг от друга.

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

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

 Модель связала задачу о точках на плоскости с алгебраической теорией чисел. 

В доказательстве используются решётки Минковского (способ превратить числа из алгебраической теории чисел в точки в обычном евклидовом пространстве), элементы нормы один и pro-3 башни числовых полей. Это инструменты из другой части математики, и именно их перенос в геометрию дал результат.

Нога Алон из Принстона отметил, что ответ оказался неожиданным, а применённые методы выглядят элегантно и нетривиально. 

При этом доказательство не даёт нового «чисто геометрического» метода, на который многие надеялись. Гипотеза опровергнута, но сама структура задачи стала ещё интереснее.

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

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

Оригинал: https://openai.com/index/model-disproves-discrete-geometry-conjecture/

В субботу 23 мая лабораторная — Docker для системных аналитиков! 🐳📊

Присоединиться и получить виртуальную машину со всеми настройками можно через Boosty! 🚀 Скидка для тех, кто хочет попробовать! 💸

Boosty - https://boosty.to/polnyistek

Подробнее - https://debugskills.ru/articles/labs/docker-basics/ 📖✨

«У меня всё хорошо»

Более всего изменениям мешает убеждение «у меня всё хорошо».

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

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

Кому охота возиться с преодолением сопротивления? Или близким родственникам, которым очень не всё равно, или приставучему начальнику, который очень хочет наносить людям пользу. Но и эти сдаются, рано или поздно.

«У меня всё хорошо» побеждает. И появляется вторая, зеркальная часть убеждения – человек сам начинает в него верить. Убедил остальных, убедил себя. Ну, почти убедил.

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

Если раньше отпор был конкретному советчику, то теперь – просто информации (из интернета, книг, этого текста и т.д.). Оппонента нет, и человек выдумывает его себе сам. Спорит в голове с автором информации, зачастую даже неизвестным.

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

Из Математики воли.

Если начальство пристаёт и требует BI-систему, а в наличии только 1С и нет бюджета - можно взять бесплатное расширение "Рабочий стол" и нарисовать диаграммы в нём.

Видео - https://vkvideo.ru/video-208482299_456239497?list=ln-BKsiW5Xfu9tyPmSipy

Расширение здесь - https://t.me/another1C/48

GitOps без романтики: эксплуатация, советы, решения

Есть подходы, которые в докладах на конференциях звучат как откровение. Git — единственный источник правды, всё декларативно, прод руками не трогаем, система сама себя лечит. А потом наступает понедельник, и выясняется, что кто-то всё-таки поправил что-то руками, конфиг задрейфовал, а rollback работает ровно до того момента, пока не нужен по-настоящему.

В новом выпуске «В SREду на кухне» поговорили о GitOps без хайпа — с Михаилом Кожемским, Lead DevOps в Банк 131, и Павлом Селивановым, руководителем продуктового направления DevTools в Яндекс Клауд.

Что на повестке

Разбираем, чем push-модель отличается от pull и почему выбор между ними — это не вкусовщина, как Argo CD и Flux ведут себя в реальной жизни, а не в туториалах, и почему иллюзия «Git = реальность» — одна из самых дорогостоящих в инфраструктуре. Отдельно — про конфигурационный drift, Terraform и Crossplane, и что GitOps до сих пор так и не научился решать.

Если вы уже внедрили GitOps и думаете «что-то пошло не так» — или только собираетесь и хотите знать, что именно пойдёт не так — этот выпуск для вас.

Смотрите видео на площадках:

🔵 VK Видео 
📺 YouTube
📌 RuTube
Ⓜ️ Mave