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

Привет, Хабр! Мы протестировали zVirt 5.0 с функциональностью, которой нет в ванильном oVirt. Главное, что нужно знать: в 5.0 на каждом узле меняется гипервизорная операционная система, фактически выполняется переустановка хостов и системы управления. В статье подробно разберу, почему переход на новую версию – это не рядовое обновление пакетов, а отдельный проект со своими особенностями и подводными камнями.

Вот уже несколько десятилетий идёт непрерывная борьба между требованиями игр к производительности компьютерного железа (и в первую очередь видеокарт) и возможностями самих видеокарт.

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

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

Так что же делать, если ещё не совсем старая видеокарта пока не превратилась в “затычку для слота”, но уже на пути к этому (или если это пусть и новая, но встройка, которая по сравнению с дискретными видеокартами никогда и не была мощной), и какая-то новая игра в нативном разрешении монитора уже откровенно не тянет?

Конечно, можно уменьшить разрешение в настройках игры — например, запустив её в 1080p или даже 720p, однако на современных мониторах с цифровыми LCD- или OLED-панелями и простейшими апскейлерами это выглядит, мягко говоря, не слишком хорошо, и изображение превращается в мыльное шоу.

Попробуем поискать другие паллиативные решения:

Госдума приняла в третьем чтении законопроект № 1254384-8 о поддержке «Почты России». Основные положения закона должны заработать с 1 марта 2027 года, а нормы об электронной почтовой системе для доставки юридически значимых сообщений — с 1 сентября 2027 года.

Через эту систему органы власти, Банк России, госкомпании, госкорпорации и юрлица с долей государства более 50% смогут направлять заявления, уведомления, извещения, требования и иные юридически значимые сообщения. Для них это будет бесплатно. А вот для ИП и компаний ящики создадут автоматически, и за их использование введут ежемесячную абонентскую плату.

Размер пока неизвестен — его должно определить Правительство, но при неоплате доступ к ящику могут и приостановить…

Привет, Хабр! Я Артем, групп-лид в Т-Банке. Я пришел в Т почти пять лет назад и с тех пор так или иначе всегда работал в домене «Кэшбэки» — одной из важных фич нашей экосистемы. А сегодня руковожу тремя стримами: кэшбэк-платформой, обработкой чеков для начисления кэшбэка и платформой доступности бонусных спецпредложений клиентам.

Моя статья — пятая в проекте «20 в 20» к 20-летию Т-Банка, в котором мы рассказываем об ИТ-хабах в разных городах и о людях в них. Сегодня — о минском ИТ-хабе, которому в этом году уже пять лет!

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

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

Привет, я Саша Овчинников, старший специалист по тестированию в Контуре.

Привет!

Буду с вами честен, для меня читать сухие переводы документации или смотреть 40-часовые видеокурсы - то еще удовольствие. Поэтому я решил устроить эксперимент и разбирать Go прямо в публичном поле, шаг за шагом документируя весь процесс.

Я не новичок в разработке - повседневно пишу на Python и TypeScript, знаком с базовым devops. Но вот на территорию Go осознанно захожу впервые.

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

Этот цикл статей - мой интерактивный учебник, который я пишу в реальном времени параллельно с изучением языка. Я не Go-гуру и не архитектор с многолетним опытом в этом стеке.

Поэтому если вы опытный Go-разработчик и видите в тексте неточность или косяк - буду искренне рад конструктивным подсказкам в комментариях.

Чек-лист для тестирования поисковых и RAG-систем — от базовой работоспособности поискового движка до качества генерации, агентных сценариев и поведения на неполных данных. Шесть уровней проверок, сводная таблица с инструментами для каждого уровня и глоссарий из 50+ терминов. Проверку стоит организовывать по порядку, нет смысла гонять RAG-метрики, если система не проходит Уровень 0, то проблема может быть в том, что поиск не находит документ из-за опечатки в запросе, а не в качестве генерации.

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

Это продолжение моей статьи о том, как я сделал движок совместимый с GTA San Andreas для запуска в браузере, рекомендую сначала прочитать:

https://habr.com/ru/articles/1051828/

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

SonarQube подключен, дашборд есть, анализ запускается на каждый MR, но никто не пользуется. В таком случае проблема не в инструменте. Проблема в том, что между «Sonar работает» и «Sonar приносит пользу» — пропасть из-за отсутствия договорённостей. Я видела это на нескольких проектах и расскажу, что конкретно превращает декоративный дашборд в работающий механизм контроля качества.

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

Сотрудники Anthropic опубликовали 6 июля 2026 года результаты своего нового исследования в котором заявили об обнаружении в Claude аналога "глобального рабочего пространства" — J-space.

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

В этой статье я рассмотрю, почему Теория глобального рабочего пространства описывает структуру находки, но молчит о её главной странности — о том, что workspace состоит из слов. И почему на этот вопрос сто лет назад ответил Лев Выготский.

Картинка: Bespalko, S.; Mizeraczyk, J. Overview of the Hydrogen Production by Plasma-Driven Solution Electrolysis. Energies 2022, 15, 7508. https://doi.org/10.3390/en15207508

В прошлой статье мы обзорно подняли вопросы, касающиеся апгрейда и смены топлива для двигателей внутреннего сгорания, в том числе обратив своё внимание на достаточно нестандартные и нетипичные варианты — малознакомые широкой публике, как-то — «лить воду в двигатель», например. 

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

Поэтому, ввиду крайней интересности вопроса, в этой статье мы попробуем более подробно остановиться на одном из них (извлечение водорода). 

До начала рассмотрения, думаю, стоит ещё раз напомнить, насколько интересен рассматриваемый круг вопросов: по сути, от того, как увеличить эффективность двигателей внутреннего сгорания, перевести их на более доступное топливо, уменьшить его потребление — зависит решение насущных потребностей огромного количества людей…

В Лаборатории искусственного интеллекта «Финама» мы изучаем и развиваем применение ИИ в финансовом домене: от бенчмаркинга LLM до прикладных сценариев в трейдинге, аналитике и управлении рисками. В предыдущей статье мы рассказывали о первой версии нашего набора бенчмарков для оценки финансовых знаний моделей. С тех пор проект вырос, получил отдельную страницу FINESSE-Bench и заметно изменился — и по объёму, и по качеству, и по строгости методологии.

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

По этой причине мы продолжаем развивать FINESSE-Bench как набор бенчмарков, который позволяет оценивать не только среднюю точность модели, но и то, как она ведёт себя при росте сложности, как переносит качество между разными типами задач и насколько уверенно работает в специализированных финансовых сценариях.

В этой статье мы хотим показать, как проект изменился после первой публикации. Мы обновили часть данных и исправили проблемные вопросы в CFA-like Level 1, добавили новый набор данных по техническому анализу — CFTe-like Level 1, расширили пул моделей, усилили расчёт метрик за счёт бутстрап-оценки и аккуратного агрегирования результатов по группам бенчмарков, а также отдельно посмотрели на различающую способность и насыщение самих наборов вопросов.

В первой части статьи мы пришли к выводу, что само использование ИИ не ускоряет инженерную систему. Можно вырастить MAU LLM, потом MAU API, раздать людям кодинг-агентов и всё равно не увидеть изменений в Lead Time, Throughput и Defect Rate.

Проблема в том, что локальное ускорение быстро упирается в остальной процесс. Один человек или одна роль могут начать делать свою часть быстрее, но задача всё равно ждёт требований, проверки, тестирования, согласований, соседних команд или бизнес-эксперта. Поэтому дальше мы пошли в Agentic Engineering.

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

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

Купили блок питания помощнее, а ПК все равно вырубается в играх? Разбираем, как за полчаса вычислить настоящую причину.

Спойлер: оба находятся в опасности, но по-разному. Эта разница имеет значение.

Я не собирался сравнивать веб и мобилку как две враждующие платформы.

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

На вебе можно спрятать админку за условием в JavaScript и решить, что доступ закрыт. В мобилке можно положить токен в SharedPreferences и надеяться, что до него никто не доберется. Можно оставить открытый бакет, отключить нормальные правила Firebase, забыть про rate limit на логине или принять userId из тела запроса.

Все это выглядит как мелочи, пока приложение работает.

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

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

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

Воодушевившись статьёй std::expected в C++23: гайд по миграции с исключений на функциональный error handling, представляю собственную с переписанными примерами на Rust. Код в статье итеративно переписывается и улучшается.

Привет, Хабр, всем случайно зашедшим и зашедшим целенаправленно! Меня зовут Семён Клюев, я фронтенд-разработчик в компании «Криптонит»! Хочу поведать вам историю о том, как я стал джуном в период конкуренции «1000 человек на 1 вакансию» и «замены всех на ИИ». 

Наверняка вы слышали о том, что на рынке труда сейчас очень сложная ситуация, что сотрудников заменяет ИИ и что в IT сейчас не попасть. Давайте разберёмся, действительно ли это так, и если нет, то на какой путь я бы встал сейчас, чтобы попасть в это самое IT ☺ Спойлер: Меня не заменили, но до этого момента было страшно. 

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

Моя история учёбы: как врач решил стать программистом 

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

Приветствую, коллеги! Это опять @ProstoKirReal.

Мы с вами прошли большой цикл статей про SFP-модули. Обсудили историю развития, типы модулей, скорости, DAC/AOC, оптические кабели, пассивные компоненты, а также технологии WDM, CWDM и DWDM: