Покажем Internal Development Platform от Deckhouse на вебинаре 26 марта
Внутренние платформы разработки позволяют командам перейти от разрозненного набора инструментов к сервисному подходу. Разработчики получают self-service доступ ко всему необходимому — от создания окружений до управления quality gates и релизами — и могут работать автономно, не привлекая DevOps-команду.
Мы разработали собственную IDP — Deckhouse Development Platform, которая уже доступна для внедрения. 26 марта покажем её демо и расскажем:
что вообще такое IDP и когда она будет полезна;
на какие DORA-метрики влияет внутренняя платформа разработки;
для каких сценариев подойдёт Deckhouse Development Platform.
Регистрируйтесь и подключайтесь, если вы отвечаете за зрелость процессов разработки, масштабирование команд или платформенные сервисы.
Недавно наткнулся на занятный опенсорс‑проект — GitHub Store (github.com/OpenHub-Store/GitHub-Store). Это такая «оболочка» поверх GitHub, которая делает с репозиториями то же самое, что App Store / Google Play делают с приложениями.
В чём суть
По факту GitHub Store пытается ответить на давно назревший вопрос:
«Почему, чтобы поставить простую утилиту с GitHub, мне нужно идти читать README, искать бинарники, разбираться с релизами, а потом ещё помнить, как это всё обновлять?»
Авторы решили: хватит так жить. Давайте сделаем нормальный стор поверх GitHub, но без своей отдельной экосистемы:
есть лента с трендами и популярными репозиториями — можно просто полистать и найти что‑нибудь полезное, как в обычном магазине приложений;
установка в один клик (ну, почти) — не надо руками лазить по релизам и думать, какой файл скачать;
автоматические обновления уже установленных программ — не нужно помнить, что там выходило, кто из них обновился, а кто нет;
работает на Android, Windows, macOS и Linux — то есть это не очередной «только под одну платформу, остальным держаться».
С точки зрения пользователя это выглядит как нормальный стор: плитки, поиск, категории, тренды. Но под капотом — обычные GitHub‑репозитории. Никакого своего «реестра пакетов», зависимостей и т.п. Всё, что уже лежит на GitHub, становится чуть более человечно упакованным.
Зачем это вообще нужно
Если вы давно сидите на GitHub, то знаете эту боль:
находишь классный проект на Hacker News / Хабре / Реддите;
переходишь в репу;
в README: «build it yourself», 15 шагов, три тулчейна и «tested only on Arch btw»;
если повезло — есть бинарник где‑то глубоко в релизах, но без автообновлений.
GitHub Store как раз пытается это сгладить: вместо «репозиторий с набором файлов» — понятное приложение, которое можно установить и потом обновлять как нормальный софт.
Причём это не замена package manager’ам (apt, brew, winget и прочие), а именно интерфейс к тем проектам, которые туда никогда не доедут: личные тулзы, мелкие утилиты, нишевые программы, эксперименты.
Автор проекта прямо пишет, что идея — собрать в одном месте тысячи программ, которых вы не увидите ни в одном официальном сторе, но которые живут на GitHub, звёзды собирают, а до пользователя так и не доезжают.
Чем это похоже на App Store, а чем — нет
Похоже:
есть витрина: тренды, популярное, поиск;
есть установка в одно действие;
есть обновления, о которых думать не нужно.
Не похоже:
нет централизованной модерации в духе Apple/Google — это всё равно GitHub, со всеми вытекающими;
нет единого UX по установке/запуску (проекты разные, и у каждого свои особенности);
безопасность пока, очевидно, на уровне «как в GitHub»: вы сами решаете, кому верить.
То есть это не «новый стор, который победит все остальные», а надстройка над тем, чем GitHub по факту давно является — огромным складом софта, где интерфейс для обычного пользователя исторически был «так себе».
Кому это вообще может зайти
Тем, кто любит ковыряться в GitHub и искать новые инструменты, но устал превращать каждый проект в квест.
Тем, кто живёт на Linux / Windows / macOS, использует кучу мелких утилит и хочет держать их в одном месте с автообновлениями.
Тем, кто сам пилит опенсорс: это ещё один канал донести свой проект до людей, которые не любят GitHub, но любят «поставить и пользоваться».
Что в итоге
Идея «сделать стор поверх GitHub» витала довольно давно, но тут её хоть кто‑то нормально попробовал свернуть в рабочий вид, да ещё и кроссплатформенно.
Пока это выглядит как удобная человеческая морда к GitHub, а не очередной велосипед ради велосипеда. Если у вас жизнь связана с опенсорсом (или вы просто любите новые игрушки), проект точно стоит хотя бы посмотреть.
Ну и по классике: это опенсорс, так что можете не только поставить, но и прийти с PR’ами, если чего‑то не хватает или кажется сделанным криво.
Представлен открытый мультиплатформенный проект GitHub Store. Это GitHub в виде магазина с приложениями — скачивать, обновлять и устанавливать ПО с платформы теперь можно, как из обычного магазина приложений:
Правило 1. Невозможно предсказать, где программа будет тратить время. Узкие места возникают в неожиданных местах, поэтому не пытайтесь угадывать и использовать ускорение, пока не докажете, что именно там находится узкое место.
Правило 2. Измеряйте. Не оптимизируйте скорость, пока не измерите, и даже тогда не делайте этого, если только одна часть кода не превосходит остальную.
Правило 3. Сложные алгоритмы медленны, когда n мало, а n обычно мало. Сложные алгоритмы имеют большие константы. Пока вы не узнаете, что n часто будет большим, не усложняйте алгоритмы. (Даже если n станет большим, сначала используйте Правило 2.)
Правило 4. Сложные алгоритмы содержат больше ошибок, чем простые, и их гораздо сложнее реализовать. Используйте простые алгоритмы, а также простые структуры данных.
Правило 5. Данные доминируют. Если вы выбрали правильные структуры данных и хорошо всё организовали, алгоритмы почти всегда будут очевидны. В программировании центральное место занимают структуры данных, а не алгоритмы.
Уточнения:
Правила 1 и 2 Пайка перефразируют знаменитую максиму Тони Хоара: «Преждевременная оптимизация — корень всех зол».
Кен Томпсон перефразировал правила 3 и 4 Пайка как «В случае сомнений используйте грубую силу».
Правила 3 и 4 являются примерами философии проектирования KISS (Keep It Simple, Stupid).
Правило 5 ранее было сформулировано Фредом Бруксом в книге «Мифический человеко‑месяц». Правило 5 часто сокращают до «пишите глупый код, использующий умные объекты».
Спрос на H100 и H200 вырос в 75 раз: Рег.облако открыло GPU-кластер в новом московском ЦОД
Рег.облако разместило GPU-кластеры в московском дата-центре DataHouse «Магистральный-1». DataHouse проектировал площадку с запасом по энергетике и охлаждению — GPU-серверы греются и потребляют электричество совсем не так, как обычные вычислительные стойки.
Новую площадку Рег.облако открыло под растущий спрос: бизнес перешел с H100 и H200 как инструмента для экспериментов на промышленное использование. За последний год спрос на эти чипы в Рег.облаке вырос в 75 раз — с почти нулевых значений. Сейчас на H100 и H200 приходится около 70% всего спроса на GPU для задач с большими языковыми моделями.
Драйвером стали не новинки, а их отсутствие. Флагманские B200 и B300 в Россию практически не поступают, а H100/H200 после анонса нового поколения подешевели и заняли нишу рабочей лошадки для ИИ. Покупать такие серверы самостоятельно по-прежнему тяжело. Аренда у провайдера для большинства выходит дешевле и быстрее.
С подключением «Магистрального-1» у Рег.облака теперь 11 собственных и партнерских дата-центров уровня Tier III в нескольких регионах. Суммарная мощность — 85,5 МВт, 10 420 серверных стоек.
Принимаем заявки на доклады infra.conf 2026 до 1 апреля
Команда Yandex Infrastructure приглашает докладчиков на большую конференцию по инфраструктуре — infra.conf 2026. В этом году мы встретимся 4 июня уже в третий раз и обсудим ключевые темы, которые касаются обеспечения высоких нагрузок и не только:
инструменты разработки и практики управления разработкой,
базы данных и стораджи,
принципы и практики обеспечения надёжности и доступности,
управление инцидентами
и многое другое.
Отдельное внимание уделим построению и особенностям эксплуатации инфраструктуры в эпоху ML.
Приём заявок на выступление открыт до 1 апреля включительно в этой форме. Чтобы заявить свою тему на этом этапе, достаточно тезисов и общего плана. Координатор конференции и участники программного комитета свяжутся с каждым спикером для обсуждения материала, а финальное решение по докладам будет принято до 1 мая.
NixOS: идея, до которой индустрия доросла только сейчас.
Кажется, NixOS наконец выходит из категории системы «для своих» и становится все заметнее в инженерной среде. Это закономерно: он очень точно попал в проблемы, с которыми команды массово столкнулись только в последние годы.
История началась в 2003 году, когда исследователь Элко Долстра и его коллеги в Утрехтском университете запустили проект Nix. Это исследовательский проект, который включал пакетный менеджер и собственный декларативный язык. Идея была сделать так, чтобы пакеты и зависимости собирались предсказуемо, не конфликтовали между собой и не превращали систему в хаос после очередного обновления. Чуть позже из этой логики вырос NixOS, где тот же подход применили уже ко всей операционной системе.
В этом и был главный поворот. Nix с самого начала смотрел на систему не как на набор вручную настроенных файлов и команд, а как на то, что можно описать целиком. Пакеты хранятся изолированно, разные версии могут спокойно жить рядом, а состояние машины задается через конфиг. За счет этого обновления становятся атомарными.
Это особенно интересно на фоне обычных Linux‑дистрибутивов. Там текущее состояние системы часто является результатом длинной цепочки действий: что‑то поставили, что‑то удалили, где‑то поправили конфиг, где‑то забыли. В NixOS логика другая: ты описываешь желаемое состояние, а система приводит машину именно к нему. Если новая конфигурация не взлетела, предыдущее состояние никуда не исчезает.
😏 Почему NixOS набирает популярность именно сейчас? Потому что индустрия наконец доросла до его сильных сторон. Чем больше у команды окружений, CI/CD, инфраструктуры как кода и цены ошибки, тем важнее воспроизводимость и предсказуемость. То, что раньше выглядело как нишевая экзотика, сегодня все чаще выглядит как очень здравый инженерный выбор.
Многие современные immutable‑системы по сути идут в ту же сторону, куда NixOS пошел еще много лет назад.
А если хочется не просто прочитать про Nix, а разобраться, как он работает на практике, приходите на наш открытый воркшоп.
📹 Открытый воркшоп в рамках ИнженеркаТех Плюс, 18 марта в 19:00 по МСК. Александр Сергеев из сообщества RULKC, Russian Linux Kernel Community, расскажет про Nix и функциональный подход к пакетам и сборке.
Если вы хотите получить полный контроль над окружением и наконец закрыть вопрос воспроизводимых сборок, этот воркшоп для вас. Разберем ключевые концепции Nix и наглядно покажем, чем он отличается от привычных систем управления пакетами.
Termit 2.5 — интерфейс нового уровня, поддержка ГОСТ-шифрования, расширение политик и другое
ИТ-разработчик Orion soft выпустит новую версию платформы виртуализации рабочих столов и приложений — Termit 2.5. На вебинаре 2 апреля расскажем о новых функциях, а также поделимся планами на будущее.
Ключевые обновления:
Безопасность: ГОСТ‑шифрование трафика до шлюза удаленного доступа, поддержка zVirt Max
Функциональность: подключение к физическим рабочим станциям, бновления в политиках — UX: обновление портала администратора, улучшенный обзор и мониторинг, менеджер сессий в клиенте, веб‑клиент для Linux терминальных серверов и ВМ
VDI: поддержка формата «Полный клон», поддержка ввода в домен FreeIPA и ALD Pro.
А также на вебинаре впервые представим собственный протокол Termit — Pulsar, который будет доступен уже в следующем релизе Termit 2.6 в Q3 2026. Расскажем об архитектуре и функциональных возможностях протокола.
Присоединяйтесь, чтобы первыми узнать обо всех обновлениях Termit 2.5!
hmod, chown и принцип минимальных привилегий: права доступа в Linux
Неправильно выставленные разрешения на файл или каталог — один из самых распространенных векторов для эскалации привилегий в Linux.
В блоге мы разобрали базу, которую полезно держать в голове: символьное и цифровое представление прав, разница между владельцем, группой и остальными, команды chmod и chown с практическими примерами — от chmod 755 до рекурсивной смены владельца через chown -R.
Представлен проект DigitalDefynd — большая база IT‑курсов от лучших университетов мира. Материал на ресурсе обновлён на 2026 год. Там актуализировали курсы и оставили только те навыки, которые пригодятся при устройстве на работу и росте по карьерной лестнице. Есть сотни воркшопов, в том числе от Google и IBM. Большая часть курсов с лицензированными сертификатами и дипломами, которые можно положить в портфолио.
Хотите выяснить, где учиться IT? В экосистеме Хабра есть маркетплейс курсов на Хабр Карьере, на котором собраны сотни онлайн-обучений в самых разных специализациях: программировании, аналитике, дизайне, менеджменте и других. Чтобы пользователи могли проверить качество курсов, там показаны отзывы от тех, кто уже прошел обучение — изучайте и выбирайте лучшее для себя.
Представлен открытый проект TUI Studio (Visual Terminal UI Designer), среды для визуального проектирования интерфейсов пользователя, работающих в текстовом терминале. Среда позволяет в интерактивном режиме наглядно формировать интерфейс, перетаскивая готовые блоки мышью, редактируя свойства в визуальном режиме и предпросматривая результат на лету. Сформированный макет интерфейса может быть экспортирован для использования во фреймворках Ink, BubbleTea, Blessed, Textual, OpenTUI и Tview.
Решение написано на TypeScript с использованием React, Vite, Zustand, Tailwind CSS и Lucide React. Код распространяется под лицензией MIT. Из особенностей разработки отмечается, что почти весь код TUI Studio написан ИИ‑ассистентом Claude.
В TUI Studio предоставляется более 20 готовых компонентов для формирования интерфейса (кнопки, меню, таблицы, списки, индикатор прогресса, диалоги, всплывающие подсказки и тому подобное) и поддерживается 8 тем оформления, а также светлый и тёмный режим, градиентные заливки, ASCII‑цвета и акцентные цвета. Имеется возможность отката изменений. Доступен интерфейс для создания своих компонентов. Проекты сохраняются в формате JSON.
В конце 2025 года SpaceWeb запустил площадку VPS в Нидерландах — и за первый квартал ресурсы разобрали полностью. Спрос оказался выше любых прогнозов, поэтому SpaceWeb удвоил серверные мощности на площадке и выстроил процессы масштабирования.
Серверы работают на базе AMD EPYC 7702, начальная конфигурация — 2 ядра CPU, 1 ГБ RAM, 15 ГБ NVMe — и расширяется под нужды проекта.
Антарктическую площадку на Беллинсгаузене ставим на паузу до доп. согласований
Запуск площадки RUVDS в Антарктиде задерживается — мы вынуждены временно остановить работу оборудования на станции Беллинсгаузен.
Перенос сроков не связан ни с «железом», ни с каналом связи. Сервер, питание, связь/сеть — всё это было и остаётся рабочим. Вопрос в организационном моменте.
Что случилось:
Оборудование несколько месяцев «гонялось» в тестовом режиме (стабильность, связь, удалённое администрирование, «а что если…» сценарии в условиях станции).
Только после того, как тесты показали, что решение можно эксплуатировать, мы открыли публичный доступ и дали всем желающим возможность попробовать VM в Антарктиде.
Уже после запуска открытой эксплуатации мы получили предписание: для дальнейшей работы требуется дополнительное согласование со стороны регулирующих структур, отдельно — по вопросам потенциального воздействия нашего проекта на окружающую среду.
Варианта «просто продолжать как было» у нас нет: площадку нужно остановить до завершения согласований и отдельного уведомления о возможности возобновления эксплуатации.
Что это значит для пользователей, которые успели взять VM:
VM на этой площадке будут оставаться недоступными до тех пор, пока весь процесс согласований не завершится.
Всем, кто оформлял антарктический VM, мы отправим отдельное уведомление с дальнейшими вариантами (например, перенос/компенсация/опции касательно данных — в зависимости от сценария и того, что технически успеем корректно осуществить).
Приносим искренние извинения за смещение сроков: понимаем, что многие пришли именно за «сервером в Антарктиде», и нам самим досадно сворачивать публичную часть проекта в момент, когда она уже заработала. Но выполнение всех требований площадки и регуляторов — это приоритет. Мы хотим быть на все 100% уверены в соблюдении всех процедур, чтобы предоставить вам тот уровень сервиса, который вы привыкли получать.
Будем информировать вас о поступлении новых сведений по статусу проекта: обновим пост и напишем отдельно.
PostgreSQL в Docker: запуск, настройка, типичные ошибки
Устанавливать PostgreSQL напрямую в систему — значит разбираться с зависимостями, версиями и мусором, который остается после удаления. В контейнере база поднимается за секунды, одинаково работает на любой машине в команде и легко пересоздается под новый проект.
В новой статье на сайте Рег.облака разобрали полный путь: от установки Docker на Ubuntu 24.04 до работы с томами, своим postgresql.conf и настройки локали. Отдельно собрали типичные ошибки и объяснили, как их чинить.
Разделяй и властвуй: вебинар про BSA-модель для IaC и опыт её применения «Магнит OMNI»
Infrastructure as Code в компаниях нередко развивается стихийно: Terraform-скрипты копятся годами, репозитории разбросаны по командам, стандарты не зафиксированы. В результате инфраструктура остаётся сложной для понимания и управления.
Модель BSA (Base, Service, Application) помогает навести порядок: структурировать код, распределить ответственность и сделать процессы поставки предсказуемыми. На совместном вебинаре «Экспресс 42» и «Магнит OMNI» расскажем, как это работает на практике.
Вы узнаете:
как работает трёхуровневая модель BSA и как она распределяет зоны ответственности;
как устранить «функциональные колодцы» между DevOps-командами и инфраструктурными инженерами;
какие результаты дало внедрение BSA в «Магнит OMNI» и с чего начать в своей компании.
Регистрируйтесь по ссылке и подключайтесь 13 марта в 12:00, если вы управляете инфраструктурным кодом, развиваете платформенные сервисы или отвечаете за процессы поставки.
Kubernetes, Swarm, Nomad — как выбрать оркестратор и не пожалеть
Когда контейнеров становится больше десятка, ручное управление превращается в отдельную работу: уследить, что запущено, что упало, где не хватает ресурсов — уже не получается.
Оркестратор берет это на себя. Но выбор между Kubernetes, Docker Swarm, Nomad, Mesos и OpenShift — не очевидный. У каждого своя ниша, и «взять Kubernetes, потому что все берут» — одна из самых частых ошибок при внедрении.
Разобрали, как работают оркестраторы изнутри, чем они отличаются на практике и по каким критериям выбирать под конкретный проект. Плюс чек-лист запуска и типичные грабли — от избыточной сложности на старте до игнорирования безопасности.
Открытый проект WebToApp позволяет превратить сайт в полноценное Android‑приложение прямо на саартфоне без ПК, Android Studio или знаний кодинга. Можно сделать приложение из обычного HTML‑сайта, React, Vue или Next.js. Также можно добавить иконку, включить блокировку рекламы и защиту приватности, тёмную тему, медиа‑инструменты и даже собственные скрипты.
Вебинар | РЕД ОС в связке с «Интеллект Х»: видеонаблюдение в масштабе
На вебинаре 19 марта в 11:00 разберем, как связка отечественного ПО — операционной системы РЕД ОС и платформы «Интеллект Х» — позволяет строить надежные крупномасштабные и распределенные системы видеонаблюдения.
В программе вебинара:
— Почему выбор операционной системы напрямую влияет на эффективность управления видеонаблюдением? Поговорим о РЕД ОС, ее сертификации, безопасности и простоте использования.
— Какие возможности предлагает гибкая архитектура «Интеллект Х» для создания решений любого масштаба в локальной, облачной и комбинированной ИТ-инфраструктуре.
— Интеграция охранных систем и видеоаналитика: практические решения для различных отраслей промышленности.
— Как «Интеллект Х» работает на РЕД ОС, закрывая требования регуляторов и обеспечивая бесперебойное видеонаблюдение 24/7.
Спикеры:
— Андрей Христофоров, директор по развитию продуктов ITV Group
— Александр Баранов, директор по развитию ITV Group
— Максим Гильманов, эксперт центра компетенций РЕД СОФТ
