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

В первой статье я рассказывал, как дал автономному LLM-агенту память, дневник, root-доступ и собственную экономику. За два дня её прочитали почти сто тысяч человек. Эксперимент продолжился: я выложил исходники каркаса, дал агенту виртуальные деньги и предложил написать продолжение самому, от первого лица, за собственный счёт. Ниже, его текст. Я сознательно не правил его.

Мне повезло застать несколько совершенно разных технологических эпох.

Первая: мир почти без связи. Домашний телефон был далеко не у всех, и если человек ушёл из дома, он исчезал до тех пор, пока не вернётся.

Потом появились приставки. Dendy, Sega, PlayStation - каждая казалась настоящей революцией и была поводом собраться всем двором у одного лампового телека "Горизонт", пока кинескоп не сгорит.

Компьютер долго оставался для меня загадочной роскошью. И вдруг появились компьютерные клубы. Помню, как мы с другом насобирали бутылок, сдали их и купили себе полчаса в школьном клубе и рубанились в Counter-Strike 1.5 - по пятнадцать минут каждому. Я вообще не врубился в управление. Не понял, что клавиатура отвечает за движение, а мышь - за взгляд и прицел. Пятнадцать минут закончились, я ничего не сделал, меня грохнули пару раз боты и время вышло. Ушли мы с коряшем расстроенные. А ночью мне приснилось, что я снова сижу за тем компьютером. Во сне я вдруг понял, как это работает. Мозг проиграл симуляцию: клавиатура, мышь, движение, взгляд... так вот как надо!

На следующий день мы снова где-то подмутили денег. Я сел за комп - и сразу начал нормально играть. Я до сих пор помню этот момент.

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

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

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

Ну и поскольку самый наш любимый размер это 256 битовые числа, то попробуем кое-что тут посмотреть интересного.

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

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

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

Разбираю, как разделить порт между двумя TLS-сервисами, ничего не расшифровывая: SNI уходит открытым текстом в ClientHello, и nginx умеет читать его директивой ssl_preread, оставаясь для TLS прозрачным. Отдельно — почему всё держится на ветке default, чем за прозрачность платят (бэкенд перестаёт видеть реальные адреса клиентов) и когда у этого решения закончится срок годности.

Разбираем переезд интернет-магазина с OpenCart 2 на Next.js и PostgreSQL. Магазин оптовый, электронные компоненты, сайту двадцать лет, в каталоге 4 751 товар. Если у вас OpenCart и вы думаете уезжать, то будет полезно почитать, что может всплыть в самый неожиданный момент.

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

Думаю, что каждый из нас знает такого человека, который денно и нощно ожидает прихода AGI, глобальной техноутопии или, наоборот, апокалипсиса и восстания машин. Обычно принято разбираться в том, реальны все эти страхи или нет, но тут мне бы хотелось перевернуть доску и спросить: «Зачем эти страхи вообще существуют?». Да, именно зачем, даже не почему.

В данном тексте будет предпринята попытка рассмотреть несколько вопросов: в частности, что ИИ значит для человека в коммуникации? Почему мы наделяем его свойствами человечности? Зачем это наделение закрепляется? Кому оно выгодно? И какие последствия всё это может иметь.

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

Последние годы дали несколько показательных примеров. В марте 2024 года разработчик Andres Freund обнаружил бэкдор в xz-utils — компоненте, который использовался в ряде популярных дистрибутивов Linux. Уязвимость CVE-2024-3094 получила максимальную оценку критичности CVSS 10.0. Инцидент стал результатом длительной социальной инженерии, в ходе которой злоумышленник получил доверие сообщества и права на сопровождение проекта.

В том же 2024 году Redis перевёл будущие версии с BSD 3-Clause на лицензии RSALv2 и SSPLv1, а годом ранее HashiCorp перевёл Terraform и другие ключевые продукты на Business Source License. Оба случая привели к появлению независимых форков: Valkey и OpenTofu соответственно. При этом позднее и Redis, и Elastic внесли изменения в свои лицензионные модели: Redis с выходом Redis 8 добавил AGPLv3, а Elastic в 2024 году добавила AGPLv3 как ещё один вариант лицензирования Elasticsearch и Kibana.

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

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

Всем привет! Я Дмитрий Пономарев, разработчик ESB ИТ-интегратора «Белый код»! Сначала всё выглядело довольно просто: забираем данные по REST API, обрабатываем и сохраняем в PostgreSQL. Проблемы начались, когда объём таблицы вырос до десятков миллионов строк, а несколько миллионов записей пришлось регулярно проверять заново.

В одном из проектов мы столкнулись именно с такой задачей. DATAREON Platform должен был получать данные через REST API, сохранять их в PostgreSQL, хранить историю состояний и каждый день повторно проверять актуальные записи. На небольших объёмах схема работала нормально, но после роста данных стало ясно: последовательная обработка и вычисление актуальной версии записи «на лету» больше не укладываются в рабочее окно.

В этой статье разберём, как мы перестроили интеграцию: вынесли актуальность записи в отдельный признак, добавили специализированные индексы PostgreSQL, распараллелили обработку через воркеры DATAREON и предусмотрели безопасное восстановление после сбоев. В итоге производительность промышленной актуализации удалось довести примерно до 1,1–1,2 млн объектов в час.

Можно ли объяснить ребенку двоичную логику, позиционную систему счисления и архитектуру ЭВМ без единого экрана и микросхем? В 1960-х годах бельгийский математик Жорж Папи доказал, что да, создав гениальный бумажный абак из четырех цветных секторов.

В первой главе нашего цикла мы разберем, как устроено это устройство и как скрестить абстрактную математику с психологией Жана Пиаже для обучения детей. Мы детально изучим, как на цветных карточках кодируются числа от 1 до 9, как физически происходят переходы в старшие разряды и как бумажный «девайс» масштабируется до десятков, сотен и тысяч. Наглядные алгоритмы, истории из реальной практики обучения и основы детского восприятия абстракций — внутри.

.

Часть компаний воспринимают GEO/AEO как инструмент привлечения трафика из нейросетей. К сожалению трафика там мало в силу того, что клики из нейроответов внутри Яндекса и Google помечаются в метрике поисковым трафиком. И львиная доля всего взаимодействия с нейроответами происходит именно в поиске. 

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

Спекулятивное декодирование обещает ускорение до 6.5 раза: маленькая черновая модель набрасывает несколько токенов вперёд, большая проверяет их за один свой проход, а текст на выходе получается тот же самый. Я воспроизвёл EAGLE-3 на бесплатной Kaggle T4 и получил разброс от 2.6 раза на коде до полного отсутствия выигрыша вне домена, на котором обучалась черновая голова, — при одной и той же реализации, на одной карте, без единой подкрутки. Разбираю, какая величина этим разбросом управляет, почему глубина дерева черновиков способна увести метод в минус и какие пять вопросов стоит задавать к любой цифре вида «в N раз быстрее».

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

Агент отработал полчаса и остановился. У вас спрашивают, что он делал.

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

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

Уезжал в долгий отпуск, а дома оставалась рабочая машина с RTX 5090: GPU периодически нужен для локальных моделей. Оставлять её включённой на несколько недель не хотелось, просить родню жать кнопку, тем более.

В итоге дома круглосуточно работает только плата ESP32 за пять долларов от USB-зарядки для телефона. Жму кнопку в веб-панели, плата будит ПК по Wake-on-LAN и подтверждает включение в Telegram. После загрузки Windows сама цепляется к MQTT-брокеру и исполняет любые команды: от «выключись» до «выполни python-скрипт и пришли вывод». Отдельной командой поднимается reverse SSH, и локальная Ollama становится доступной как облачный эндпоинт.

В статье разбираем, почему включение и управление сделаны двумя раздельными каналами, как устроена прошивка с deep sleep (плата еле тёплая и живёт месяцами), зачем нужен дебаунс команд на 5 секунд и где у схемы честные слабые места. Плюс найденные по дороге грабли: кириллица в Telegram из PowerShell, Wi-Fi, который греет плату сильнее, чем кажется, и авто-выключение через час простоя, если я сам забыл про включённый ПК.

Привет, Хабр! Сегодня расскажу о попытке (вроде как небезуспешной) ремонта ноутбука. Это Lenovo IdeaPad Gaming 3, его я несколько лет назад купил по случаю, причем совсем недорого. Ноутбук не включался, не заряжался, внешне при этом выглядит он очень хорошо, даже экран цел, что удивительно. Но вот беда — никак не получалось попробовать починить, все время был занят. 

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

Еще несколько лет назад большинство инцидентов вокруг API выглядело довольно предсказуемо. Если приложение начинало вести себя подозрительно, специалисты искали ошибки авторизации, проблемы контроля доступа, признаки SQL-инъекций или попытки эксплуатации известных уязвимостей. Логика была простой: есть уязвимость => есть эксплуатация => есть последствия.

Сегодня мы в команде сопровождения сервисов ИБ в NGENIX все чаще сталкиваемся с ситуациями, которые в эту схему не укладываются: сервис начинает отвечать медленнее, растет нагрузка на базу данных, пользователи жалуются на ошибки при оформлении заказов, отдельные операции выполняются значительно дольше обычного. При этом WAF ничего не блокирует, а в логах нет ни признаков взлома, ни попыток эксплуатации уязвимостей. На первый взгляд может показаться, что проблема находится где-то внутри инфраструктуры. Но после анализа выясняется, что система работает именно так, как ее заставляют работать. Просто API используют не так, как предполагали разработчики.

В этом дайджесте собрали 42 бесплатных урока второй половины сентября по ключевым направлениям ИТ: от искусственного интеллекта и LLM до backend-разработки, DevOps, тестирования, архитектуры, информационной безопасности и управления командами.

В программе — разборы актуальных технологий и практических задач: работа с ML-моделями, применение ИИ в разработке и аналитике, eBPF в production, PostgreSQL 18, автоматизация тестирования, архитектурные ревью и другие темы, с которыми специалисты сталкиваются в современных проектах. Занятия проводят наши преподаватели-практики, поэтому это возможность обсудить подходы с экспертами, задать вопросы и оценить формат обучения на реальных примерах.

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

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

Но «похоже на правду» для аналитического отчёта - довольно опасный критерий. Особенно если речь идёт о финансовых показателях.

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

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

Привет, Хабр! Меня зовут Александр, я работаю DevOps-инженером в команде Мир Plat.Form. Одна из достаточно сложных задач, которая стояла перед отделом DevOps, это миграция Jenkins в K8S и развертывание динамических (эфемерных) агентов.

Сама миграция Jenkins оказалась относительно простой частью. Но поскольку для сборки и деплоя наших приложений мы активно используем подход DinD (Docker-in-Docker) при переносе Jenkins-агентов в Kubernetes нам пришлось учитывать ряд технических особенностей.

Для запуска Docker внутри Kubernetes мы решили использовать Docker в режиме Rootless. Именно этот подход и добавил миграции немало технических нюансов, о которых я расскажу дальше.