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

Статья — третья часть цикла о том, как пережить крупную облачную аварию, не потеряв безопасность. Основная мысль: во время сбоя нельзя просто отключить защиту ради скорости — её нужно перевести в заранее подготовленный аварийный режим с короткими процедурами, но чёткими границами, ответственными и сроками. Ключевые тезисы. Во время аварии меняется модель угроз: одновременно исчезают привычные доказательства доверия (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 лучше». Полезного содержания почти ноль, для читателя с задачами вроде «как настроить пайплайн генерации референсов» статья ничего не даёт. Актуальность темы нейросетевой генерации высокая, но подача — легковесный обзор-витрина, фактически промо инструментов.

Елена "Ива" Кириллова — оператор БПЛА 78-го отдельного полка БПС 51-й гвардейской армии группировки "Центр", ефрейтор. До войны 15 лет работала в строительстве, авторском надзоре и проектировании в Москве, вела спортивный и туристический образ жизни. После начала мобилизации, когда ушли почти все друзья, решила, что тоже должна пойти, но только при условии, что освоит военную профессию и по физике не будет уступать мужчинам. Прошла подготовку в учебно-тренировочном центре "Воевода" (отдельно благодарит инструктора, считает, что подготовка спасла ей жизнь), в начале 2023 года подписала контракт. Боевой путь: Донецк, Авдеевка и вокруг, затем в сторону Александрополя, потом Селидово. В сентябре 2024 года при ротации, поехав на машине "на авось", группа попала под удар FPV-дрона (попадание в бензобак, пожар), затем под сбросы и артиллерию; связи не было, рация пригорела к руке, нога была сильно повреждена, самостоятельно передвигаться группа не могла. Вытащили их двое добровольцев, которых никто не ждал, координаты передал заметивший подрыв разведчик. После ранения почти два года провела в госпиталях, но с самого начала — уже на восьмой день, наговорив голосовое сообщение перебинтованными руками, — заявила сослуживцам, что вернётся. Вернулась летом 2025 года. Признаёт, что за время отсутствия произошёл огромный рывок: новая техника, новые системы связи, другие средства РЭБ у противника, новые приёмы работы, поэтому осваивает специфику заново — учиться с чистого листа проще, чем переучиваться. Работает на FPV, для разведки — "мавики" и "аутели", хочет освоить дроны самолётного типа, по которым полноценного обучения не было. Оценку числа боевых вылетов даёт осторожно — "зацепилась бы за цифру двести", — поясняя, что задачи разные (разведка может длиться сутками со сменой батарей) и что подсчёт поражённой живой силы в единицах оператором БПЛА считает спорным. Из запомнившихся эпизодов: уничтожение замаскированного под гору мусора транспорта противника при корректировке танков; "пряничный" домик с розовой крышей и вражеской антенной, который жалко было бить; попытка сбить "Бабу-ягу" тараном винтами своего дрона — приём, применявшийся только на этапе становления БПЛА, сейчас неактуальный. Тяжелее всего даётся наблюдение на "мавике" без сброса, когда гибнут товарищи, а помочь ничем нельзя. О службе женщины в мужском коллективе: в подразделении не было разделения на "девочек и мальчиков", грузы таскали вместе, поблажек не просила и считает, что идущая служить женщина не должна выделяться. Конфликтов на этой почве за всё время СВО не было, отношения с сослуживцами — "братики и сестрёнка". Награды: медаль "Участнику СВО", "За Отвагу", "За храбрость" и "За разминирование"; о присвоении двух последних узнала уже после госпитализации и не привязывает их к конкретным эпизодам. Материал ценен прежде всего как человеческий документ: он показывает реальную мотивацию, изматывающую цену восстановления после тяжёлого ранения, темпы технической эволюции дроновой войны и отсутствие в подразделениях деления по полу там, где идёт настоящая работа. Аналитики и обобщений здесь нет, но конкретика по БПЛА и госпитальному опыту полезна.

По данным SecurityLab.ru, задержаны трое предполагаемых участников группировки из четырёх человек, связанной со взломом IT-системы «Додо Пицца». Один из подозреваемых раскрыл свой реальный IP-адрес при работе с похищенными данными, что помогло следствию выйти на группу. Атака началась с учётных данных Dodo Pizza, оказавшихся в открытом доступе на GitHub; затем злоумышленники получили доступ к корпоративным системам, облачным хранилищам и базам данных, а также к дополнительным паролям. В конце сентября 2026 года компания сообщила о кибератаке и возможной утечке персональных данных клиентов: имён, адресов, email, телефонов, дат рождения и составов заказов. Платёжные данные не хранятся, поэтому они в безопасности. «Додо Пицца» уведомила Роскомнадзор, доступ злоумышленникам заблокирован, идёт внутренняя проверка, а принудительный разлогин — мера защиты аккаунтов. В сети также публиковалась неофициальная версия постмортема инцидента.

На форуме GISDAYS 2026 в Москве прошла третья «Киберарена» — киберполигон компании «Газинформсервис». Участвовали 12 команд, включая одну из СНГ: восемь Red Team и четыре Blue Team. Соревнования шли два дня на четырёх независимых инфраструктурах: Университет, Нефтегаз, Банк и Госсектор. Red Team атаковали, соревнуясь между собой по скорости и точности, а Blue Team расследовали атаки только на своём полигоне и должны были оперативно подготовить отчёт для судей из GSOC. Главная сложность для синих — свободный выбор красными времени, цели и методов атаки. Особенность года — применение ИИ для генерации активности и адаптации агентов к сбоям, а также тестирование партнёрских ИБ-продуктов в реалистичных условиях. За полтора дня почти полностью разрушены три инфраструктуры — Банк, Госсектор и Университет; дольше всех продержался Нефтегаз. Лучшими среди Red стали CR4.ch и ChiLL Chain, среди Blue — Лемниската и К2 Кибербезопасность. «Киберарена» также является отдельной платформой для киберучений, обучения и тестирования ИИ и средств защиты. По словам технического директора «Газинформсервиса» Николая Нашивочникова, главный посыл — проактивная кибербезопасность, практический опыт без риска и помощь в соответствии требованиям регуляторов.

Google разрешила запускать созданные с помощью генеративного ИИ приложения на Android без публикации в Google Play. Такие сервисы можно запускать через обычную учётную запись Google, они остаются полностью приватными: не отображаются в поиске и списках Play и доступны только создателю. Раньше для использования нативного Android-приложения его приходилось публиковать в магазине, из-за чего многие выбирали веб-приложения. Теперь ИИ-приложения всё равно должны соответствовать правилам Google Play, но экспериментировать станет проще. На первом этапе функция доступна в США пользователям от 18 лет. В ближайшие месяцы обещают возможность делиться ИИ-разработками с доверенными друзьями, а при популярности — переводить в общедоступный статус после проверок безопасности и правил Play. Вице-президент Google Сэм Брайт назвал курс на персонализацию, безопасность и создание собственного продукта каждым пользователем: переход от концепции «для любой задачи найдётся приложение» к концепции «есть приложение, созданное специально для меня». Также Google развивает ИИ в Play: систему персональных рекомендаций игр Game Finder на данных 1,2 млрд игроков, пользовательские подборки игр, раздел Community Posts, 48-часовые игровые «спринты», обновление ИИ-помощника Ask Play для сравнения приложений и более глубокую интеграцию приложений и игр Play в диалоги с Gemini. Кроме того, появилась функция, позволяющая родителям сообщать разработчикам возрастной диапазон ребёнка без точной даты рождения. Ранее Google представила Playground — браузерную платформу для создания игр текстовыми промптами с возможностью делиться ими.

Суть: Трамп заявил, что Зеленский не хочет мира, разрушил Украину и что он не поклонник Зеленского. Медведев откликнулся потоком уничижительных инвектив в адрес Зеленского (тварь, насекомое, вошь, гнида), утверждая, что тот предал кормящую его руку и стал одной из причин поражения Трампа. Упомянуты европейские союзники Киева, которые якобы уговаривают Зеленского дождаться проигрыша республиканцев на выборах в Конгресс и тоже не любят Трампа. Вывод: Трамп как «дядя дезинсектор» злопамятен и не должен прощать, а скорейшая гибель «тифозных гнид» улучшит ситуацию в мире. Фактической информации минимум — по сути пересказ одной цитаты Трампа, обёрнутый в брань и энтомологическую метафорику; никакого анализа, конкретики по политике или данных нет.

Население Украины за 2025 год сократилось ещё примерно на 800 тыс. человек — это подтвердил глава Офиса миграционной политики Украины Василий Воскобойник. Причины две: естественная убыль (смертность превышает рождаемость в 3,5 раза) и эмиграция. Убыль идёт с 1991 года, но резко ускорилась после 2014-го и особенно после 2022-го. По докладу ООН (осень 2024) после 2022 года население сократилось на 8 млн человек, а с 2014 года суммарные потери — около 10 млн. За рубежом находится порядка 6,7 млн украинцев. Рождаемость упала до одного ребёнка на женщину — один из самых низких показателей в Европе. Отчёты ЦРУ за 2024–2025 годы относят Украину к странам с самой высокой смертностью и самой низкой рождаемостью в мире; средняя продолжительность жизни мужчин — 57,3 года, женщин — 70,9 года. Оценки численности расходятся: Институт демографии НАН Украины даёт 34–35 млн к 2026 году, на подконтрольной Киеву территории — от 22 до 29 млн (Европейский центр экономической стратегии — около 28 млн). Для сравнения: в 1991 году было 52,1 млн. Прогнозы: к 2033 году не более 35 млн, к 2051-му — до 25 млн, к концу столетия — риск падения до 15 млн. На фоне нехватки рабочих рук Верховная рада приняла поправки в трудовое законодательство (вступят в силу через полгода после отмены военного положения), ухудшающие положение работников вредных производств, беременных женщин и матерей малолетних детей: ночные смены, отмена права на перевод на лёгкую работу, лишение льготных пенсий, повышенной оплаты, сокращённого дня, дополнительных отпусков и бесплатного лечения при производственной травме. Зарегистрирован законопроект № 16114, повышающий предельную рабочую неделю для подростков 16–18 лет до 38 часов, для 14–15 лет в каникулы — с 24 до 26 часов, и отменяющий безусловный запрет на работу несовершеннолетних в выходные. Эксперты (Владимир Скачко, Александр Дудчак) считают демографическую катастрофу закономерным итогом курса Киева на войну «до последнего украинца»: деиндустриализация, распродажа земли, требования МВФ, превращение людей в расходный ресурс, роль страны как инструмента Запада. Вывод обоих: без смены власти в Киеве и нормализации отношений с Россией у Украины будущего нет.