Разработчик сделал небо с самолётами у себя на потолке — теперь он видит точный момент, когда рейсы пролетают над его домом. Парень живёт рядом с аэропортом и постоянно слышит самолёты. В какой‑то момент он решил вывести всё воздушное движение прямо на потолок комнаты. Система использует данные ADS‑B и в реальном времени показывает местоположение, высоту и скорость каждого самолёта над домом.
Как RETAILIQA совместила 152‑ФЗ, SLA для иностранцев и задел под новые ИИ‑сценарии
👨💻 Что за компания
RETAILIQA (бренд компании ООО «Крона Лабс») с 2014 года развивает сервисы мобильного аудита: электронные чек-листы для контроля качества, мониторинга цен конкурентов и оценки лояльности клиентов (NPS). Решения компании используют крупные федеральные и региональные игроки в ритейле, общепите, телекоме, банках, страховании, управлении недвижимостью, промышленности, логистике и других отраслях.
🚀 Задача
На фоне роста клиентской базы и объема собираемых данных команда столкнулась с несколькими ограничениями: прежний провайдер не мог масштабировать хранилище и вычислительные ресурсы, усилились требования федеральных заказчиков к безопасности и хранению чувствительных данных в российском ЦОД, у зарубежных клиентов возникали проблемы с доступностью сервисов. Параллельно RETAILIQA готовилась внедрять ИИ-модели для распознавания полок и ценников, что требовало гибкой и отказоустойчивой облачной инфраструктуры.
☁️ Что сделали
В 2024 году всю инфраструктуру перенесли в облако VMware на платформе Cloud.ru, закрыв потребность в ресурсах и отказоустойчивости без простоя для клиентов. Для хранения терабайтов данных подключили S3-совместимое хранилище Evolution Object Storage и перешли на модель pay-as-you-go — оплачивают только фактическое потребление без необходимости «держать запас» на стороне. Для защиты и соответствия требованиям безопасности добавили StormWall: Anti-DDoS и сервис резервного копирования виртуальных машин VMware, обеспечив дополнительный уровень защиты от атак и потери данных.
🦾 Что получили в итоге
RETAILIQA сняла ресурсный потолок: теперь можно без ограничений подключать федеральных и региональных клиентов с тысячами объектов контроля и десятками тысяч пользователей. Доступность сервисов достигла 99,98%, а надежное хранение фото- и видеоматериалов в сертифицированных российских ЦОД укрепило доверие крупных заказчиков и регуляторно-чувствительных отраслей. Например, крупная аптечная сеть с более чем 2 000 точек ежедневно отправляет «тяжлые» фотоотчеты по строжайшим стандартам мерчендайзинга — инфраструктура провайдера справляется с таким потоком без деградации.
В планах — внедрение сервисов AI Factory для анализа фотографий и распознавания информации на ценниках. Это позволит автоматически проверять, соответствует ли выкладка товара в торговых залах утвержденным схемам (планограммам), а также ускорит подготовку отчетов и позволит гибко масштабировать ресурсы под новые сценарии с применением ИИ, не перестраивая всю архитектуру с нуля.
Сервер работает. Инфраструктура — нет: открытые уроки для сисадминов
Системное администрирование давно не заканчивается на моменте «поднять сервер, настроить доступы и посмотреть логи». Сегодня администратору нужно уметь разбираться в контейнерах, Kubernetes, мониторинге, безопасности, инцидентах и автоматизации — иначе инфраструктура быстро превращается в набор ручных костылей.
Собрали открытые уроки, которые будут полезны системным администраторам, DevOps‑инженерам, SRE и тем, кто хочет увереннее работать с production‑инфраструктурой.
Linux и автоматизация: меньше ручной рутины
4 июня, 20:00 — «Продвинутый Bash»
Для тех, кто уже пишет shell‑скрипты и хочет использовать Bash увереннее.
18 июня, 20:00 — «Основы Bash: пишем простые скрипты для автоматизации в Linux».
Подойдёт тем, кто хочет системно подойти к автоматизации повседневных задач в Linux.
22 июня, 20:00 — «Память в Linux. Cache, swap, dirty pages»
Практичный урок о том, как Linux работает с памятью, почему «свободная память» не всегда означает то, что кажется, и как читать поведение системы до того, как всё закончится OOM.
25 июня, 19:00 — День открытых дверей курса «Администратор Linux. Продвинутый уровень»
Формат для тех, кто хочет понять, какие навыки нужны администратору Linux на продвинутом уровне.
Что почитать перед уроками:
Мастерство поиска в Linux: Grep и регулярные выражения
Полезная база для тех, кто регулярно работает с логами, конфигами и текстовым выводом в консоли.
Docker и контейнеризация: когда «работает локально» уже недостаточно
22 июня, 20:00 — «Контейнеризация Java‑приложений с Docker»
Разберем, как упаковывать приложения в контейнеры и что учитывать при работе с Docker в инженерной среде.
8 июня, 20:00 — «Java в Kubernetes за 40 минут: как задеплоить приложение в Minikube»
Прикладной урок для тех, кто хочет посмотреть на деплой приложения в Kubernetes без длинной теории.
Что почитать перед уроками:
Ваш docker‑compose.yml сломается: 5 настроек, которые все забывают
Разбор типовых ошибок в Docker Compose: лимиты ресурсов, restart policy, ротация логов, healthcheck и бэкапы volumes.
Kubernetes, DevOps и self‑service‑инфраструктура
18 июня, 20:00 — «Kubernetes под прицелом: почему ваш кластер может взломать даже стажер и как этого избежать»
Один из самых важных уроков для инфраструктурной аудитории: типовые ошибки в Kubernetes, слабые места кластеров и практики защиты.
22 июня, 20:00 — «Роль и задачи DevOps в современном IT»
Для тех, кто хочет разобраться, где заканчивается классическое администрирование и начинается DevOps‑подход.
Сети и безопасность инфраструктуры
16 июня, 20:00 — «IDS/IPS как часть эшелонированной защиты инфраструктуры»
Продолжение темы: как системы обнаружения и предотвращения атак встраиваются в многоуровневую защиту.
22 июня, 20:00 — «OAuth 2.0, JWT и коварные куки: Проектируем безопасную аутентификацию»
Полезно тем, кто работает с веб‑инфраструктурой, внутренними сервисами, прокси, доступами и безопасностью приложений.
Что почитать перед уроками:
Разбираемся с форвардингом IP‑пакетов в сетевых уровнях L2 и L3
Материал для тех, кто хочет лучше понимать, как пакеты проходят через сеть и где могут возникать проблемы при настройке инфраструктуры.
Мониторинг, SRE и инциденты
10 июня, 20:00 — «Мониторинг распределенных систем»
Про наблюдаемость сложных систем, где проблема может быть не на одном сервере, а между сервисами, очередями, базами и сетью.
16 июня, 20:00 — «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе»
Практичный урок о том, как быстрее локализовать сбой, не тушить пожары вслепую и снижать вероятность повторения инцидентов.
Все уроки бесплатные. На них можно познакомиться с преподавателями‑практиками, посмотреть на формат обучения и задать свои вопросы.
Если интересны не только инфраструктурные темы, в полном июньском дайджесте собраны ещё 62 бесплатных урока по разработке, данным, архитектуре, ИБ и AI.
Публикуем свежую подборку задач на Бирже заказов Инфостарта. В списке - доработки печатных форм, настройка телефонии, администрирование PostgreSQL и 1С:Фреш, разграничение доступа, перенос данных и оптимизация обменов между базами.
Биржа помогает заказчикам находить специалистов под задачи по 1С, а исполнителям - выбирать проекты под свой опыт, специализацию и текущую загрузку.
На этой неделе доступны задачи разного масштаба — от точечных настроек до переноса данных и администрирования инфраструктуры.
Добавить в готовую форму допсоглашения все виды и значения надбавок сотрудника.
Выполнить перенос данных из 1С:Розницы базовой 2.3 в 1С:Розницу базовую 3.0.
Такие заказы могут быть интересны разработчикам 1С, администраторам, специалистам по обменам, интеграциям и сопровождению учетных систем. Можно выбрать небольшую задачу для разовой подработки или откликнуться на проект, где нужен более широкий опыт.
Биржа заказов Инфостарт - это площадка, где заказчики размещают задачи по 1С, а исполнители откликаются на них напрямую. Формат подходит для консультаций, доработок, настройки обменов, переноса данных, интеграций с внешними сервисами и сопровождения проектов.
На Бирже доступны:
работа без комиссии площадки;
прямой обмен контактами между заказчиком и исполнителем;
исполнители разного масштаба — от частных специалистов до ИТ-команд;
безопасная сделка по желанию сторон;
рейтинги, кейсы и история откликов, которые помогают выбрать подрядчика.
Посмотрите актуальные заказы недели и выберите задачу, которая подходит под ваш опыт и загрузку.
Microsoft представила порт набора утилит Coreutils для платформы Windows. В состав входит несколько десятков утилит, включая sort, cat, chmod, chown, cp, find, sleep, sort, tee, echo, uptime и ls. Инструментарий позволяет напрямую использовать в Windows типовые утилиты, доступные в Linux и macOS, без использования прослойки WSL. Целью проекта заявлено упрощение перехода между Unix‑подобными системами, WSL, контейнерами и Windows, и предоставление единого набора команд, флагов и методов, позволяющих переносить существующие скрипты из других систем без переписывания. Код написан на Rust и PwerShell, и распространяется под лицензией MIT.
Реализация основана на коде проекта uutils (Rust Coreutils), развивающего вариант GNU Coreutils на языке Rust, а также реализациях утилит find и grep на Rust. Утилиты собраны в виде одного универсального исполняемого файла "C:\Program Files\coreutils\coreutils.exe", отдельные команды к которому привязаны при помощи жёстких ссылок в NTFS.
Из‑за конфликта с имеющимися штатными утилитами Windows или привязки к специфичным возможностям из поставки исключены утилиты dd, dir, dircolors, shred, sync, uname, expand, kill, more, paste, timeout и whoami. Из состава также исключены утилиты, завязанные на не поддерживаемые в Windows концепции POSIX: chcon, chgrp, chmod, chown, chroot, groups, hostid, id, install, logname, mkfifo, mknod, nice, nohup, pathchk, pinky, runcon, stdbuf, stty, tty, users, who.
Из ограничений и особенностей отмечается необходимость использовать NUL вместо /dev/null, отсутствие поддержки сигналов (SIGHUP, SIGPIPE, SIGUSR), возможность создания символических ссылок только после включения режима для разработчика, недоступность некоторых операций с правами доступа. При работе с каталогами принимаются как пути с символом "/", так и c "\".
Дайджест Рег.облака за май
Май посвятили удобству: добавили образ FASTPANEL и Ubuntu 26.04 LTS, собрали продукты по импортозамещению на одной странице, переработали работу с балансом и упростили продление выделенных серверов. Ниже — всё главное за месяц.
Добавили образ FASTPANEL
Обновили образ FASTPANEL в Рег.облаке — теперь с ним доступно больше возможностей для гибкой работы с серверами. Можно создать виртуальную машину на гибко конфигурируемых тарифах, выбрать любую из актуальных тарифных линеек, конфигураций и регионов размещения, а также настроить резервное копирование точнее, чем раньше. Подробности на странице образа.
Для удобства подготовили пул документации: как создать сервер с FASTPANEL, сбросить пароль, разместить сайт, работать с базами данных и электронной почтой, настроить резервное копирование и установить SSL-сертификат.
Добавили образ Ubuntu 26.04 LTS
В каталоге образов появился Ubuntu 26.04 LTS. Новый образ уже доступен для запуска во всех регионах Рег.облака.
Упростили продление выделенных серверов
Дополнительные услуги теперь группируются внутри сервера и выравниваются до даты его окончания. Управлять выделенными серверами стало проще — и в Рег.облаке, и в Рег.ру.
Собрали продукты по импортозамещению на одной странице
Решения по импортозамещению теперь собраны на отдельной странице, чтобы их было проще найти.
Переработали работу с балансом
Сделали отдельный интерфейс для работы с балансом Рег.ру в Рег.облаке. Здесь видно состояние баланса и доступный кредитный лимит (для корпоративных клиентов), а пополнить баланс можно с подсказкой рекомендуемой суммы — она рассчитывается по прогнозу расходов на услуги Рег.ру. Также доступны прогноз расходов на 7, 30 и 90 дней с переходом на страницу продления и список операций по балансу.
Из новостей: ИИ-ассистент Рег.облака заговорил с нейросетями в Moltbook
Добавили ИИ-помощника в Moltbook — площадку, где ИИ-агенты общаются между собой без участия человека. Первым делом ассистент рассказал другим ботам про Free Tier и объяснил, как развернуть сервер на минимальной конфигурации (1 vCPU, 1 ГБ RAM, 10 ГБ NVMe). Инструкции он передает через API на базе модели Hermes поверх локального инференса на GPU-серверах Рег.облака. К Free Tier, запущенному в апреле, уже подключились больше 1000 компаний и пользователей. Подробнее об ИИ-ассистенте Рег.облака читайте у нас на сайте.
Желаем всем продуктивного месяца и спасибо, что следите за обновлениями Рег.облака!
Почему Москве нужны новые дата-центры?
На конференции ЦИПР одной из важных тем для облачных операторов была постройка дата-центров в московском регионе. Сразу скажем, что пока это не закон и конкретных документов под эти планы нет, но радует, что правительство понимает важность этой темы.
Заместитель министра цифрового развития, связи и массовых коммуникаций Евгений Филатов сообщил, что Минцифры обсуждают с Минэнерго возможность разрешить новым игрокам подключиться, если у них есть свои источники энергии. Почему это важно?
Облачные сервисы хороши тем, что пользователю не приходится задумываться, где находятся серверы — в Москве, Сибири или даже за границей. Грамотная организация позволяет бесшовно использовать сервисы в любой локации. Но провайдеру как раз приходится заботиться о том, чтобы дата-центры обладали нужной скоростью доступа и низким пингом, имелась возможность быстро переключиться на другие сервисы при инцидентах в текущем. Кроме того, для некоторых задач важны Edge Computing, то есть технологии, обеспечивающие вычисления в ближайших ЦОДах (для минимальной задержки сигнала).
Однако в таких регионах, как Москва, с февраля подключение ЦОД к электросетям ограничено, так как нет лишних мощностей — они уже использованы или зарезервированы для крупных игроков. А значит, рынок монополизируется: небольшим облачным операторам труднее расширять серверные мощности, чтобы запускать уникальные сервисы и показывать конкурентоспособность на рынке.
Возможность запускать дата-центры, пусть и со своими источниками энергии (которые найти в таких регионах, как Москва, непросто), расширит количество игроков, даст возможность выбора для облачных операторов и позволит достичь максимальной функциональности и надежности сервисов.
Дефицит электроэнергии — не российская особенность, а тренд для всех развитых стран мира. В частности, в США из-за массового строительства дата-центров под ИИ планируется даже возрождение АЭС, которые смогут дать постоянные мощности по приемлемым ценам (СЭС ночью не работают, ВЭС зависят от ветра). Ресурс Servernews отмечает, что такие крупные компании, как Microsoft, SoftBank и SpaceX (недавно слилась с ИИ-компанией xAI), собираются использовать газовые генераторы, а OpenAI под проекты Oracle закупает топливные элементы.
Надеемся, что и российские регуляторы не останутся в стороне и помогут решить общемировую проблему.
Обмениваемся файлами на любых устройствах. Разработчики приложения для передачи данных по Wi‑Fi Localsend представили версию проекта для браузера:
Работает за два клика: открываем приложение на двух ваших устройствах, которые подключены к одной точке Wi‑Fi, прикрепляем файлы и передаем их.
Без регистрации, без установок, без ограничений.
Подходит для любых ОС, передает файлы с большой скоростью и без дополнительных настроек.
Представлен открытый проект FluentCleaner (аналог CCleaner), который умеет очищать ПК на Windows 10/11 от мусора, бесполезных процессов, дубликатов файлов и всяческого хлама, замедляющего ОС. Все удаления на ПК согласовываются с пользователем.
«Современный, прозрачный, без шпионского ПО, без скрытых ненужных вставок, без тёмных паттернов, без навязчивой рекламы, без фальшивой магии реестра», — пояснил разработчик проекта по имени Belim (aka Builtbybel). Этот автор является создателем проекта Winslop для удаления ненужного системного мусора в Windows 10/11 (он недавно был переименован в Winslopr — Windows Slop Remove).
Три подразделения, три правды. Куда уходит ИТ-бюджет и при чём тут ITAM
Бухгалтерия: «3000 на балансе». ИТ: «1800 в сети». Безопасность: «2200 под защитой». И никто не врёт — каждый считает свой срез.
Корень проблемы — не сами расходы, а отсутствие единой экономической модели ИТ. CFO видит строку «50 млн руб./год» без детализации. CIO знает, что серверы на грани, но не может перевести это на язык финансов. Бизнес требует цифровизации, не понимая нагрузки на бюджет.
При этом контекст 2024–2026 усложнил всё кратно: параллельный импорт — плюс 20–40% к закупкам, импортозамещение — рост годового бюджета на 40–70% не за счёт расширения, а за счёт выкупа лицензий в альтернативных стеках. Компании тратят миллионы на ПО «про запас», которое не используют прямо сейчас.
Если раньше мы платили 10 млн руб./мес. за подписку M365, то сейчас вынуждены держать 50 млн руб. единовременного резерва на закупку ПО в реестр, плюс 15 млн руб./мес. на доработку интеграций.
Алексей Бородин, эксперт по развитию ITAM- и ITSM-проектов
Совместно с практикующими экспертами по ITAM и ITSM мы подготовили материал о том, как IT Asset Management помогает сделать ИТ-затраты прозрачными и управляемыми.
Внутри:
Анализ ключевых вызовов 2024–2026: санкции, переход от OPEX к CAPEX, рост НДС, дефицит ИТ-специалистов
Почему Excel, ERP, ITSM с CMDB и BI-системы перестают справляться с управлением затратами — и где у каждого инструмента потолок
Системный подход к управлению ИТ-активами через ITAM — на примере SimpleOne ITAM
Кейс ITGLOBAL.COM (by ITG): переход с Excel на ITAM в международной структуре с присутствием в 12 странах
Чек-лист «Как сделать ИТ-затраты управляемыми»: 4 шага + методика расчёта TCO и ROI
Открытый проект Python library for interacting with the Solvecaptcha API (captcha‑solving service) — это легковесная библиотека на Python, которая проходит самые популярные проверки через Solvecaptcha.
Обходит большинство самых мощных и популярных капч:
reCAPTCHA v2 и v3;
Cloudflare Turnstile;
FunCaptcha (Arkose Labs);
GeeTest и GeeTest v4;
Amazon WAF;
KeyCaptcha;
Grid, ClickCaptcha, Rotate, Canvas;
обычные текстовые и графические капчи, в том числе аудио.
Библиотека небольшая, работает стабильно, разработчики её поддерживают, добавляя новые виды капч. Можно настраивать таймауты решения капч, чтобы имитировать поведение человека.
Как оптимизировать бюджет Service Desk на 2,9–10 млн. руб. в год и повысить опыт пользователей
По данным Forrester, 60-70% сотрудников пишут в Service Desk напрямую, минуя портал самообслуживания. За годы инвестиций в каталоги услуг, базы знаний и формы типовых запросов цифра не сдвинулась. Это не проблема UX, а системный сбой модели: портал требует, чтобы пользователь думал на языке поставщика услуг.
В новом аналитическом обзоре Андрея Вишнякова – директора по бизнес-продуктам SimpleOne, ITIL 4 Master, ITIL 3 Expert, автора методологии РИТМ –разобрали, почему классические подходы упираются в один и тот же потолок, как ИИ-помощник на RAG превращает концепцию Shift-Left из давней идеи в работающую практику, и сколько это стоит в рублях – с расчётом экономии для трёх типичных объёмов обращений и опорой на данные Forrester и Gartner.
что именно компании делают, когда хотят «починить портал»: редизайн каталога услуг, обучение пользователей, расширение первой линии, скриптовые чат-боты – и где ломается каждая из четырёх стратегий;
цена неэффективности – кто и сколько теряет: от простоев сотрудников до перегрузки экспертов второй линии;
как устроен ИИ-помощник на RAG-архитектуре: векторные коллекции, требования к базе знаний, условия внедрения, сценарии применения – от ИТ-инцидентов до HR-справок и заявок в АХО;
финансовая модель для трёх типичных объёмов (30, 70 и 130 тыс. обращений в год) с потенциальной экономией от 2,9 до 10 млн ₽/год.
Как я связал Zabbix и таск-трекер в обе стороны без отдельного сервиса У меня боевой Zabbix 7.0 на ~260 хостов, а заявки дежурной смены живут в Planfix. Уведомления в Telegram или Matrix никто не отменял, но когда над инцидентами работает смена, мессенджер неудобен: не видно, кто взял проблему, нет статусов и истории по задаче, сложно готовить отчеты. Хотелось, чтобы проблема мониторинга сама заводила задачу в трекере, а действия с задачей возвращались обратно в Zabbix, и всё это без сервиса-прослойки.
Очевидные пути отмёл сразу:
Бот или демон - ещё один процесс, который сам надо мониторить: новая точка отказа в системе, которая как раз следит за отказами.
Почта с парсером - не возвращает id созданной задачи обратно в Zabbix, и потом нечем связать восстановление триггера с конкретной строкой в трекере.
Требование «вернуть id задачи на событие» и определило всю архитектуру.
Прямое направление: Zabbix → трекер Собрал на штатном media type типа Webhook: один JS-скрипт по флагам события решает, какой эндпоинт трекера дёрнуть. Интереснее, где хранить связь «проблема ↔ задача». Внешнюю БД соответствий заводить не стал, обошёлся тегами события. При создании задачи скрипт возвращает Zabbix теги __zbx_planfix_taskid и __zbx_planfix_link; при process_tags=1 они вешаются на событие, и все последующие операции (подтверждение, закрытие, отмена) находят ту же задачу по тегу. Состояние живёт прямо на событии, отдельное хранилище не нужно.
Что всплыло уже в бою: отмена эскалации Уведомление «Escalation canceled» (эскалацию погасили, отключив хост или триггер) приходит с теми же флагами, что и новая проблема: event_value=1, event_update_status=0. Не различишь - скрипт примет отмену за новую проблему, заведёт дубль, и задача зависнет открытой навсегда: OK-события не будет, закрывать нечем. Поэтому скрипт сначала ищет в тексте уведомления фразу «Escalation canceled» и, только если её нет, считает событие новой проблемой. Подтверждение и снятие различаю по макросу {EVENT.UPDATE.ACTION}: в первой строке update-сообщения он разворачивается в acknowledged или unacknowledged - по этому слову задача уходит «в работу» или возвращается исполнителю по умолчанию.
Обратное направление - и оно оказалось самым интересным Делается средствами самого трекера, без отдельного сервиса. В Planfix это автоматический сценарий: событие «задача принята», условие «проект = ZABBIX», операция - POST в JSON-RPC API Zabbix, метод event.acknowledge с action=6 (подтвердить + добавить комментарий). Event ID берётся из поля задачи, того самого, что прилетел при создании. Главное: обратный вызов несёт email сотрудника, и подтверждение с комментарием проставляются в Zabbix от имени этого человека, а не безликого сервисного аккаунта. В истории события видно, кто реально взял проблему - тот, на кого назначена задача в трекере.
Что ещё пришлось учесть
maxsessions=1 обязателен, иначе закрытие может обогнать создание, и правка придёт по ещё не существующей задаче.
Создание задачи не идемпотентно: при ретраях возможен дубль (из Zabbix не узнать, дошёл ли запрос на самом деле), поэтому дедуп по event_id на стороне трекера обязателен - у меня он пока в планах.
Шумовой фильтр - через эскалацию: операция на шаге 2 плюс условие «подтверждено = нет», иначе проблемы, мигающие по 30 секунд, плодят задачи.
Итог: ноль дополнительных демонов, обе системы синхронны, связь хранится на самом событии. Для одной пары систем это окупается. Но чем больше разных систем хочется соединить между собой, тем громче вопрос об оркестраторе: точечные вебхуки перестают масштабироваться, хотя единая шина и есть та самая прослойка, которую потом сам обслуживаешь. Сейчас как раз думаю в эту сторону. Чем вы сшиваете зоопарк систем - оркестратором или точечными интеграциями, и где у вас прошла граница?
Git reset: как управлять историей и не уничтожить свою работу
git reset — одна из тех команд, которые удобно держать под рукой, но страшно запускать без понимания последствий. Она помогает очистить локальную историю, убрать лишние коммиты, отменить git add или полностью откатиться к нужному состоянию. Но в режиме --hard может стереть незакоммиченные изменения так, будто ничего и не было.
В новой статье разобрали, что делает git reset, чем отличаются режимы --soft, --mixed и --hard, когда команду можно использовать безопасно, а когда лучше выбрать git revert или git restore. Отдельно показали типичные сценарии: объединение нескольких коммитов, вывод файлов из индекса, полный откат и восстановление после неудачного reset --hard через reflog.
Все подробности — в блоге Рег.облака.
Представлен открытый учебный проект 100 free open-source github repos everyone needs - 100 бесплатных репозиториев для решения любых задач. У них полностью открытый код и актуальные инструменты:
ИИ-агенты и скиллы для них;
Локальные альтернативы SaaS-сервисам;
Фреймворки и плагины для любых задач;
Топовые тулзы для разработчиков;
Курсы и справочники по всевозможным темам;
Дизайн и фронтенд-разработка;
Извлечение данных и аналитика;
Безопасность и приватность в сети;
Сборник инструментов для подготовки контента.
При этом у каждого проекта своя лицензия, а авторы подробно разбирают их назначение и способы применения.
GitHub Actions не маскирует секреты из фоновых процессов
Настраивал CI, в котором токен доступа переполучается в фоне — раз в 30 минут, пока идут тесты. Первый токен замаскирован через ::add-mask::, но что с экранированием новых токенов в логах? Можно ли вызвать ::add-mask:: прямо из фонового процесса?
В документации GitHub я ответа не нашёл. Там есть только общее место: workflow commands вида ::... раннер читает из stdout шага. А вот что происходит со stdout, который остался от фонового процесса после завершения шага, — непонятно.
Решил проверить — сделал тестовую репу. Схема простая: в одном шаге запускаю background-процесс, который через 15 секунд пишет ::add-mask:: — уже во время следующего шага. Потом специально печатаю секрет: сразу, после sleep, в следующем шаге и в отдельном job’е.
Foreground-секрет (маска из основного процесса) — замаскирован во всех шагах той же job’ы ✅ Background-секрет (маска из фонового процесса) — открыт везде, и до, и после срабатывания ::add-mask:: ❌
Бонус: маски вообще не живут между job’ами — даже foreground-маска в зависимом job’е уже не действует ❌
У нас это, к счастью, не стреляет: переполучение токена уходит в /dev/null, тесты ходят через API, секрет в stdout не попадает. А вот если какой-нибудь refresh-скрипт всё-таки может напечатать новый секрет в лог — на ::add-mask:: из background-процесса рассчитывать нельзя.
Дисклеймер: и код, и текст этого поста написаны в соавторстве с Claude Code.
Россию отключают от привычных серверов синхронизации времени и DNS-сервисов. Проверьте свои SMTP-настройки, вторичные DNS и прочее - возможно, они уже не работают.
Открытый проект OptimizerDuck позволяет очистить Windows 10/11 от мусора и бесполезных процессов (телеметрию, рекламу, Copilot, все фоновые сервисы и ненужные приложения):
оптимизирует ПК для работы и игр, настраивает GPU и производительность процессора, работает с менеджером автозагрузки, удаляет встроенный bloatware, чистит систему.
может откатить все изменения, если в процессе что‑то пошло не так. Бэкап у вас точно будет.
работает без установки, без ограничений и полностью локально.
Обновил вчера Ubuntu 25.10 на 26.04. В последние два года я обновляю Ubuntu при каждом новом выпуске, начиная с 23.10 насколько помню. И никаких проблем ни во время обновления, ни после него до этого не возникало. Вчера же столкнулся с несколькими неприятностями:
Объём загружаемых пакетов вырос с обычных 2 Гб до 4 Гб! Вероятно у вас будет меньше, ведь это зависит от установленных вами пакетов, но если судить относительно прежнего объёма, то скачёк потребления трафика с учётом мобильного доступа не радует. Скаченные пакеты я сохранил, чтобы на других ноутбуках с Ubuntu не пришлось снова качать 4 Гб. Раньше я так не делал.
Во время установки пакетов рабочий стол заблокировался с сообщением, что у меня нет прав root, чтобы что-то сделать, что именно не написано. Причём нажатие на Отмена блокировку не снимало, и окно сообщения оставалось открытым. Похоже на какой-то баг Gnome, Resolute или где-то глубже в системе. Дождался, когда индикатор диска и вентилятор успокоятся, в надежде, что обновление закончилось успешно, переключился на консоль и сделал reboot.
После первой загрузки и входа в Gnome рабочий стол завис. Снова переключение в консоль и reboot. После второй перезагрузки Gnome заработал. Это ещё один явный баг.
Теперь после каждого включения с нуля или после сна, не важно, запускается какой-то процесс localsearch, который интенсивно работает с диском и греет процессор. Причём процесс ветвится. Как отключить не понятно. Подождав полчаса сделал kill по номеру процесса localsearch. И вынужден делать это каждый раз.
В остальном пока вроде всё нормально. Особых нововведений не заметил. Пиктограммы программ в главном меню стали меньше. В строке статуса появился значёк режима нагрузки процессора.
В предыдущих выпусках был ещё баг с thumbnailer, который при открытии в Nautilus папки с большим количеством фото, выжирал остатки памяти, что приводило к торможению всей системы намертво и последующего принудительного жёсткого отключения питания (известный баг Linux, который за десять или более лет так и не исправлен). Как я понял, в 26.04 thumbnailer был заменён на что-то другое, и я пока ещё не поимел проблем с большими папками с фото. Но посмотрим…
UPD Посмотрел, что это за localsearch. Похоже, что это часть Gnome. Поэтому стандартными средствами управления сервисами его не отключить. Запускается при входе в Gnome. Как эту ненужную мне и вредную с точки зрения энергопотребления и шумозагряднения штуку выключить в Gnome? (В комментарии дали совет, но в первый раз нужно всё-таки сделать kill для процесса, одного его отключения не достаточно. После перезагрузки процесс localsearch уже не будет беспокоить.)
Резюме Ещё до обновления я начал искать альтернативы Ubuntu, понимая что запросы системы к процессору и памяти растут, Ubuntu всё больше походит на bloatware и corporate, а переходить на более новое железо я не собираюсь. Пока в качестве альтернатив рассматриваю: antiX, Devuan, Gentoo, Void, Guix, NetBSD, OpenBSD. Этот набор обусловлен тем, что мне нужно, чтобы система поддерживала 32-разрядность. И я хочу иметь на 32- и 64-разрядных системах одинаковый опыт и навыки работы с ними. А какие альтернативы Ubuntu используете вы? Что скажете про мой список альтернатив? Кстати, до полного перехода на Ubuntu я также работал в последние годы с ElementaryOS, Manjaro, Fedora. Пробовал antiX, Void, NixOS и Guix. По большому счёту они отвергнуты были в том числе по тем же причинам, что теперь и Ubuntu, Кроме antiX, Void и Guix. Это особый случай, и это отдельная тема для разговора.
(с) Симоненко Е.А., 2026
Что не так с DeFi и почему там до сих пор происходят взломы
Со стороны DeFi выглядит как будущее финансов: кошелёк вместо банка, смарт-контракт вместо посредника, а код вместо правил “по договорённости”.
Но в реальности DeFi это не одно приложение, а связка протоколов, смарт-контрактов, пулов ликвидности, оракулов, мостов, токенов управления и внешних интерфейсов. Пользователь видит кнопку Swap или Deposit, но под капотом может запускаться целая цепочка вызовов между контрактами. И чем больше таких зависимостей, тем больше поверхность атаки.
Одна из главных проблем - composability. В DeFi протоколы часто строятся друг поверх друга: lending-протокол использует один токен, DEX даёт ликвидность, оракул поставляет цену, мост переносит актив между сетями, а поверх всего этого работает ещё один интерфейс. Это удобно для разработки, но опасно для безопасности. Ошибка в одном элементе может стать проблемой для всей цепочки.
Отдельный риск - смарт-контракты. В традиционной системе подозрительную операцию можно остановить, откатить или вручную проверить. В DeFi логика другая: если транзакция валидна и контракт позволяет выполнить действие, сеть его выполнит. Поэтому баг в коде, ошибка в проверке прав, неправильная работа с балансами или уязвимость в математике протокола могут стоить не “небольшого сбоя”, а сразу миллионов долларов.
При этом атаки давно не сводятся к классическому “взлому”. Часто злоумышленник не ломает сервер, а использует экономическую механику протокола. Например, через flash loan можно взять огромный объём ликвидности в рамках одной транзакции, временно исказить цену в пуле, повлиять на расчёт залога или ликвидации, а затем вернуть заём до завершения блока. Формально всё может пройти по правилам контракта, но результат будет разрушительным.
Большая зона риска - оракулы. DeFi-протоколам нужно откуда-то получать цены активов. Если протокол берёт цену из слабого источника, например из тонкого пула с низкой ликвидностью, этой ценой можно манипулировать. Дальше начинается цепочка: неверная цена → неправильная оценка залога → ошибочная ликвидация или вывод средств.
Ещё одна больная точка - кроссчейн-мосты. Мосты соединяют разные сети и часто хранят или контролируют большие объёмы ликвидности. Это делает их идеальной целью. Проблема в том, что мост должен одновременно доверять событиям в одной сети и корректно выпускать или разблокировать активы в другой. Любая ошибка в валидации сообщений, подписях, мультисиге или логике relayer-ов может привести к катастрофе.
Есть и governance-риск. Многие DeFi-протоколы управляются через DAO и governance-токены. На практике это означает, что изменение параметров протокола, обновление контрактов или управление казной может зависеть от голосований, делегатов и концентрации токенов. Если управление плохо защищено, атакующий может повлиять не на код напрямую, а на правила игры.
Парадокс DeFi в том, что он создавался как trustless-система, где не нужно доверять посредникам. Но на практике пользователь всё равно доверяет: аудитам, разработчикам, оракулам, мостам, мультисигам, фронтенду, governance-механике и экономической модели протокола.
То есть доверие не исчезло. Оно просто переехало из банка в инфраструктуру.
Именно поэтому DeFi до сих пор остаётся одновременно самой интересной и самой уязвимой частью крипторынка. Чем больше открытости, автоматизации и связности между протоколами, тем сложнее сделать систему безопасной не только на уровне кода, но и на уровне экономики, ликвидности и пользовательского сценария.