Зачем мы интегрируем свой анализатор в такое количество инструментов?
Мы разрабатываем и продаём статический анализатор PVS-Studio. В самом продукте есть множество всякого интересного: утилиты командной строки, диагностические правила разных категорий, вспомогательные утилиты и тому подобное.
За не самым красивым оборотом “тому подобное” мы обычно скрываем наши многочисленные интеграции со сторонними продуктами (плагины, расширения, сценарии работы). Вы можете спросить: “А зачем скрывать?” Смотрите сами: первой нашей интеграцией был плагин для Visual Studio 2005, вышедший 18 лет назад. Сегодня же анализатор интегрируется с более чем тремя десятками других инструментов для разработки: плагины для IDE, игровые движки, платформы контроля качества кода, сборочные системы, платформы CI/CD и т. п.
Поддерживать всё это в актуальном и рабочем состоянии — большая работа, и в новой статье расскажем, зачем мы вообще этим занимаемся.
Исследователь из компании Anthropic Джейкоб Коксон ушёл из ИИ-индустрии, опасаясь, что гонка технологических корпораций приближает мир к «точке невозврата»:
Я ушёл из Anthropic сегодня. Последние три года я занимался исследованиями предобучения как в OpenAI, так и в Anthropic. Ни одна из компаний не действует ответственно. Они несутся напролом к самоулучшающемуся сверхразуму и играют в рулетку нашими жизнями. Больше мыслей ниже.
Не недооценивайте мощь этой технологии. Вскоре это будут сверхчеловеческие системы, способные взламывать что угодно, революционизировать любую область за ночь и обретать реальную власть и ресурсы. Мы все были свидетелями прогресса в каждой из этих областей, и прогресс не замедляется.
Люди, создающие ИИ, искренне верят, что он может погубить нас всех к концу десятилетия. Это не маркетинговый трюк. Если уж на то пошло, многие руководители и старшие исследователи будут подбирать слова в прессе так, чтобы звучать разумно, — но я слышу, как те же самые люди выражают страх наедине. Никакая другая человеческая деятельность не несёт такой степени опасности.
Типичный ответ: «Если они действительно в это верят, почему они всё ещё это строят?» В OpenAI многие не осознали в полной мере цивилизационные ставки. В Anthropic ставки хорошо поняты, но они оказались в гонке, чтобы добраться туда первыми — они считают, что никто другой не будет действовать ответственно, поэтому им самим приходится это делать, несмотря на риск.
Принятие этой гонки и вступление в «эндшпиль» — это горделивый риск, который не должен запускаться из Slack частной компании. Попытка форсировать выравнивание должна требовать чрезвычайной уверенности в том, что нет лучших траекторий.
Я оптимистично настроен относительно потенциала координации. Предупреждающие сигналы, такие как атака на Hugging Face, сделали соглашения о темпах между американскими лабораториями более осуществимыми. Я не чувствую, что мы на правильном пути к предотвращению глобальной гонки, которая может потребовать дорогостоящих действий, таких как временный запрет на улучшение возможностей моделей.
Если вы исследователь в лаборатории, я призываю вас задуматься о том, как на самом деле будут ощущаться ближайшие несколько лет. Хотите ли вы запустить цикл обучения RL с суперразумным интеллектом, не имея строгого понимания его разума? Должны ли вы просто опустить голову, потому что «это всё равно произойдёт» — или использовать этот момент, чтобы призвать к иным условиям?
Уникальная книга, ведь её написал император Римской Империи. Просто представьте – вы читаете книгу, написанную властителем половины мира, известного на тот момент. Это не биография, написанная позже другими авторами, исследователями или соратниками. Это прямая речь.
Наверное, этим меня книга и зацепила. Я читал много автобиографий, но эта – первая не про события из жизни государственного деятеля, а про отношение к жизни, оглядываясь на эти события. Обычно же всё о работе да о работе пишут, оставляя в конце одну главу под «после отставки», да в середине книжки – блок фотографий, в т.ч. из личной жизни.
Книга Марка Аврелия – органичная смесь стоицизма и авторитета (во время прочтения не возникает вопроса «а ты, автор, собственно, кто такой?»). Стоицизм, не оторванный от реальности, а пронизанный опытом трудной жизни на одной из самых ответственных должностей в истории. Если можно так выразиться – пережёванный стоицизм. Не для других, не для публики, а для себя. Это завораживает.
При этом книга на удивление добрая и душевная. Там нет экстремумов – ни ярких восторгов, ни возвышенной гордыни, ни горьких сожалений. Будто писал обычный наш интеллигентный дедушка на пенсии. Но мы-то знаем, кто писал, и это знание заставляет каждую букву светиться изнутри.
Читая книгу, невольно ищешь ответ – стоило ли оно того, Марк Аврелий? Что даёт жизнь, переполненная ответственностью, событиями, почестями, невзгодами? Чёткого ответа в книге нет, но тон повествования, настроение, послевкусие говорят о том, что… Прочитайте, и составьте собственное мнение.
В качестве учебника стоицизма книга Марка Аврелия – не лучшее решение. Скорее, как опыт, практика жизни в стоицизме на самом высшем уровне. В этом плане она – совершенно уникальна. Поэтому и рекомендована к прочтению.
Хороший бэкап умеет не только сохранять, но и возвращать нужное
В большой инфраструктуре десятки тысяч машин, БД, контейнеров, платформ. И сценарии восстановления у всех свои: где-то нужно поднять всё с нуля, а где-то – вернуть один объект или несколько атрибутов. Российские вендоры последовательно движутся в сторону точности.
Свежий пример: в «Кибер Бэкапе Облачном» теперь можно выбирать отдельные объекты внутри Kubernetes. Резервируешь и восстанавливаешь только то, что действительно нужно, – не тащишь весь кластер ради одной ошибки.
Не просто «есть копия», а умение достать из неё именно то, что сломалось, и не трогать остальное.
Тот же принцип особенно важен для каталогов. В гетерогенных средах и особенно при миграции с AD на Linux инфраструктура становится сложнее: параллельные среды, скрипты, промежуточные состояния. И тут ошибка часто не убивает каталог целиком. Можно неверно изменить атрибуты пользователей, удалить группу, разорвать связи — система продолжит работать, но доступы поедут.
Восстанавливать весь каталог из полной копии — как из пушки по воробьям.
Нужно найти, что именно сломалось, и вернуть только это — один объект, один атрибут. Это и есть гранулярное восстановление. Оно не отменяет полное восстановление — это разные сценарии. Пожар в дата-центре и кривой скрипт, поменявший одну группу, лечатся по-разному.
Простая логика для каталога: перед миграцией сделал копию, потом сравнил состояния и точечно исправил последствия.
И здесь Kubernetes и каталог оказываются ближе, чем кажется: бэкап ценен не только фактом наличия, но и тем, насколько точно ты можешь им воспользоваться, когда что-то пошло не так.
У пользователя @Wesha 41 500 комментариев на хабре за последние 11 лет.
11 лет это 3 960 дней.
41 500 / 3 960 = 10.5 комментариев в среднем каждый день.
Но я копнул глубже и выяснил, что с 2015 до 2023 года он написал всего лишь 9 500 комментариев.
А значит за последние 3 года и 8 месяцев (всего 44 месяца) он написал 32 000 комментариев.
44 месяца это 1 320 дней.
32 000 / 1 320 = 24 комментария каждый день.
Но я не остановился и на этом.
Первый комментарий за 2026 год находится на 368 странице в его профиле. На одной странице отображается 20 комментариев. Значит за 8 месяцев он написал 7 360 комментариев.
8 месяцев это 240 дней.
7 360 / 240 = 30 комментариев каждый день.
Часто комментарии состоят из цитат или слабо относятся к теме статьи. И эти комментарии влияют на общий облик хабра, потому что они есть почти в каждой топовой статье, особенно если эта статья упоминает ИИ.
Удивляет еще его карма.
Сейчас она -6 при 1116 голосах. Получается ровно половина людей плюсанула карму, а другая половина минусанула. Как ему удалось за столько лет не слить карму до -30, чтобы получить статус read-only, для меня загадка.
EDIT: Может показаться, что я прошу людей слить карму пользователю до -30, чтобы он получил статус read-only. Хотя я лишь указал на сам факт того, что она ни разу не была -30 в прошлом. Ведь в положительную сторону карма может быть любой. Но в отрицательную достаточно один раз дойти до -30, и больше возможности оставлять комментарии не будет.
OpenAI запустила около 10 000 агентов, которые 88 часов решали одну математическую задачу.
И, судя по всему, решили.
Это обсуждают как очередное доказательство того, насколько умным стал ИИ. Но мне здесь интереснее другое.
Если посадить десять тысяч хороших живых математиков на одну задачу на 88 часов, я буду несколько разочарован, если они не добьются чего-то интересного.
Проблема в том, что десять тысяч математиков почти невозможно заставить работать как один организм. Их надо собрать, разделить работу, координировать, передавать результаты, отсекать тупиковые ветки и следить, чтобы они не потратили первые двое суток на обсуждение того, кто главный и когда будут кормить.
С агентами это внезапно можно.
Есть хороший аналог из физики.
Килограмм солнечного вещества производит гораздо меньше тепла, чем килограмм человеческого тела. Солнце чудовищно не потому, что каждый его килограмм особенно эффективно производит энергию.
Просто этих килограммов там примерно два нониллиона (2 × 10³⁰ кг, 30 нулей).
По факту с ИИ происходит примерно то же самое.
Мы продолжаем спрашивать, умнее ли отдельная модель отдельного человека, хотя гораздо интереснее становится другой вопрос: сколько «интеллектуальной» мощности можно одновременно собрать, скоординировать и направить на одну задачу.
Иногда преимущество системы возникает не из качества элемента.
Как не поделиться свежей историей про ответственность на проектах!.. Причем формально-то совсем не про них, зато ее можно использовать как аргумент «а вот даже у лидеров рынка еще хуже нашего»...
Кратко: в Штатах строят Lake Mariner — дата-центр за 3,2 лярда долларов. Интересанты соответствующие: Google и Anthropic.
И там бахнул пожар. Слава богу, без катастроф: никто не погиб, пожар потушили. Но зато выяснилось, насколько объект "готов" к пожару.
Пожарные приехали и обнаружили, что рабочей сигнализации нет, системы пожаротушения нет, три гидранта сухие, а документация по системе пожаротушения предположительно уже сгорела сама. Начальник пожарной службы говорил, что его люди заходили внутрь фактически вслепую.
А дальше - вот оно, прекрасное устройство проекта. Одна контора владеет и управляет дата-центром, землю арендует у другой структуры, связанной с тем же собственником, Гугл финансирует, Anthropic покупает. Плюс подрядчики, местные власти, энергетики, пожарные и наверняка еще много кто остался за рамками статьи.
То есть там наверняка была нарисована целая библиотека матриц ответственности, оргструктур, протоколов, оценок рисков и прочей прекрасной проектной документации. Каждый прекрасно отвечал за что-нибудь свое. А потом случился пожар, которому пофиг на это...
Но вот про противопожарную безопасность никто не думал. Часть гидрантов была не подключена, документации по системам тушения не было и т.д. А тут бах - и пожар. И концов нет. И нет планов действий. И некому их выполнять. Все молодцы, всё сделали в зоне своей ответственности и пошли смотреть на пожар как зрители (Ну ладно, кто-то хотя бы вызвал пожарных).
Финал тоже неплох. После пожара TeraWulf (это типа управляйка) сообщила, что происшествие разобрали и приняли дополнительные меры, в том числе по гидрантам и взаимодействию с пожарными. Но через два месяца начальник пожслужбы сказал журналисту, что, "насколько ему известно", проблемные гидранты всё еще сухие.
Всё продолжая разбираться в данных Росстата за январь-июль 2026, я наткнулся на индекс промышленного производства, который составил 100,1% к аналогичному периоду 2025года.
Это означает рост на 0,1%, что скорее означает, что промышленность сейчас производит примерно столько же, сколько производила год назад. Причём это не разовая история, по итогам первого полугодия индекс вообще составлял ровно 100,0%.
И конечно же, средняя в размере 0,1% мало что говорит о каждой отрасли в целом, поэтому лучше смотреть на график, где каждая отрасль будет фигурировать отдельно.
Вообще, сильнее всего прибавляют производство прочих транспортных средств, фармацевтика и готовые металлические изделия, а в минусе – нефтепродукты, бумага, металлургия, стройматериалы, машины и оборудование.
Рост есть, но он не особо широкий
Вообще, когда экономика растет устойчиво, то движение обычно постепенно распространяется по производственным цепочкам. Я имею ввиду, что больше выпуска, означает больший спроса на материалы, оборудование, сырьё и перевозки. И так по цепочке.
Сейчас же это история скорее про перетягивание каната: одни отрасли тянут индекс вверх, другие почти с такой же силой тянут его вниз.
Обрабатывающие производства за январь-июль выросли всего на 0,5% год к году, энергетика - на 0,7%. А допустим добыча снизилась на 0,9%, а водоснабжение, водоотведение и утилизация отходов - на 3,2%.
Что может означать ноль
Я бы сказал, что само по себе отсутствие роста (а как ни крути 0,1% или близкие к нулю значения сложно назвать ростом) вообще не означает промышленного кризиса как такового. В июле выпуск всё еще сохраняется на уровне прошлого года. То есть существующий объем производства сохраняется на определенном уровне, и это означает, что пока что дальнейшего расширения производства пока не планируется. И поэтому говорить о каком-то обвале явно рано.
И, опять же, общая цифра тут не совсем показатель, гораздо информативнее будет структура, ведь рост одних отраслей почти полностью съел спад других.
Я регулярно разбираю такие темы в своём Telegram‑канале, если вам интересно глубже понимать аналитику, экономику и рынок труда, там регулярно выходят короткие заметки и обзоры актуальных событий.
Безопасная разработка от кода до прода — новый бесплатный курс Cloud.ru
Кто-то считает безопасность головной болью ИБ-отдела и вспоминает о ней за день до релиза — когда править уже долго и дорого. Кто-то уверен, что контейнер — это просто «легковесная виртуалка», и удивляется, когда изоляция оказывается не такой уж изолированной. Безопасность часто воспринимают как отдельный этап в конце пайплайна, а не как часть жизненного цикла разработки. Чтобы глобально исправить это, мы собрали свой опыт провайдера облачных и ИИ-решений в экспресс-курс «Основы безопасной разработки в облаке» и сделали доступ к нему открытым.
⏳За один кофе-брейк (около 20 минут) вы можете узнать:
Как безопасность распределяется между этапами разработки, сборки, развертывания и эксплуатации приложения.
За счет чего контейнеры дают скорость и гибкость, какую цену за это платит изоляция и как эту цену скомпенсировать.
Какие практики чаще всего приводят к инцидентам, и как их избежать с самого начала.
Какие готовые сервисы безопасности закрывают типовые задачи защиты быстрее самостоятельной разработки.
Кому подойдет курс?
ИТ-специалистам и DevOps-инженерам. Поможет встроить проверки безопасности в существующий CI/CD-конвейер и автоматизировать их без потери скорости релизов.
Специалистам по ИБ и облачной безопасности. Структурирует модель угроз для облачных приложений и позволит говорить с разработкой на одном языке.
Всем, кто интересуется кибербезопасностью. Систематизирует разрозненные знания об облаке в единую картину жизненного цикла.
Курс открывается сразу после регистрации на платформе, заниматься можно в любой момент в комфортном темпе. Все уроки и прогресс отражаются в личном кабинете, доступ к материалам остается с вами навсегда. После финального теста вы получаете сертификат о прохождении курса.
Сделайте безопасность частью разработки, а не препятствием перед релизом!
Проектов больше, чем людей: как управлять портфелем в условиях дефицита ресурсов?
Рост числа проектов не всегда сопровождается ростом команды. Когда ресурсов не хватает, приходится вручную расставлять приоритеты и перераспределять людей, а контроль сроков, бюджета и обязательств становится всё сложнее.
Как сохранить управляемость портфеля, когда проектов становится больше, а ресурсов – нет? На вебинаре 17 сентября в 12:00 покажем, как с помощью решения Digital.Q.PM «Управление проектами» выстроить сквозной процесс – от постановки бизнес-цели и создания проекта до его выполнения и завершения.
Покажем на практике, как Digital Q.PM помогает снизить ручную нагрузку на менеджеров, эффективнее использовать ограниченные ресурсы и управлять большим количеством проектов без потери прозрачности и контроля.
Также разберем, как на каждом этапе процесса связаны данные, задачи и различные системы платформы, чтобы управление проектами оставалось прозрачным и контролируемым.
Создание проекта на основе поставленной бизнес-цели
Управление ресурсами в условиях их дефицита
Планирование и контроль бюджета
Контроль выполнения проектных обязательств
Взаимодействие различных систем платформы в едином процессе управления проектом
Кому будет интересно:
Руководителям РМО
Руководителям проектов и программ
Специалистам по управлению ресурсами и портфелем проектов
Хакерская группировка PhantomCore продолжает активно использовать ошибки в конфигурации 1С для атак на российские организации.
В рамках расследования инцидента команда комплексного реагирования на киберугрозы Positive Technologies (PT ESC IR) обнаружила компрометацию сервера 1С, работающего на операционной системе семейства Linux 🐧
Среди характерных признаков — наличие вредоносных исполняемых файлов в подкаталогах домашней директории служебного пользователя usr1cv8 и команд в .bash_history того же пользователя — в частности просмотр и удаление файла res.txt, в который записывается результат выполнения кода посредством 1cshell.
После получения доступа в систему PhantomCore установили ReverseSSH-туннель, что является типичным поведением для данной группировки.
🕵️♂️ Помимо часто используемого инструментария мы встретили и более диковинную утилиту croc, предназначенную для удаленной загрузки и эксфильтрации файлов.
На исследуемом узле были обнаружены команды формата: CROC_SECRET=[REDACTED] ./croc
С помощью нее злоумышленники могли загрузить на скомпрометированный узел файл, который был предварительно отправлен через веб-интерфейс https://getcroc.com/ (на скриншоте) или с другого компьютера, на котором установлен croc.
💡 Для поиска следов использования croc можно поискать исполняемый файл с соответствующим именем, а также использование переменной окружения CROC_SECRET.
В качестве сетевого индикатора может служить домен getcroc[.]com.
🤔 Аналитический кластер не всегда выгодно масштабировать целиком
Когда объем данных растет — нужно больше дисков. Если становится много тяжелых запросов — нужны дополнительные CPU. В ситуации, когда хранение и вычисления жестко связаны внутри одного кластера, вместе с нужным ресурсом приходится наращивать и второй.
➗Разделение compute и storage позволяет масштабировать их независимо. Данные остаются в общем слое хранения, например S3, а для обработки можно использовать отдельные вычислительные кластеры и движки. Такой подход лежит в основе современных Data Lakehouse-архитектур.
Что меняет разделение compute и storage:
🔹 под тяжелую обработку можно добавить compute, не расширяя хранилище 🔹 рост объема данных не требует одновременно покупать дополнительные вычислительные мощности 🔹 разные инструменты могут работать с одним набором данных без создания отдельных хранилищ 🔹 вычислительные ресурсы проще распределять между ETL, BI, ad hoc-запросами и другими нагрузками.
Важно учитывать, что данные передаются между storage и compute по сети, поэтому на производительность влияют пропускная способность, задержки и организация доступа к данным.
В статье VK Cloud разбираем, когда разделение compute и storage действительно нужно аналитической платформе, что оно дает и какие архитектурные компромиссы приходится учитывать.
Переход на Astra Linux SE 1.8 — вопрос времени для многих организаций. Регуляторы требуют, но детальной информации о том, что именно изменилось, на рынке мало. Документация есть, а живого разбора с настройкой — нет.
Программа: ⭐ Что изменилось в версии 1.8 по сравнению с 1.6/1.7 ⭐ Почему миграция вызывает сложности и где возникают типичные ошибки ⭐ Настройка защиты и администрирование в реальном времени ⭐ Курсы по Astra Linux SE 1.8: для пользователей и администраторов. Даты старта, специальная цена для участников вебинара
Что нужно для участия: базовое знание Linux, опыт с Astra Linux SE 1.6/1.7 будет плюсом.
📆 Когда: 11 сентября в 17:00 (Мск) 👨🎓 ️Спикер: Брейман Александр, эксперт в области разработки и архитектуры ПО
Шутки шутками, а существующие реализации DI на ноде либо перегружены, либо используют декораторы, для которых нет единого стандарта у старого и нового кода.
import { provide, inject } from "di-kit";
export class WalkerLogicPublicService {
private readonly loggerService = inject<LoggerService>("loggerService");
...
}
...
provide("loggerService", () => new LoggerService());
Вот почему нельзя просто вот так? Никаких минусов нет, выносите типы в enum, создавайте изолированные пространства имен.
import { createActivator } from "di-kit";
export const { init, inject, provide } = createActivator("separate-scope");
Представлен открытый проект Spotify Portal AI Plugins. Это решение от инженеров Spotify, которое экономит до 90% ресурсов ИИ-агентов:
перенаправляет шаблонные задачи на более дешёвых агентов и оставляет Claude только приоритетные дела;
bulk‑reader разбирает многострочный код, Gemini 2.5 Flash внутри читает файлы на тысячи строк и отдаёт Claude саммари;
code‑writer генерит рутинный, проверенный и предсказуемый код, пишет тексты, конфиги, type stubs, boilerplate и другие переиспользуемые части;
Claude забирает себе только самые важные и реально сложные задачи, где нужен мощный ризонинг — фикс багов, проработка архитектуры и внесение сложных правок.
Нейросеть GPT-6 Astra собрала приложение Sweep, которое показывает прямо на полу, где уже прошлись пылесосом, а какие участки ещё пропустили. Камера смартфона отслеживает уборку и в реальном времени отмечает уже пройденные зоны.
Дисклеймер: Пост несет юмористический характер и не ставит своей целью оскорбить или дискриминировать кого-либо.
В своей практике иногда отвечаю на некоторые вопросы STFW, но прогресс не стоит на месте, и сейчас всё чаще актуальным ответом может быть ATFAI (Ask The F*****g AI), однако я не нашел какого-либо устоявшегося варианта на этот случай. Решил воспользоваться ATFAI и получил следующий ответ (внимание нейрослоп):
Аббревиатура ATFAI (как Ask The F*****g AI) грамматически и логически абсолютно подходит и идеально ложится в канон старого гиковского сленга. Она построена ровно по тому же принципу, что и её «предки».
Однако, если ваша цель — чтобы вас мгновенно поняли в чате или на форуме без дополнительных объяснений, есть один нюанс и пара альтернативных вариантов.
1. Самый близкий к оригиналу: RTFAI
Расшифровка:Read The F*****g AI (или Run The F*****g AI).
Почему это лучше: Абсолютно мимикрирует под легендарную RTFM. Визуально меняется всего одна (последняя) буква. Любой айтишник или заядлый пользователь интернета мгновенно считает отсылку на ментальном уровне, даже если видит это сокращение впервые.
Контекст:«Чувак, этот код пишется в одну строчку, RTFAI».
2. Максимально точный: STFAI
Расшифровка:Search The F*****g AI (или Smartly Task F*****g AI).
Почему это лучше: Прямой наследник STFW (Search The F*****g Web). Отражает суть действия — вместо поисковика человек должен был пойти в строку ввода нейросети.
Контекст:«Зачем ты спамишь в чат базовыми вопросами? STFAI».
Как вы считаете, какой из предложенных вариантов ATFAI, RTFAI или STFAI лучше и точнее отражает смысл и годится для внесения в канон? Может быть у вас есть альтернативный вариант?
Я формулирую задачу, помогаю железному болвану преодолеть сложности, которые он сам себе создает, поправляю его, проверяю результат, объясняю, почему получилась фигня, и отправляю на следующую итерацию.
Работа при этом делается. Иногда плохо, иногда хорошо, иногда «умри, тварь железная».
Но ощущения «я это сделал» нет, сам процесс, который обычно это ощущение производит, пропущен.
Вместо него я весь день ставил задачи, отвечал на вопросы и принимал результаты.
То есть технически ИИ избавил меня от значительной части работы.
А практически устроил мне непрерывный проектный созвон с не самыми умными людьми.
Теперь я ничего не делаю сам, весь день объясняю другим, что они сделали не так, и к вечеру совершенно не понимаю, а что ж я так устал-то.
Представлен открытый набор навыков text-to-cad для ИИ-агентов для инженеров, чтобы создавать детальные CAD-модели. Достаточно описать нужную деталь, а ИИ-агент сам строит модель с экспортом в STEP, STL и другие форматы. В комплекте есть просмотр в браузере, поиск готовых винтов, подшипников и моторов, проверка толщины стенок и нависаний перед 3D-печатью. Работает не только с Codex, но и с Claude Code и другими ИИ-агентами.
