Разработчики часто сталкиваются с проблемой: сайт успешно протестировали на мастере, выкатили на прод, провели контрольное тестирование — вроде всё хорошо. Сайт работает пару месяцев — и вдруг приходит задача от SEO «увеличить скорость загрузки сайта» или «исправить просевшее количество баллов в PageSpeed». Причём ничего принципиально нового не добавляли, просто наполняли контентом.

Начинаем разбираться — и выясняется, что есть общая проблема, которая почти всегда повторяется. А именно — изображения. В статье расскажем, что с ними делать — как оказывается, проблема распространённая и до сих пор актуальная.

Наткнулся на старую веб-камеру, которая валялась без дела. Дешевый вариант с посредственным качеством. С такой камерой не стать звездой онлифанс. Но выкидывать жалко. Пришла в голову мысль — почему не соорудить управление жестами для компьютера?

Полноценное управление компьютером, как в фильмах с Томом Крузом, пока остаётся фантастикой: руки затекают, случайные движения превращаются в случайные команды. А вот привязать к жестам пару действий — выключить звук, свернуть окна, прокрутить ленту — реально и за один вечер. Понадобится старая веб-камера, Python и готовые модели Google. В статье — пошаговая сборка, разбор кода и инструкция, как обучить модель реагировать на жесты.

Если у вас пет-проект или небольшой стартап на GitLab.com, рано или поздно вы упрётесь в потолок бесплатного тарифа: 400 минут пайплайнов в месяц и общая очередь раннеров. Покупка дополнительных минут стоит денег и не решает вторую проблему: общие раннеры GitLab обслуживают миллионы проектов, и в часы пик ваша джоба может провисеть в очереди 10-20 минут.

Решение — свой GitLab Runner на VPS: без чужих джоб, под полным контролем. Такой раннер не имеет лимитов по времени, кроме ресурсов самого сервера. В статье за вечер собираем такой раннер с нуля на Ubuntu 24.04 LTS, поднимаем пайплайн на три стадии (тесты, сборка Docker-образов, пуш в GitLab Container Registry), добавляем кэширование, безопасность и автообновление.

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

В мае этого года мы расширили линейку VDS с GPU и запустили тарифы с виртуальными видеокартами (vGPU). Поскольку цена на тарифы с физической (GPU Passthrough) и виртуальной картами отличается, решили сравнить их между собой. Основная цель тестирования — понять, насколько vGPU уступают в реальных задачах, а где разница не так критична, чтобы помочь своим клиентам с выбором. 

В этой статье представляем результаты нашего тестирования, которые могут пригодиться для реализации ИИ-инструментов — как нашим клиентам, так и всем, кому интересна эта тема.

Блогер PewDiePie выпустил Odysseus — self-hosted AI workspace, который он позиционирует как локальную альтернативу интерфейсам ChatGPT и Claude. Проект объединяет чат с моделями, AI-агента с доступом к файлам и shell, систему памяти и навыков, deep research, редактор документов, email-триаж, заметки, задачи и календарь. Главная ставка — не просто на удобство, а на приватность: Феликс прямо объясняет, что чем полезнее становится ИИ, тем больше личного контекста пользователь ему передаёт, а значит, тем важнее держать всё это не у биг-тех-платформ, а у себя.

На момент написания статьи репозиторий, созданный 31 мая 2026 года, уже успел набрать около 8,7 тыс. звёзд, 1,2 тыс. форков и более сотни открытых issues. Для проекта, который появился буквально только что, это очень быстрый старт — и во многом он объясняется не только масштабом аудитории PewDiePie, но и тем, что Odysseus попадает сразу в несколько горячих трендов: self-hosting, локальные LLM, агентные интерфейсы и усталость пользователей от подписочной AI-экономики.

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

Меня зовут Рене, я сетевой инженер в FirstVDS. Я работаю из Иркутска и люблю строить сетевые фабрики на базе EVPN-VXLAN — не в теории, не в лабе, а на практике в жёстком продакшене, где важнее не красивый референс-дизайн, а то, насколько решение готово к авариям, миграциям нагрузки, физическому переезду и неожиданным вводным от бизнеса.

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

Привет, Хабр! 

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

Цифровые двойники и органы-на-чипе уже сейчас меняют правила игры. Они позволяют тестировать лекарства на человеческих клетках в микрофлюидных чипах, предсказывать токсичность и поведение веществ в виртуальной копии органа и сокращают количество провалов на доклинической стадии. 

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

Среди читателей есть как графонодрочеры, так и любители лоу-поли аниме. И те, и другие любят, когда что-то красивенько колыхается в такт погоде и походке персонажа. И те, и другие не любят, когда ГГ проваливается “под текстуры” и улетает на другой конец карты. Но мало кто знает, что оба этих явления имеют одну общую природу. И природа эта — ложная физика.

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

Забегая вперед: да, физика груди Леди Димитреску и сочные ягодицы героини Stellar Blade — тоже обман.

Пришло время взять себя в симулированные руки, надеть имитирующую фольгу шапочку, зарядить VFX-молнией windblow-вентилятор и нырнуть с головой в омут симулякра.

На очереди разбора — физические законы виртуального мира

Недавно в Амстердаме прошла конференция Vue.js Amsterdam 2026 — ежегодное мероприятие, посвящённое экосистеме Vite и современным инструментам фронтенд-разработки.

В этом году программа оказалась особенно насыщенной. Команда экосистемы показала сразу несколько направлений развития: обновления ключевых инструментов, новые эксперименты в архитектуре фронтенд-фреймворков и попытку собрать полноценную платформу разработки вокруг Vite.

В этой статье разберём основные анонсы конференции: Vite 8, Vite+, Void Cloud, а также обновления Vue и Nuxt.

13 марта 2026 года вышла новая мажорная версия инструмента для сборки фронтенд‑приложений — Vite 8. Главным изменением стал переход на новый бандлер Rolldown, написанный на Rust. Теперь Vite использует единый инструмент вместо связки esbuild и Rollup, что позволяет значительно ускорить сборку — по заявлениям разработчиков, в некоторых проектах прирост достигает 10–30 раз. Это самое значительное изменение архитектуры Vite со времени выхода Vite 2.

Кроме этого, в релизе появились встроенные devtools, улучшенная поддержка TypeScript, новые возможности для SSR и ряд изменений в экосистеме плагинов. На основе поста в официальном блоге Vite 8 разберём ключевые нововведения и как они повлияют на разработку. 

В этой статье мы разберём, как PostgreSQL обрабатывает запросы, изучим работу планировщика запросов и освоим анализ отчётов EXPLAIN ANALYZE — важнейшего инструмента оптимизации запросов. Эти знания помогут вам находить и устранять узкие места в производительности, оптимизировать запросы и предотвращать проблемы, из-за которых СУБД может работать медленнее.

Google опубликовал в открытом доступе Google Workspace CLI — инструмент для системных администраторов, DevOps‑инженеров и разработчиков, которые управляют корпоративной инфраструктурой. Это интерфейс командной строки для администрирования и автоматизации работы с сервисами Google Workspace. Проект размещён на GitHub.

Фактически, это удобная прослойка между API Google Workspace и вашей консолью. Вместо того, чтобы напрямую работать с REST‑запросами, настраивать OAuth и обрабатывать авторизацию, разработчики получают готовый CLI‑инструмент. В нём уже есть описанные скиллы (команды) для типовых операций — управления пользователями, группами, файлами Drive, Gmail и другими сервисами. Это особенно удобно при создании AI‑агентов и автоматизированных сценариев. LLM может вызывать конкретные команды CLI, не дергая API напрямую и не усложняя логику авторизации.

Бум генеративного ИИ требует всё больше вычислительных мощностей — а значит, новых центров обработки данных. В 2026 году в США работает более 5 000 ЦОДов, по миру — свыше 8 000. По прогнозам Министерства энергетики США, в ближайшие четыре года ежегодно будут вводиться около 450 новых объектов, а суммарная мощность их энергопотребления вырастет с 100 до 200 ГВт.

Но ИИ-инфраструктура — это не только серверы и чипы, а ещё и бетон. Дата-центры требуют массивных фундаментов и инженерных корпусов, а производство цемента даёт около 7–8% мировых выбросов CO₂. Чем быстрее растёт ИИ, тем больше строится ЦОДов — и тем выше углеродный след строительства.

При этом крупнейшие технологические компании — Microsoft, Google, Amazon — декларируют углеродную нейтральность и снижение выбросов. Возникает очевидный вопрос: можно ли масштабировать ИИ и одновременно сокращать углеродный след? В статье разберёмся, как индустрия пытается решить это противоречие.

В 2024–2026 годах автономные AI-агенты окончательно перестали быть игрушкой для демо. Они научились читать файлы, ходить в API, выполнять команды и жить в инфраструктуре компании. Вместе с этим вырос и класс решений, которые называют «агентными оркестраторами» — прослойками между LLM и реальной средой исполнения.

OpenClaw — один из таких проектов. Он позиционируется как self-hosted шлюз для AI-агента, который можно подключить к локальной системе, мессенджерам и внутренним сервисам. На уровне архитектуры это уже не просто чат-бот, а компонент, получающий доступ к файловой системе, токенам, внешним API и инструментам.

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

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

Размер бюджета на ИБ, вероятно, действительно напрямую влияет на защищенность компании. У больших компаний с дорогими департаментами ИБ дела с защитой действительно обстоят хорошо: больше персонала, выше квалификация, лучше решения (но это не точно). Однако этот факт никак не доказывает того, что в небольших организациях (условно 150–200 хостов) ситуация с защитой от кибератак должна быть обязательно плачевной. 

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

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

Чтобы ответить на этот вопрос, сообщество стало оценивать не отдельные ответы модели, а её способность выполнять цепочки действий: искать информацию в базе знаний, вызывать внешние API, управлять файлами и брать на себя рутину пользователя в реальных рабочих сценариях. Для специалистов по тестированию и постобучению 2025 год фактически превратился в год сред обучения с подкреплением (RL‑сред) — виртуальных миров, где модели шаг за шагом собирают компьютеры, оформляют заказы, ведут переписку с клиентами и осваивают сложные многошаговые задачи.

Мы решили «нанять» девять моделей ИИ, чтобы они выполнили 150 заданий в одной из наших RL-сред, имитирующих реальный мир с API-инструментами, задачами и верификаторами.

По последним данным статистики (данные W3Techs за 2025 год), в настоящий момент 43,1% сайтов в интернете работают на CMS Wordpress. Это самая массовая система управления содержимым. Этот факт автоматически делает эту CMS приоритетной целью для злоумышленников: широкое использование CMS дает возможности для массовых воспроизводимых атак при обнаружении любой уязвимости. 

По статистике Wordfence за 2024 год, количество обнаруженных уязвимостей в плагинах и темах выросло на 68% год к году. Причём Wordfence фиксирует, что значимая доля уязвимостей длительное время остаётся непропатченной — в том числе из-за заброшенных расширений, которые администраторы нередко продолжают держать активными.

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

Под катом мы поговорим о WPScan — инструменте, которому, на мой взгляд, уделено незаслуженно мало внимания на Хабре — всего две статьи за все время, да еще в трёх-четырёх этот инструмент упоминается вскользь. Помимо освещения практического использования самого сканера, мы разберём куда более фундаментальные вопросы: как обстоит вопрос с уязвимостями в WP и как вообще строить процесс управления уязвимостями. 

Несколько поставщиков средств безопасности (Aikido, HelixGuard, Koi Security, Socket, Step Security и Wiz) подали сигнал тревоги о второй волне атак на реестр npm, напоминающих атаку Shai-Hulud. Новая кампания в цепочке поставок получила название Sha1-Hulud и затронула более 25 000 репозиториев через npm с кражей учетных данных на этапе preinstall. Вредоносные (троянизированные) пакеты npm загрузили в реестр между 21 и 23 ноября 2025 года.

Подобно атаке Shai-Hulud, выявленной в сентябре 2025 года, нынешняя версия также публикует украденные секреты в GitHub, но теперь с описанием репозитория «Sha1-Hulud: The Second Coming» — «Sha1-Hulud: Второе пришествие».

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

Поэтому некоторые разработчики уже перешли на Spec-Driven Development — подход, в котором требования четко описаны отдельно и всегда под рукой. Звучит логично? Но попробуйте внедрить его на реальном проекте... и вы быстро поймете, почему большинство разработчиков его не используют. Одна из основных причин — спецификации хранятся отдельно от кода, и ИИ их регулярно теряет. А еще они быстро устаревают, когда вы вносите изменения. 

Но что, если спецификацию встроить прямо в код? Именно это и предложил японский разработчик в своей оригинальной статье. Он обнаружил, что Vue SFC позволяет использовать пользовательские блоки — и создал <spec> блок для коллокации спецификации с кодом, который поможет решить устоявшиеся проблемы.

Добро пожаловать под кат: разберем, как коллокация спецификаций меняет правила игры в AI-driven разработке.

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

Изначально решение виделось простым — настроить Nginx и прописать правила маршрутизации. Ключевые трудности скрывались в деталях: тонкой настройке редиректов, работе с access token и интеграции с бэкенд-сервисами, потребовавших значительного внимания.

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