Все потоки

Зачем рынку ещё одна замена Microsoft AD

Подоспела новость: MONT и Avanpost договорились о партнёрстве.

На первый взгляд - обычная дистрибьюторская новость. Но для компаний, которые работают с MONT и рассматривают миграцию с Microsoft AD на Linux-каталог, появляется интересный вариант службы каталога — Avanpost DS. Сейчас многие возразят: на рынке же полно российских решений-аналогов MS Active Directory — ALD Pro, РЕД АДМ, Роса Dynamic Directory, Альт Домен и другие. Зачем нам ещё один? Копнём поглубже, чтобы понять, а действительно нужен ли нам этот "ещё один".

Российские Linux-каталоги собраны по-разному: одни вокруг FreeIPA, другие на Samba DC. Вместе с каталогом заказчик выбирает его архитектуру, зависимости и инструменты администрирования. Поэтому два продукта с одной задачей в эксплуатации ведут себя по-разному.

Avanpost пошёл другим путём

Ядро Avanpost DS — LDAP-сервер и Kerberos — написано на Go с нуля, без использования open-source-компонентов. По заявлению вендора, их служба каталога протестирована под нагрузкой до 30 млн объектов.

Что это даёт?

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

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

Но производительность важна не только в штатном режиме

Проблема начинается, когда нужно быстро исправить ошибку в каталоге. Неудачный скрипт, сбой интеграции или массовое изменение могут затронуть множество объектов. Контроллеры при этом доступны, пользователи аутентифицируются, мониторинг зелёный – но у части сотрудников уже изменены атрибуты, членство в группах или права доступа. Формально всё работает, а данные внутри — уже нет.

Мало обслуживать миллионы объектов в штатном режиме. Нужно ещё быстро понять, что именно сломалось, и исправить это, не откатывая миллионы корректных данных вместе с ошибочными.

При больших объёмах узким местом может стать уже сам каталог. В компании, где я работаю (другой ИТ-вендор), был похожий опыт при нагрузочном тестировании одного из Linux-каталогов, построенных на open-source-компонентах: массовые операции на сотнях тысяч объектов выполнялись критически медленно, а удаление нескольких тысяч учётных записей заняло несколько дней. Во время нагрузки возникали ошибки, а репликация между контроллерами некоторое время не восстанавливалась.

Поэтому производительность каталога при больших объёмах – это не вопрос комфорта администратора. От неё напрямую зависит, сколько времени займёт исправление массовой ошибки.

И здесь у Avanpost есть ещё одна полезная связка

С августа Avanpost DS Pro совместим с Granulex Recovery. Granulex сравнивает текущее состояние каталога с резервной копией, показывает, что изменилось не туда, и позволяет выборочно вернуть нужные объекты и атрибуты — без полного отката каталога.

Так что при выборе замены Microsoft AD важен не только список функций. Сколько объектов реально выдерживает каталог? Как ведёт себя под нагрузкой? И насколько быстро можно найти и исправить ошибку, если она затронула тысячу объектов из миллиона?

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

Источники:

Статья на Cnews "MONT и Avanpost начали сотрудничество в области дистрибуции решений для защиты корпоративной инфраструктуры"
Telegram-канал Granulex ⚡️ российский ИТ без простоев
Telegram-канал Avanpost

Хочу придраться к слову «план»

План. Plan. Планирование. Planning.

Часто встречаю эти слова в бизнес‑литературе, особенно в переводной.
А дальше слышу это слово у менеджеров.

Я не уверен, у меня нет управленческого опыта в англоязычной зоне.
Но у меня есть Ютуб.

И так как я умею слушать, я слышу...

Слышу, что наш человек вкладывает в слово «план» коннотации почти векового опыта советских пятилеток.

План у нас — это «чтоб на века», «чтоб стояло крепче, чем советская власть!», это наш дед строил дачу, приговаривая обоснование своего фундаментализма.

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

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

Диаграмма Ганта в три экрана вышиной и шесть экранов шириной — вот это план! Явно видно, люди поработали, молодцы!

И это в современных ИТ‑компаниях с достаточно молодым менеджментом.

Тем временем в англоязычной зоне я слышу «Show me something, plan, notes, anything.»

Покрутить эту фразу на языке. Почувствуйте иное отношение.

‑-

И то же самое со словом «планирование».

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

А там это planning.

Я это слышу как «постоянное планирование».
Как процесс, а не проект.

Это у нас до сих пор считается, что стратегия — это план, что надо собраться, поднатужиться, сделать серьёзные морды и раз в году на сратегической (я не опечатался) наврать друг другу, как мы будем взаимодействовать ближайшие три года, чтоб всем доказать, что мы ещё ого‑го!

А на Западе стратегия и не была планом, даже у Ансоффа, отца‑основателя стратменеджмента. Даже у него это процесс с корректировками.

Но отечественный менеджер не может просто так отпустить опыт советских пятилеток.

‑-

Встаёт вопрос, почему мы оглядываемся на Запад?
Наша производительность ниже.
Мы решили жить в их мире с их правилами, растём на их опыте и их бизнес‑литературе.
Хорошо бы в своём нарративе понимать, что и онтология у нас разная.

Gradle — один из главных инструментов в мире Java-разработки, но насколько хорошо вы действительно с ним знакомы?

Мы подготовили 10 вопросов по современному Gradle: зависимости, плагины, задачи, конфигурация, сборка и другие возможности инструмента. Здесь не нужно разбирать фрагменты кода — проверим именно ваше понимание того, как работает Gradle и как его используют в реальных проектах.

Переходите по ссылке и проходите квиз! В конце вас будет ждать подарок! Удачи!

Миграция ВМ, бэкапы и DR в едином сервисном слое

Привет, Хабр! Еще недавно миграция ИТ-инфраструктуры казалась чем-то вроде капитального ремонта: один раз стиснул зубы, пережил хаос и дальше живешь спокойно. Но сейчас всё иначе, нагрузки постоянно перемещаются между on-premise, облаками и легаси-контуром.

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

Поэтому мы в «Хайстекс» решили завести миграцию, бэкапы и аварийное восстановление в единый контур, так всё работает в прочной связке. Этот принцип лег в основу свежего релиза «Хайстекс Акура».

В ближайшую среду 30 сентября в 11:00 (МСК) проведем технический стрим и расскажем:

• Как на практике работает концепция управляемой мобильности рабочих нагрузок; 

• Что нового появилось в решении: Backup 2.0, Object Lock, поддержка PostgreSQL, работа с OpenStack без привязки к СХД и DR через Direct2Target; 

• Как сегодня сравнивать enterprise-решения по бэкапу и миграции;

• Покажем дорожную карту «Хайстекс Акура» до конца 2026 года.

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

Регистрация по ссылке 

«Сибур-Нефтехим» заработал 160 миллионов рублей на том, что закончил ремонт на восемь суток раньше.

Меняли катализатор в реакторах окисления этилена. Раньше на это уходило 28 суток на каждую линию, и всё это время установка стоит. В этот раз одну линию закрыли за 25 суток, вторую за 23. Установка отработала выигранные сутки и дала лишние 4,5 тысячи тонн продукции.

Опыт этого ремонта не остался на площадке: его разобрали, оформили и передали на другие заводы компании. Несколько лет назад так бы не вышло.

Поговорили с Василием Можаровым. Он отвечает за систему управления знаниями в СИБУРе. Вот что рассказал:

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

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

Сложить документы в одно место оказалось мало

За пару лет мы набрали в базу больше 20 000 страниц. Новые появлялись быстрее, чем мы успевали проверять старые. Документ по названию ещё найдёшь, а решение, о котором не знаешь, уже нет.

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

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

Разделы мы нарезали по задачам, а не по отделам

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

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

Ждать, что сотрудник сам расскажет о своей практике, не стоит

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

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

Всё это оформили как лучшую практику и передали на «Нижнекамскнефтехим» и другие предприятия, где меняют катализатор.

Один реестр мы отдали языковой модели целиком

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

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

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

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

Владельцев разделов и регламент обновления мы завели задолго до всякого ИИ. Восемь суток на ремонте катализатора выиграли тоже без него.

Подписывайтесь на наш тг‑канал. Он полезен айтишникам, которые хотят понять, что реально происходит в промышленном ИТ.

Проблемы с MAXой - там возник канал «Фиксальной службы …. ».
Приходит оповещение о возникновении задолженностей, подробности по ссылке, удостоверьте себя через Госуслуги... и переход туда, а там большое сообщение на экране "Вас взломали" и телефон, по которому активный сотрудник продолжит дурить дальше.
Понятно, что «Все умные и все ВСЁ понимают», а самые-самые вообще этим продуктом не пользуются, но речь о последствиях.
Итак – предположим, что есть пожилой родственник, который попался на это и что дальше??
Суматошные попытки заблокировать счета, карты, недвижимость, что-то узнать «по официальным каналам» - а вот там-то и ждёт засада!
- по 112 послали в отделение полиции писать заявление и звонить в Госуслуги
- в Госуслугах «ии» отвечает про что ему велено, но не про то, что необходимо и просьбы переключить на оператора/человека/«естественный интеллект» игнорирует…

Если время уже позднее, то даже найти информацию о центрах «Госуслуг/Моих документов», работающих после 20:00 оказывается затруднительным – таже «ии»  требует что бы ей назвали адрес центра, и тогда она расскажет о его режиме работы… тыкать во все отметки этих центров на карте, что бы узнать режим работы – то ещё развлечение…,  а вот Алиса с этой задачей справилась быстро…
Но предположим, что «потерпевший» живёт в небольшом городке или его окрестностях, где центр «Госуслуг» закрывшись в четверг, начнёт работать только во вторник?

Можно сколько угодно вещать о необходимости развивать «суверенную имитацию интеллекта» и «суверенную МАХу», но если не защищать граждан от недостатка информации, то для «злоумышленников» будут всегда широко открыты двери для любых воздействий на граждан страны.

Мои попытки продвинуть создание «информационного пространства» для качественной, нужной, доверенной информации утыкаются в непонимание – «А зачем? Если будет вопрос, на него ответит «искусственный интеллект» …

Если вспомнить сколько нервов было испорчено после укуса клеща пару лет назад и невозможностью получить однозначную достоверную информацию…

И если предположить, что в подобные ситуации попадает большое количество не только просто «граждан», но и некоторые близкие люди – то может стоит отнестись к проблеме серьёзно??

Как построить РБПО без боли для AppSec и разработчиков? Расскажем на GoCloud Tech 2026

РБПО хотят выстроить все, но на практике процесс быстро упирается в несколько противоречий: AppSec тонет в ручном триаже, разработчики — в шуме находок, а готовые внешние решения не позволяют развивать процесс под потребности компании. Мы прошли этот путь и построили систему, в которой безопасность встроена в разработку по слоям: от локальной проверки до релизного среза, и при этом не тормозит ни одну из сторон. На докладе покажем архитектуру такого процесса и разберем, как умная автоматизация с ИИ-агентами помогает сделать его комфортным для участников, не искажая реальную картину на аудите.

Спикер:
Иван Басенко — Go-разработчик, Cloud.ru.

Трек: Разработка

📅 Когда: 15 октября в 14:30–15:00 мск.

👉 Зарегистрироваться

А пока ждете выступление, можете узнать, как мы готовились к сертификации процессов безопасной разработки: ГОСТ Р 56939-2024 на практике: что мы сделали, чтобы получить сертификат РБПО.

Разработчик Юстус Маттерн сообщил, что GPT-6 Astra удалось сжать более 600 МБ аудиоданных в 20 КБ.

«Я был наиболее удивлён её решением в задаче сжатия аудио по Колмогорову: Вместо того чтобы писать алгоритм сжатия, Astra разобралась, что мы синтезировали аудио программно, и просто провела обратную инженерию кода для него. Таким образом, ей удалось сжать более 600 МБ аудиоданных в 20 КБ», — пояснил Маттерн.

Когда в Kubernetes что-то сломалось: как ИИ-агент помогает искать проблемы в кластере

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

Чем сложнее становится инфраструктура, тем больше времени уходит на задачи вроде анализа состояния кластера, поиска отклонений и проверки типовых проблем. В этот момент возникает вопрос: можно ли часть такой работы передать ИИ?

На практике ИИ-агент для инфраструктуры — это уже не просто чат с подсказками. Он может получать данные о состоянии Kubernetes, работать с ресурсами кластера и помогать инженеру быстрее разобраться в ситуации.

На открытом уроке 1 октября в 20:00 разберём связку Kagent + Ollama: как подключить локальную LLM к агенту, какие возможности это даёт для работы с Kubernetes и какие DevOps-сценарии можно автоматизировать уже сейчас. Присоединяйтесь.

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

Мысли про DHH, Rails и AI в Ruby

Посмотрел выступление DHH с Rails World 2026. Ниже просто мои мысли по поводу того, что он говорил.

Никто не спорит что DHH гениальный маркетолог. Помню еще по истории когда он пересел с Mac на Linux и начал активно про него рассказывать, потом появились Omakub и Omarchy. В какой-то момент это местами звучало почти как проповедь.

С рельсой у меня сейчас похожее ощущение. DHH рассказывает, что Rails чуть ли не идеально подходит для эпохи AI: convention over configuration, мало кода, агенту проще разобраться в проекте, меньше токенов тратится, в этом есть логика. Но Надо помнить что Ruby является динамическим типизированным языком. Сам DHH статическую типизацию исторически не особо любит и, насколько я знаю, Sorbet или RBS активно не использует. Для человека отсутствие типов вполне может быть плюсом: быстрее пишешь код, не надо делать перегонять данные из одного типа в другой. Но для AI типы — это дополнительная информация. Поэтому мне не очень понятно, почему динамичность Ruby должна быть большим преимуществом именно в эпоху AI.

Но самое интересное не это. В том же выступлении DHH рассказывает, что в 37signals теперь фактически pencils down — код руками стараются почти не писать. И одновременно рассказывает, что HEY переписывают с использованием Rust. Причём, по его словам, получили огромную экономию CPU и памяти.

Сам DHH ещё говорит:

If I look at the past 21 years, over half of my work was Ruby code. This year, about 3%.

что раньше больше половины его кода было на Ruby, а в этом году что-то около 3%.

Получается довольно интересная ситуация, которая вызывает вопросики. Одно из главных преимуществ Ruby всегда было в том, что на нём очень приятно писать человеку. Синтаксис простой, код выразительный, Rails позволяет очень быстро собрать рабочий продукт. Но если код теперь в основном пишет агент, то насколько вообще важно, приятно ли человеку этот код писать?

DHH сам говорит примерно об этом же на примере Rust: смотреть на него ему не нравится, зато результат, который делает AI, нравится. И получается, что AI в каком-то смысле убирает одно из главных преимуществ Ruby. Раньше можно было сказать: да, Rust или Go быстрее, но Ruby позволяет разработчику быстрее получить результат, а теперь агент может довольно быстро написать и Rust, и Go.

При этом у тебя остаются статическая типизация, нормальная работа с многопоточностью и более предсказуемое потребление ресурсов. С Ruby всё сложнее. В MRI всё ещё есть GIL. Для обычного веба это далеко не всегда проблема, но если нужна CPU-параллельность, приходится уже думать про воркеры, дополнительные инстансы и так далее. А инфраструктура тоже стоит денег.

С Hotwire у меня похожее ощущение. Сама идея нормальная и для определённого класса приложений действительно удобная. Но DHH иногда очень хорошо умеет взять подход, который отлично работает в 37signals, и продать его так, будто именно так теперь должен писать весь интернет.

Поэтому DHH я всегда воспринимаю сразу в двух ролях. С одной стороны, это очень сильный инженер, который сделал один из самых крутых фреймворков. С другой, один из лучших маркетологов среди разработчиков. Он умеет взять своё мнение о разработке, превратить его в философию, дать ей красивую обёртку и заставить всех нас потом это обсуждать. Но после этого выступления я так и не понял, почему именно Ruby должен идеально ложиться на эпоху AI. Да, у Rails есть сильные conventions, мало шаблонного кода и агенту действительно может быть проще ориентироваться в проекте. Но при этом часть преимуществ Ruby была важна именно человеку, который этот код пишет. А если код всё чаще пишет агент, то эти преимущества уже не выглядят настолько очевидными.

Здесь кейс про очень интересное решение арбитражного суда, когда Роскомнадзор откровенно поставили в угол.

В чем суть?

Имело место оспаривание решения Роскомнадзора о привлечении Рекламодателя к ответственности за размещение рекламы с помощью платформы Telegram Ads в телеграм-канале "Автомобили *** " без наличия маркировки по двум публикациям.

Согласно правоприменительной практике, при отсутствии маркировки рекламы ФАС и Роскомнадзор всегда наказывают Рекламораспространителя (владельца интернет-площадки, где имело место размещение рекламы). Однако в случае размещения публикации через Telegram Ads делается исключение и привлекают Рекламодателя, так как специфика такова, что никто у Рекламораспространителя разрешения не спрашивает при размещении рекламы и платформа Telegram Ads тупо втыкает рекламную публикацию в ленту владельца телеграм-канала.

Так вот, в публикации фигурировали координаты сервиса по продаже автомобилей ООО "*****" как якобы Рекламодателя по мнению Роскомнадзора.

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

"- постановление № ПО-77/01/495 от 2 октября 2025 г. о назначении административного наказания в виде штрафа в размере 100 000 рублей,
- постановление № ПО-77/29/510 от 9 октября 2025 г. о назначении административного наказания в виде штрафа в размере 100 000 рублей..."

Как мы видим, по каждому нарушению имел место отдельный админпротокол. Роскомнадзор поступил достаточно жестко и объединять нарушения не стали в рамках единого административного протокола😠. В итоге штраф удвоился.

ООО "******" не согласилось с решением Роскомнадзора и подала в суд (дело А62-8924/2025)

"В рассматриваемых заявлениях ООО «*****» указывает на то, что:
- никогда не размещало никаких рекламных сообщений ни в приложении Telegram, ни на иных ресурсах в сети Интернет,
- никогда не заключало и не оплачивало каких-либо договоров на производство и размещение рекламных материалов с третьими лицами, сведения о которых указаны в ИС ЕРИР,
- никогда не регистрировало в приложении Telegram никаких Telegram-каналов, в том числе и канал под названием «Автомобили ***» по адресу: ..."

Ушли в полную несознанку, а Роскомнадзор упрямо гнул свою линию

👉 В итоге суд полностью оправдал ООО "*****" и посадил Роскомнадзор в лужу первый раз:

"Управлением Роскомнадзора указанные требования закона не выполнены: вывод ... сделан при неполно выясненных обстоятельствах"

второй раз

"Суд отмечает, что в представленной ФГУП «ГРЧЦ» информации отсутствуют сведения о лице, разместившим рекламное объявление по адресу ...."

и напоследок третий раз

"При этом административный орган не установил и не предпринял попыток установить лиц, разместивших рекламные объявления, сведения о заключенных договорах, способах оплаты и лицах, которыми произведена оплата за оказанные услуги по изготовлению и размещению указанных рекламных объявлений, ограничившись формальными сведениями о лице, от имени которого размещены рекламные объявления, - ООО «******»"

Такие дела)

Было замечено, что Роскомнадзор иногда делает слишком вольготные выводы по отдельным кейсам, надеясь, что в суд не пойдут. Ан нет...Не все такие покорные

😬 Мораль сей басни такова: всегда есть суд, чтобы обрубать аппетиты регулирующих органов, а то порой их заносит на поворотах

22 августа разработчик и глава студии Studio Bitdot Нас Накарус (вероятно, псевдоним) выложил в личном микроблоге концепт игры. Вернее, это была видеодемонстрация геймплея технического прототипа: игроку предлагалось найти иголку в стоге сена из 5 млн соломинок. Тем самым Накарус совершил одну из крупнейших ошибок своей жизни.

Страница игры на Steam открылась лишь 27 августа. Твит за неделю набрал полсотни миллионов просмотров. Концепт завирусился, игра набирает вишлисты, плейтест без проблем привлёк 23 тыс. игроков — осталось только выпустить Needle In A Haystack Simulator. Однако сейчас в Steam получается насчитать минимум десять самостоятельных клонов, несколько из которых уже играбельны.

Первой до релиза добралась Needle In A Haystack — A Time For Goats. Вышедшая 18 сентября игра предлагает получать деньги за перебранное сено, а затем тратить их на инструменты и сортировочные машины. Авторы почему-то стесняются статуса клона и яростно настаивают, что начали разработку ещё в начале мая, задолго до вирусного твита Накаруса. В качестве подтверждения прямо в блоге продукта прикреплены скриншоты SteamDB и логи Perforce, однако идентифицировать игру в чейнджлоге SteamDB как Needle In A Haystack получится лишь с 31 августа, когда приложение переименовали.

Среди других клонов — A Needle In a Haystack от Persidera Industries с датой релиза где-то в этом году, Needle In A Haystack от NoGlyph (выход планируется 29 сентября) и Story of The Needle In a Haystack от Rebel Pickle Games, которая должна выйти в IV квартале. В каждом из трёх случаев база SteamDB зарегистрировала приложение до твита Накаруса (1, 2, 3).

Другие клоны всплыли явно после вирусного видеоролика, и некоторые застолбили страницу в Steam крайне оперативно. Needle in a Haystack от Mr. Needle появилась в SteamDB спустя примерно два часа после приложения Studio Bitdot; ещё через несколько часов там зафиксировалась Find The Needle.

Не все клоны находчивы и оригинальны. CO-OP Needle Hunt с датой релиза 25 сентября вообще не имеет апгрейдов и инструментов; A Needle In A Haystack: Sorting Game должна выйти 25 сентября и основана на примитивном цикле сбора сена, продажи и улучшения сарая; как следует из названия, главный плюс Hay! One Billion! (заявлена на октябрь) — миллиард соломинок. В других случаях изменения яркие и неожиданные. 29 октября студия Grod Games в игре Needle in a Million Haystacks предложит решать задачу дробовиком, бензопилой, огнемётом и даже козлом.

Общеизвестно, что игровая индустрия откровенно перегрета, конкуренция в отрасли чудовищна. К примеру, только за неполные девять месяцев 2026 года в Steam уже вышло почти 20 тыс. игр. Обилие инструментов на искусственном интеллекте и вайбкодинг ситуацию только ухудшают. Сейчас сваять простенькую игру может любой желающий, просто попросив об этом Claude Code или Codex.

С 2024 года Valve требует от разработчиков заполнять в анкете о содержимом игры раздел о генеративном ИИ. Из перечисленных выше игр плашка AI Generated Content Disclosure есть только у A Needle In A Haystack: Sorting Game, где студия Thinflow Games указывает: ИИ использовался исключительно для создания некоторых изображений.

Понятно, что отсутствие плашки не означает, что к игре не приложил руку ChatGPT, Claude, Copilot или другой нейрогенеративный инструмент. Да и вообще, Valve просит декларировать прежде всего контент, созданный с помощью генеративного ИИ и попадающий к игроку: графику, звук, тексты, локализацию и так далее. Среди требований прямо указано, что средства эффективности инструментов разработчика в этот список не входят.

Стандартное объяснение эпохи быстрой ИИ-разработки — теперь важны идеи, а не их реализация. К сожалению, идею позаимствовать может любой желающий.

Утешение в этой ситуации тоже есть. Studio Bitdot имеет опыт выпуска игр: в ноябре 2025 года она довела до релиза Nano Neighbors, поэтому поиск иголки в стоге сена тоже наверняка получится доделать. К тому же Needle In A Haystack Simulator — это оригинал с десятками тысяч вишлистов.

Как управлять разработкой, если процессы и данные распределены по разным системам?

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

2 октября в 12:00 на вебинаре представим новый этап развития Deckhouse Development Portal.

Покажем, как Development Portal встраивается в разнородный ИТ-ландшафт и объединяет управление разработкой. Руководители получают больше прозрачности и инструментов контроля, а команды — портал самообслуживания для работы с инфраструктурными сервисами, инструментами и данными.

Разберём:

• расчёт стоимости инфраструктуры разработки отдельных бизнес-инициатив;

• стандартизацию процессов и требований безопасности;

• упаковку согласованного стека в готовые шаблоны;

• заказ окружений и баз данных по кнопке без ручной обработки заявок;

• адаптацию портала к процессам компании и интеграцию с используемыми системами.

Бонус: для участников вебинара проведём чекап процесса SDLC вашей команды.

👉 Зарегистрироваться

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

Статистика из книги "Двигатели, двигающие рынки: британский железнодорожный бум", описывающая поведение акций и процентных ставок 1820-1840-е годы, подтверждает опасения игроков рынка. В случае роста инфляционных ожиданий и начала роста процентных ставок, на рынках акций технологических лидеров может начаться сильная коррекция.

Хорошего дня! заходите на тг канал https://t.me/TradPhronesis

pear-crypt: клиентское шифрование

pear-crypt — небольшая TypeScript-библиотека, которая шифрует на клиенте и больше ничего не делает. На входе — пароль, PIN или Recovery Code, на выходе — ciphertext, который можно положить хоть в S3, хоть в Postgres. Пароль в этот blob не зашит.

• Библиотека: github.com/yamakca/pear-crypt

• Демо: github.com/yamakca/pear-crypt-demo

Лицензия MIT. Из зависимостей только hash-wasm: нативного Argon2id в браузере нет. AES-256-GCM и HKDF-SHA256 берутся из Web Crypto, без велосипедостроения.

Почему бы не собирать самому?

Типичный сценарий: сгенерить мастер-ключ, обернуть его паролем, тем же ключом зашифровать файл и отдельно мету. Если каждый раз клеить это из crypto.subtle, через год уже не вспомнить, был ли AAD, какой длины nonce и куда делась salt.

Здесь wire-format зашит в спеке и в тестовых векторах. Поменять раскладку байтов «чуть-чуть» нельзя: старый ciphertext просто перестанет открываться.

Под капотом

Мастер-ключ — 32 случайных байта. В открытом виде наружу не светится: только внутри AES-GCM-обёртки. Ключ обёртки получается из секрета через Argon2id: 32 МиБ памяти, два прохода, без раскладки на несколько ядер. Параметры KDF лежат в JSON рядом с nonce и ciphertext, чтобы было видно, чем именно заворачивали.

Дальше HKDF с пустой солью режет мастер-ключ на домены. В info зашито, для чего ключ: файл или метаданные. Строка вида pear-keep-file:{uid} — это и есть domain separation. Файл и его имя одним ключом не вскрываются: это разные info.

Сам файл — кадр версия | nonce 12 байт | ciphertext и GCM-тег. AAD pear-keep-file:{uid}:{bindAt} привязывает blob к идентификатору и поколению содержимого. Подменили uid или bindAt — тег не сойдётся, расшифровки не будет.

Метаданные — тот же кадр, другой ключ и JSON внутри: подпись, комментарий, время, etc. Recovery Code — 25 символов из алфавита без сомнительных похожих, группами по пять. Им заворачивается тот же мастер-ключ, но отдельно от пароля: пароль забыл — ищи бумажку с кодом.

Как проверяется, что байты не разъехались

В репозитории лежат docs/crypto/SPEC.md и JSON с векторами. Тесты бьют не только в прямую «зашифровал и тут же расшифровал», но и в зафиксированный ciphertext. Покрытие держится выше 90%. Поменяли src/ — пересобрали векторы через npm run export:vectors и закоммитили вместе с кодом. Иначе спецификация и реализация тихо разъедутся.

Чего в комплекте нет

Библиотека не решает, куда класть ciphertext, как устроен логин и когда блокировать сессию. Длину PIN тоже не проверяет. И кофе не варит.

Ошибки — PearKeepCryptoError с машинным кодом: wrongPassword, cannotDecryptMetadata и дальше по списку. Человеческого текста ошибок нет и не будет. Как и i18n.

Итого

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

Телефон на корпоративе — не всегда зло.

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

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

Как именно — показываем на примере огурчика Пиклза. Скролльте. Его телефон сегодня при деле.

Всегда в тонусе или 21-й и 117-й приказы ФСТЭК России

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

С 1 марта 2026 года, когда вступил в силу 117-й приказ ФСТЭК России, эта логика перестала работать. Он заменил «разовые действия» на 19 постоянных процессов защиты информации: контроль конфигурации, физическую защиту и др. Они должны идти непрерывно в каждой организации для оценки эффективности деятельности по защите информации и управления системой защиты информации. Кроме того, 21-й приказ ФСТЭК России для систем персональных данных тоже никто не отменял. 

Максим Куртин, директор департамента ИБ «Группы Астра», уверен, что сделано все не случайно «для галочки», а для того, чтобы держать систему защиты в тонусе. Она всегда должна быть готова к реагированию на новые угрозы. 

Звучит мощно, но на практике… ну вы сами понимаете. Нужно оборудование, сильно подорожавшее в 2026 году, нужно расширять штат ИБ, когда на рынке дефицит кадров. 

Как компаниям искать выход, обсудили в подкасте AM Live.

Слушать здесь: Rutube и VK Video. 

Агенты под наблюдением #1. Как я собрал свой велосипед

Всем привет 😎

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

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

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

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

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

Вот так и началось моё знакомство с AI-агентами. Сначала через недоверие.

Сейчас могу сказать, что у меня появилось понимание того, как программировать с их помощью. Но для меня это всё равно контролируемая AI-разработка.

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

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

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

Так начинается рубрика «Агенты под наблюдением». Буду иногда писать здесь просто и по факту о том, что происходит. Когда будет что рассказать.

***

А первая новость такая. У меня глюкнул DeepSeek 4.1 Flash.

Да, я сам удивился. Даже немного страшно стало. Как будто его закоротило, и он никак не мог прийти в себя. Он раз пятьдесят подряд спамил логами:

Думаю. Размышляю.

Потом извинялся за происходящее в чате и продолжал делать то же самое. Таких циклов было около трёх.

Я сильно удивился, мягко говоря. Такого ещё ни разу не видел: чтобы агент зациклился, сам это понял и ещё за это извинился.

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

Часа два, наверное, работали. Хорошая штука эта новая версия DeepSeek: быстрая, как Muse 1.3, умная, как 5.6 Sol, очень вежливая, не то что Muse, и с хорошей логикой работы.

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

А потом её заело. Как икота началась…

Не знаю, что это было. Я пока оставил её в покое. Пусть отдохнёт.

И да - команда /compact не помогала в OpenCode. Думаю, это какой-то баг из-за длинной сессии.

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

Практически все главные вопросы ИИ — вопросы философского характера. Это не значит, что ИИ само по себе не является цифровой сущностью и продуктом IT в классическом понимании. Но считать, что проблематика ИИ — это задача для технарей, это как считать, что познание о человеке является предметом биологии. Биология человека, безусловно, является частью науки о человеке — но наука о человеке вовсе не является частью биологии.

В каком-то смысле, я ждал этого поворота до того, как он случился (т.е. до того, как ChatGPT де-факто обессмыслил тест Тьюринга), когда писал, например «Как этика стала самой дорогой проблемой Кремниевой долины, а философия — её самым практичным решением». И всё же я не ожидал, на самом деле, что время этого перехода настанет так быстро. И тем не менее — мы уже в нём.

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

Ликбез. Как ИИ рисует картинки.

После пяти постов возникает закономерный вопрос: если ИИ все это время продолжает текст, то как он рисует картинки?

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

Для нас на фотографии кот. Для компьютера - много-много цветных точек. Работать с ними по одной так же разумно, как писать «межконтинентальная» по одной букве. Поэтому картинку тоже дробят на подобие токенов и учат модель работать уже с ними. Для компьютера картинка начинается примерно как огромная таблица чисел. Каждая точка хранит несколько значений: сколько в ней красного, зеленого и синего. Условный белый пиксель - 255, 255, 255, черный - 0, 0, 0, красный - 255, 0, 0. Фотография 1000×1000 превращается уже примерно в три миллиона чисел. Никакого «кота» среди них нет: есть только числа, расположенные в определенном порядке. А кот появляется уже из связей между ними - где проходят границы, какие участки похожи по цвету, что образует шерсть, глаз, ухо и в конце концов целую морду.

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

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

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

Генератор картинки снова и снова, несколько десятков раз, перетряхивает будущего кота целиком, пока тот наконец не станет похож на кота.

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

С текстом она снова и снова решает, какой кусочек добавить следующим. С картинкой - что изменить в шуме на следующем шаге.

И вот здесь наконец можно сформулировать основной принцип: мы не научили машину писать и не научили ее рисовать.

Мы научили ее выбирать следующее действие.

А текст или кот - это уже мелочи.