«Радикальная прямота. Как управлять людьми, не теряя человечности» Ким Скотт
Хорошая книжка-аспиринка (Стивен Кови называл «аспирином» книги, где не принципы рассматриваются, а рецепты даются). Бывает аспирин некачественный, а тут – прям хороший. И очень востребованный.
Книга – про обратную связь подчинённым от руководителя. У нас с этим прям беда какая-то, особенно в ИТ и похожих, розово-понических отраслях. Я понимаю, как сложилась культура сильно фильтрованной, лакированной, выхолощенной обратной связи, и не буду гундеть «вот в наше время было, у-у-у». Но проблема есть.
Вот вам простая сценка, как проблема выглядит. Пришёл сотрудник работать. Начальник его хвалит и поддерживает. Сотрудник что-то как-то делает, хорошо ли плохо ли. Начальник его хвалит и поддерживает. Сотрудник вдохновенный, работает, строит планы на карьеру и ипотеку. Начальник его увольняет.
Начальник не давал обратную связь. Точнее, давал, но только положительную – ту, что усиливает текущее поведение сотрудника. Но не давал отрицательную – ту, что меняет вектор или усилия. Хотя был недоволен тем, как сотрудник работает. Но не умел об этом сказать.
Вот таких историй – «всё же было хорошо, а потом взяли и уволили» - очень много. И причина, почти всегда – неумение начальника дать отрицательную обратную связь. С радикальной прямотой, если в терминах автора (спойлер: не так уж там и радикально).
Заглядывая чуть вперёд, скажу: проблема отрицательной обратной связи будет усугубляться. Потому что начальников, способных её давать – всё меньше. Как и сотрудников, способных её принять и что-то изменить в своей работе.
YouTube начал требовать отключить средства обхода блокировок для просмотра видео. Ограничение касается каналов с жёсткими региональными правами на контент: в первую очередь спортивных — «Формула 1», некоторые футбольные лиги, отдельные музыкальные лейблы. Это каналы, где рекламодатели платят за показы в конкретных странах, а правообладатели продают лицензии по регионам. YouTube обязан контролировать, из какой страны смотрит зритель, — иначе нарушаются условия лицензий.
Для обычных видео — летсплеев, обзоров, подкастов, авторского контента — ничего не изменилось. Средства обхода блокировок работают как прежде. Явление касается единичных каналов с крупными медиапартнёрами и существует уже не первый год — просто периодически всплывает у новых пользователей и вызывает волну тревоги.
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 и похожих инструментах, но хочет понять, где реально ускоряется, а где просто красиво сжигает контекст.
Прятать данные в 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, чистит систему.
может откатить все изменения, если в процессе что‑то пошло не так. Бэкап у вас точно будет.
работает без установки, без ограничений и полностью локально.
Как людям на самом деле НРАВИТСЯ нейрослоп. В том числе на Хабре.
Я изредка делаю кросспосты заметок из своего тг-канала в 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. Это особый случай, и это отдельная тема для разговора.
В Google сломали поиск — новый ИИ‑поиск сделал поисковик глупее. Теперь при коротких фразах вроде «отвали», «иди» или «стой» система воспринимает это как личное обращение и команду.
Что даёт: Пешеход видит самокат спереди, а не со спины. Даже если тупит в телефоне то боковым зрением замечает. Время среагировать есть.
Почему это почти рабочее правило:
· Не нужны миллиарды, разметка, камеры. · Всего два простых пункта:
Держись своей стороны.
Самокат едет навстречу пешеходу, а не догоняет сзади.
Главное ограничение (честно): Самокат всё равно быстрее. Но теперь хотя бы ты его видишь. Пешеходу понятно, самокатчику тоже (он знает, что его ждут спереди).
Итог: Правило не идеальное, но лучше, чем сейчас. Внедрить можно хоть завтра через памятки и привычку. Главное: не ездить рядом с бордюром.
llm-nano-vm v0.8.0 — выход в PyPI, валидация вывода и per-step таймауты
В прошлом посте мы описывали концепцию nano-vm — детерминированного ядра исполнения на базе конечных автоматов (FSM) для LLM-воркфлоу, где модель не является оркестратором, а лишь предлагает действия внутри жесткого графа \delta(S, E) \to S'.
За это время проект перерос стадию концепта. Мы опубликовали рантайм на PyPI и выпустили релиз v0.8.0. Ниже — сухой отчет о том, что конкретно было сделано, измененено и протестировано.
Что нового в v0.8.0
1. Выход на PyPI и релиз пакетов
Рантайм и сопутствующие компоненты полностью изолированы и доступны для установки:
pip install llm-nano-vm==0.8.0
pip install llm-nano-vm[litellm]==0.8.0 # поддержка провайдеров через LiteLLM
pip install nano-vm-mcp # MCP-шлюз
2. allowed_outputs — LLM enum guard
Добавлена жесткая валидация сырого вывода модели по белому списку до того, как значение попадет дальше в пайплайн.
Реализовано три политики обработки ошибок: fail (trace \to FAILED), skip (подстановка allowed_outputs[0]) и retry (перезапрос модели до max_retries).
3. timeout_seconds + on_timeout — таймауты на уровне шага
Решена проблема «зависания» внешних LLM API. Любой llm-шаг теперь можно ограничить по времени выполнения с политиками fail или fallback (подстановка дефолтного значения без падения автомата).
4. Стабилизация ASTEngine
Мы окончательно избавились от eval() для условий (condition). Написан кастомный песочный интерпретатор JSON AST. Любые системные вызовы и скрытые вызовы методов (вроде .lower()) теперь вызывают ASTEvalError на этапе компиляции графа.
Результаты бенчмарков (v0.8.0 · WSL2 · Python 3.12)
Тесты производительности на синтетическом адаптере (3 провайдера \times 5 сценариев \times 10k итераций) показали 1,096,500 операций и 0 нарушений контракта графа.
Crash consistency (BM-INT-07): При crash_rate=100% повторное воспроизведение (replay) пайплайна после симулированного падения рантайма выдает идентичный хэш трейса в 100% случаев.
Memory leak test (BM-INT-10): Пиковый RSS — 76.5 MB, аллокация — 3.62 MB для программ на 1000 шагов. Утечек памяти нет.
Валидация на реальных платежных API
Концепт успешно проверен на двух интеграционных сценариях (9/9 тестов пройдены):
MoMo Payment API v4: 3-way ветвление, HMAC-SHA256 IPN верификация, цикл пуллинга статуса с ретраями.
Stripe Payment API v1: Обработка 3DS-флоу (REQUIRES_ACTION), refund-пайплайн и верификация вебхуков.
В процессе интеграции со Stripe пофиксили важный баг: коллизию доменного статуса "PENDING" от API Stripe с внутренним сентинелом рантайма, который триггерил заморозку (SUSPEND) автомата.
Текущий фокус и краткосрочный роадмап
Phase 0: Разработка ProgramValidator для статического анализа графов до их выполнения (поиск циклов, недостижимых шагов и битых таргетов). Актуально, когда сами программы генерируются «на лету» внешними моделями.
Phase 1: Консистентность шлюза. Перенос StateContext между вызовами MCP в SQLite WAL (execution_contexts + UPSERT на каждый шаг). Это полностью уберет риск повторного списания (Double-Spend) при перезапуске процесса шлюза.
Phase 2: Интеграция OpenTelemetry для распределенного трассирования шагов.
Дилемма: 1. Раньше, когда кто-то патчил уязвимость в ПО с открытым исходным кодом, разработчик мог попытаться вполне успешно скрыть факт устранения уязвимости. А сегодня агент может посмотреть pr и нет-нет да и сообразить, насколько уязвимы машины, не установившие последний патч(все машины)
2. Но ведь существует и другая проблема - активно разрабатываемый(особенно новейший) софт всегда добавляет всякие уязвимости из-за вайбкодеров сегодня. Не только из-за вайбкодеров, проблема существовала и раньше, стойкое недоверие к самому последнему патчу постепенно развивается у некоторых людей. Лучше всего тренируется на arch linux* или любом другом rolling release distro. Nvim, если все патчи подгружать, как только они появляются, тоже помогает с этим. Взаимодействие с результатами бесплатной децентрализованной разработки с самыми разными мотивациями, квалификациями и интересами - это вот самый топ обучения, наверняка те, у кого это приводит к supply chain attack особенно квалифицировались.
Выход: ограничить использование нового софта без достаточной контейнеризации, при этом не торопиться за самым последним обновлением всего и вся. Пользоваться в основном, а лучше исключительно только проверенным боями ПО. Возможно это неочевидно многим, потому что индустрия ушла от понимания к запоминанию, от мастерства к экспертности, от любопытства к курсам. Не знаю, чему там "этично" сегодня учат на инфобез курсах, но есть много вещей, о которых как бы нельзя говорить, и это скорее всего будет закреплено на законодательном уровне, потому что политиков пугает возможность роста количества подозреваемых.
*Это не в огород арха. Arch linux у джуна всегда был зелёным флагом - человеку интересно, и отговорить можно. А вот если это миддл, то надо сначала выяснить, каким образом он его гоняет. Без раскрытия деталей, по умолчанию страшно с таким человеком работать
Что не так с DeFi и почему там до сих пор происходят взломы
Со стороны DeFi выглядит как будущее финансов: кошелёк вместо банка, смарт-контракт вместо посредника, а код вместо правил “по договорённости”.
Но в реальности DeFi это не одно приложение, а связка протоколов, смарт-контрактов, пулов ликвидности, оракулов, мостов, токенов управления и внешних интерфейсов. Пользователь видит кнопку Swap или Deposit, но под капотом может запускаться целая цепочка вызовов между контрактами. И чем больше таких зависимостей, тем больше поверхность атаки.
Одна из главных проблем - composability. В DeFi протоколы часто строятся друг поверх друга: lending-протокол использует один токен, DEX даёт ликвидность, оракул поставляет цену, мост переносит актив между сетями, а поверх всего этого работает ещё один интерфейс. Это удобно для разработки, но опасно для безопасности. Ошибка в одном элементе может стать проблемой для всей цепочки.
Отдельный риск - смарт-контракты. В традиционной системе подозрительную операцию можно остановить, откатить или вручную проверить. В DeFi логика другая: если транзакция валидна и контракт позволяет выполнить действие, сеть его выполнит. Поэтому баг в коде, ошибка в проверке прав, неправильная работа с балансами или уязвимость в математике протокола могут стоить не “небольшого сбоя”, а сразу миллионов долларов.
При этом атаки давно не сводятся к классическому “взлому”. Часто злоумышленник не ломает сервер, а использует экономическую механику протокола. Например, через flash loan можно взять огромный объём ликвидности в рамках одной транзакции, временно исказить цену в пуле, повлиять на расчёт залога или ликвидации, а затем вернуть заём до завершения блока. Формально всё может пройти по правилам контракта, но результат будет разрушительным.
Большая зона риска - оракулы. DeFi-протоколам нужно откуда-то получать цены активов. Если протокол берёт цену из слабого источника, например из тонкого пула с низкой ликвидностью, этой ценой можно манипулировать. Дальше начинается цепочка: неверная цена → неправильная оценка залога → ошибочная ликвидация или вывод средств.
Ещё одна больная точка - кроссчейн-мосты. Мосты соединяют разные сети и часто хранят или контролируют большие объёмы ликвидности. Это делает их идеальной целью. Проблема в том, что мост должен одновременно доверять событиям в одной сети и корректно выпускать или разблокировать активы в другой. Любая ошибка в валидации сообщений, подписях, мультисиге или логике relayer-ов может привести к катастрофе.
Есть и governance-риск. Многие DeFi-протоколы управляются через DAO и governance-токены. На практике это означает, что изменение параметров протокола, обновление контрактов или управление казной может зависеть от голосований, делегатов и концентрации токенов. Если управление плохо защищено, атакующий может повлиять не на код напрямую, а на правила игры.
Парадокс DeFi в том, что он создавался как trustless-система, где не нужно доверять посредникам. Но на практике пользователь всё равно доверяет: аудитам, разработчикам, оракулам, мостам, мультисигам, фронтенду, governance-механике и экономической модели протокола.
То есть доверие не исчезло. Оно просто переехало из банка в инфраструктуру.
Именно поэтому DeFi до сих пор остаётся одновременно самой интересной и самой уязвимой частью крипторынка. Чем больше открытости, автоматизации и связности между протоколами, тем сложнее сделать систему безопасной не только на уровне кода, но и на уровне экономики, ликвидности и пользовательского сценария.
