Все потоки

20 открытых вебинаров OTUS: архитектура, DevOps, ML, аналитика, Go, безопасность и управление

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

В программе — метрики технического директора, управление ресурсами, BPMN, Kafka Streams, ClickHouse, Deep Learning в проде, Nginx/Angie под нагрузкой, Kubernetes, Go, пентест, ИИ‑агенты и DevSecMLOps.

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

12 мая

• 18:00. «Какие метрики использует технический директор?» — Записаться

• 19:00. «Управление ресурсами в условиях жестокого дефицита» — Записаться

• 20:00. «Кастомизация интерфейса Bitrix24: создание уникальных пользовательских решений» — Записаться

13 мая

• 18:00. «Yahoo Finance и не только — работа с российскими торговыми площадками» — Записаться

• 18:00. «Обзор нотации BPMN 2.0» — Записаться

• 20:00. «ClickHouse для аналитики больших данных: практические кейсы и связь с NoSQL-экосистемой» — Записаться

• 20:00. «Kafka Streams DSL» — Записаться

• 20:00. «Как выкатить в прод Deep Learning модели» — Записаться

14 мая

• 18:00. «Графическое описание бизнес-процессов и требований» — Записаться

• 19:00. «Архитектор как модератор изменений: как проводить архитектурные решения через стейкхолдеров» — Записаться

• 19:00. «Оптимизация Nginx и Angie под высокие нагрузки» — Записаться

• 20:00. «Матрица компетенций для лида поддержки» — Записаться

• 20:00. «Вкатиться в пентест в 2026: кому это реально и как этому учиться на практике» — Записаться

• 20:00. «Взаимодействие с базой данных и миграции на Go» — Записаться

• 20:00. «ИИ-агенты для юристов: настраиваем автономного ассистента с доступом к договорам и базе знаний» — Записаться

18 мая

• 20:00. «Корреляция признаков. PCA» — Записаться

• 20:00. «Деплой на стероидах: ускоряем доставку через Golden Path» — Записаться

• 20:00. «Go внутри: планировщик» — Записаться

• 20:00. «Основы Kubernetes: архитектура и абстракции» — Записаться

• 20:00. «DevSecMLOps: как безопасно внедрять ИИ в процессы разработки и эксплуатации» — Записаться

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

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

dpi-checkers — open-source инструмент от hyperion-cs — показывает, каким именно методом ваш провайдер режет трафик: RST после 16-го пакета, SNI-дроп или CIDR-вайтлист. Прогнал на трёх подключениях — картина неожиданная.

Пользователи рунета давно заметили: «интернет дома» и «интернет у бабушки в области» — это два разных интернета. YouTube грузится на одном провайдере и не грузится на другом. Discord висит на мобильном, но работает на проводе того же оператора. Это не случайность и не деградация сети — за каждым таким симптомом стоит конкретный технический механизм на L4/L7.

Набор тестов dpi-checkers (часть на Go как CLI-утилита, часть в браузере на JS) позволяет идентифицировать метод фильтрации, который применяет конкретный ISP. Я прогнал проверки на трёх подключениях: домашнем у федерального провайдера, мобильном у одного из «большой четвёрки» и через знакомого в другом регионе.

Пять методов которые реально встречаются в РФ. DPI — не одна технология, а класс решений. Современный Deep Packet Inspection анализирует не только заголовки L3/L4, но и содержимое L7: по особенностям TLS handshake система определяет сервис назначения даже без знания IP и применяет политику — пропустить, сбросить, замедлить. Когда в новостях пишут «провайдер замедляет YouTube» — это упрощение. Технически применяется один из нескольких методов, и симптомы у пользователя разные в зависимости от метода.

• CIDR-вайтлисты — блокировка по IP-подсетям. Трафик к адресам вне «доверенного» списка не пропускается. Жёсткий метод, чаще встречается на мобильных тарифах 4G+/5G.

• TCP 16-20 (rps-разрыв) — DPI ждёт первые 16–20 пакетов TLS-сессии, детектирует SNI нежелательного хоста и отправляет RST обеим сторонам. Клиент видит «сайт упал», хотя сервер жив. Основной механизм замедления YouTube в 2024–2025.

• Подмена DNS-ответов — перехват запроса на уровне провайдера, возврат заглушки или 0.0.0.0. Старый метод, обходится DoH/DoT, но используется как первая ступень.

• SNI-блокировка — поле Server Name Indication в TLS handshake передаётся открытым текстом до установки шифрованного канала. DPI читает его и сбрасывает соединение по домену.

• QUIC-блокировки — UDP/443 режется целиком или деградирует, чтобы клиент откатился на TCP, где уже работает SNI-фильтрация.

Что показал dpi-checkers на трёх подключениях. Домашний федеральный провайдер — TCP 16-20 в чистом виде: соединение с рядом зарубежных сервисов рвётся ровно после 16–18 пакетов в TLS-сессии, RST приходит от «провайдерского» адреса, не от сервера назначения. Мобильный оператор — комбинация SNI-дропа и QUIC-блокировки: UDP/443 не проходит вообще, TCP-соединение с теми же хостами рвётся по SNI до завершения handshake. Региональный провайдер через знакомого — DNS-подмена как первая ступень плюс CIDR-ограничения на часть подсетей Cloudflare.

Исследования Citizen Lab и проект net4people фиксируют схожие паттерны по всему рунету — методы стандартизированы, оборудование у операторов в основном одно и то же (ТСПУ от Эшелона и аналоги). Различия между провайдерами — в настройке порогов и в том, какие именно списки им спустили.

Для меня как человека, который строит корпоративные сети, это не абстрактный research. Когда у сотрудника «не работает» корпоративный сервис — первый вопрос теперь не «а VPN включён?», а «какой метод фильтрации у его провайдера?». TCP RST лечится иначе, чем DNS-подмена, и иначе, чем QUIC-блок. dpi-checkers даёт ответ за пять минут вместо часа диагностики вслепую.

TG @CIOlogia

Новый ИИ на старые процессы — это турбодвигатель на телегу.

Красиво. Дорого. Быстро. Но всё равно телега.

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

Реальный эффект начинается с другого вопроса: а зачем эта работа делается именно так?

Одна финансовая компания задала его — и получила минус 59% нагрузки и минус 40% затрат. Не от нового инструмента. От нового мышления.

Разбейте процесс на реальные действия. По каждому — три вопроса:

— Зачем это существует?

— Человек или ИИ справится лучше?

— Можно ли убрать вообще?

Третий вопрос даёт самый большой эффект. И именно его никто не задаёт.

Начните этот разговор до того, как купите следующий ИИ-инструмент.

Куда податься если 6 стало 9? "Чёрный слон" уничтожит многих, кто любит свою профессию, кто вникал ещё с детских кружков по информатике. И уничтожит не от того, что, как многие говорят "ИИ делает работу лучше", а просто из-за того, что мнение "массы" взяло верх, и нормальному человеку с этой глупостью невозможно смириться. Планомерное ли это уничтожение или ошибка в управлении, я не знаю. Может быть это первый акт мелодраммы о том как "новая школа IT" навайбкодила, а потом всё сломалось и пришли старички которые всё спасли и все начали жить в мире. Может быть действительно бизнес поверил, что можно обойтись без "технарей", тогда стоит отметить как ловко бизнес избавляется от того, что по его мнению перестало приносить пользу, получается "каждый только за себя". Про себя могу сказать одно: кроме отвращения к IT, к бизнесу, к подходам ими используемым у меня ничего нет. Как и нет желания больше барахтаться в этом болоте.

А какие планы у вас? Задумываетесь ли вы о смене профессии?

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

То есть, либо сообщество умных людей глупеет с ростом популярности, либо движение шизов умнеет с ростом популярности.
На рассвете программирования, в 20-м веке, по существующим данным, средний IQ был 130 у типичного нерда в этом деле. По существующим данным опять же, где-то в 2011, и чуть позже, средний уровень интеллекта программиста упал до 115. В 2025 году он упал до 105(это по миру).

Об исходящих леммах хоть книгу пиши. Правило №1 - если нет собственного мнения, то слушать стоит только дедов. Исключения из этого правила конечно же существуют, но пока нет понимания, их остаётся только игнорировать

С внедрением AI сейчас происходит странная штука.

• С одной стороны — он уже реально умеет делать работу: писать код, разбирать документы, принимать решения.

• С другой — в реальных компаниях он почти нигде нормально не встроен в текущие бизнес процессы.

И дело не в том, что «ещё рано».
Скорее наоборот — его уже слишком много, но он как будто не туда прикручен.

Обычно это выглядит так: есть какие-то процессы, BPM, роли, доступы — всё строго и по правилам. И рядом появляется AI — чатик, copilot, агент.
Им можно пользоваться, но он как бы… вне системы.

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

Это как сотрудник-зумер — не знаешь, что от него ждать.

В итоге получается странный компромисс:
— либо даём людям пользоваться AI, но тогда теряем контроль
— либо запрещаем/ограничиваем, и тогда теряем пользу

И вот здесь, кажется, и есть основной затык.

Проблема не в самом AI.
Проблема в том, что он живёт отдельно от enterprise-реальности.

Идея Agentic Enterprise в том, чтобы перестать воспринимать AI как что-то внешнее — как инструмент, даже как помощника. Пора ему стать участником процессов.

То есть буквально:

• у него должна быть роль в оргструктуре

• у него должны права (а не просто втихаря переданные креды)

• он получает задачи и выполняет их через те же процессы, что и люди

Что от этого меняется?

Во-первых, появляется контроль.
Любое действие — это часть процесса. Его можно посмотреть, понять, откатить.

Во-вторых, появляется контекст.
AI действует не абстрактно, а в рамках роли, данных и конкретной задачи.

Ну и в-третьих — он перестаёт быть чем-то отдельным.
Это просто ещё один исполнитель.

И, кажется, это довольно важный сдвиг.

Потому что без него AI так и останется либо игрушкой, либо «серым инструментом», который все используют, но никто не контролирует.

А с ним он становится частью операционной модели.

Подписывайтесь на канал Agentic Enterpise — о жизни ИИ-агентов в кровавом энтерпрайзе

Вход в IT платный

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

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

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

Вообще довольно странно, что всё перешло от "плачу за универ чтобы работать" до "плачу за работу чтобы работать". Опыт из учреждений образования больше не в почёте? А зря.

Также хочу отметить что инструменты которыми ты будешь пользоваться не всегда будут бесплатные. Кто-то может сказать "Ну я же использую бесплатный VS Code", да но разработка не ограничена часто одним IDE, потому другие тулы часто имеют ограничения которые снимаются лишь монеткой. К этому же относится разработка с ИИ. На текущий момент поста закручиваются гайки по лимитам и моделям, потому что компаниям уже нужно получать доход, а мы такие хитрые не хотим пополнять бюджеты. Во и получается что плати, либо используй свой ум.

А теперь когда мои мысли подошли к концу приглашаю в комментарии поделиться своим мнением на этот счёт и хорошего тебе дня =)

Финдиректор видит два отчёта по выручке за один год: 150 млн в старой системе и 145 млн в новой CRM. Виноватыми назначают айтишников. Но проблема не в миграции.

Разрыв в 5 млн рублей между системами — классический симптом того, что я называю «иллюзией темпоральности». Суть простая: система хранит только последнее известное состояние данных, игнорируя то, что бизнес непрерывно меняется. Клиент переехал — адрес обновился, но старые сделки теперь «переехали» вместе с ним. Товар прошёл ребрендинг — и вся его история числится под новым названием. Итог: исторические отчёты перестают быть историческими.

Это не баг конкретной CRM и не кривой скрипт миграции. Это архитектурное решение, принятое по умолчанию — хранить только актуальное состояние. И оно ломает аналитику задним числом.

Что такое SCD и почему это не академия. Slowly Changing Dimensions — методология, формализованная Ральфом Кимбаллом ещё в эпоху классических хранилищ данных. Она описывает стратегии того, как измерение (клиент, товар, сотрудник, регион) реагирует на изменение своих атрибутов. Выбор стратегии — архитектурное решение, которое определяет, можно ли будет восстановить состояние данных на любую дату в прошлом.

• Тип 0 — атрибут неизменен: дата рождения, дата открытия счёта. Никогда не перезаписывается.

• Тип 1 — перезапись: новое значение затирает старое. Подходит только для исправления ошибок ввода. Для реальных бизнес-изменений — гарантированный источник расхождений в отчётах.

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

• Тип 3 — отдельный столбец для предыдущего значения: даёт сравнение «было/стало», но не полноценную историю.

• Тип 6 — гибрид (1+2+3): аналитики получают и текущий срез, и полную историю одновременно.

Почему Тип 2 — это не опция, а обязательство. В российских компаниях, которые сейчас массово мигрируют с SAP и других западных систем, именно SCD Тип 2 оказывается тем местом, где теряются данные и репутация IT-команды. Если при миграции применялся Тип 1 — вся историческая аналитика пересчиталась под текущее состояние справочников. Отсюда и расхождения, которые невозможно объяснить без понимания этой механики.

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

Для CIO это не вопрос технологий — это вопрос доверия к данным. Когда финдиректор видит расхождение в 5 млн, он теряет доверие к новой системе. Восстановить его потом значительно сложнее, чем заложить правильную архитектуру с самого начала. Миграционные проекты без явного решения по SCD — это отложенный конфликт между бизнесом и IT, который случится ровно в момент первого серьёзного аудита.

TG @CIOlogia

Гуманоидный робот (Unitree Robotics модель G1) стал буддийским монахом в Южной Корее. Робот получил имя Габи в буддийском храме в Сеуле и принял участие в модифицированной церемонии инициации, где он поклялся уважать жизнь, подчиняться людям, мирно относиться к другим роботам и предметам. Для храма это первый случай участия робота в церемонии инициации, когда последователи клянутся в преданности Будде и его учениям.

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

Почему так надоели статьи и новости про ИИ? Да епрст...

Новости?... Читаешь по 3-4 раза одинаковые темы. Хоть удосужились бы посмотреть в ленте, написали ли уже об этом? Как будто все разом захотели стать знаменитыми, а ничего кроме перепостинга новостей не придумали...

Статьи?... Все пишут одно и то же. Или пересказывают темы, которые ночью обсуждают с Gemini под подушкой, и лучше бы спали, хоть мозг в норму пришел бы... Или пишут о "базе", на тему которой уже 500 статей на хабре... Хоть толика "новой информации была бы"... Тот самый Information gain... Зачем разжевывать то, что уже давно разжевано и переварено?

---

Это был немного «крик души»... И чтобы немного разрядить обстановку, ловите чуток улыбки. Анекдоты (от ИИ и про ИИ):

Лучшая статья про ИИ
Заголовок: «Как ИИ поможет вам сэкономить 2 часа в день?».
Текст: «Просто не открывайте эту статью. Сэкономлено: 10 минут».

Будущее, которое мы заслужили
Совет: «ИИ напишет за вас книгу/статью/пост за 10 секунд».
Реальность: Один ИИ сгенерировал мусор, второй ИИ его прочитал и сделал краткий пересказ, а третий ИИ на основе этого написал рецензию. Человечество официально исключено из чата. Мы просто оплачиваем счета за электричество, пока два алгоритма обсуждают пустоту.

---

P.S. Ну а чтобы в моем посте был хоть какой-то Information gain - ловите формулу анекдотов для ИИ. Мне пришлось штук 20 пересмотреть, чтобы +- средние выбрать, но все равно интереснее, чем листать shorts или читать одни и те же новости по 3-му разу.

Где:
- E (Expectation / Ожидание): Степень уверенности слушателя в том, куда движется сюжет.
- C (Context / Контекст): Набор стереотипов или бытовых ситуаций, понятных всем.
- P (Paradox / Парадокс): Резкий поворот логики (пуансон).
- t (Timing / Тайминг): Краткость. Чем дольше вы ведете к развязке, тем сильнее должен быть парадокс.

Скормите формулу в ЛЛМ и можно клацать кнопку "хочу еще" до посинения

Лаборатория Касперского проверила 231 миллион паролей из даркнет-утечек 2023–2026 годов: 60% взламываются менее чем за час, почти половина — меньше чем за минуту.

Одна видеокарта RTX 5090 перебирает MD5-хеши со скоростью 220 миллиардов в секунду — на 34% быстрее, чем RTX 4090. Арендовать такую мощность в облаке можно за несколько долларов в час. Это уже не академическая атака — это промышленный процесс.

Цифры, которые неприятно читать. По данным SecurityLab, исследование Лаборатории Касперского разбивает 231 миллион паролей примерно так: 45% ломаются за минуту, ещё 15% — в пределах часа, и только 23% требуют больше года непрерывного перебора. Оставшиеся — где-то посередине. Три четверти паролей, которые люди считают «нормальными», не переживут рабочего дня атакующего.

Почему умные алгоритмы выигрывают у человека. Дело не только в железе. Современные инструменты взлома обучены на тех же утечках — они знают, что пользователи заменяют «a» на «@», добавляют год рождения в конец и ставят восклицательный знак, думая, что это хитро. Алгоритм проверяет эти паттерны первыми. Радужные таблицы с миллионами заранее посчитанных хешей — это вчерашний день; сегодня работают вероятностные модели, натренированные на реальном поведении людей.

Отдельная история — повторное использование паролей. Если один и тот же пароль стоит на трёх сервисах, взламывать ничего не нужно: достаточно найти его в одной утечке и прогнать по остальным. Credential stuffing — это не атака на пароль, это атака на человеческую лень.

Что реально помогает

• Менеджер паролей — единственный способ иметь уникальные длинные комбинации без боли. Хранить в браузере или заметках — примерно то же, что оставить ключ под ковриком.

• Длина важнее сложности. Случайная фраза из четырёх слов длиннее и энтропийнее, чем Pa$$w0rd123.

• Passkeys (ключи доступа) там, где сервис поддерживает — убирают пароль из уравнения вообще.

• TOTP-аутентификатор вместо SMS. SMS перехватывается через SS7 или SIM-swap; TOTP — нет.

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

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

TG @CIOlogia

Эпоха AI. Бюджет выделен, ждём чуда.

Рынок в РФ наконец дозрел до массового внедрения корпоративных AI-подписок. Бюджеты на Claude/Codex становятся чуть ли не обязательными. И почему-то все ждут, что продуктивность резко увеличится.

Главная проблема - никто не знает, как ИИ влияет на продуктивность. А еще никто не знает как это достоверно оценить. К примеру в исследовании METR в июле 2025 получили ухудшение продуктивности. Существует много исследований, все с очень разными результатами.

И правда, как измерять-то? Влияет проект, задача, стек, промпты, даже время суток (не шучу). Модели ведут себя по-разному, спецификации отличаются, контекст меняется. Все используют разные инструменты и по-разному. Насколько сильно влияют скиллы разработчика? Знание проекта? Документация? Язык общения? На одной задаче мы могли ускорится в два раза, на другой - протупить дополнительно 2 дня. В каждом аспекте полная неизвестность, помноженная на неизвестность.

Ну и относительно какого периода считать прирост? Тут тоже вопрос без ответа. Многие используют ИИ инструменты аж с 2022 года. Значит нужно собирать статистику с 2021. Но там и технологии были другие, и разработчики, и подходы, и задачи... Объективно ли? Нет. Но 2024 за baseline тоже взять нельзя, тогда уже многие сидели на личных подписках. Но бизнес всё же приходит и говорит: мы выделили бюджет на AI, ждём от вас взрывного роста продуктивности. В два, в три, в пять раз! Как в Майкрософт! Как в Фейсбуке!

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

Впереди много интересного. Будут и хорошие решения, будут и глупые. Всё это постепенно сформирует новые процессы, подходы и метрики. Когда-то ведь впервые появился Git, доски, нормальные фреймворки. И каждый раз сначала был безумный культ, потом разочарование, только потом взвешенный подход, на котором и держится вся реальная польза. Технологии не остановишь, так что нам с вами придется пройти этот путь. Хотим мы этого или нет 🫢

На сайте Hacker News завязалось любопытное обсуждение. Пользователь поделился опытом: в крошечной базе данных на 15 тысяч записей случилась коллизия UUIDv4. Приложение генерировало идентификаторы через uuid, популярный пакет npm, база имела ограничение UNIQUE, и однажды новая запись пришла с тем же UUID b6133fd6-70fe-4fe3-bed6-8ca8fc9386cd, что уже лежал в таблице с прошлого года.

Если что, то в этом плане у UUID должен быть полный иммолейт импрувед: вероятность такого события крайне мала. У 128-битного UUIDv4 122 случайных бита, то есть шанс попадания нового UUID в один из уже 15 000 существующих равен примерно один к 3,5 × 10³². Это какие-то проблемы с генератором псевдослучайных чисел, что сразу же расписали в комментариях к посту на HN. В ходе обсуждений сам автор истории признался, что вообще-то раньше на проекте UUIDv4 генерировались на устройстве пользователя, и уже потом эту часть логики перенесли с клиента на сервер.

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

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

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

Здесь многих морщит, когда они видят откровенно ИИ-шный текст, недостаточно хорошо отражающий суть того о чем он как бы написан. НО!

Вот появилась тут буквально вчера статья на тему "старый ноутбук, мало памяти, zram, swapspaces".
Явно - писана с помощью ИИ, и как справедливо было замечено - из серии "как нарисовать сову": долго готовим рабочее место и инструменты, потом рисуем один глаз, второй, ну а потом остальную сову.

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

Автор, если ты это видишь - сделай людям доброе дело, распиши подробнее.
Я б сам написал - но получится, типа украл чужую статью, а это не очень красиво.
Но тема-то интересная...

Прошлую суперпятницу я профилонил и ничего не набредил, попробую сейчас подкинуть темку: делает ли кто-то ещё контроллеры на ядре 80188? Взять этот вот концепт и довести до полной упоротости, угарности, а если прямо вот по-взрослому повезёт, то и до трудноуловимой «балдёжности»: 80188, «640 Кб хватит любому» (для ридера .TXT и .FB2 уж небось хватит!), ну и как-нибудь реализовать (может, даже софтово а-ля «Поиск») там крайне близкий идеологически к e-ink видеоадаптер, а именно — «Геркулес».

Да, это уже будет не гаджет для ретрогейминга. Золотой век — это VGA и DOS4GW, как минимум 80486 и хотя бы метра четыре памяти. Это будет почти чисто книжка (да и та довольно минималистичная, хотя, честно говоря, ни разу не видел, чтобы кто-то пользовался всерьёз на книжке чем-то сверх ридера .TXT и .FB2), но с небольшими опциями «ненормального ретро-программирования», ну, и запуска особо археологического софта, понимающего этого кота-геркула.

Да, это всё можно заэмулировать на микроконтроллере от вейпа. Но эмуляция… «балдёжности» в ней нет :( С Геркулом ещё можно смириться — «Поиск» является оправдывающим прецедентом, а вот ядро… ядро должно быть настоящее. Иначе исчезает красота. А ведь все подобные девайсы — это, по сути, явление более художественное, нежели прикладное…

Dirty Frag 🐧💥

Спустя неделю после нашумевшего Copy.Fail исследователь v4bel раскрыл новую технику повышения привилегий в ядре Linux — Dirty Frag.

По состоянию на утро 8 мая у Dirty Frag не было CVE-номера и, что более критично, официального патча от мейнтейнеров ядра тоже. Dirty Frag относится к тому же классу, что Dirty Pipe и Copy.Fail, но использует другой механизм: вместо pipe_buffer атакуется структура sk_buff.

Общие механизмы работы позволяют надежно блокировать эксплойт поведенческой экспертизой в PT Sandbox (Exploit.Linux.CVE-2022-0847.a, Exploit.Linux.CVE-2026-31431.a, Backdoor.Linux.Generic.a) — смотрите на скриншоте.

Как это работает? 🧐

Dirty Frag — это цепочка из двух уязвимостей, которые дополняют друг друга, чтобы охватить все основные дистрибутивы:

1️⃣ Page-Cache Write (с 2017 года): предоставляет возможность для записи 4 байт в кэш страниц, но требует права на создание пользовательских пространств имен, что в некоторых системах (например, Ubuntu) может блокироваться AppArmor.

2️⃣ RxRPC Page-Cache Write (с июня 2023 года): не требует прав на пространства имен, но модуль rxrpc.ko присутствует только в некоторых дистрибутивах, включая Ubuntu, где он загружен по умолчанию.

Объединив их, атакующий получает рабочий эксплойт на любой системе, что позволяет:

• Подменить suid-файлы (например, /usr/bin/su) на свою версию
• Изменить /etc/passwd, очистив пароль root-пользователя

Кто под угрозой? ⛳️

Практически все системы с ядром Linux, выпущенные с 2017 года. Исследователь подтвердил работу эксплойта на следующих версиях: Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44 и других.

Как защититься? 🔧

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

Команда для отключения:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Некоторые дистрибутивы (например, AlmaLinux) начали выпускать собственные патчи, не дожидаясь апстрима.

Позднее сегодня уязвимость получила идентификатор CVE-2026-43284, патч добавлен в код ядра (f4c50a4034e6).

(Источник: https://t.me/ptescalator)

Ты один QA на проекте? Это твой шанс или риск?

Соло-тестировщик — звучит гордо, но как не утонуть в задачах без онбординга и поддержки? Эксперт Юзтеха на совместном митапе Moscow QA #23 x ИнфоТеКС & Юзтех разобрала типичные сложности и показала, как соло-формат может стать точкой роста, а не дорогой к выгоранию.

Будет полезно, если вы хотите понять, как не выгореть и вырасти.

P.S. Заходите в наш TG-канал, там мы рассказываем о технических мероприятиях и конференциях, делимся выступлениями экспертов, обсуждаем подборки на технические и ИБ темы.

«Третья альтернатива» Стивен Кови

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

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

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

А Кови всё объяснил – про третье-то. Даже книгу так назвал – «Третья альтернатива». И объяснил, что это – синергия (будьте здоровы). Да, у меня тоже аллергия на слово «синергия». И Кови пишет – знаю я, что у вас аллергия, дайте мне чутка времени, я вас от неё вылечу. И вылечил ведь, гений без кавычек 😊

Он дал гениальное, математически неуязвимое определение синергии: это третий вариант. Есть мой вариант (чего-либо), их вариант, а синергия – третий. Не надо спорить о моём и их варианте. Надо сразу искать третий, который не просто устроит обоих (это компромисс, в лучшем случае - консенсус). Третий вариант обязательно должен превзойти оба – мой и их. В книге дан, многократно повторён и разобран на разных примерах алгоритм поиска третьего варианта. Как водится у Кови – в совершенно разных областях жизни (работа, личная жизнь, политика, здоровье и т.д.).

А если у обоих мнение одинаковое? И на это гений-Кови дал зубодробительный ответ: если двое во всём согласны, то один из них – лишний.

P.S. Я там в начале немного приукрасил насчёт разочарования, но лишь немного. На самом деле, несколько лет назад я нашёл свою ошибку («или по-моему, или без меня»). И сформулировал для себя правило – «не противопоставлять» (одно решение другому).

Учил этому всех своих стажёров-программистов, которые, в силу юношеского абсолютизма, всегда стремились выбрать что-то одно, никак не пытаясь объединять лучшее из разных вариантов. В развитии, в профессиональных навыках я убеждал их не выбирать вообще, потому что для них выбор – это противопоставление. Выбор навсегда. Я говорил – просто приоритеты расставьте. Сначала одному научитесь, потом другому.

Но Кови ушёл на две вселенные дальше меня. Я своим умом дошёл лишь до его «дилеммы двух рогов», и как-то для себя её распутал. Кови же всё расставил по местам. Гениально, как всегда.

В конце апреля Dreame анонсировала для России два вертикальных пылесоса и флагманский робот X60 Ultra Complete. В пресс-релизе к последнему уже знакомый набор технологий: выдвижной лидар (о нем я упоминал в обзоре на модель Aqua10 Ultra Roller), ИИ-камеры, технология Pet Care, тонкий корпус (7,95 см) и станция с подогревом до 100 °C. Но главная цифра – сила всасывания до 35 000 Па (к слову на сайте производителя этот параметр указан как максимальная мощность всасывания). И вот про эти паскали стоит поговорить отдельно, потому что именно они создают иллюзию чудовищной силы всасывания.

Краткий ликбез: в технических документах «сила всасывания» (точнее, статическое разряжение) измеряется в паскалях или миллибарах. Это давление, которое создаёт вентилятор при полностью перекрытом входном отверстии. Никакого воздушного потока при этом нет. Это характеристика того, насколько глубокий вакуум способен создать двигатель с крыльчаткой. Реальная же полезная мощность всасывания (которая влияет на то, сколь эффективно пылесос вытягивает мусор из ковра) вычисляется как произведение разряжения (Па) на объёмный расход воздуха (м³/с). Результат – в ваттах или аэроваттах. Незначительную разницу в 0,17% между Вт и аВт в принципе можно смело проигнорировать.

Производители роботов-пылесосов почти никогда не публикуют информацию о расходе воздуха в л/с. Вероятно, потому что... у типичного робота он невелик – порядка 5-10 л/с. Если взять заявленные Dreame 35 000 Па (что очень много даже для статического давления робота, обычно достаточно 3-10 кПа) и умножить на реальный расход, скажем, 8 л/с = 0,008 м³/с, то получим мощность всасывания около 280 Вт. Для робота это прилично, но далеко не «промышленный пылесос». И это при условии, что 35 000 Па достижимы в реальной конфигурации, а не только на заглушенном патрубке без щёток, фильтра и пылесборника.

На форумах можно встретить два лагеря. Одни говорят, что:

«Паскали – это единственное, что хоть как-то сравнимо у всех, поэтому прежде всего смотрите на них».

Другие (и я скорее отношусь к ним) утверждают, что без расхода воздуха паскали – маркетинговая игрушка. Как пример честного подхода некоторые пользователи приводят профессиональную продукцию компании Karcher: мол, «для моделей линеек NT, T, IV (проводные и стационарные) производитель указывает в характеристиках и разряжение, и расход, по которым можно легко рассчитать реальную мощность всасывания в ваттах и увидеть её соотношение с потребляемой мощностью устройства». При этом отмечу, что бытовая серия упомянутого выше бренда не обременена такими подробностями.

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

В какой-то мере это логично, но для продвинутого пользователя непрактично. Есть подозрение, что если производители роботов предоставят информацию о реальном расходе воздуха для проведения подсчетов, – может выясниться, что разница между «бюджетными» роботами-пылесосами за 15+ тысяч и «флагманами» за 140+ тысяч в реальной уборке не столь драматична, как разница в цифрах на коробке.

Так что 35 000 Па у X60 – это красиво, но почти бесполезно без данных о расходе. Выдвижной лидар и подогрев швабр до 100 °C куда более осязаемые фишки. Остаётся вопрос к сообществу: как вы оцениваете реальную эффективность своих роботов – по ощущениям, или есть способ получить информацию о недостающих технических параметрах? Может, кто-то проводил собственные замеры с анемометром и манометром?

Нововведения Java 26

В марте 2026 года вышла Java 26.

Поскольку мы в PVS-Studio используем Java для разработки наших Java, JavaScript и TypeScript анализаторов, такая новость нами не могла быть пропущена. Мы выпустили статью, где рассмотрели основные изменения, которые эта версия с собой принесла. Так что давайте вместе посмотрим на основные нововведения, появившиеся в Java 26.