Дайджест за 30 сентября 2026

· 24 материала из 9 писем и 2 статей с сайтов

Криптографы взломали RSA-подписи без факторизации ключа — это переворачивает представления о надёжности одного из столпов современной безопасности. В мире ИИ произошло сразу несколько важных событий: Claude Opus 5.5 показывает, как снизить затраты на 40% без потери качества, а исследователи наконец разобрались, почему языковые модели галлюцинируют и как это остановить. На фронте разработки Shopify демонстрирует, почему нативная разработка победила React Native, а инженеры обсуждают браузерные API, которые окончательно вытеснили популярные JavaScript-библиотеки.

Главное

  • Почему dial-up модем выжимал 56 килобит/сек, а не 64
  • Криптографы взломали RSA-подписи без факторизации ключа
  • Claude Opus 5.5: как получить 40% экономии и не потерять качество
  • Почему языковые модели галлюцинируют и как это исправить
  • Почему Shopify отказался от React Native ради нативной разработки

Подробно

Claude Opus 5.5: как получить 40% экономии и не потерять качество

ИИ и агенты · Linas from Linas's Newsletter · 9/10

Anthropic выпустила Claude Opus 5.5 — новую модель по умолчанию, которая дешевле предыдущей (40% экономии), работает на 30% быстрее и превосходит Claude Fable 5.1 на большинстве задач. Цены на токены упали на 20% ($4 за миллион input-токенов, $20 за output), остальная экономия достигается за счёт эффективности модели при правильной настройке. Реальные примеры впечатляющие: один разработчик провел аудит 200-тысячного кодовой базы за три часа вместо двадцати на Opus 5, Quantium сократил задачу кодирования со 38 промптов за 4 дня до 11 промптов за 3 часа. Однако большинство команд не получат эти выигрыши, если не изменят свои привычки. Основные ошибки: запуск модели на максимальной мощности (сводит экономию к нулю), сохранение старых привычек в промптах (вроде "think carefully"), доверие неконтролируемым долгим задачам, которые модель может закончить промежуточным отчётом. У модели также есть слабые стороны — на 44% больше проблем параллелизма в коде и только 33.5% исправлений безопасности проходят проверки. Решение: использовать medium effort по умолчанию, передавать всю задачу в одном сообщении с чёткой границей завершения и проверять результаты в слабых местах.

Иллюстрация из материала
Иллюстрация из материала
Иллюстрация из материала

Выводы автора:

  • Opus 5.5 дешевле и быстрее предыдущей версии, но полная 40% экономия достигается только при правильной настройке, а не при максимальных параметрах
  • Основные затраты времени и денег связаны не с ценой токена, а с неправильными привычками использования: максимальный effort, старые промпты и неконтролируемые длинные задачи
  • Для получения результатов нужна систематическая настройка: medium effort по умолчанию, одно сообщение с ясной границей завершения, проверка качества на известных слабых местах модели
На работе, которая касается доходов, кода или капитала, различие между настроенной конфигурацией и конфигурацией по умолчанию измеряется в долларах за задачу и часах за проект на каждом запуске.

Почему языковые модели галлюцинируют и как это исправить

ИИ и агенты · ByteByteGo · 9/10

Статья разбирает фундаментальную проблему языковых моделей — галлюцинации, когда они уверенно выдают вымышленную или неправильную информацию. На примере AI-ассистента поддержки, который обещает несуществующий 30-дневный период возврата вместо реальных 14 дней, автор показывает опасность этой проблемы. Выделены три типа ошибок: фактические галлюцинации (противоречие реальности), нарушения верности (противоречие предоставленным источникам) и полная фабрикация. Механизм проблемы кроется в том, что LLM предсказывают вероятный следующий токен, а не проверяют истинность утверждений — модель может знать структуру ссылок на исследования, но выдумать их. Модели также обучены угадывать, когда награды даются как за правильный ответ, так и за неправильный. Автор предлагает три основных защиты: RAG (retrieval-augmented generation) для снабжения модели фактическими документами компании, использование инструментов (tools) для проверки данных о конкретном клиенте через API, и проверку ответов перед отправкой пользователю.

Выводы автора:

  • Галлюцинации LLM возникают не от недостатка знаний, а потому что модели предсказывают текст, а не проверяют истинность, и обучены угадывать в условиях неопределённости
  • RAG и инструменты (tool use) работают дополнительно: RAG обеспечивает общие правила из документов, а tools проверяют конкретные факты о пользователе через внешние системы
  • Уверенность модели в ответе — это просто результат обучения на плавном тексте и не гарантирует правильность; процентные оценки уверенности без калибровки бессмысленны
Вероятное продолжение — не то же самое, что проверенное утверждение. Вероятность, используемая для выбора следующего токена, касается генерации текста, а не верификации всего ответа.

Еженедельный дайджест: налоги, санкции, новые модели AI и битва за регулирование

ИИ и агенты · Habr · 8/10

Дайджест охватывает главные новости финансов и технологий за две недели: от налоговых реформ в России до международных событий в AI. Минфин предложил поднять налоги на инвестиционные доходы с 2027 года, включив дивиденды и доходы от ценных бумаг в пятиступенчатую шкалу НДФЛ с ставками до 22% для высоких доходов. Также обновлены условия семейной ипотеки – теперь ставка зависит от числа детей и региона, подорожав до 8–12% для семей с одним-двумя детьми. На международной арене Трамп подписал закон об «адских санкциях» на покупателей российской нефти и газа, а ФРС впервые с 2023 года подняла ставку на 0,25 п.п. В сфере ИИ Anthropic выпустила Claude Opus 5.5 – более дешевую и экономичную версию флагмана, а OpenAI представила GPT-6 Sol и Luna с похожей логикой удешевления. Яндекс анонсировал Alice AI Foundation LLM на 80 млрд параметров. Главная политическая дискуссия разгорелась вокруг регулирования AI: Дарио Амодей, Сэм Альтман и Демис Хассабис призвали притормозить гонку для безопасности, но Трамп и Дженсен Хуанг выступили против новых ограничений, полагая это поможет Китаю. Anthropic планирует IPO на Nasdaq осенью с оценкой около $2 трлн, а OpenAI обсуждает новый раунд финансирования с оценкой $1,2–1,5 трлн.

Выводы автора:

  • Налоговая реформа в России коснется около 4 млн инвесторов и значительно повысит налоги на инвестиционные доходы с 2027 года
  • Anthropic и OpenAI каждые пару недель выпускают более дешевые версии моделей с сопоставимой производительностью, сдвигая фокус с максимальной производительности на экономичность
  • Вокруг регулирования AI формируется политический раскол: лидеры крупных AI-лабораторий выступают за международный контроль, а администрация Трампа и лидеры промышленности видят в ограничениях помеху конкурентоспособности США
Страхи вокруг нейросетей раздувают, новые ограничения только помогут Китаю, а США сейчас важнее выиграть AI-гонку.

Taiga-S1: компактная нейросеть для автоматизации CAD-операций

ИИ и агенты · Habr · 8/10

Разработчик Шив Шанмугам представил Taiga-S1 — компактную модель с 1,2 млн параметров, которая управляет FreeCAD без использования LLM, скриншотов и компьютерного зрения. Модель работает как специализированный слой в составе AI-агента: планировщик передаёт структурированный список операций, а Taiga-S1 выбирает необходимые команды FreeCAD (создание эскиза, выдавливание, создание отверстий, снятие фасок и т.д.) за ~1 мс на каждое действие. Числовые параметры она не генерирует — они поступают из исходного задания. Обучение проводилось на 25 тыс. синтетических сессий (590 тыс. решений), затем следовали два этапа дообучения с итеративным сбором ошибок через самоконтроль модели. На тестах Taiga-S1 показала 100% успех на задачах с 11 элементами (55 действий, хотя видела последовательности максимум с 5 элементами) и 95% на задачах с 17 элементами. Код и веса модели открыты на GitHub и Hugging Face под лицензией MIT.

Выводы автора:

  • Компактная специализированная модель способна выполнять сложные CAD-операции лучше, чем более крупные универсальные системы
  • Архитектура с разделением ролей (планировщик + исполнитель) позволяет эффективно использовать малые модели в составе AI-агентов
  • Синтетическое обучение с итеративной коррекцией ошибок даёт хорошее обобщение на более сложные задачи, чем видела модель во время обучения
Модель обучили с нуля на 25 тыс. синтетических сессий моделирования, включающих около 590 тыс. решений, затем провели итеративное дообучение через самоконтроль ошибок.

Nscale: ставка на $103 млрд в полнослойную AI инфраструктуру

ИИ и агенты · App Economy Insights · 8/10

Материал разбирает готовящееся IPO компании Nscale – спин-офф Bitcoin-майнера, который стал полнослойным провайдером AI-инфраструктуры. Компания уже подписала контракты на будущую выручку в $103 млрд, но сегодня использует только 25 тыс. из 461 тыс. обещанных GPU. Nscale контролирует цепочку от власти и земли через дата-центры и GPU к облачным сервисам и ПО (планирует приобрести Anyscale).

Иллюстрация из материала

Ключевая проблема: компания продаёт будущую вертикально интегрированную версию самой себя, тогда как физическая инфраструктура ещё строится. Основной доход поступает от долгосрочных контрактов на зарезервированные вычисления (Nscale Infrastructure), облако же (Nscale Cloud) пока менее значимо. Стратегия опирается на тезис, что электроэнергия — главный лимит для AI, а не GPU.

Выводы автора:

  • Nscale продаёт полнослойную AI-инфраструктуру, но основное время и капитал уходит на строительство физических активов, которые будут генерировать контрактованные $103 млрд в будущем.
  • Первоначальное конкурентное преимущество компании — доступ к дешёвой электроэнергии в Норвегии, Исландии, Португалии и США — используется как основание для расширения вверх по стеку вплоть до ПО.
Электроэнергия — основное узкое место AI-инфраструктуры, а не GPU; Nscale начала с этого преимущества и теперь пытается контролировать весь стек экономики вокруг AI-вычислений.

Эффект щуки: как устаревшие убеждения саботируют AI в компаниях

ИИ и агенты · Modern Data 101 · 8/10

Статья разбирает парадокс корпоративного внедрения ИИ: самая большая опасность — это не незнание, а устаревшие знания, которые организация воплотила в процессы и решения. Автор Сагар Пол, опираясь на биологический пример с щукой, которая перестала охотиться после многократных столкновений со стеклом (даже после его удаления), показывает, как хорошо обученные организации закодируют реальные ограничения 2010-х годов в свою институциональную память так глубоко, что не замечают, когда эти ограничения исчезают.

Он приводит конкретные примеры: автопроизводители в 2016 году правильно кодировали реальные барьеры (регулирование, архитектура продукта), но когда Tesla доказала, что эти барьеры преодолимы, они продолжали действовать из устаревшей модели мира. То же произошло с финтехом — альтернативные данные для кредитных моделей стали доступны в 2010-х, но банки продолжали опираться на FICO-модели 1989 года, закодированные в их системах риска.

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

Выводы автора:

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

Критический взгляд на волну ИИ-энтузиазма в разработке

ИИ и агенты · Habr · 7/10

Статья критически разбирает тренд на внедрение ИИ во все сферы разработки, подвергая сомнению как громкие обещания, так и поверхностное применение инструментов. Автор указывает на несколько фундаментальных проблем: люди делают далеко идущие выводы, едва начав экспериментировать с ИИ; часто под требованием "ускорить разработку" скрываются проблемы с планированием и процессами, а не нехватка скорости кодирования; организации редко обдумывают граничные условия и альтернативы на случай, если модель станет недоступна, дорожает или будут введены ограничения. Автор подчёркивает необходимость более честного обсуждения: где ИИ действительно помогает, где требует проверки каждого шага, где дешевле сделать самому, и когда выбранный подход перестаёт окупаться. Особое внимание уделено конфликту между голосами с трибун (консультанты, обещающие замену 70% работников) и практическими озабоченностями разработчиков о поддерживаемости, сложности системы и качестве кода. Автор предлагает слушать опыт скептиков, которые видели, как системы деградировали под прессингом "больше фич", а не отмахиваться от их возражений как от неумения писать промпты.

Выводы автора:

  • ИИ следует применять осмысленно в рамках конкретных ограничений и условий, а не пытаться использовать везде; необходимо честно выяснять, где инструмент помогает, где нужна проверка, и когда лучше не применять его вообще.
  • Под требованием "ускорить разработку" часто скрываются организационные и процессные проблемы, а не нехватка технической скорости кодирования; нужно разбираться в корне проблемы, прежде чем выбирать решение.
  • Организации должны заранее продумать, что происходит при изменении условий: рост стоимости моделей, их недоступность, государственные ограничения или смена поставщика — и кто вообще сможет перейти на альтернативные подходы.
Может быть, его опыт тоже хотелось бы рассмотреть поближе — что именно он пытался сделать, где инструмент помог, где начал мешать и в какой момент следовало остановиться.

Почему dial-up модем выжимал 56 килобит/сек, а не 64

Разработка и архитектура · Habr · 9/10

Статья разбирает историю и техническую логику ограничения скорости dial-up модемов на отметке 56 кбит/с, а не теоретически возможных 64 кбит/с. Телефонный канал ограничен полосой частот 300–3400 Гц для обеспечения совместимости с системами уплотнения. Предел Шеннона для такого канала с отношением сигнал/шум 30–35 дБ составляет 31–36 кбит/с. Протокол V.34 (1994–1996) работал на пределе этого отношения на скорости 28,8–33,6 кбит/с. Прорыв к 56 кбит/с произошёл благодаря патентованной в 1994 году идее канадца Брента Таунсенда: если провайдер подключен цифровым потоком (E1/T1), его модем может передавать байты напрямую, минуя аналого-цифровое преобразование на этом участке. Вместо двух преобразований остаётся одно на стороне абонента, что устраняет шум квантования. Однако 56 кбит/с вместо теоретических 64 кбит/с (8000 байт/сек) объясняется необходимостью резервировать один бит на каждый байт для синхронизации и контроля четётности, плюс дополнительные ограничения в США из-за регулирования телефонной сети.

Выводы автора:

  • Скорость 56k достигается только если провайдер подключен цифровым каналом, что исключает одно лишнее аналого-цифровое преобразование и связанный с ним шум квантования
  • Асимметрия 56k вниз и 33,6k вверх была следствием того, что трюк работал только в одном направлении — нисходящем потоке от провайдера
  • Окончательное ограничение в 56 кбит/с вместо 64 было связано с резервированием битов для синхронизации и техническими требованиями телефонной сети
На стороне сервера от аналога можно избавиться — если провайдер сидит на цифровом потоке, его модем может выставлять байты напрямую, исключив одно преобразование и связанный с ним шум

Почему Shopify отказался от React Native ради нативной разработки

Разработка и архитектура · The Pragmatic Engineer · 9/10

Shopify неожиданно объявил о переходе с React Native на нативную разработку (Swift и Kotlin) для мобильных приложений, хотя ещё год назад компания была довольна этим фреймворком. Причина – революция в AI-агентах для кодирования, которые теперь достаточно хороши, чтобы писать нативный код на обеих платформах, нивелируя главное преимущество React Native (разделяемый код). Shopify мигрировал на RN в 2020 году специально для ускорения разработки под Android, поскольку до этого компании, включая Clubhouse, месяцами не могли запустить Android-версию. За пять лет шесть приложений Shopify успешно работали на RN с производительностью <500мс и стабильностью >99.9%. Однако новые возможности AI в кодировании изменили расчёт: теперь нативная разработка на двух платформах стоит меньше благодаря автоматизации, а преимущества нативного доступа к платформенным API и инструментам остаются. React Native добавляет слой абстракции между кодом и платформой, тогда как нативные приложения работают непосредственно с OS.

Иллюстрация из материала

иллюстрирует исторический баланс: React Native экономил на разработке, но уступал в доступе к возможностям платформы. AI изменил левую часть этого уравнения.

Иллюстрация из материала
Иллюстрация из материала

Выводы автора:

  • AI-агенты для кодирования теперь достаточно развиты, чтобы сделать разработку под две платформы на нативных языках экономически обоснованной, переломив главный аргумент в пользу кросс-платформенных фреймворков
  • Нативная разработка сохраняет преимущество в производительности, доступе к платформенным API и официальным инструментам, а AI убирает его главный недостаток – дублирование работы
  • История показывает цикличность: Airbnb аналогично перешёл с React Native на нативную в 2018 году; теперь решения о технологии будут приниматься с учётом возможностей AI-помощников
Что изменилось, так это то, что агенты теперь выполняют достаточно работы по реализации, трансляции, тестированию и проверке, чтобы это больше не было решающим фактором, как в 2020 году.

Семь привычек Linux-инженера, которые спасают прод

Разработка и архитектура · Habr · 8/10

Статья разбирает семь реальных случаев сбоев на Linux-серверах, произошедших из-за неочевидных ошибок инженеров, и извлекает из них практические привычки для предотвращения проблем. Первый кейс: распаковка архива в домашнем каталоге случайно изменила права доступа с 700 на 775, заблокировав SSH-ключи, потому что архив содержал метаданные текущей директории (./) создателя архива. Второй: график пропускной способности при резервном копировании между дата-центрами показывал плато на 1 Гбит/с, но виновником оказалось не сетевое ограничение, а CPU, упирающийся в обработку шифрования SSH и дедупликацию, хотя сеть поддерживала 5 Гбит/с. Третий: Apache не запускался на порту 8081 не из-за его занятости, а из-за SELinux, который блокировал доступ к нестандартному порту в домене безопасности веб-сервера. Четвёртый: обновление Linux с версии 4.18 на 6.1 вызвало деградацию производительности крупной системы с 400 контейнерами на процессорах Intel Cascade Lake, причём стандартные стресс-тесты не воспроизводили проблему — потребовалось построить идентичный стенд с похожей нагрузкой, чтобы выявить новый механизм защиты от аппаратной уязвимости как причину. Главные выводы: проверяйте архивы перед распаковкой, разлаживайте диагностику по слоям стека вместо поиска виновника по одному графику, используйте отключение защиты только для диагностики и затем правильно настраивайте контекст, и добивайтесь стабильного воспроизведения проблемы на идентичной нагрузке перед расследованием.

Выводы автора:

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

10 браузерных API, которые заменили популярные JS-библиотеки

Разработка и архитектура · Habr · 8/10

Обзор современных встроенных браузерных API, которые вытеснили необходимость установки внешних npm-пакетов. IntersectionObserver заменил библиотеки ленивой загрузки (lazysizes, lozad), делегируя работу браузеру вместо обработки событий прокрутки. Элемент dialog автоматизирует модальные окна с захватом фокуса, фоном и закрытием по Esc, вытесняя micromodal и jQuery-диалоги. Popover API решает задачу показа/скрытия всплывающих меню и подсказок (частично заменяя tippy.js и popper.js), хотя для позиционирования ещё требуется Floating UI или якорное позиционирование CSS. View Transitions API анимирует переходы между страницами без barba.js и swup, поддерживая как внутристраничные переходы (SPA), так и межстраничную навигацию. AbortController отменяет fetch-запросы, вытесняя axios и его cancel tokens. structuredClone() выполняет глубокое копирование объектов с сохранением типов (Date, Map, Set), заменяя lodash.cloneDeep(). Object.groupBy() группирует массивы по ключу вместо _.groupBy(). Для каждого API указана поддержка основными браузерами.

Выводы автора:

  • Современные браузеры предоставляют встроенные API для задач, которые раньше требовали внешних библиотек (dialog, popover, IntersectionObserver, fetch с AbortController).
  • Некоторые API полностью готовы к использованию (dialog, popover поддерживаются со второй половины 2024 года), другие требуют полифиллов или отката на библиотеки (View Transitions в Chrome/Safari, якорное позиционирование).
  • Встроенные решения часто проще в использовании и производительнее благодаря оптимизации браузера, но некоторые остаются дополнением к существующим инструментам (View Transitions + barba.js, Popover + Floating UI для позиционирования).
IntersectionObserver делегирует эту работу браузеру. Вы описываете, какие элементы вас интересуют, и браузер выполняет соответствующий код, когда они входят или покидают область просмотра.

Coyote Time: как игры красиво врут игроку для удобства

Разработка и архитектура · Habr · 8/10

Статья разбирает механику Coyote Time в играх — приём, позволяющий персонажу прыгать в течение нескольких кадров после того, как он физически покинул платформу. Проблема возникает из фундаментального противоречия: игра измеряет мир дискретными состояниями (кадры по 16,7 мс при 60 FPS), а человек воспринимает действие непрерывно. Когда игрок видит себя ещё на краю и нажимает прыжок, для системы персонаж уже в воздухе, и логически прыжок должен быть запрещён. Автор объясняет, что строгая физическая корректность делает игру неотзывчивой: задержка между зрительным восприятием, нервной реакцией и нажатием кнопки может составить до 30 кадров (420 мс). Coyote Time решает эту проблему, позволяя прыгнуть за несколько миллисекунд после края — популярные игры используют значения 100–120 мс. Дополнительно вводится Jump Buffer, который запоминает нажатие кнопки незадолго до приземления, чтобы позволить игроку прыгнуть в серии действий. Современные игроки уже привыкли к такому "прощению" и считают его нормой; отсутствие этой механики воспринимается как глюк управления, хотя технически это физически корректно.

Выводы автора:

  • Coyote Time — это не баг, а целенаправленная "ложь" игры для согласования дискретного восприятия системы с непрерывным восприятием человека
  • Механика значительно упростила игры, позволив дизайнерам создавать более сложные уровни, но теперь стала культурным стандартом, и её отсутствие воспринимается как ошибка
  • Хорошая игра должна понимать намерение игрока и исполнять его, даже если буквально это не соответствует физике или временной последовательности событий
Игра знает, что персонаж находится в воздухе, игра знает, что поверхность закончилась, игра знает, что игрок опоздал. Но мы вернули правильное поведение, которое ожидает игрок.

Архитектура Windows NT против Linux: анализ дизайна ядер

Разработка и архитектура · Habr · 7/10

Исследовательница Google Лори Кирк, ранее работавшая в Microsoft, утверждает, что ядро Windows NT остаётся инженерным шедевром и во многих отношениях превосходит Linux, особенно для управления ресурсами и моделью безопасности. Кирк хвалит объектно-ориентированную архитектуру NT, где все сущности (процессы, файлы, устройства, маркеры доступа и более 25 типов объектов) управляются единым диспетчером с централизованной моделью прав через дескрипторы и списки управления доступом (ACL). Linux, напротив, использует модульный подход с раздельными механизмами: UID/GID для идентификации, capabilities для разделения прав root, SELinux/AppArmor для политик безопасности, cgroups для ограничения ресурсов и пространства имён для изоляции. Кирк предполагает, что этот монолитный дизайн NT лучше подойдёт для управления ИИ-агентов, полномочия которых растут. Она предложила гипотезу, что в 2000-х Microsoft должна была выпустить Open NT (открытую версию), позволяющую крупным организациям вроде Amazon создавать собственные форки. Инженеры сообщества возразили, что модульная философия Linux — это сознательный выбор, а издержки поддержки форков NT были бы непомерны. Microsoft уже разрабатывает Microsoft Execution Containers (MXC) для управления агентов, используя именно NT-модель с собственными SID, маркерами доступа и ACL.

Выводы автора:

  • Архитектура Windows NT строится на единой объектной модели с централизованным управлением доступом, в то время как Linux развивался путём добавления модульных механизмов к базовой архитектуре Unix
  • Монолитный дизайн NT потенциально более удобен для управления ИИ-агентов с явной типизацией ресурсов и надёжным аудитом, чем модульная система Linux
  • Реальные издержки поддержки форков делают концепцию Open NT непрактичной, так как каждое обновление безопасности требовало бы переинтеграции и повторного тестирования
Ядро NT — это поистине инженерный шедевр, который во многих отношениях до сих пор оставляет Linux далеко позади

Криптографы взломали RSA-подписи без факторизации ключа

Кибербезопасность · Habr · 9/10

Исследователи под руководством Нади Хенингер разработали новый метод подделки RSA-подписей, который не требует факторизации ключа и значительно снижает вычислительные затраты на взлом. Метод успешно применён к 1024-битным ключам за несколько месяцев на академическом кластере, тогда как факторизация требовала бы миллионов долларов и ресурсов государственного уровня. Для 2048 и 4096-битных ключей атака снижает уровень безопасности с требуемых 128 бит до 2⁶⁵, 2⁹⁰ и 2¹¹⁹ соответственно. Атака применима только к реализациям со слепой подписью, включая протокол Privacy Pass, используемый Apple и Cloudflare — для его взлома потребуется около 2⁴³ запросов токенов. Авторы использовали модифицированное специальное решето числового поля (2007 года) в сочетании с криптографическим оракулом, требуя всего 2⁶⁵ операций вместо 2⁸⁰ для факторизации. Хотя на данный момент атака не представляет непосредственной угрозы, она свидетельствует о концептуальном прорыве в криптоанализе RSA и указывает на необходимость скорейшего перехода на постквантовые криптосистемы.

Выводы автора:

  • Разработан принципиально новый метод взлома RSA через подделку подписей, требующий на порядки меньше вычислительных ресурсов, чем факторизация ключа
  • Атака практически применима к 1024-битным ключам и снижает безопасность 2048/4096-битных ключей ниже нормативного уровня 128 бит
  • Уязвимы только системы со слепой подписью (например, Privacy Pass), а большинство современных реализаций RSA с дополнением PKCS/PSS остаются защищены
Считалось, что взломать RSA так же сложно, как разложить на множители большие целые числа. Теперь же исследователи показывают, что RSA можно практически взломать, не вскрывая сам ключ.

Аттестация госинформсистем по приказу ФСТЭК 117: процессы и требования

Кибербезопасность · Habr · 8/10

Статья подробно разбирает процедуру аттестации государственных информационных систем (ГИС) по требованиям приказа ФСТЭК № 117, который кардинально изменил подход к защите госсистем. Процесс аттестации включает несколько этапов: анализ требований и определение объекта аттестации, выбор лицензированного подрядчика, подготовка инфраструктуры согласно методическому документу ФСТЭК от апреля 2026 года, проведение испытаний, анализ уязвимостей и пентест, а также контроль после получения аттестации. Ключевые нововведения приказа включают масштабирование процессов безопасности на всю организацию, переопределение мобильных устройств, обязательную двухфакторную аутентификацию для систем К2 и К1, использование инструментов управления доступом (IdM/IAM), применение встроенных средств защиты виртуализации вместо наложенных решений, а также использование EDR-систем и специализированных средств защиты от DDoS. Пентест обязателен для ГИС классов К1 и К2 с 1 сентября 2026 года и включает как внешние, так и внутренние проверки на проникновение, включая социальную инженерию. После получения аттестации важно постоянно контролировать соответствие документированной инфраструктуры реальному состоянию системы.

Выводы автора:

  • Аттестация ГИС по ФСТЭК 117 — многоэтапный процесс, требующий привлечения лицензированного подрядчика и реализации технических мер, включая двухфакторную аутентификацию, системы управления доступом и EDR.
  • Новые требования включают обязательный пентест для систем К1 и К2, анализ уязвимостей и проверку защиты от социальной инженерии, при этом должны использоваться сертифицированные в реестре ФСТЭК средства защиты.
  • Аттестация — не завершающая точка: требуется постоянный контроль соответствия реальной инфраструктуры документированной, периодические тренировки и обучение, а также анализ любых изменений в системе.
На своем опыте можем сказать, что сотрудничать даже с хорошо знакомым партнером может быть сложно, особенно если целевая система многокомпонентная и нестандартная.

Новый закон США позволит судам заставить VPN и DNS блокировать пиратские сайты

Кибербезопасность · Habr · 7/10

В американском Конгрессе представлен законопроект ACPA (American Copyright Protection Act of 2026, HR 10364), который даст судам полномочия обязывать интернет-провайдеров, VPN- и DNS-сервисы блокировать иностранные сайты с пиратским контентом. Запретительный приказ будет вступать в силу через 14–30 дней, но при прямых трансляциях спортивных событий и шоу срок может быть сокращён по усмотрению судьи. DNS-блокировка на уровне провайдера относительно проста, так как большинство пользователей используют DNS своего оператора, хотя внешние сервисы (Google DNS, Cloudflare, OpenDNS) могут игнорировать запросы из США. Исключения предусмотрены для небольших провайдеров с числом пользователей менее 100 тыс. в месяц, а также для корневых DNS-серверов. Однако в законопроекте не уточнены механизмы блокировки и возникают множественные юридические вопросы: как определить, где находится конечная точка VPN-соединения, как учитывать CDN, как классифицировать гражданина США за границей или на судне в международных водах. Подобные законодательные подходы уже критиковались во Франции и Испании за массовые блокировки и ложные срабатывания — в частности, суды в этих странах вынесли решения против провайдеров CDN и VPN-сервисов.

Выводы автора:

  • Законопроект ACPA расширит полномочия американских судов на принудительное блокирование сайтов с пиратским контентом через VPN и DNS-сервисы, что создаст новые обязательства для сетевых посредников.
  • Механизм блокировки не уточнён в законопроекте, что может привести к массовым и неточным блокировкам, как произошло в Испании и Франции.
  • Множество нерешённых юридических и технических вопросов (определение геолокации, статус граждан за границей, учёт CDN) могут затруднить применение закона на практике.
Блокировка на уровне интернет-провайдера и DNS относительно проста, так как большинство пользователей применяют DNS своего провайдера.

Как банки интегрируют автоматизированную упрощённую систему налогообложения

Финтех и финансы · Б.О: Банки · 8/10

Материал рассказывает о внедрении банками налогового спецрежима АУСН (Автоматизированная упрощенная система налогообложения) и его значении для финансовых организаций. Число предпринимателей на АУСН выросло с 40 тысяч в начале 2025 года до 500 тысяч — в 12 раз, что делает наличие статуса уполномоченного банка критически важным для сохранения клиентской базы и конкурентоспособности. К августу 2026 года в реестр ФНС вошли более 50 уполномоченных банков, в том числе Газпромбанк, ТКБ и МТС Банк. Для получения статуса банк должен внедрить техническое решение, поддерживающее протоколы обмена данными с ФНС. Это включает клиентскую часть дистанционного банковского обслуживания, адаптер для передачи данных и аналитическую систему разметки транзакций. Процесс получения статуса занимает примерно четыре месяца и требует прохождения тестирования с ФНС. Банки отмечают положительный эффект: закрытие риска оттока клиентов, привлечение новых предпринимателей и улучшение качества диалога с ними. Эксперимент АУСН продлится до конца 2027 года.

Выводы автора:

  • Число предпринимателей на АУСН выросло в 12 раз, сделав статус уполномоченного банка обязательным для конкурентоспособности в сегменте МСБ.
  • Внедрение АУСН требует технического решения с протоколами обмена данными с ФНС, занимает около четырёх месяцев и открывает новые возможности для удержания и привлечения клиентов.
Статус уполномоченного ФНС банка является обязательным для обслуживания клиентов на режиме АУСН, это вопрос сохранения текущей клиентской базы и конкурентоспособности.

Цифровой рубль: основные ошибки интеграции и как их избежать

Финтех и финансы · Б.О: Технологии · 7/10

Статья разбирает технические и организационные проблемы при подключении банков к Платформе цифрового рубля, которые регулярно приводят к срывам сроков и перерасходованию бюджета. Компания «Информзащита», реализующая такие проекты с 2024 года, выделяет ключевые ошибки: начало с минимальной конфигурации вместо архитектуры по конечной модели, попытки переиспользовать существующее оборудование без проверки совместимости, недостаточная проработка требований к информбезопасности на этапе проектирования. Инфраструктура цифрового рубля включает серверы, межсетевые экраны, TLS-шлюзы, удостоверяющие центры, HSM и криптографические средства защиты, которые должны работать в едином контуре, отвечая строгим регуляторным требованиям. Второй блок проблем — организационный: параллельно ведутся разработка адаптера, доработка АБС и ДБО, интеграция с внешними сервисами, настройка ПОД/ФТ-проверок, внедрение СЗИ, и задержка в одном направлении немедленно влияет на другие. Успех зависит от интегратора, который видит весь проект и координирует зависимости между участниками (вендорами, поставщиками, командами безопасности банка), а также от своевременности закупок и активного участия специалистов самого банка в согласованиях.

Выводы автора:

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

Музыка для продуктивности: почему Lo-Fi лучше Моцарта при кодировании

Продукт и карьера · Habr · 8/10

Статья разбирает научные основы влияния фоновой музыки на концентрацию и умственную работоспособность при программировании. Популярный «эффект Моцарта» — миф: классическая музыка с её полифонией, динамическими скачками (60–80 дБ) и непредсказуемостью заставляет мозг расходовать ресурсы на анализ звука вместо фокусировки на задаче. Слуховая система в процессе активно прогнозирует следующую музыкальную фразу, отвлекая префронтальную кору от основной работы. Lo-Fi с монотонным ритмом (70–90 BPM) и «грязным» звуком (шум винила, кассетное шипение) работает как розовый шум, стабилизируя спектральную плотность и позволяя мозгу быстро пометить звук как безопасный фон. Исследования показывают: слушатели Lo-Fi демонстрируют снижение тревожности и лучше удерживают фокус, чем в тишине. Чиптюн с его жёсткими техническими ограничениями (прямоугольные волны, циклическое переключение нот) создаёт абсолютно предсказуемый аудиопоток, не требующий скрытого анализа и стабилизирующий альфа-волны мозга (8–12 Гц). Саундтреки видеоигр — оптимальный выбор: инструментальность исключает речевой канал, циклические паттерны без финальных аккордов удерживают глубокое погружение, а высокая звуковая энергия при предсказуемости стимулирует дофамин без хаоса. Главное условие: музыка должна быть эмоционально нейтральной, иначе личные воспоминания разрушат фокус.

Выводы автора:

  • Классическая музыка переегружает рабочую память при сложных задачах из-за полифонии и непредсказуемости; эффект Моцарта для кодирования — миф, подтверждённый анализом 154 экспериментов
  • Lo-Fi, чиптюн и геймовые саундтреки эффективнее благодаря абсолютной предсказуемости, которая позволяет мозгу пометить звук как безопасный фон и сохранить ресурсы на основную задачу
  • Фоновая музыка работает только если остаётся эмоционально нейтральной; острая ностальгия или личные ассоциации мгновенно превращают её в раздражитель, перехватывающий внимание
Мозг помечает звуковой поток как безопасный фон и перестаёт расходовать энергию на его микроанализ, сохраняя максимальный объём рабочей памяти для решения логических задач

10 карьерных ловушек для думающих людей

Продукт и карьера · John Cutler from The Beautiful Mess · 8/10

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

Иллюстрация из материала

Выводы автора:

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

Видео докладов саммита Lenny & Friends теперь онлайн

Продукт и карьера · Lenny's Newsletter · 7/10

Опубликованы все основные доклады саммита Lenny & Friends, где спикеры из Stripe, Google, Atlassian, OpenAI, Anthropic и других компаний обсуждали будущее product management в эпоху ИИ. Материал включает пять ключевых трендов: (1) растущий спрос на живые события для профессионального общения, особенно в условиях работы с агентами; (2) отсутствие единого правильного подхода — все ещё экспериментируют, как строить продукты; (3) с упрощением разработки критичными становятся выбор правильной идеи, вкус и внимание к деталям, а не просто скорость доставки; (4) роли PM не исчезают, а расширяются, захватывая функции инженерии, дизайна и других областей; (5) необходимость поднимать амбиции и видеть, что возможно при помощи ИИ. Через цитаты спикеров выделяется главный вывод: лучшие практики ещё не написаны, и community должна их создавать вместе.

Иллюстрация из материала
Иллюстрация из материала
Иллюстрация из материала

Выводы автора:

  • В эпоху ИИ критичным для PM становится вкус, суждение и забота о деталях, а не просто скорость разработки
  • Ни один из подходов к разработке (фабрики ПО, отсутствие дорамап и т.д.) не универсален — нужно экспериментировать в зависимости от контекста
  • Роли PM, инженеров и дизайнеров не сливаются, а расширяются, позволяя каждому делать больше
Если мы используем ИИ только для того, чтобы делать то же самое быстрее, мы определённо упускаем самую интересную часть. ИИ может помочь нам поднять потолок, а не просто пол.

Коротко

Прочее