Все потоки

ЕЦБ экстренно собирает банки из-за ИИ, ломающего защиту за минуты

Европейский центробанк срочно созывает совещание с крупнейшими финансовыми институтами. Причина — появление ИИ-моделей, способных находить критические уязвимости в инфраструктуре быстрее, чем банки успевают их закрывать.

По информации Financial Times, регулятор обеспокоен новым поколением моделей вроде Claude Mythos, которые демонстрируют качественно иной уровень работы с кодом и системной архитектурой. Если раньше поиск 0-day уязвимостей требовал недель ручного аудита, то теперь ИИ справляется за минуты.

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

Для банковского сектора это критично. Финансовые системы строились десятилетиями, технический долг огромен, а миграция на новые стеки занимает годы. Многие core-системы всё ещё на COBOL и Java 8, где каждое изменение требует согласований и регрессионного тестирования. Скорость реакции физически не поспевает за скоростью обнаружения.

ЕЦБ, судя по всему, хочет понять масштаб угрозы и выработать общие меры. Возможные направления: ужесточение требований к мониторингу, обязательное использование runtime-защиты, пересмотр SLA на патчинг критических уязвимостей. Но главный вопрос остаётся открытым — можно ли вообще защищаться традиционными методами, когда противник на порядок быстрее.

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

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

Россию отключают от привычных серверов синхронизации времени и DNS-сервисов. Проверьте свои SMTP-настройки, вторичные DNS и прочее - возможно, они уже не работают.

Подарок начинающему руководителю

В кабинет зашла девушка в ослепительном платье. Руководитель отдела обратился к нам: «Ребята, знакомьтесь, это Марина, стажёр». Наш сугубо мужской коллектив притих: это что же, теперь и ругнуться будет нельзя?

Марина, выпускница МГТУ им. Баумана, быстро училась, разбиралась в продукте и писала качественный код.

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

Когда пришёл начальник отдела и объявил нового руководителя группы, ребята усмехнулись: это что же, наша Маринка — и тимлид? Через неделю шутки закончились: Марина начала активно осваивать новую роль.

За следующие 7 лет Марина выросла до руководителя службы разработки API «Яндекс.Карт», а позже стала директором по продукту рободоставки в Яндексе.

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

Книга называется «Мама, я тимлид». Автор — Марина Перескокова.

«Радикальная прямота. Как управлять людьми, не теряя человечности» Ким Скотт

Хорошая книжка-аспиринка (Стивен Кови называл «аспирином» книги, где не принципы рассматриваются, а рецепты даются). Бывает аспирин некачественный, а тут – прям хороший. И очень востребованный.

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

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

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

Вот таких историй – «всё же было хорошо, а потом взяли и уволили» - очень много. И причина, почти всегда – неумение начальника дать отрицательную обратную связь. С радикальной прямотой, если в терминах автора (спойлер: не так уж там и радикально).

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

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

Осваиваем вайб‑кодинг с нуля бесплатно — вице‑президент Wix запустил платформу Zero to Claude Code, которая научит кодить в паре с нейронками:

• внутри 150 интерактивных уроков и 14 уровней;

• платформа проведёт вас от основ работы в терминале до настройки MCP и автономных агентов;

• всё написано простым и понятным языком;

• при этом курс качественный — его оценил даже Борис Черни, создатель Claude Code.

YouTube начал требовать отключить средства обхода блокировок для просмотра видео. Ограничение касается каналов с жёсткими региональными правами на контент: в первую очередь спортивных — «Формула 1», некоторые футбольные лиги, отдельные музыкальные лейблы. Это каналы, где рекламодатели платят за показы в конкретных странах, а правообладатели продают лицензии по регионам. YouTube обязан контролировать, из какой страны смотрит зритель, — иначе нарушаются условия лицензий.

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

⚙️ ASMLings - подробный гайд на русском

ASMLings - это набор из ~32 коротких упражнений на ассемблере Intel 8086, выстроенных по возрастанию сложности: от mov ax, 0x1337 до 32-битного сложения через carry flag, циклов, подпрограмм, работы с памятью и стеком.

Полный русскоязычный гайд по asmlings - интерактивной песочнице для изучения ассемблера Intel 8086, в которой 16-битный x86-эмулятор написан на Rust. 

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

Думаю, может быть интересно многим.

Представлен проект anitabi - это карта реальных мест из японских аниме. Anitabi собирает локации прямо в Google Maps: станции, улицы, магазины, школы и целые районы, где происходили сцены из сериалов и фильмов.

Можно открыть тайтл, найти точку и буквально повторить кадр из мульта в реальной жизни. Там уже тысячи локаций по всей Японии, а база пополняется комьюнити вручную. Люди буквально сидят и сравнивают кадры из аниме с реальными улицами. А ещё у проекта открытый API.

Microsoft выложила в open source AI Engineer Coach - плагин, который оценивает, насколько адекватно вы работаете с агентами и не сливаете токены в пустоту.

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

Отдельно плагин проверяет 45 анти-паттернов. Например, если вы не используете plan mode, гоняете мощные модели на мелкие задачи, повторяете одни и те же действия руками или плохо готовите проект под работу агентов - он это подсветит.

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

Всё работает локально и бесплатно. Microsoft отдельно подчёркивает, что данные никуда не отправляются.

Выглядит как полезная штука для тех, кто уже живёт в Claude Code, Codex, Cursor и похожих инструментах, но хочет понять, где реально ускоряется, а где просто красиво сжигает контекст.

https://github.com/microsoft/AI-Engineering-Coach

Прятать данные в TLS-трафике: как выглядит настоящий стелс

Больше 70% интернет-трафика — зашифрованный TLS. Это не баг, это фича: тонны HTTPS-соединений, WebSocket-потоков, мобильных приложений и игровых клиентов создают идеальный фон для передачи данных без привлечения внимания.

Идея простая: если нужно спрятать дерево, прячь его в лесу. В случае интернета этот лес состоит из миллионов TCP/443-соединений, которые выглядят настолько обычно, что именно это делает их интересной средой для экспериментов.

Почему TLS-трафик — удобная маскировка

TLS скрывает содержимое пакетов. DPI может видеть метаданные — размер, timing, SNI в Client Hello, но не payload. Если ваше соединение выглядит как обычный HTTPS-запрос или долгоживущий WebSocket, оно сливается с фоном.

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

Где это может быть полезно

• Обход блокировок в странах с жёстким DPI — если трафик неотличим от обычного HTTPS, его сложнее фильтровать

• Распределённое хранилище данных в трафике — архивные данные можно держать не на диске, а в виде пакетов, циркулирующих между нодами

• Covert channels для исследований в области безопасности — тестирование систем мониторинга и обнаружения аномалий

Технические ограничения и риски

Главное ограничение — timing и packet size analysis. Если трафик выглядит нетипично по объёму или интервалам, статистические методы могут его вычислить. Traffic shaping помогает, но не решает проблему полностью.

Второе — легитимность. Если используешь чужую инфраструктуру или протоколы без согласия провайдера, это может нарушать ToS. В корпоративной среде такие эксперименты быстро привлекут внимание security-команды.

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

В итоге: технически возможно, но требует продуманной архитектуры, понимания сетевых протоколов и готовности к тому, что решение будет хрупким. Как proof-of-concept — интересно. Как production-инструмент — сомнительно.

Открытый проект OptimizerDuck позволяет очистить Windows 10/11 от мусора и бесполезных процессов (телеметрию, рекламу, Copilot, все фоновые сервисы и ненужные приложения):

• оптимизирует ПК для работы и игр, настраивает GPU и производительность процессора, работает с менеджером автозагрузки, удаляет встроенный bloatware, чистит систему. 

• может откатить все изменения, если в процессе что‑то пошло не так. Бэкап у вас точно будет.

• работает без установки, без ограничений и полностью локально.

Кто такой UX/UI разработчик на практике?

Чем он занимается в реальной приземленной разработке?

P.S. делаю программу для завода и глазам больно от интерфейса

Как людям на самом деле НРАВИТСЯ нейрослоп. В том числе на Хабре.

Я изредка делаю кросспосты заметок из своего тг-канала в threads и на хабр, чтобы выйти из пузыря умных читателей канала. На хабре очевидно короткие посты вместо статей не заходят. Более того, мои плотные посты с нумерацией почти каждый раз обвиняли в AI слопе (хотя конечно это несправедливо).

"Ну ладно!" подумал я. Сделал эксперимент: взял один из недавних постов про статистику фейковых гитхаб-звезд, попросил клод "распиши до размеров небольшой статьи", убрал буквально пару формулировок и просто опубликовал на хабре: https://habr.com/ru/articles/1025032/

Статья вошла в топ-5 за день 🥲

То есть текст стал очевидно ХУЖЕ, но людям понравился больше. Никто не поставил минус за подозрение на нейрослоп (там можно видеть причины). А редакторы хабра добавили статью в соцсети (включая тг канал), чего ни разу не случалось с моими кросспостами.

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

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

Как выйти из кризиса перегрузки без найма: опыт двухнедельного Stop the Line

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

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

Проблема не в скорости разработки, а в том, что система перестала справляться с объёмом параллельных задач. Когда в работе одновременно 20 фич, а команда реально может закрыть 5 в спринт — каждая задача тормозит остальные. Контекстные переключения съедают до 40% времени, код-ревью затягиваются, интеграция превращается в русскую рулетку.

На практике видел это десятки раз. Компания вводит «режим ускорения»: сокращает ревью, откладывает рефакторинг, пилит MVP параллельно с production-фиксами. Через месяц скорость не растёт — падает. Команда тушит пожары вместо того, чтобы делать продукт.

Что даёт Stop the Line

Двухнедельная остановка конвейера — это не каникулы. Это хирургическое вмешательство: временно прекращаешь приём новых задач и закрываешь то, что уже в работе. Параллельно команда разгребает техдолг, который мешает двигаться дальше: чинит CI/CD, актуализирует документацию, закрывает критичные уязвимости.

Ключевой момент — это не просто «месяц на техдолг». Это сознательное решение восстановить пропускную способность. За две недели команда из условного «ФинТеха» может:

• Закрыть 15 из 20 зависших фич — вместо того чтобы держать их в работе ещё месяц

• Разобрать backlog инцидентов и понять, какие из них — симптомы одной проблемы

• Автоматизировать то, что отнимает 2-3 часа в день у каждого разработчика

• Обновить зависимости, которые тянут за собой уязвимости и блокируют миграцию на новые версии

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

Как продать это бизнесу

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

Опыт показывает: после Stop the Line скорость delivery возвращается к нормальной в течение месяца, а качество выходит на новый уровень. Главное — не скатываться в ту же воронку снова. Установить WIP-лимиты, внедрить метрики cycle time, договориться с бизнесом о реалистичных планах.

Ограничение подхода — он работает, если команда ещё не выгорела окончательно и проблема в процессах, а не в людях. Если половина уже ищет новую работу — Stop the Line не спасёт. Но если команда готова работать, просто задыхается под грузом — это работает.

Удалено удалено удалено

удалено

Удалено удалено удалено

Обновил вчера Ubuntu 25.10 на 26.04. В последние два года я обновляю Ubuntu при каждом новом выпуске, начиная с 23.10 насколько помню. И никаких проблем ни во время обновления, ни после него до этого не возникало. Вчера же столкнулся с несколькими неприятностями:

• Объём загружаемых пакетов вырос с обычных 2 Гб до 4 Гб! Вероятно у вас будет меньше, ведь это зависит от установленных вами пакетов, но если судить относительно прежнего объёма, то скачёк потребления трафика с учётом мобильного доступа не радует. Скаченные пакеты я сохранил, чтобы на других ноутбуках с Ubuntu не пришлось снова качать 4 Гб. Раньше я так не делал.

• Во время установки пакетов рабочий стол заблокировался с сообщением, что у меня нет прав root, чтобы что-то сделать, что именно не написано. Причём нажатие на Отмена блокировку не снимало, и окно сообщения оставалось открытым. Похоже на какой-то баг Gnome, Resolute или где-то глубже в системе. Дождался, когда индикатор диска и вентилятор успокоятся, в надежде, что обновление закончилось успешно, переключился на консоль и сделал reboot.

• После первой загрузки и входа в Gnome рабочий стол завис. Снова переключение в консоль и reboot. После второй перезагрузки Gnome заработал. Это ещё один явный баг.

• Теперь после каждого включения с нуля или после сна, не важно, запускается какой-то процесс localsearch, который интенсивно работает с диском и греет процессор. Причём процесс ветвится. Как отключить не понятно. Подождав полчаса сделал kill по номеру процесса localsearch. И вынужден делать это каждый раз.

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

В предыдущих выпусках был ещё баг с thumbnailer, который при открытии в Nautilus папки с большим количеством фото, выжирал остатки памяти, что приводило к торможению всей системы намертво и последующего принудительного жёсткого отключения питания (известный баг Linux, который за десять или более лет так и не исправлен). Как я понял, в 26.04 thumbnailer был заменён на что-то другое, и я пока ещё не поимел проблем с большими папками с фото. Но посмотрим…

UPD Посмотрел, что это за localsearch. Похоже, что это часть Gnome. Поэтому стандартными средствами управления сервисами его не отключить. Запускается при входе в Gnome. Как эту ненужную мне и вредную с точки зрения энергопотребления и шумозагряднения штуку выключить в Gnome? (В комментарии дали совет, но в первый раз нужно всё-таки сделать kill для процесса, одного его отключения не достаточно. После перезагрузки процесс localsearch уже не будет беспокоить.)

Резюме Ещё до обновления я начал искать альтернативы Ubuntu, понимая что запросы системы к процессору и памяти растут, Ubuntu всё больше походит на bloatware и corporate, а переходить на более новое железо я не собираюсь. Пока в качестве альтернатив рассматриваю: antiX, Devuan, Gentoo, Void, Guix, NetBSD, OpenBSD. Этот набор обусловлен тем, что мне нужно, чтобы система поддерживала 32-разрядность. И я хочу иметь на 32- и 64-разрядных системах одинаковый опыт и навыки работы с ними. А какие альтернативы Ubuntu используете вы? Что скажете про мой список альтернатив? Кстати, до полного перехода на Ubuntu я также работал в последние годы с ElementaryOS, Manjaro, Fedora. Пробовал antiX, Void, NixOS и Guix. По большому счёту они отвергнуты были в том числе по тем же причинам, что теперь и Ubuntu, Кроме antiX, Void и Guix. Это особый случай, и это отдельная тема для разговора.

(с) Симоненко Е.А., 2026

В Google сломали поиск — новый ИИ‑поиск сделал поисковик глупее. Теперь при коротких фразах вроде «отвали», «иди» или «стой» система воспринимает это как личное обращение и команду.

Представлен открытый ИБ-проект bumblebee от команды Perplexity для защиты ПК на Linux и macOS:

• проверяет файлы, установочные сборки, библиотеки, фреймворки

• сканирует пакетные менеджеры, плагины для IDE, браузерные расширения, конфиги Claude, Cursor, Coder и других ИИ‑инструментов.

• сканирует метаданные.

Решение конфликта «пешеход vs самокат» на тротуаре без стройки и денег.

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

· Пешеходы → правостороннее движение. · Самокаты → левостороннее движение.

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

Почему это почти рабочее правило:

· Не нужны миллиарды, разметка, камеры. · Всего два простых пункта:

1. Держись своей стороны.

2. Самокат едет навстречу пешеходу, а не догоняет сзади.

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

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