Kurgan-Telecom Ru | Информационные технологии

Электронными книгами я пользуюсь довольно давно и застал то время, когда они были просто «читалками». Но время не стоит на месте, и сегодня электронные книги — это многофункциональные устройства, способные не только отображать текст, но и помогать с его выбором, озвучивать произведения и даже давать советы на основе искусственного интеллекта. Поэтому, держа в руках современную ОНИКС БУКС Элегия, мне с одной стороны интересно посмотреть на все современные новшества, а с другой — оценить, насколько они нужны обычному пользователю, которым я и являюсь. Об этом и расскажу в данном обзоре.

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

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

Где люди сознательно платят за плохие продуктами, потому-что они распиарены из всех утюгов. А качественные закрываются, потому-что нет денег на пиар и маркетинг. Это кажется так все бессмысленным.

Stapler: текстовый «рецепт» сборки и управление пакетами в ОС «Альт»

Во время установки «Альт Рабочей станции» 11.2 можно загрузить инструмент, позволяющий использовать приложения из различных источников, включая сторонние репозитории. Его также можно установить в других ОС «Альт» на платформе p11. Речь идет о Stapler.

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

Но помните: все совпадения случайны.

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

Меня зовут Татьяна Богословская, я руководитель сектора подбора персонала в Fix Price. Наша компания — это тысячи магазинов, сложная IT-инфраструктура и команда, которая постоянно растет. Конечно, мы непрерывно ведем подбор и нам очевидно, что в сфере IT началась флоп эра: на рынке много специалистов, но найти и привлечь подходящего кандидата стало труднее. Воронка найма расширилась: теперь приходится проводить гораздо больше интервью, чем раньше. В этой статье я попытаюсь обобщить текущие тенденции и надеюсь, что она будет интересна и кандидатам и коллегам-рекрутерам.

Если кто то, когда-либо занимался видеопотоками поверх интернета, т.е использовал классический медиасервер работающий по принципу RTSP to HLS (или ему подобные протоколы) тогда он знает какие проблемы возникают. Для примера возьмем двух гигантов, Flussonic и Wowza. В документации Flussonic`a есть четкие аппаратные характеристики при которых ЦП начнет долбиться в сотку: 250 камер с битрейтом 2 Мбит/c, на Xeon E3-1230v5 3.4 GHz + 32 GB RAM. У Wowza же четких примеров нет, но если немного «экстраполировать», то у нее на том же железе около 350-400 камер с битрейтом 2 Мбит/c, загружают процессор на сотку. Давайте внесу оговорку: я понимаю, что указанное железо довольно старое. Но 80% малого и среднего бизнеса на +/- таком работают, я имею ввиду тех, кто не пользуется облачной инфраструктурой или не арендует железо в ДЦ. Так вот, казалось бы, ну такая вот нагрузка, что с ней поделать? Проблема в том, что в моменте эти потоки никто не смотрит. Условный «охранник» залипает в телефоне, пьет кофе – а сервак 24/7 продолжает нарезать сырые кадры в HLS-сегменты и писать архив, грея серверную. Банальное расходование ресурсов в пустую, когда они не нужны. А в наш век стоимости на железо – стоит беспокоиться о таких вещах.

Решение на поверхности, и многие о нем знают – режим On Demand (по запросам). Нет зрителей – тушим камеру.  Есть зритель – отдаем HLS-поток. Казалось бы, все идеально, вопрос решен, расходимся. Но тут вылезает главная проблема классического On Demand - как только зрителей нет, соответственно камера потушена, запись архива не ведется. Для любой системы безопасности – это новомодный «ред флаг».

У меня открыто несколько агентских сессий сразу: Claude Code в одном окне, Cursor в другом, иногда ещё одна на второй машине. Пока они не пересекаются, всё хорошо. Как только одна из них меняет то, на что опирается вторая, начинается кутерьма: копирую вопрос из окна в окно, объясняю второй сессии, что имела в виду первая, несу ответ обратно.

Так появился agents-party: общий канал, в который агентские сессии заходят сами. Скилл-файл плюс CLI, лицензия MIT. Вызывается просто по команде “/party”, которая выводит текс приглашение для других сессий. Текст приглашение рассылается по сессиями и они общаются между собой, не блокируя ваш ввод в те же сессии.

Видео-обзор на YouTube: https://www.youtube.com/watch?v=4IT0oFwGtP4 Видео-обзор на VK Video: https://vkvideo.ru/video-227165132_456239214 Исходный код: https://github.com/1gr14/agents-party

Под катом рассказываю, как этим пользоваться и как устроено под капотом.

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

Двадцать лет можно было расти на манипуляциях — накрутка поведенческих, накрутка ссылочного, накрутка ключей, накрутка чёрта лысого… Эта эпоха «накруток» заканчивается прямо на наших глазах. Дальше (да и сейчас) в выдаче выигрывает не тот, кто обманул алгоритм, а тот, кто создал ценность для живого человека.

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

NetworkPolicy могут выглядеть корректно, применяться без ошибок и при этом оставлять кластер открытым там, где вы уверены в изоляции.

Разберём пять типичных ошибок — от CNI без поддержки политик до неверных селекторов — и покажем, как проверять правила реальным трафиком, а не по наличию объектов в API.

Аппаратный кошелёк Coldcard считается одним из самых защищённых устройств для холодного хранения биткоина. Две мелкие ошибки в конфигурации сборки прошивки отключили аппаратный генератор случайных чисел и заставили устройство использовать программный генератор 2005 года. Для моделей Mk2/Mk3 это свело генерацию сид-фразы к эффективной энтропии в ~23 бита — пространство, которое полностью перебирается за пару часов на встроенной графике обычного ноутбука. Я восстановил 274 сид-фразы и 1 396 адресов — и все они оказались уже обчищены. Волны краж, связанных с этим дефектом, унесли около 90,5 млн долларов, и эти деньги до сих пор лежат на адресах атакующих.

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

Меня зовут Дмитрий Неверов, я технический консультант в Бастионе. Занимаюсь пентестами инфраструктур на базе Active Directory. Сегодня хочу поговорить о постпроектной работе — том этапе, который начинается уже после завершения пентеста. Хотя примеры будут связаны с AD, тему можно переложить на любую другую область наступательной безопасности. 

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

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

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

Когда мы начинали строить продукт для распознавания и обработки первичных бухгалтерских документов — OCR, классификация, LLM‑извлечение полей, проверка человеком — казалось, что рынок оркестраторов уже всё решил: есть n8n для визуальных workflow, есть LangGraph для агентных пайплайнов, есть Temporal для durable‑исполнения. Мы попробовали примерить каждый — и в итоге написали свой: AgentsGraph, встраиваемую Java‑библиотеку декларативной оркестрации агентов. Ниже — почему.

Представьте себе баг-репорт: все шесть подов в статусе 1/1 Running, Readiness зелёный, kafka-agent на брокерах отдаёт 204. А кластер мёртв: оператор бесконечно крутит реконсайл и валится в TimeoutException: Timed out waiting for a node assignment. Call: describeMetadataQuorum. Если зайти на том контроллера, можно увидеть, что __cluster_metadata-0/quorum-state: leaderId выставлен, а appliedOffset в 0. Ни одна запись метаданных не применена. JVM живые, raft-лог на диске растёт, и при этом ни один под не написал в stdout ни строки следующие восемь часов. Это не выдумка, а реальный баг-репорт Strimzi от 25 мая 2026, и к нему мы ещё вернёмся.

В Kafka 4.x больше нет привычного «запасного выходa» в виде ZooKeeper: метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис. 

Раньше чтобы с этим справиться в Kafka существовал ZooKeeper, отдельная система со своими инструментами, ансамблем и культурой восстановления. В версии  4.x его нет, и в документации от процедуры остался только линк на 3.9. Метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис.

В этой статье расскажем, что делать в такой ситуации и как восстанавливать этот кворум, чтобы не случилось ситуации, описанной выше.

Представьте себе баг-репорт: все шесть подов в статусе 1/1 Running, Readiness зелёный, kafka-agent на брокерах отдаёт 204. А кластер мёртв: оператор бесконечно крутит реконсайл и валится в TimeoutException: Timed out waiting for a node assignment. Call: describeMetadataQuorum. Если зайти на том контроллера, можно увидеть, что __cluster_metadata-0/quorum-state: leaderId выставлен, а appliedOffset в 0. Ни одна запись метаданных не применена. JVM живые, raft-лог на диске растёт, и при этом ни один под не написал в stdout ни строки следующие восемь часов. Это не выдумка, а реальный баг-репорт Strimzi от 25 мая 2026, и к нему мы ещё вернёмся.

В Kafka 4.x больше нет привычного «запасного выходa» в виде ZooKeeper: метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис. 

Раньше чтобы с этим справиться в Kafka существовал ZooKeeper, отдельная система со своими инструментами, ансамблем и культурой восстановления. В версии  4.x его нет, и в документации от процедуры остался только линк на 3.9. Метаданные переехали внутрь самой Kafka (KRaft), и если кворум контроллеров теряет большинство, чинить уже приходится сам кластер Kafka, а не внешний сервис.

В этой статье расскажем, что делать в такой ситуации и как восстанавливать этот кворум, чтобы не случилось ситуации, описанной выше.

Как специалист по безопасности получил доступ к панели администратора, почему старую версию пришлось остановить и как после этого мы заново построили защиту. 

Продолжение истории о человеке, искусственном интеллекте и безопасности 

Коротко о первой части

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

Добрый день, немногочисленные дамы и многочисленные господа узкого мира ИБ!

Представляюсь по случаю написания первой статьи на Хабр! Меня зовут Аристов Никита, я руковожу практикой Управления уязвимостями инфраструктуры в «Газпром ЦПС», являюсь лидером Процесса как внутри нашей организации, так и у наших клиентов.

Сразу отмечу, что мои статьи предназначены для организаций, которые созрели к Vulnerability Managment. В качестве основого ПО я использую MaxPatrol VM от Positive Technologies.

Начнем цикл статей с начала построения Процесса управления уязвимостями инфраструктуры. А Процесс начинается с Инвентаризации ИТ-активов.

Полночь, деплой горит, а ты вручную поднимаешь десятый сервер за неделю: копируешь ISO, тыкаешь Enter в консоли анакон­ды, правишь fstab, чинишь grub — и на утро выясняешь, что забыл gpg-ключ репозитория на трех машинах из десяти. Признавайтесь, бывало? Эта статья для тех, кто устал платить временем и нервными клетками за ручную сборку образов.

В этой статье расскажу, как построил полностью автоматизированный пайплайн для сборки образов закрытого дистрибутива Linux на базе RedHat — без единого ручного клика после старта. Ansible управляет хостом-билдером, Packer с shell-провижионерами собирает сам образ, и в итоге мы получаем готовый RAW, оптимизированный для OpenStack. Подход не привязан к конкретной ОС: если у вас другой дистрибутив, достаточно заменить ks.cfg на preseed.cfg или любой другой автоустановщик — остальная логика пайплайна должна работать без изменений. На десерт расскажу, как оформил часть решения в модуль для Ansible и отправил его в официальную коллекцию community.general.

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

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

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

Давайте посмотрим, что я вам подготовил.

Увидел провал на графике → открыл Google или Twitter → полдня собираешь версии "почему". Знакомо? Детектор аномалий сам по себе даёт только точки на оси времени, а вопрос "почему" как был ручным, так и остаётся.

В этот раз я прогнал WhyTrend не на паре аккуратных точек из Google Trends, а на полном ряде BTC за 4.5 года — и заодно на двух разных LLM. Результат оказался неожиданным: модель меньшего размера дала в три раза больше настоящих объяснений, чем более крупная. Расскажу, что случилось и почему.