Друзья, написал текст как пародию на переводные бравурные статьи про Artemis. Улыбки ради.

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

Сто лет назад, в апреле 2026 года, Artemis II облетела Луну. Тогда это подавали как начало новой эпохи. Теперь, с расстояния в век, видно другое: именно тогда началась не новая лунная гонка в духе Apollo, а длинная эпоха согласований, комиссий, переходных интерфейсов, «полезных для бюджета» архитектур и превращения красивых схем в то, что хотя бы не разваливается на глазах.

На дворе 2126 год. Я инженер NASA, почти сорок лет отдавший детской мечте о полёте к звёздам. Не историк и даже не человек, заставший Apollo. Про ту эпоху я знаю из учебников, внутренних обзоров, старых страниц NASA, кусков документации, которые спасли не архивисты, а чужая лень, и по мемуарам старых астронавтов, для которых космос ещё был временем, когда можно было подъехать к стартовому комплексу на своём Corvette, надеть скафандр, сесть в кресло и улететь к звёздам. Нам после ранней Artemis досталось уже другое наследство. Его мы разгребали десятилетиями. Поэтому позвольте говорить не от лица пресс-службы, а языком человека, которому потом пришлось видеть архитектуру изнутри.

Бывало у вас такое: листаете ленту, читаете комментарии, гуглите что-нибудь — и накрывает странное ощущение дежавю? Словно текст написан «рыбой», картинка сгенерирована по промпту «sad cat in space», а автор комментария «User12345» — это просто скрипт, который должен поднять охваты. Контент словно повторяется. Дискуссии идут по кругу. Тренды появляются ниоткуда, а за ними не стоит никакого реального культурного импульса.

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

Суть укладывается в одно предложение: большая часть контента и активности в современном интернете генерируется ботами и алгоритмами, а не живыми людьми. Интернет, каким мы его знали — с форумами, самодельными сайтами, стихийными мемами и настоящими разговорами — умер где-то в районе 2016–2017 года. То, что осталось — симуляция.

Звучит как бред параноика? Ну да. Только вот реальность последних лет подкидывает аргументы быстрее, чем любой фантаст успел бы их придумать.

31 марта 2026 года наружу буквально вывалились исходники Claude Code (через sourcemap в npm‑пакете). История уже сама по себе комичная: продукт, который помогает писать код и в теории должен быть особенно аккуратен с публикацией артефактов, случайно публикует не просто кусок дебажной информации, а почти анатомический атлас самого себя.

Но меня в этой истории интересует не столько сам факт утечки, сколько более приземлённый вопрос: что там внутри? Если убрать обычное для таких случаев «вау, утекло», остаётся более интересная интонация: ну‑ка, посмотрим, что тут у нас (или «там у них»?) и нормально ли там написан код.

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

Через несколько недель

Я писал на C# программу для распаковки gzip-файлов и неожиданно поймал странное исключение, из которого следовало, что архив поврежден.

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

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

У продукта есть и внутренние пользователи, которые пользуются им каждый день, и внешние альфа-тестеры. Он выпускается, разворачивается, ломается и чинится. Отличие в том, что весь код — логика приложения, тесты, конфигурация CI, документация, observability, внутренние инструменты — написан Codex. По нашей оценке, мы сделали это примерно в десять раз быстрее, чем если бы писали код вручную.

Люди задают направление. Агенты выполняют.

Мы специально ввели это ограничение, чтобы построить то, что было нужно для роста темпа разработки на порядки. У нас были недели, чтобы выпустить то, что в итоге оказалось миллионом строк кода. А чтобы это сделать, нам понадобилось понять, что меняется, когда основная задача команды разработки ПО — уже не писать код, а проектировать окружения, формулировать намерение и строить петли обратной связи, которые позволяют агентам Codex работать надежно.

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

В конце 2024 года на просторах GitHub появился проект, который заставил даже самых серьёзных системных программистов улыбнуться: scx_horoscope — планировщик задач для ядра Linux, корректирующий поведение CPU в зависимости от положения планет, фаз Луны и так называемой ретроградности. Автор, Lucas Zampieri, с иронией обыграл давний системный фольклор о зависимости работы систем «от фазы Луны», превратив мем в рабочий код, который действительно загружается в ядро и участвует в распределении процессорного времени.

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

Запуск больших языковых моделей на своём железе — это всегда поиск компромисса. Либо ты тратишь больше $10 000 на потребительские видеокарты, которые едва тянут модели на 70 миллиардов параметров, либо лишь мечтаешь о серьезном железе корпоративного класса, которое, увы, тебе не по карману. Платформа Grace‑Hopper — архитектура суперчипа NVIDIA, объединяющего CPU и GPU, — это именно та инфраструктура для ИИ, о которой грезит сообщество LocalLlama. Но такие системы обычно стоят от $100 000 и доступны только дата‑центрам и научным институтам.

Поэтому, когда на Reddit я наткнулся на систему Grace‑Hopper за 10 000 евро, первой мыслью было: «Это развод». А второй: «Интересно, получится ли договориться за 7500?».

Эта история — о том, как я купил корпоративное ИИ‑оборудование, изначально рассчитанное на жидкостное охлаждение в серверной стойке, но кое‑как переделанное предыдущим владельцем на воздушное. Затем я вновь переделал его на водяное охлаждение, пережил несколько ситуаций на грани фола (включая работу с GPU, который докладывал о температуре в 16 миллионов градусов) и в итоге получил десктопную систему, способную запускать у меня дома модели на 235 миллиардов параметров. Это рассказ о сомнительных решениях, творческом решении проблем и о том, что происходит, когда пытаешься превратить серверное чудовище в домашнюю рабочую станцию.

Если вам когда‑нибудь было интересно, что нужно, чтобы запускать по‑настоящему большие модели локально, или если вы просто зашли посмотреть, как кто‑то разбирает «железо» за $80 000 с одной лишь надеждой и бутылкой изопропилового спирта — вы по адресу!

Сначала новость кратко: Let's Encrypt собирается постепенно сократить срок жизни сертификатов с 90 до 45 дней. Это решение знаменует собой очередной этап в эволюции стандартов безопасности веба, в которой, да, изначально всё началось с гораздо более длительных сроков действия сертификатов. Еще в 2015 году сертификаты могли действовать до 5 лет, но по мере роста угроз и появления новых уязвимостей в криптографических алгоритмах индустрия постепенно переходит к более коротким срокам.

С 13 мая 2026 года появится (пока как опция) возможность получения 45-дневных сертификатов. Далее, 10 февраля 2027 года максимальный срок сократится до 64 дней, а к 16 февраля 2028 года — до финальных 45 дней.

Закулисный взгляд на основные компоненты серверов MCP — от обработки запросов и управления сессиями до кеширования и хранилищ контекста.

Современные ассистенты на базе искусственного интеллекта (ИИ) столь же эффективны, насколько богатыми данными и инструментами они располагают.

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

Вместо создания уникальных интеграций для каждой базы данных, API или корпоративной системы разработчики могут полагаться на единый интерфейс MCP, словно на универсальное “AI-USB”, подключая ИИ к любому источнику данных.

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

Скорее всего, за последние месяцы вы уже сталкивались с аббревиатурой MCP (Model Context Protocol). Что это такое — просто очередной API или действительно что‑то стоящее внимания? В этом материале мы разберёмся, что такое MCP, почему благодаря нему LLM становятся мощнее, а также рассмотрим основные угрозы и уязвимости безопасности.

Если Вы уже знакомы с MCP, можете сразу переходить к разделу «Моделирование угроз». Тем не менее, советуем сначала ознакомиться с разделами «Sampling (выборка)» и «Композиция (composability)», — они раскрывают новые, довольно необычные векторы атак.

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

О проекте Arc, его будущем и появлении AI‑браузеров — момент ответить на самые масштабные вопросы, которые вы задавали нам в прошлом году.

Перевод довольно старой статьи, которая, кажется, не теряет актуальность.

В Панели управления Windows можно выбирать, как часто вас будет донимать UAC. На выбор пользователю даётся четыре варианта...

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

Первоначальный отчёт индекса предоставляет уникальные данные и анализ, основанные на миллионах анонимизированных диалогов с Claude.ai. Он рисует самую чёткую картину того, как ИИ внедряется в выполнение реальных задач в современной экономике.

Проксмокс, он же прокс, он же Proxmox VE, или Proxmox Virtual Environment - в очередной раз обновился. Платформа виртуализации, плавно, в отличии от конкурентов развивающаяся уже 16 с половиной лет (!), вышла, в этот раз, с небольшим, но интересным списком обновлений.

Встречайте! Вышла Grafana 11.3, являющая публике дашборды на основе библиотеки Scenes — а это основа того, каким мы видим будущее дашбордов Grafana.

Но и без этого Grafana изменилась весьма заметно! Улучшен пользовательский интерфейс, включая возможность вызывать API из любого элемента на холсте с помощью новой опции «Действия» во многих визуализациях. Также появились правила записи для управляемых Grafana алертов, и теперь все могут использовать Explore Logs, часть набора приложений Explore в Grafana, представленного на ObservabilityCON, который быстро и легко извлекает аналитику из ваших данных — без каких-либо сложных языков запросов.

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

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

Когда был создан SMTP, он работал, передавая данный в открытом виде, поскольку тогда мы ещё не разработали решение для безопасной передачи данных, то, что мы называем сейчас «безопасность транспортного уровня» (transport layer security, TLS). Когда TLS наконец-то был готов, нам потребовалось придумать способ поэтапного внедрения TLS. Был создан STARTTLS, предлагающий шифрование «по возможности». По сути, почтовый сервер отправителя мог спросить почтовый сервер получателя: «Поддерживашь ли ты шифрование?», и, если ответ был положительным, устанавливалось TLS-соединение с использованием сертификата, предоставленного сервером. Если нет, использовалось SMTP-соединение с передачей данных в открытом виде.

Любой, кто знаком с темой сетевой безопасности, увидит здесь проблему. Активно действующий злоумышленник, осуществляющий атаку «атакующий посередине» (attacker-in-the-middle, AitM), может подставить свой собственный ответ, указывая, что шифрование не поддерживается, и обманом заставить отправителя использовать открытый текст, что позволит злоумышленнику перехватывать сообщения. Это классическая атака понижения версии.

Мониторинг может оказаться дорогим делом из-за огромных объемов данных, которые необходимо обрабатывать. В этой статье вы узнаете о лучших способах хранения и обработки метрик мониторинга для снижения расходов и о том, как VictoriaMetrics может в этом помочь.

(cм. вторую статью из этой серии — Как снизить расходы на мониторинг: более разумный подход к данным.)

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

В июне 2023 года Red Hat приняла спорное решение изменить способ распространения исходного кода Red Hat Enterprise Linux (RHEL). В социальных сетях разгорелись бурные обсуждения, оставившие многих в недоумении относительно последствий этого решения. Возникло множество вопросов о будущей жизнеспособности вторичных сборок RHEL, затрагивающих такие дистрибутивы, как Rocky Linux, AlmaLinux, Oracle Linux и другие. Каждый из них впоследствии сделал заявления, пытаясь успокоить свои сообщества.

Тем не менее, многие в сообществе открытого ПО расценили решение Red Hat как откровенно подлый ход.

Всё больше людей заявляют, что они перейдут (или уже перешли) на Debian, ища убежища от того, что они считают жадным корпоративным влиянием. Я полностью понимаю это чувство. Однако есть проблема, о которой я хочу поговорить: безопасность.