Дайджест Новостей

20 сентября в International Journal of Equine Science вышла работа британских учёных из Хартпери и Портсмута: 21 опытная наездница проехала шагом, учебной рысью и галопом на механическом тренажёре-лошади, а затем пробежала по дорожке — в четырёх вариантах белья (обычный на косточках, спортивный «для езды» с раздельными чашками, комбинированный беговой и вовсе без белья). Восемь инфракрасных камер снимали движение груди относительно корпуса (а не абсолютное, иначе измерялась бы качка лошади, а не работа бюстгальтера) и заодно симметрию посадки. Это первая работа, где грудь наездниц измерили в 3D и сравнили с их же бегом. Ключевые числа: без поддержки вертикальный ход груди при беге — 5,6 см, на любом аллюре примерно вдвое меньше (шаг 2,3, рысь 2,5, галоп 2,2). Беговая модель на дорожке снизила вертикальный ход на 62%, на рыси на 29%, на галопе лишь на 8,5% (в пределах разброса); модель «для езды» на галопе по вертикали не дала ничего. Зато по боковой оси картина переворачивается: на галопе боковое смещение 1,76 см, и «ехательная» модель срезала его на 40%, а беговая только на 16%. Вывод: беговое бельё оптимизировано под одно вертикальное колебание, а в седле нагрузка разложена по трём осям, поэтому «меньше прыгает» и «ровнее сидится» — не одно и то же. По осанке оба спортивных бюстгальтера держали корпус прямее, тогда как обычный на косточках не отличался от полного отсутствия белья; самая симметричная посадка чаще выходила в модели для езды. Анкеты: три четверти ездят в спортивном белье, почти половина иногда чувствует боль в груди, обычный бюстгальтер не выбрал никто. Автор (подборщица белья с 2019 года) даёт содержательную критику методики: заявленная корреляция боли и смещения (Спирмен 0,428, значимость лучше 0,001) при 19 степенях свободы на деле даёт p около 0,053, то есть на грани; заявленная значимость получается только если считать наблюдением каждую пару «участница–бельё–режим» (336 замеров), но такие замеры не независимы и завышают значимость. Даже в щедром прочтении смещение объясняет меньше пятой части различий в боли. Ограничения: маленькая выборка, женщин с чашкой D и больше всего восемь, тренажёр вместо живой лошади, по одной модели на тип белья, все подобраны специалистом, проценты считаны от медиан. Открытые вопросы — как должна выглядеть конструкция бюстгальтера под трёхосную нагрузку и можно ли заменить лабораторные камеры парой инерциальных датчиков на живой лошади. Материал добросовестный, не рекламный, с самостоятельным пересчётом статистики, но тема узкая, к IT, политэкономии и остросоциальной повестке не относится — это популярная биомеханика и потребительский обзор нишевого товара.

Статья представляет собой конспект по низкоуровневой архитектуре x86: как процессор выполняет примитивные логические операции и инструкции, что такое машинное слово, шины данных и адреса, почему битность шины связана с режимом работы. Далее разбираются три основных режима. Real mode — 16-битные регистры и машинные слова, но 20-битная адресация через сегментацию, доступ к BIOS через прерывания, проблема A20 и её включение через порт 0x92. Protected mode — 32-битный режим, линейная адресация до 4 ГБ, защитная сегментация через селекторы и дескрипторы, обязательная GDT, появление paging с таблицами страниц. Long mode — 64-битный режим, сегментация почти не используется, кроме FS и GS для TLS, paging обязателен, адресация виртуальная, канонические адреса, разделение пользовательского и ядерного пространства, четырёхуровневая и потенциально пятии шестиуровневая страничная адресация. В конце перечислены условия переходов между режимами: GDT и бит PE в CR0, затем paging, CR3, PAE, LME и far jump. Материал полезен в первую очередь новичкам в OSDev и системном программировании, но это не новость, не прорыв и не общественно-политическая тема. Рекламы нет. Статья актуальна как вечнозелёное объяснение основ x86, однако многие вещи сильно упрощены, местами есть огрехи форматирования и пропущенные формулы, а автор сам признаёт, что находится в начале пути и статья может быть «дырявой». Для широкого читателя ценность невысокая, для узкой аудитории — умеренно полезная.

Hinterland Games анонсировала дополнение Iron Road для режима выживания The Long Dark. Игроков отправят на остров Котёл, которого давно нет на картах. Главная механика — старый поезд, простоявший около века: его нужно восстановить, чтобы проехать более 100 километров по вулканической кальдере. По словам разработчиков, местная история заметно изменит привычное выживание. Идея железной дороги возникла при работе над пятым эпизодом сюжетной кампании, поезд понравился авторам и игрокам, поэтому под него сделали отдельное DLC. Выпускать контент частями не будут: после консультаций с Valve студия решила сразу запустить Iron Road в раннем доступе. Релиз — 27 октября 2026 года, полноценный трейлер и детали механик покажут перед самым выходом.

VK объявил новый JT Mobile Meetup. Он пройдёт офлайн в двух городах: 31 октября в Москве и 14 ноября в Санкт-Петербурге. В Москве будет два параллельных трека — iOS и Android, в Санкт-Петербурге один общий. Выступят разработчики из ВКонтакте, Дзена, MAX, VK Tech и других команд VK. В программе iOS: импакт-анализ UI-тестов, снапшот-тестирование в дизайн-системе, поиск визуальных регрессий и ИИ в тестах. В программе Android: достижение 120 FPS в сложных списках, анализ отклонений A/B-метрик через Tracer и ИИ, проектирование прерываемых систем и безопасная отмена цепочек операций, доставка изменений на Kotlin за несколько часов без нового релиза приложения. После докладов обещают интерактивы и афтепати. Участие только офлайн, нужна регистрация. Для мобильных разработчиков в Москве и Санкт-Петербурге новость практически полезна, для широкой IT-аудитории это в основном анонс мероприятия без содержательных деталей.

Автор — пользователь с личной системой питания (метаболическая тарелка по Обложко, нормы: до 1000 ккал, белок 78 г, жиры 30–37 г, углеводы от 70 г, клетчатка от 25 г) — рассказывает, как подключила официальный MCP-сервер ВкусВилла к Claude и автоматизировала сбор недельной корзины. До этого заказ продуктов занимал 30–40 минут, потому что фильтра по КБЖУ в магазинах нет и приходилось читать карточки вручную. Из российских продуктовых официальный MCP с КБЖУ и корзиной есть только у ВкусВилла; у Лавки — неофициальный через веб-API, у маркетплейсов — только сравнение цен. Техническая суть: сервер mcp.vkusvill.ru умеет поиск по каталогу, карточку товара, аналоги, скидки, рецепты, магазины и создание ссылки на корзину (до 30 позиций). Личные инструменты (история заказов, персональные скидки, «Любимый продукт») требуют OAuth 2.0 с PKCE; вход через /mcp не работает из-за offline_access, поэтому токен получают отдельным скриптом с PKCE, а Claude Code подключается через headersHelper. Автор честно перечисляет ограничения: 10 товаров на страницу, пустой запрос не принимается, лимит 60 запросов в минуту (заголовки X-RateLimit), Qrator блокирует Python по User-Agent (помогает маскировка под curl), иногда «Ошибка создания ссылки» требует повторов с паузой. Через HTTP-обход собрала 7 222 уникальных товара, из них 2 005 до 150 ккал, но у 1 202 нет КБЖУ (включая многие овощи и фрукты). КБЖУ одного и того же товара у разных производителей различается в 2–3 раза — правило брать товары с узким разбросом. Ключевая находка: ручная подгонка дня под 5 норм КБЖУ не сходится, поэтому Claude переводит задачу в линейное программирование (scipy.optimize.linprog, метод HiGHS) с ограничениями по калориям, белку, жирам, клетчатке и углеводам и узкими границами граммовки (30–180% от исходной). Итог — 8 корзин от ≈5 370 ₽ до ≈9 850 ₽ в неделю, каждая укладывается в нормы; в финальной версии — 4 корзины по способам готовки (духовка, мультиварка, рыба, котлеты), готовит два вечера в неделю. Есть артефакт-отчёт и готовый промпт для копирования. Отмечает, что персональные скидки дают мало эффекта, а цены — каталог на 13 октября 2026. Оценка: не реклама (личный проект, не от ВкусВилла), максимально свежие данные, редкий практический разбор реального бытового применения MCP с кодом, скриптами обхода и честным перечислением грабель; при этом тема узкобытовая, без полит-экономического и остросоциального контекста, и часть трюков (обход Qrator, ручной OAuth) скорее для энтузиастов.

Статья — практическое руководство по усилению локальной безопасности на macOS с помощью Touch ID и Secure Enclave, без потери удобства. Автор исходит из типичной проблемы: разработчики отключают пароль на sudo, держат SSH-ключи незашифрованными и секреты открытым текстом в ~/.zshrc, потому что не хотят постоянно вводить пароли. Предлагается три решения. Первое — sudo через Touch ID. Начиная с macOS 14 Sonoma в системе есть шаблон /etc/pam.d/sudo_local.template; достаточно скопировать его в /etc/pam.d/sudo_local и раскомментировать строку auth sufficient pam_tid.so. Таймаут авторизации настраивается через Defaults timestamp_timeout=0 в visudo. Внутри tmux/screen Touch ID не сработает, так как процесс-демон не привязан к GUI-сессии; лечится установкой pam-reattach из brew и добавлением его строкой выше pam_tid.so. Второе — SSH-ключи в Secure Enclave. С macOS 26 Tahoe это поддерживается нативно: ключ создаётся командой sc_auth create-ctk-identity -l user@server -k p-256-ne -t bio, публичная часть выгружается через ssh-keygen -w /usr/lib/ssh-keychain.dylib -K -N "" или добавляется в ssh-agent через ssh-add -K -S. Файл id_ecdsa_sk_rk приватным ключом не является — это лишь ссылка на аппаратный ключ, скопировать и перенести его нельзя ни для бэкапа, поэтому нужен запасной доступ к серверам. Поле «Valid To» относится к автогенерируемому X.509-сертификату и для SSH неважно. Сервер должен поддерживать OpenSSH 8.2+ и алгоритм sk-ecdsa-sha2-nistp256@openssh.com (проверяется через ssh -Q key и sshd -T). Для старых macOS предложены Axo Pass и Secretive. Третье — секреты в переменных окружения. Вместо открытого текста в ~/.zshrc используется подход 1Password CLI: файл .env хранит ссылки вида op://Vault/Item/field, а запуск идёт через op run --env-file=.env -- myapp. Автор нашёл менее известную альтернативу envrcctl (Python), хранящую секреты в Keychain: envrcctl secret set, запуск через envrcctl exec -- команда, экспорт в shell через eval "$(envrcctl inject --shell)" (обёртка senv), интеграция с direnv через envrcctl init --inject и direnv allow — тогда секреты подгружаются автоматически при входе в папку с запросом Touch ID. Честно отмечено, что экспорт секретов в текущий shell менее безопасен, чем запуск через exec. Вывод автора: каждое из трёх решений внедряется за 5–10 минут, использует штатные средства macOS и пару утилит из brew; sudo больше не срабатывает молча, приватный SSH-ключ физически нельзя украсть, а .zshrc чист от секретов. Это не абсолютная защита, но заметный шаг вперёд малой ценой. Слабые места: материал сугубо прикладной и macOS-специфичный, часть приёмов (pam_tid) широко известна, есть элементы продвижения конкретных утилит (envrcctl, brew-пакеты) — но это не прямая реклама платных услуг. Прорывных или общественно-политических тем нет, зато практическая ценность и актуальность для разработчиков на macOS высокие.

Статья — третья часть цикла о том, как пережить крупную облачную аварию, не потеряв безопасность. Основная мысль: во время сбоя нельзя просто отключить защиту ради скорости — её нужно перевести в заранее подготовленный аварийный режим с короткими процедурами, но чёткими границами, ответственными и сроками. Ключевые тезисы. Во время аварии меняется модель угроз: одновременно исчезают привычные доказательства доверия (SSO, Vault, CI/CD, журналы), поэтому старую среду нельзя считать доверенной автоматически, а инцидент надо рассматривать по двум сценариям — технический отказ или компрометация. Для каждого решения автор предлагает пять вопросов: кто запросил, минимально нужный доступ, где останется след, когда доступ истечёт, что проверить после восстановления. Разобраны конкретные ситуации. При падении внутреннего мессенджера нужен заранее выбранный внешний канал связи с MFA, подтверждённым списком участников и запретом на секреты (дана сравнительная таблица вариантов — от подготовленного чата до публичной страницы статуса). При отказе Vault — это циклическая зависимость, когда ключи нельзя достать из умершей инфраструктуры; нужны аварийный контур хранения секретов вне основного облака, разделение полномочий (два человека), краткоживущие реквизиты, независимый аудит; запрещено слать пароли в общий чат, почту, репозиторий. При отказе SSO/IAM — именованные аварийные учётные записи с независимым вторым фактором и оповещением о входе. При падении GitLab — сборка на ноутбуке допустима, но только в чистом окружении по принципу двух человек, с фиксацией коммита, зависимостей, подписью артефакта и последующей штатной пересборкой. При потере журналов и SIEM — локальная очередь плюс независимый внешний приёмник ключевых событий. При потере VPN — временный бастион с ограничением по IP, ключами, сроком жизни и записью сеансов, а не открытый всему миру SSH. Отдельно даны обязательные AppSec-проверки перед переключением трафика (разбиты на блокирующие, допустимые временно и пост-запусковые), реестр временных исключений с крайними сроками, план подготовки до инцидента, действий в первые часы и после стабилизации, а также таблица распределения ответственности между DevOps, AppSec, ИБ, разработкой, юристами и руководством. Вывод: устойчивость и безопасность нельзя проектировать отдельно — зрелый DevSecOps сохраняет обе за счёт независимых каналов, минимальных прав, короткоживущих доступов, журналирования и учений. Ссылки на NIST SP 800-61, OWASP (секреты, журналирование, CI/CD) и HashiCorp Vault. Материал практичный и насыщенный, без явной рекламы конкретных услуг (Vault упомянут как пример технологии, а не как продаваемый продукт), опирается на авторитетные источники. Не новость и не прорыв, но ценное методическое руководство по DevSecOps-реагированию; актуально для SRE/DevOps/ИБ.

Автор увлёкся калькуляторами Casio после того, как наткнулся на эмулятор карманного компьютера с BASIC и портом RS232: за восемь недель от полного равнодушия к калькуляторам он перешёл к покупке двух реальных устройств из Японии, написанию четырёх программ (часть уже на GitHub) и генерации фанарта при помощи ИИ. Переломный момент — осознание, что RS232 плюс BASIC открывают дорогу к его второму хобби, любительской радиосвязи: так появились альфа-версия программы журнала радиосеансов Jamoncito FX и заготовка CW-передатчика. Купленный Casio VX-4 пришёл в идеальном состоянии, с документацией, 32-килобайтным модулем расширения ОЗУ и кабелем FTDI RS232 на 2,5 мм; второй калькулятор Z-1GR оказался полностью нерабочим (помечен как junk, есть планы по восстановлению через внешнее питание и замену поляризационной плёнки ЖК). Главный проект — настоящая telnet-BBS, размещённая на калькуляторе с 8 КБ ОЗУ (специально ориентировались на базовую версию, чтобы работало на любых VX-4; FX-870P с 64 КБ решили не поддерживать). Калькулятор остаётся хостом на 100%, а Raspberry Pi Zero W выполняет только роль сетевого моста и архиватора сообщений в txt, чтобы разгружать ОЗУ и защищаться от спама. Подключение ограничено одним одновременным пользователем и скоростью 4800 бод (9600 возможны, но менее стабильны), сообщения — до 60 символов. BBS просит у звонящего радиолюбительский позывной, имеет меню из четырёх пунктов, страницу About, статус выводится на OLED HAT, безопасность обеспечивается Tailscale с туннелированием. Демо proof of concept снято: подключение по telnet через мобильную сеть 5G, чтение и отправка сообщений, выход. Планы — публикация альфы на GitHub, возможный перенос с BASIC на C, расширение функциональности в пределах 8 КБ и защита от выгорания ЖК-дисплея скринсейвером. Автор признаёт, что найдутся критики, считающие такую BBS «ненастоящей» из-за моста на Pi Zero W, и подчёркивает, что делает всё ради обучения и удовольствия.

Ubisoft начала набор на закрытое тестирование ремейка Heroes of Might and Magic III. Заявки принимаются на официальном сайте издателя, нужна учетная запись Ubisoft. Тестирование пройдет в четыре этапа: сначала оценка обновленной графики и настраиваемого интерфейса, затем проверка геймплейных механик и игровых режимов, в финале — редактор карт, поддержка модов и сетевой мультиплеер. Точной даты релиза нет, ориентир — 2027 год. Страница в Steam уже открыта, можно добавить в список желаемого.

Разработчик разобрал, почему фирменная подсветка док-станции Flydigi Charging Dock 2 Pro выглядит дёшево, и написал открытую альтернативу FlyGlow. Ключевой вывод: виноват софт, а не железо — сам док лишь проигрывает заранее присланные кадры и не генерирует эффекты. В фирменной Space Station генераторы эффектов крутят всего 50 кадров на цикл (на медленных скоростях кадр держится 100+ мс — получается слайд-шоу), цвета смешивают линейно в гамма-кодированном sRGB (середина перехода грязнеет), радугу строят через HSL с неравномерными для глаза полосами, а затухание считают по 8-битным значениям с округлением вниз, отчего «дыхание» гаснет рывками. Автор разобрал протокол дока (HID, VID 37D7/PID 6001, 162 светодиода в 16 рядах, до 255 кадров, период кратно 20 мс, максимум 50 к/с, пакеты по 50 байт с подтверждением, свой формат заголовка и контрольной суммы), отметил задержку ~85 мс на кадр и ошибку на единицу в подсчёте пакетов у Space Station, а также что память кадров не очищается и остатки старой анимации замешиваются в мусор. В FlyGlow всё считают в линейном свете, а градиенты и затухание интерполируют в OKLab (с затуханием по воспринимаемой яркости через куб), радугу строят по равным расстояниям в OKLab, применяют временной дизеринг для плавности в тенях и бесшовные циклы через фазу [0,1) и четырёхмерный зацикленный шум, с автотестом на 21 эффект. Отдельно описано, как обойти занятый канал фоновой службы Space Station, открыв HID совместно (FILE_SHARE_READ/WRITE) и фильтруя чужие подтверждения, а также редактор на C++20/Qt 6 со слоями, кистью по шестиугольной сетке, ключевыми кадрами, импортом GIF и видео через Media Foundation с усреднением ячеек по 19 точкам. В планах — подсветка геймпадов, возможный живой режим через неиспользуемую команду записи кадра и интеграция с OpenRGB; код под MIT. Материал не рекламный, технически глубокий, с реальным реверс-инжинирингом и полезными приёмами, но тема узкая и нишевая — для владельцев конкретной периферии и любителей DIY-подсветки.

Статья — вторая часть практического руководства по аварийной миграции сервисов из отказавшей зоны одного облака в другое; она не про рекламу, а про реальный порядок действий под давлением. Первая часть делила отказы на уровни VM/зоны/провайдера и назначала RPO/RTO, теперь речь о самом переезде. Главные тезисы: до любых изменений нужен единый журнал инцидента с руководителем работ, где фиксируются факты, гипотезы, решения, ответственные и последние успешные бэкапы; чат для этого не годится. Сначала останавливают рост ущерба — критично не допустить двух независимо изменяющихся копий одного сервиса: переводят источник в read-only или режим обслуживания, фиксируют позицию в журнале транзакций, делают свежий бэкап средствами приложения, выносят его за пределы аварийной зоны, считают размер и контрольную сумму, запрещают автозадачи, способные менять обе стороны. Если источник недоступен, явно фиксируют фактический RPO. Старую площадку нельзя удалять после первого успешного запуска: там могут быть единственные копии свежих файлов, конфигураций вне Git, SSH- и шифровальных ключей, локального слоя образа, журналов. Правильный порядок — остановить, запретить запись, пометить, снять снимок, ограничить доступ и удалить только после формального подтверждения. Выбор нового провайдера предлагается делать по проверяемым возможностям, а не по цене CPU/RAM: покрытие ресурсов через Terraform и API (сети, маршруты, балансировщики, IP, объектное хранилище, IAM, DNS, снимки, импорт существующих ресурсов, изменение без пересоздания), квоты и фактическая физическая ёмкость (квота не гарантирует, что VM запустится), импорт OVA/OVF с проверкой форматов, UEFI/BIOS, контроллера дисков, версии виртуального оборудования, выдачи ID образа через API, совместимость S3 (путь против virtual-host, multipart, versioning, Object Lock, lifecycle, шифрование, контрольные суммы, стоимость исходящего трафика, отдельные write-only креды для бэкапов), скорость реакции поддержки на нестандартные запросы и модель биллинга, которая может не дать ресурсам стартовать. Приведена таблица критериев DR с «красными флагами». Для каждого сервиса выбирается свой способ переноса: пересоздание из IaC и GitOps — для сетей, stateless-приложений, Kubernetes, CI/CD, мониторинга; штатный бэкап средствами приложения — для PostgreSQL, GitLab, Vault и прочих хранящих состояние систем; репликация с плановым переключением — для критичных БД, если обе площадки живы; снимок диска — для однородных платформ; импорт OVA — для NGFW и готовых виртуальных систем, с переносом техдолга. Дана сравнительная таблица способов по переносимости, скорости и рискам. Восстановление идёт не по списку VM, а по волнам зависимостей: волна 0 — контур восстановления (копия IaC, GitOps, инструкции, доступ к целевому облаку, аварийные креды, state Terraform, целевой бакет бэкапов, внешний DNS); волна 1 — сеть и безопасность (VPC, маршруты, публичные адреса, межсетевой экран/NGFW, VPN, DNS-резолвер, NTP, PKI); волна 2 — системы с актуальным состоянием (GitLab и код, Vault, IAM, реестр образов в минимально нужном объёме), причём восстановление GitLab не должно зависеть от CI/CD в самом GitLab; волна 3 — платформа (Kubernetes, CNI/CSI, ingress, сертификаты, Argo CD/Flux, БД, мониторинг и логи); волна 4 — критичные приложения, затем внутренние инструменты и стенды. Отдельно расписан перенос GitLab: открывшаяся страница входа ничего не доказывает, так как данные лежат в PostgreSQL, репозиториях, файловой системе и объектном хранилище, а стандартный бэкап не включает объектное хранилище, /etc/gitlab, TLS- и SSH-ключи. Нужны совпадение версии и редакции, восстановление БД, репозиториев, wiki, LFS, артефактов, пакетов, реестра, gitlab-secrets.json и gitlab.rb, сверка групп, проектов, MR, конвейеров, веток и тегов до уровня SHA, git fsck, пробное клонирование и push, запуск пайплайна. Предложены приёмочные проверки по каждому сервису (PostgreSQL, GitLab, Docmost, Plane, Vault, S3, Kubernetes, NGFW) вместо бесполезного «контейнер запущен» — с проверкой предметных данных, прав, поиска, вложений, версий. Про IaC: Terraform ускоряет пересоздание и повторные попытки, но сам по себе не переносим между облаками; рекомендуется не один «универсальный» модуль, а слои — общие входные параметры, отдельные модули на провайдера, общие Ansible-роли и манифесты GitOps, средства выгрузки/загрузки данных и проверки результата. Состояние Terraform — удалённо, с блокировкой, шифрованием и независимой копией. Даны таблицы «что создаёт код, а что требует отдельного плана» и что восстанавливает код инфраструктуры. Переключение DNS — только после технической приёмки: источник в read-only, дельта перенесена, приёмка пройдена, мониторинг видит новую площадку, сертификат и цепочка корректны, TTL заранее снижен, порядок отката записан; после переключения проверяют ответы нескольких публичных резолверов, HTTP/TLS, отпечатки SSH-ключей и реальные пользовательские операции. Откат возможен только до первых новых записей. После переезда закрывают временный техдолг (открытый SSH, лишние публичные IP, секреты в env-файлах вместо Vault, ручной импорт ОС, завышенные права, временные DNS-записи, оплачиваемые остановленные ресурсы, исключения из мониторинга) с владельцем и сроком, и проводят тест восстановления уже из новой копии. Есть одностраничная инструкция из 12 шагов и раздел про DevSecOps, AppSec и ИБ: восстановление должно проходить те же инженерные гарантии, нельзя «временно» отключать проверки, нужно сверять версии, миграции, TLS-настройки, закрытость админ-маршрутов и замену секретов, попавших в аварийные скрипты, а решения о переключении DNS — согласовывать между владельцем продукта, разработчиками, AppSec, ИБ, юристами и руководством. Материал предельно практичный, без воды и без рекламы, с таблицами, чек-листами и ссылками на первоисточники GitLab и HashiCorp; минус — статья не про прорывные новости и не про политэкономию IT, а «инженерный longread», полезный в первую очередь DevOps/SRE/ИБ-специалистам и актуальный на фоне участившихся облачных аварий.

С 29 по 31 октября в новосибирском Экспоцентре на форуме «Учебная Сибирь – 2026» откроется витринная площадка фестиваля «Орбита инженерных кадров» программы «Таланты для космоса». Посетители увидят интерактивную карту «5 технологий космической сферы»: цифровое проектирование, робототехника, искусственный интеллект, беспилотники и программируемые среды. На каждой станции можно будет выполнить практические задания и понять, как эти технологии работают в космических исследованиях и разработке аппаратов. Основная аудитория — школьники 8–11 классов, студенты СПО и вузов, молодые педагоги. Фестиваль идёт весь октябрь на разных площадках Новосибирска и области: лекции в вузах, мастер-классы и соревнования в «Кванториуме» и инженерных кружках, космический диктант в школах, а также онлайн-игры, квесты и лекции с сентября по ноябрь. Регистрация на сайте talant.kosmos.kvantorium54.ru, также возможна на месте. Адрес: Новосибирск, ул. Станционная, 104, павильоны А и В. Организатор в регионе — детский технопарк «Кванториум» ОЦРТДиЮ. Новость прежде всего локальная и образовательно-профориентационная. Она актуальна для школьников, студентов и педагогов Новосибирска, но для широкой аудитории интереса к политике, экономике или IT почти не представляет, хотя тематически касается ИИ, робототехники и беспилотников.

Вышли октябрьские обновления 1С:ERP, Управления холдингом, Комплексной автоматизации, Управления торговлей, УНФ, Розницы, Бухгалтерии, ЗУП и 1С:Аналитики. В ERP 2.6.2 график производства учитывает альтернативные рабочие центры, выбирает более быстрый, позволяет делить партию между центрами, появились производственные наряды и массовое изменение операций. При обновлении контроль лимитов принудительно переводится с 2.4 на 2.5; в бюджетировании исправлены возвраты лимитов и ускорен сбор факта. По маркетплейсам автоматизирована работа FBS с Wildberries, в Ozon добавлены OAuth 2.0, обработка возвратов и отмен, отдельный выбор картинок для площадок. В Бухгалтерии 3.0.208 чеки самозанятых можно отправлять и получать по ЭДО, оплату цифровыми рублями от физлиц принимать по QR. В ЗУП 3.1.38.123 ЕФС-1 проверяется программой ПО ПД ЕЦП, доработан воинский учет, есть интеграция с 1С:Персоналом. В 1С:Аналитике 1.89 в подсказках диаграмм видно несколько показателей, связи объектов показываются деревом, карты копируются и выгружаются картинкой, появился Docker-образ. В УНФ и Рознице доработан обмен с Бухгалтерией для депозитов, в Управлении холдингом 3.3.4.9 проценты начисляются и после окончания договора при непогашенном долге. Полный список изменений на Инфостарте.

Статья — первая часть практического руководства о том, как проектировать облачную инфраструктуру, устойчивую к отказу зоны, региона и самого провайдера. Ключевая мысль: облако снимает часть аппаратных рисков, но не берёт на себя архитектурные решения — ВМ привязана к зоне, диск может быть зональным, квоты и API могут оказаться недоступны одновременно, а копия в том же аккаунте разделяет риски провайдера. Автор разбирает уровни отказа (процесс, ВМ, диск, зона, регион или контур управления, провайдер, аккаунт организации) и подчёркивает, что вопрос должен звучать не «сколько у нас зон», а «какой сценарий отказа и за какое время мы готовы пережить». Для этого вводятся RPO (допустимая потеря данных) и RTO (допустимое время простоя), причём сервисы делятся на три класса — критичный, важный, восстанавливаемый — с разными целями и типами защиты. Отдельно объясняется, зачем нужна карта зависимостей: список ВМ не равен инфраструктуре, в него входят DNS, сертификаты, секреты, бакеты, внешние списки разрешённых адресов; часто она вскрывает одиночные точки отказа вроде инструкции по восстановлению GitLab, лежащей в самом GitLab. Далее сравниваются два подхода. Первый — два независимых провайдера или ЦОД, где важна реальная, а не брендовая изоляция; внутри него четыре варианта: active-active (минимальный RTO, максимальная сложность и цена), основной плюс тёплый резерв, минимальный резервный контур (pilot light) и восстановление из копии. Разбираются нюансы данных (асинхронная репликация, WAL/binlog, логические дампы, версионирование и Object Lock для объектного хранилища, отдельное хранение ключей шифрования), вопросы сети и переключения (DNS, TTL, статические IP, завершение TLS, доступ сотрудников при отказе VPN), а также приводится таблица выбора с ориентировочными RTO, RPO, стоимостью и сложностью. Второй подход — один провайдер, несколько зон плюс независимые резервные копии: разнесение stateless-компонентов и данных по зонам, модель 3-2-1, неизменяемые копии, разделение прав боевой среды и хранилища копий, важное предупреждение, что при крупном сбое формальные квоты не гарантируют физическую ёмкость, а также таблица, показывающая, что несколько зон не превращаются в несколько независимых облаков. Затем — про автоматизацию: IaC это рецепт, а не готовые продукты, поэтому рядом нужны GitOps-манифесты, управление конфигурацией, независимое хранилище состояния Terraform, переносимый способ восстановления секретов, доступ к модулям провайдеров без основного реестра, автотесты восстановления и инструкция, доступная без основного GitLab. Приводится минимальная программа подготовки из девяти шагов, где подчёркивается: копия считается успешной только после реального восстановления сервиса, раз в квартал нужно восстанавливать хотя бы один критичный сервис, раз в полгода — учения с переключением DNS. Финальный раздел связывает тему с DevSecOps, AppSec и безопасностью: во время аварии легко забыть про секреты, TLS и админ-доступ, поэтому безопасность должна быть частью процесса восстановления, а ответственность распределяется между разработчиками, DevOps/SRE, ИБ, владельцами продукта, руководством и юристами. Материал структурный, плотный, без воды и без рекламы конкретных услуг, с опорой на официальные источники (Yandex Cloud, HashiCorp, NIST SP 800-34).

Разработчик Вали Нягу представил LinPad — открытую Linux-среду для iPad, работающую локально без джейлбрейка и удалённого подключения. Доступен рабочий стол с окнами и несколькими рабочими пространствами, переключение клавиатурой, мышью или сенсором. Поддерживается около 800 приложений, среди них Firefox, VS Code, Thunar, VLC, LibreOffice, GIMP, Git, Python и Node.js. В основе Alpine Linux 3.21 с модифицированным эмулятором iSH-ARM64, который транслирует системные вызовы Linux в вызовы iPadOS, без отдельного ядра и гипервизора. Поэтому доступны пакеты Alpine, но не работают Docker и другие возможности, требующие namespaces и cgroups. Оболочка DesktopKit написана на SwiftUI, связана с Linux через Wayland-композитор ishwl: изображения окон передаются через файлы в памяти, ввод — через именованные каналы. Для ускорения применяется JIT-компилятор, активируемый в режиме разработчика, без него используется медленный интерпретатор. Графика ускорена через Mesa Venus/Zink, virglrenderer и MoltenVK с выводом через Apple Metal. Ограничения iPadOS остаются: фоновые приложения приостанавливаются, при нехватке памяти система закрывает программы, большие проекты в VS Code упираются в лимит даже на iPad с 8 ГБ ОЗУ. Авторы решают это восстановлением сессий и автоматическим завершением части Linux-процессов до выгрузки. Код открыт под GPLv3, требуется iPad на чипах M-серии с iPadOS 17 или новее, установка через сторонние магазины, для настройки нужен компьютер, распакованная система занимает около 2,3 ГБ.

Автор (техлид Java/Kotlin в финтехе, преподаватель OTUS) разбирает, почему AI-агенты, сгенерированные SQL, блестяще работают на демо и разваливаются на реальном корпоративном хранилище. Главная мысль: модель — не главная проблема, проблема в контексте, который живёт вне схемы (определения метрик, кардинальность связей, корпоративный словарь, по какой дате резать период). Без явной передачи этого контекста модель угадывает. Опирается на три источника. Бенчмарк Spider 2.0 (ICLR 2025): агент на o1-preview решает 21,3% задач на корпоративных базах против 91,2% на учебном Spider 1.0 и 73% на BIRD — падение в 4,3 раза (правда, на новом срезе Spider 2.0-Snow лучшие агенты уже выше 90%). Бенчмарк BEAVER на реальных логах: 9128 пар вопрос-SQL, в среднем 4 таблицы и 5,7 соединения на запрос, точность агентов ReFoRCE — 10,8–11,4%. Подсказки по схеме поднимают точность с 9,5% до 25,9%, но и с ними 46,8% ошибок структурные. Статья Стоунбрейкера и Чена в CACM (сентябрь 2026): чистая LLM на BEAVER даёт ноль, RAG и агенты — около 10%, передача нужных таблиц и условий соединения — около 30%. На хранилище MIT с 1400+ таблицами выделены четыре проблемы: закрытость данных, «гниение» схемы (шесть колонок salary с разным смыслом), корпоративный словарь (J-Term, пронумерованные здания), большая сложность реальных запросов. Далее автор проводит собственный эксперимент на синтетической SQLite-схеме интернет-магазина (1000 заказов, отмены, частичные платежи, возвраты) и показывает три синтаксически корректных запроса на вопрос «какая выручка за сентябрь»: по дате создания заказа (4 465 500), по завершённым заказам с join к платежам (4 623 500) и по чистым денежным поступлениям (3 613 500). Запрос B — самый показательный: он выглядит строже, но даёт больше из-за двух независимых ошибок — fan-out при соединении один-ко-многим (суммируется мера уровня заказа после размножения строк, задвоились 138 заказов) и фильтр по дате заказа вместо даты оплаты (44 сентябрьских заказа оплачены в октябре). Все три запроса проходят без ошибок, различаются только семантикой. Вывод: спасает семантический слой — машинно-читаемое описание сущностей, кардинальности, зерна таблиц и метрик (пример на dbt Semantic Layer с derived-метрикой net_cash_collected и своей датой агрегации у каждой метрики). Он переносит знание из догадок модели в проверяемое описание; там, где термина нет, агент должен переспрашивать, а не угадывать. Ограничения: слой не заменяет моделирование данных, требует поддержки, покрывает только повторяющиеся вопросы. В конце — чек-лист проверки AI-аналитики за вечер (10–15 эталонных вопросов с согласованным SQL, зерно таблиц, словарь терминов, пилот на пяти метриках, вопрос с неизвестным термином). Финальная мысль: роль аналитика не уменьшается, а смещается от написания запросов к формализации смысла данных. Статья содержательная и практичная, с конкретикой, цифрами и воспроизводимым экспериментом, но с рекламной концовкой — приглашение на вебинары OTUS и упоминание дайджеста, что несколько снижает оценку.

Статья представляет собой эмоциональный публицистический набросок о том, как современные русскоязычные блогеры и «экзопатриоты» игнорируют отечественных научных деятелей, подменяя их импортными авторитетами. Автор напоминает: интернет подорвал монополию традиционных СМИ, но не устранил низкопоклонство перед Западом. С XIX века навязывался стереотип, что либерал и «противник власти» — это якобы интеллектуал и духовно развитый человек. Запад же претендует на монопольный приоритет и диктат в науке, образовательных и социальных технологиях. В качестве примера приводится Александр Богданов (Малиновский) — русский советский революционер и учёный, из научного наследия которого, по мнению автора, западные специалисты путём «перелицованного заимствования» вывели кибернетику и общую теорию систем, а имя Богданова при этом вычищено. Показательна реакция одного блогера («Кто этот Богданов?»), демонстрирующая невежество и подмену своих деятелей импортными авторитетами. В подтверждение цитируется комментарий пользователя Электрик (2018 г.) о том, что Запад монополизировал технический прогресс, навязывая через образование и социальные технологии ювенальную юстицию, ЛГБТ-повестку, толерастию и прочие деструктивные практики. Автор также иронизирует над псевдопатриотами, стремящимися «застолбить полянку русского патриотизма» и заимствующими западные представления о происхождении русской государственности, включая нападки на Ломоносова. Мысль о недооценке отечественного научного наследия и о культурной гегемонии Запада здравая, но подана крайне сумбурно, с массовыми отступлениями, жаргоном и путаницей. Ценность материала как дайджеста невысока из-за хаотичности изложения и отсутствия внятной фактуры.

Simons Foundation анонсировал инициативы, чтобы помочь математическому сообществу адаптироваться к быстрому развитию ИИ. Совместно с Anthropic и OpenAI выделено $15 млн финансирования и ресурсов; фонд будет управлять и распределять средства, в том числе через открытый конкурс заявок. Поддержка пойдёт на семинары и проекты, помогающие исследователям оценивать научные результаты, полученные с помощью ИИ, осваивать новые инструменты, обмениваться мнениями и вырабатывать общие стандарты применения ИИ. Anthropic и OpenAI также предоставят доступ к ИИ-инструментам и вычислительным мощностям, причём не только математикам, но и учёным в фундаментальных науках. Президент фонда Дэвид Спергель заявил, что математику стоит рассматривать как коллективное понимание, движимое человеческим любопытством, а не только как набор доказательств и теорем, и что именно сообщество, а не отдельная компания, должно определять, как оценивать и внедрять эти инструменты. Ранее фонд финансировал применение машинного обучения в науке, включая систему формальной верификации доказательств Lean. Контекст: Международный математический союз поддержал предупреждение о влиянии технологической индустрии ИИ на науку; это произошло после заявления OpenAI о том, что одна из её моделей опровергла 80-летнюю гипотезу в геометрии. OpenAI также представила решения ряда давних математических задач, полученные передовой невыпущенной моделью, опубликовав 722 документа по 372 направлениям, однако математическое сообщество бойкотирует эти материалы.

Activision признала усталость игроков от конвейера Modern Warfare и Black Ops. В 2027 году серия Call of Duty получит новую подфраншизу — впервые со времён Vanguard 2021 года. Маркетинговый директор серии Тайлер Баль в интервью The Game Business заявил, что смены сеттингов и механик уже не работают: аудитории нужен тональный сдвиг, фундамент для него заложен. Частично новизну должна дать Modern Warfare 4, выходящая 23 октября: кампания о полномасштабном конфликте на Корейском полуострове, бои в Нью-Йорке, Париже и Мумбаи. MW4 также станет первой игрой серии на консолях Nintendo со времён Ghosts 2013 года.

Автор делает референсные анкеты (листы персонажей) для фэнтези-игры с помощью трёх генераторов изображений — Grok Image 2.0, Krea 2 и Nano Banana Pro. Прогоняет через них 16 архетипов (странствующая волшебница, бард-полувервольф, жрица культа проклятых, маг-отшельник, рыцарь-наёмник, лучница, гном-кузнец, тёмный эльф-ассасин, паладин-жрица, орк-варвар, некромант, воровка, друид-оборотень, стражник, алхимик, ведьма) и сравнивает результаты. Вывод: лучше всех задачу решает Grok Image 2.0 — держит консистентность персонажа по всем генерациям, показывает качества, параметры, арсенал и разные ракурсы; Krea 2 даёт более «эффектных» женских персонажей, но проигрывает по стабильности. По сути это галерея картинок без методики, промптов, технических деталей, тестов и сколько-нибудь воспроизводимых критериев сравнения. Текста минимум, аналитики нет, всё сводится к «вот три модели, вот результат, Grok лучше». Полезного содержания почти ноль, для читателя с задачами вроде «как настроить пайплайн генерации референсов» статья ничего не даёт. Актуальность темы нейросетевой генерации высокая, но подача — легковесный обзор-витрина, фактически промо инструментов.