Навайбкодил небольшое веб-приложение для управления ИИ-сервером под Ubuntu. Управляем произвольными systemd-сервисами, добавляем новые + спец. диалог для добавления llama-server как сервиса. Возможно, кому-то пригодится: aiservermanager.

В начале проекта Uwoslab запланировал использовать 400 батареек: закупил четыре упаковки по сотне и 50 групп по восемь элементов. В процессе работы конструкция вышла проще. На всё ушло 192 батарейки. Энтузиаст распределил элементы по трём блокам, по 64 штуки в каждом. Ток от этой такой мегабатареи идёт напрямую в материнскую плату через переходник 12V DC-to-ATX.

По прикидкам Uwoslab, именно сборка из 400 таких батареек могла бы выдавать около 160 Вт на протяжении десяти часов. Характеристики ПК: система на сокете AM4 со встроенной графикой и без накопителя. ОС грузится прямо с флешки - Hannah Montana Linux на базе Debian.

На старте батарейный блок выдавал около 13 В, а под нагрузкой встроенного теста stress-ng, когда процессор загрузили на 98%, напряжение просело лишь до стабильных 11,95 вольта — ПК работал штатно. По остаточному заряду автор предположил, что она могла бы протянуть ещё пару часов, прежде чем напряжение упадёт слишком сильно. Также энтузиаст запустил на таком ПК FreeDoom.

Публикации про инцидент с xz на Хабре:

• «Можно ли было обнаружить бэкдор xz при более продуманной работе с пакетами в Git и Debian?»

• «Бэкдор в xz нашли из‑за замедления работы sshd в полсекунды».

🔥 Docker для начинающих: от «что это» до своего контейнера за 4 часа

Docker используется везде: от локальной разработки до production. Фокус лабы — не на запоминании команд, а на понимании. Вы пройдёте путь от первого контейнера до настройки сетей и данных — своими руками. После лабы сможете уверенно обсуждать контейнеризацию с разработчиками, DevOps и архитекторами.

25 июля, 10:00-14:00 МСК | Максим Тачков, Middle Developer (BIM), преподаватель Docker. По отзывам с прошлой лабы: экспертиза 9/10.

5 блоков за 4 часа: (1) Основы Docker → (2) Сборка (Dockerfile) → (3) Управление (Compose, логи, мониторинг) → (4) Данные (volumes, bind mounts) → (5) Сети (Docker Network, DNS)

За 4 часа вы:

- 🐳 Освоите словарь Docker: image, container, volume, network, Dockerfile

- 🔧 Соберёте и запустите свой первый контейнер из Dockerfile

- 🛠 Научитесь управлять контейнерами через Docker Compose

- 📦 Настроите хранение данных через volumes и bind mounts

- 🌐 Настроите сетевое взаимодействие между контейнерами

Для кого: Backend, frontend, fullstack разработчики, QA-инженеры, системные и бизнес-аналитики, архитекторы, технические менеджеры. Нужно: базовый CLI, понимание веб-приложений, VS Code.

🎬 Запись — 20%. Живая практика с ведущим, ответы на вопросы, разбор ошибок — только на лабораторной.

📖 Pre-read: за 3 дня до лабы высылаем шпаргалку по Docker-командам — подготовьтесь заранее и не теряйте темп.

🛠️ Makefile как «пульт управления» — одна команда = одно действие. Фокус на понимании, а не на синтаксисе CLI.

🚀 Дальнейший маршрут: Kubernetes → REST+OpenAPI → Keycloak → Kafka → Prometheus+Grafana.

🔗 Подробнее: https://debugskills.ru/content?article=labs-docker-basics

Вы пробовали ChatGPT и Cursor. Но система из нескольких AI-агентов — это другой уровень: агенты конфликтуют, теряют контекст, зацикливаются, а отладка напоминает расследование без улик.

🎻 Один AI = музыкант. Несколько AI = оркестр. А кто дирижёр?

19 июля, 10:00-14:00 МСК — лабораторная работа с Андреем Чуяном, создателем ROLES-экосистемы (3 экосистемы, 15+ ролей). За 4 часа: проектирование AI-ролей с YAML-контрактами, 5 хаос-сценариев, MCP-сервер на личной VM, самодиагностика экосистемы.

📐 Проверенная методология FPF + TDD в основе каждого блока.

🔗 Подробное описание: https://debugskills.ru/content?article=labs-ai-orchestration
Готовы спроектировать свою первую AI-экосистему? Приходите 19 июля! 🚀

Обновили ядро Linux на всех Ryzen-серверах в Москве

В копилку стабильности — и с конкретным обновлением под капотом.

Во время работы с высокопроизводительными серверами на Ryzen 7950X нашли причину редких зависаний нод. На старом ядре Ubuntu 22.04 эти процессоры могли работать нестабильно.

Это могло обернуться внезапной недоступностью виртуальных машин, хотя с самими проектами все было в порядке.

Чтобы устранить проблему, обновили ОС и ядро на всех Ryzen-серверах в московской локации.

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

Теперь гипервизоры работают на новом ядре, а риски возможных зависаний нод осталась в прошлом.

Если вам нужны мощные серверы в Москве, есть еще одна новость — расширили парк Ryzen 7950X, чтобы было больше доступных конфигураций под ваши проекты.

Многодоменная архитектура: почему бэкап одного домена не восстанавливает сервис

В инфраструктурных проектах иногда возникает идея разделить окружение на несколько доменов:

• пользователи – в одном контуре;

• серверы и рабочие станции – в другом;

• тестовая среда – в третьем.

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

Но в эксплуатации важен не только вопрос «где лежит объект».

Важнее другое: какие зависимости связывают объекты между собой.

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

Сценарий

Пользователь – в домене A.
Рабочая станция – в домене B.
Группа доступа к приложению – в домене C.

Цепочка доступа:

учётная запись → группа → DNS → доверие между доменами (Kerberos) → права на сервере.

Каждый компонент по отдельности может выглядеть исправным:

KDC отвечает. LDAP-серверы доступны. DNS разрешает имена. Билеты выдаются. Группа существует. Пользователь в группе.

А доступ к приложению всё равно не работает.

Почему? Потому что сломался не отдельный объект, а связь между объектами.

Именно здесь обычная логика «объект изменился → нашли резервную копию → восстановили объект» перестаёт быть достаточной.

В многодоменной среде важно уметь восстановить не только объект, но и связность: группы, доверительные отношения между доменами, DNS SRV-записи, Kerberos-зависимости и порядок применения политик.

Что стоит проверить заранее

• Основной источник данных – где создаются пользователи, где живут группы, какие домены участвуют в кросс-аутентификации.

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

• Контур восстановления – какие домены можно восстанавливать отдельно, а какие требуют жёсткой последовательности: например, сначала восстановить домен A, проверить состояние доверия к B и только потом тестировать доступ.

• DNS и Kerberos – понимаем ли мы, как после восстановления домены находят друг друга? Не разъедутся ли ключи на сервисах и контроллерах, если восстановление идёт из старого снепшота? При откате может измениться KVNO в SPN-записях, и Kerberos-аутентификация для ресурсов сломается, хотя формально всё «зелёное».

• Сквозной тест доступа – проверяем не только доступность серверов, а весь путь: пользователь из одного домена должен получить доступ к ресурсу в другом.

Главный вывод

Многодоменная архитектура – это не просто «удобно разделили контуры». Это более сложная эксплуатационная модель.

Если пользователи, ресурсы, группы и политики разнесены по разным доменам, план восстановления должен описывать всю цепочку, а не один объект.

Иначе гибкость на этапе проектирования превращается в непрозрачность при первой серьёзной аварии.

Коллеги, тестируете восстановление всей цепочки доступа или только каждый домен по отдельности?

#Linux #Инфраструктура #Backup

Если вы хотите лучше разобраться во внутреннем устройстве Linux и узнать, как его ядро взаимодействует с физическими устройствами, то приходите на бесплатный офлайн мастер-класс YADRO. Вместе пройдем полный цикл создания драйвера дисплея LCD1602 для VisionFive2: от теории до добавления новых функциональных элементов и запуске на одноплатнике.

Что будем делать:

• загрузим информацию о дисплее в ядро через Device Tree Overlay;

• выведем текст на дисплей через драйвер Linux для embedded-систем;

• считаем содержимое дисплея из ядра Linux и выведем в консоль;

• научимся управлять подсветкой и курсором через интерфейсы Linux Kernel Driver;

• займемся обработкой IRQ по нажатию кнопки;

• разберем типичные ошибки при разработке Linux-драйверов.

Мастер-класс проведет Никита Косырев, инженер-программист группы системного ПО в YADRO. Никита — энтузиаст embedded-систем и архитектуры RISC-V, несколько лет занимался разработкой драйверов периферийных устройств в ядре Linux. 

Приглашаем инженеров, которые хотят лучше разобраться в низкоуровневой разработке для Linux и особенно тех, кто работает с user space-приложениями. 

Мастер-класс пройдет офлайн 3 июля в московском офисе YADRO, количество мест ограничено. Участие бесплатное, но регистрация обязательна.

Российский Linux. Встреча с реальностью

Есть у нас один заказчик. Весь в Windows. Решил переезжать на российское.
На бумаге всё выглядит понятно: выбирает дистрибутив, разворачивает сервисы, переносит приложения, постепенно уходит от прежнего стека.
Упирается в версию Samba, которой в родных репах нет. Пакет конфликтует с системными библиотеками. Yum (dnf) не может разрешить зависимости и ломается.
Решили просто: подключили репы CentOS, перетерли половину системных пакетов.
На тесте взлетело. В продакшен – уже риск.

Вопрос, который сразу возникнет: «А почему просто не собрать Samba из исходников?»

Для тестовой лабы – ок. Для прода с сотнями пользователей – нет. И вот почему.

Почему это проблема, а не просто настройка

Когда для домена (Samba, Kerberos, DNS) вы собираете из исходников или лезете в чужие репозитории – вы теряете три вещи:

Поддержку вендора
В договоре чёрным по белому: только штатные репозитории. Подменили пакет или поставили самосбор – тикет закроют фразой «сами собрали, сами и поддерживайте».

Безопасные обновления
Выходит апдейт от вендора. При левых репах – dnf update падает с конфликтом зависимостей. При самосборе – вы вообще не получите апдейт, чинить каждую CVE придётся руками.

Сертификацию (ФСТЭК/Минцифра)
И левый репозиторий, и самосбор аннулируют сертификат моментально. На проверке это увидят.

Важное уточнение для тех, кто вспомнит EPEL
EPEL подключают к RHEL для установки дополнительного софта, которого нет в базе. Он не трогает системные пакеты. В нашем кейсе – родной репозиторий ОС не содержал нужной версии критического пакета (Samba). Пришлось лезть в чужой репозиторий и заменять базовые пакеты. Это совсем другая история.

Коротко про вендора

Вендор скажет ровно одно: «Ваша система — не наша сборка. Приходите, когда переустановите без левых реп и самосборов». Никто не приедет, не поправит, не подстрахует. Вы один на один с костылём.

Вывод

Столкнулись с тем, что роль не ставится из родного репозитория?

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

Правильные решения:
Взять другую российскую ОС, где эта роль работает из коробки.
Потребовать от вендора добавить нужные пакеты в свой репозиторий.
Отказаться от этой роли/стека, если ОС его не тянет.

Подмена пакетов в продуктиве – не выход, а вход в ад техподдержки.

Больше про российский ИТ без простоев – в телеграм-канале.

Это пошаговый маршрут изучения Linux с упором на практику. Каждый раздел содержит объяснение «почему это устроено именно так», разбор команд и обязательные задания, которые нужно выполнить руками в терминале. Чтение без повторения навыка не даёт — держите терминал открытым рядом с этим текстом.

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

https://github.com/justxor/linuxfullroadmap/

Кому нужно больше инфы пишите, буду отвечать!

Скоро будет доступен гитхаб проекта и сайт!

Реализация основана на коде проекта 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 "\".

На лицензию OpenMDW-1.1 переходят 4 семейства: Cosmos, Isaac GR00T, Ising и Nemotron.

Стандарт разработан Linux Foundation для ИИ-индустрии и одним документом покрывает все компоненты релиза: исходный код, датасеты, веса, метаданные и документацию. Лицензия позволяет делать дообученные модели и производные продукты проприетарными.

Разработчики получают права на коммерциализацию, модификацию и распространение моделей. Единственное требование - сохранение оригинальных копирайтов при дистрибуции.

https://openmdw.ai/

• Объём загружаемых пакетов вырос с обычных 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

• проверяет файлы, установочные сборки, библиотеки, фреймворки

• сканирует пакетные менеджеры, плагины для IDE, браузерные расширения, конфиги Claude, Cursor, Coder и других ИИ‑инструментов.

• сканирует метаданные.

2. Но ведь существует и другая проблема - активно разрабатываемый(особенно новейший) софт всегда добавляет всякие уязвимости из-за вайбкодеров сегодня. Не только из-за вайбкодеров, проблема существовала и раньше, стойкое недоверие к самому последнему патчу постепенно развивается у некоторых людей. Лучше всего тренируется на arch linux* или любом другом rolling release distro. Nvim, если все патчи подгружать, как только они появляются, тоже помогает с этим. Взаимодействие с результатами бесплатной децентрализованной разработки с самыми разными мотивациями, квалификациями и интересами - это вот самый топ обучения, наверняка те, у кого это приводит к supply chain attack особенно квалифицировались.

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

*Это не в огород арха. Arch linux у джуна всегда был зелёным флагом - человеку интересно, и отговорить можно. А вот если это миддл, то надо сначала выяснить, каким образом он его гоняет. Без раскрытия деталей, по умолчанию страшно с таким человеком работать

«Запускайте приложения и открывайте окна прямо в вашем мире Minecraft. Перетаскивайте данные из одного окна в другое. Закрепите видеоплеер на вашем HUD. Выбор за вами. Важно: этот мод работает только под Linux! MacOS и Windows не поддерживаются», — пояснил автор проекта.

Puppet - мой основной рабочий инструмент. Сейчас он обслуживает нашу офисную и торговую сеть, а это более 9000 хостов на Linux под самые разные нужды. На русском языке актуальных материалов по нему практически нет, поэтому я взялся за англоязычную «Puppet 8 for DevOps Engineers». Читалось не быстро, но, как говорится, дорогу осилит идущий.

И книга оказалась просто 10 из 10.

Больше всего понравилось, что это не просто сборник синтаксиса и примеров, а разбор Puppet как полноценного инженерного инструмента.

Что внутри:

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

Большой блок посвящён коду. Код описан через примеры и советы, но так же описаны типовые ошибки, подводные камни и наследие старых версий, которое всё ещё можно встретить в живых инфраструктурах, но лучше заменить. Не всегда код из книги отрабатывал корректно, нужны были мелкие правки, может это из за версий, а может задумка автора, чтобы ты немного прикладывал голову.

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

Последняя небольшая часть посвящена сравнению с платной версией. Автор честно говорит, что многие возможности можно собрать и в бесплатной версии, если готовы вложить время и поддерживать всё самостоятельно.

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

По итогу:

Книга оказалась полезной со всех сторон: и для написания нормального Puppet-кода, и для понимания архитектуры, и для эксплуатации серверов Puppet в реальной инфраструктуре.

Хочется, чтобы по другим DevOps-инструментам чаще попадались книги такого уровня.

Есть, правда, грустный контекст: Puppet 8 стал последней open source-веткой. После изменений со стороны Perforce новые пакеты и бинарные сборки Puppet начали уходить в закрытую модель распространения. Сообщество в ответ развивает форк OpenVox. По командам, структуре и общей логике он во многом продолжает привычный Puppet-подход, так что история инструмента, похоже, не закончилась.

В Linux и GCC есть constructor-функции - они запускаются автоматически до входа в main().

Выглядит почти как магия:

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

Где это используется:

- инициализация глобального состояния

- подготовка shared libraries

- регистрация плагинов

- настройка runtime-окружения

- выполнение служебного кода до основной логики

Именно поэтому в C-программе не всегда всё начинается с main().

Иногда до него уже кто-то успел поработать.

Подсмотрел в тг про С++ : https://t.me/cpluspluc/1449

Вот и сейчас обновил кое-что с Bullseye на Bookworm. И получил при попытке зайти со старого OpenSSH 5.3 на новый 9.2 “no hostkey alg”. В новой версии OpenSSH по умолчанию отключены алгоритмы ssh-rsa и ssh-dss (первый из-за небезопасного хеша SHA1, второй из-за общей проблемности DSA); а старые версии ещё не умеют rsa-sha2-256, rsa-sha2-512 (не говоря уж об эллиптических кривых).

К счастью, эти алгоритмы ещё не удалены напрочь! Поэтому для обеспепчения возможности подключения старого клиента OpenSSH 5 к новому серверу OpenSSH 9 достаточно записать такие строки в файл /etc/ssh/sshd_config.d/local.conf (и перезапустить sshd):

HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

В обратную сторону тоже работает, чтобы иметь возможность заходить новым клиентом OpenSSH 8 (и выше) на старый сервер OpenSSH 5 (и ниже) достаточно прописать такие три строки в файл ~/.ssh/config:

Host old-server
        Hostname 1.2.3.4
	. . .
        HostKeyAlgorithms +ssh-rsa
        PubkeyAcceptedKeyTypes +ssh-rsa
        KexAlgorithms +diffie-hellman-group14-sha1

🔥 МастерАп 262: AI-оркестрация, фронтенд, бекенд и системная разработка

Второй МастерАп в серии — живая встреча, рестобар, три доклада от практикующих экспертов.

В этот раз говорим про AI в разработке: вербализация как инженерный навык, оркестрация AI-систем и как AI меняет системную разработку Linux.

---

📅 12 мая, 19:00–22:00
📍 Рестобар Точка, 5 минут от м. Пионерская → Яндекс Карты

👉 РЕГИСТРАЦИЯ

🎟 Вход свободный — просто возьмите что-нибудь в баре

---

⚡️ Программа:

🚀 Андрей Ерёменок — «Вербализация как инженерный навык: от кода к тексту, от текста к дизайну»
CTO, сооснователь, AI-консультант с 20-летним опытом. Ведущий канала «Пикник Айтишника».

🐳 Андрей Чуян — «Оркестрация AI систем в разработке контента и решений»
FullStack-разработчик, автор канала «IT-волна» (ITChuyana). Основатель сообщества ПолныйСтек. Эксперт по автоматизации и AI.

🐧 Алексей Сапрунов — «AI в системной разработке Linux»
Системный разработчик Linux. Эксперт по AI в системной разработке, автоматизации и низкоуровневому программированию.

---

👥 Для кого:
Разработчики всех направлений, тимлиды, CTO, DevOps — и все, кто хочет живого общения про AI без воды

---

✅ Что будет:
— Три доклада от практиков
— Вопросы и дискуссия вживую
— Нетворкинг в неформальной обстановке

Спустя неделю после нашумевшего Copy.Fail исследователь v4bel раскрыл новую технику повышения привилегий в ядре Linux — Dirty Frag.

По состоянию на утро 8 мая у Dirty Frag не было CVE-номера и, что более критично, официального патча от мейнтейнеров ядра тоже. Dirty Frag относится к тому же классу, что Dirty Pipe и Copy.Fail, но использует другой механизм: вместо pipe_buffer атакуется структура sk_buff.

Общие механизмы работы позволяют надежно блокировать эксплойт поведенческой экспертизой в PT Sandbox (Exploit.Linux.CVE-2022-0847.a, Exploit.Linux.CVE-2026-31431.a, Backdoor.Linux.Generic.a) — смотрите на скриншоте.

Как это работает? 🧐

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

1️⃣ Page-Cache Write (с 2017 года): предоставляет возможность для записи 4 байт в кэш страниц, но требует права на создание пользовательских пространств имен, что в некоторых системах (например, Ubuntu) может блокироваться AppArmor.

2️⃣ RxRPC Page-Cache Write (с июня 2023 года): не требует прав на пространства имен, но модуль rxrpc.ko присутствует только в некоторых дистрибутивах, включая Ubuntu, где он загружен по умолчанию.

Объединив их, атакующий получает рабочий эксплойт на любой системе, что позволяет:

• Подменить suid-файлы (например, /usr/bin/su) на свою версию
• Изменить /etc/passwd, очистив пароль root-пользователя

Кто под угрозой? ⛳️

Практически все системы с ядром Linux, выпущенные с 2017 года. Исследователь подтвердил работу эксплойта на следующих версиях: Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44 и других.

Как защититься? 🔧

Так как официального патча от мейнтейнеров ядра пока нет, единственный способ защиты — немедленно отключить и выгрузить уязвимые модули ядра.

Команда для отключения:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Некоторые дистрибутивы (например, AlmaLinux) начали выпускать собственные патчи, не дожидаясь апстрима.

Позднее сегодня уязвимость получила идентификатор CVE-2026-43284, патч добавлен в код ядра (f4c50a4034e6).

(Источник: https://t.me/ptescalator)

Очевидный ответ…

Я не верю что это так просто, и так легко!
Но вот прямо щас сижу и сморю tcpdump и офигеваю...

Смотри: клиент заходит на сайт (https).
Сайт отвечает ему: у меня такой сертификат.
Клиент идет в интернет проверить сертификат.
РКН режет эту проверку.
Клиент не верит серверу и не заходит на него.

Легко!

Да не может такого быть!

23 апреля 2026 года Canonical выпустила Ubuntu 26.04 LTS Resolute Raccoon. Для меня это старт большого проекта. Работа Linux-администратора в крупной компании подразумевает создание «золотого образа», который потом годами будет крутиться на сотнях машин.

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

Первое знакомство.

Canonical в документации указывает для Ubuntu Desktop 26.04 минимум 6 ГБ RAM, 2 GHz dual-core CPU и 25 ГБ. В чистом виде, без swap-файла, система заняла у меня около 6.6 ГБ на диске. Потребление оперативки на старте чуть меньше 2 ГБ. На фоне этого официальная рекомендация в 6 ГБ RAM выглядит как оценка для комфортной работы. Думаю после загрузки всех требуемых пакетов, браузеров с десятками вкладок, мессенджерами, антивирусами, агентами и прочими пожирателями ресурсов будет в самый раз. После тестовой установки нескольких тяжеловесных приложений, система ощущается плавной и отзывчивой. Дальше предстоит выяснить что поменялось в системе, где могут сломаться сценарии Puppet, не поедут ли настройки dconf/gsettings и ещё тысячи других мелочей.

Что нового в «Решительном еноте»?

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

• Ядро Linux 7.0. Ubuntu 26.04 базируется на новой мажорной версии ядра. Это поддержка самого свежего железа, оптимизации в работе планировщика, а также свежие фичи в сетевом стеке.

• GNOME 50 принёс улучшения в адаптации интерфейса под небольшие экраны, аппаратное ускорение записи экрана, прокачанный remote desktop и более плавную работу. GNOME-сессия теперь работает только на Wayland. Старый добрый X11 не бросили (он работает через XWayland), но стандартная сессия как X.org больше не запускается. Здесь есть риск что все настройки связанные с графикой и удалённым доступом могут сломаться.

• Также Canonical удалила PreLogin и PostSession скрипты. Это может задеть корпоративные сценарии, например синхронизацию домашней директории при входе/выходе или очистку временных данных.

• Расширилось использования Rust в системе. Это помогает бороться с целым классом ошибок памяти, что всё равно не делает утилиты полностью безопасными.

• APT 3.1. Наконец то история операций и команды для отката: apt history-info, apt history-undo, apt history-redo, apt history-rollback. Вещь полезная, особенно когда случайно удалил лишнее.

Так же появилось несколько изменений, которые важны для администратора.

• Dracut — новый механизм сборки initramfs по умолчанию. Он отвечает за ранний этап загрузки системы: подготовку драйверов, модулей, шифрования дисков и всего, что нужно до старта основной ОС.

• TPM-backed full-disk encryption — полнодисковое шифрование с привязкой ключей к TPM-чипу. Система может разблокироваться автоматически, если проверка целостности прошла успешно. Это удобно, но требует аккуратности при обновлениях BIOS или замене платы.

• CUDA и ROCm в репозиториях Ubuntu — упрощённая установка инструментов для вычислений на GPU, что полезно для ML.

Итог

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

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

Уязвимость CVE-2026-31431, которую мы считаем трендовой, состоит из четырех шагов:

1️⃣ Пользователь открывает сокет AF_ALG и инициализирует AEAD-алгоритм без привилегий;

2️⃣ Через splice() страницы кэша целевого файла попадают в буфер операции;

3️⃣ Ошибка в authencesn дает запись 4 байт за границы буфера прямо в страницы кэша;

4️⃣ Ядро исполняет модифицированный setuid-файл из кэша → выполнение кода с правами root.

Данная цепочка уязвимости частично схожа с Dirty Pipe (CVE-2022-0847), которая также использует системные вызовы:

• pipe — создает однонаправленный канал передачи данных;

• splice — позволяет передавать данные между файловыми дескрипторами без промежуточного копирования.

Так как данная уязвимость уже обнаруживалась в PT Sandbox при анализе ПО в образе Astra Linux, процесс эксплуатации новой уязвимости Copy Fail также обнаруживалась в PT Sandbox еще до выхода публичного эксплойта.

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

Как исправить 🔧

Если вы администрируете Linux-системы — обновите ядро. Патч зафиксирован в коммите a664bf3d603d. Основные дистрибутивы начали выпускать исправленные пакеты с 29 апреля. После обновления потребуется перезагрузка.

Если немедленное обновление невозможно — временная мера: отключить модуль algif_aead:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf

rmmod algif_aead 2>/dev/null

(Источник: https://t.me/ptescalator)

Уязвимость CVE-2026-31431 связана с локальным повышением привилегий в компоненте ядра Linux AF_ALG. Она вызвана ошибкой работы с памятью и позволяет непривилигированному пользователю поднять привилегии до максимальных (root). Это позволяет злоумышленнику полностью захватить систему: читать и изменять любые файлы, включая пароли и ключи, подменять системные файлы, отключать защитные механизмы и средства мониторинга, незаметно устанавливать бэкдоры и закрепляться в системе, скрывать следы своей активности, использовать устройство как возможность для атак на другие сетевые активы. Злоумышленник может проэксплуатировать уязвимость в рамках атак на инфраструктуру, которые могут привести к недопустимым последствиям (утечки информации, кража денежных средств, техногенные катастрофы и т.п).

Эксплуатабельность недостатка безопасности была подтверждена на актуальных версиях популярных дистрибутивов Linux: Ubuntu, Amazon Linux, RHEL, SUSE и другие.

Ядро Linux Kernel уже сталкивалось с громкими уязвимостями повышения привилегий - например, Dirty Cow и Dirty Pipe. Как сообщают исследователи, в отличие от предыдущих уязвимостей, Copy Fail — это прямолинейная логическая ошибка. Одна и та же программа (скрипт), не требуя каких-либо изменений, работает на всех протестированных дистрибутивах и архитектурах. Эксплойт для уязвимости - это короткий скрипт на Python, использующий только стандартные модули os, socket, zlib. Он не требует никакой настройки под конкретный дистрибутив или архитектуру. Экслуатация уязвимости не детектируется встроенными инструментами безопасности ОС. Кроме того, недостаток безопасности может ставить под угрозу межконтейнерное воздействие и работу кластеров Kubernetes.

На данный момент для того, чтобы защититься, можно обновить ядро самостоятельно. Если вы не готовы это делать, следует дождаться, когда обновления пакетов ядра выпустит вендор вашего Linux-дистрибутива. В качестве альтернативного решения исследователи предлагают заблокировать создание сокетов AF_ALG. Обнаружить эту уязвимость в инфраструктуре можно с помощью MaxPatrol VM. MaxPatrol SIEM детектирует эксплуатацию уязвимости с помощью правила CVE_2026_31431_Linux_Copy_Fail_LPE.

Александр Леонов, ведущий эксперт по управлению уязвимостями PT Expert Security Center, Positive Technologies

В репозитории:

• NodeGroupConfiguration, который блокирует загрузку модуля и выгружает его, если он загружен;

• FalcoAuditRules для детекта попыток эксплуатации (доступно в DKP EE и CSE).

Применяется через kubectl apply, подробности и инструкции в README.

1. Добавляем в систему раскладку сербской латиницы в варианте Qwerty, делается это через Keyboard -> Layouts

2. Заходим в терминал и пишем: setxkbmap -query
   Видим примерно такое:

   rules:      evdev
   model:      pc105
   layout:     us,ru,rs
   variant:    ,,latinyz
   options:    grp:win_space_toggle,terminate:ctrl_alt_bksp,grp:caps_toggle

   Внимание на us,ru,rs и вариант - latinyz

3. Пилим исполняемый shell скрипт, например в ~/use_default_layout.sh
   Этот скрипт будет временно убирать сербскую раскладку, чтобы не мешалась.

   #!/bin/bash
   current_layouts=$(setxkbmap -query | grep layout | awk '{print $2}')
   
   if [[ "$current_layouts" != "us,ru" ]]; then
       setxkbmap -layout "us,ru"
   fi

4. Идём в Keyboard, добавляем кастомные сочетания клавиш:

   

   Я переключаю раскладку с помощью Caps Lock, поэтому рассказываю как удобно мне. Вы делайте на те клавиши, которые удобны вам (иначе какой смысл).
   
   - Переключение на сербскую раскладку: CTRL+Caps Lock, команда:
   setxkbmap -layout rs -variant latinyz
   
   - Отмена сербской раскладки: просто Caps Lock, который зовёт скрипт use_default_layout.sh из пункта 3.

Готово, вы великолепны.

Я полностью пересмотрел концепцию библиотеки LDL.

Что такое LDL?
Это графическая библиотека с единым API для всех систем как старых, так и новых.

Раньше я писал её на C++98, что давало хорошую портабельность. Но сейчас я пересмотрел многие тезисы, которые декларировал на GitHub, чтобы наконец добраться до первого релиза.

Новая стратегия

Я решил выпускать релизы без реализации полного функционала (графика, звук, шрифты и т.д.) постепенно, итеративно.

• Перешёл на C89 для максимальной переносимости. Это не только DOS или Windows 3.x, но и старые системы вроде Solaris, PlayStation 1 и другие.

• Для первого релиза реализую минимальный базовый функционал: графику (OpenGL, Vulkan), окна и события. По возможностям аналог GLFW.

• С каждым следующим релизом буду добавлять: 2D-рендер, звук, шрифты и прочее.

Лицензия и целевые платформы

• Лицензия меняется на LGPLv3.

• На старте поддерживаются Windows и Linux.

Качество и инструменты

При разработке использую:

• AddressSanitizer (ASan)

• UndefinedBehaviorSanitizer (UBSan)

• Различные анализаторы кода

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

Примеры и бэкенды

• Добавлю десятки примеров с OpenGL 1.x, OpenGL 3.x и Vulkan.

• Буду добавлять бэкенды для LDL: не только под ОС, но и поверх других графических библиотек — SDL, SFML, GLFW и т.д.

• API остаётся единым для всех бэкендов.

Это позволит сразу добавить поддержку звука и шрифтов (через бэкенды), а в нативных версиях реализовывать их позже.

 2D-рендер без границ

Одной из главных задач LDL я вижу создание единого 2D-интерфейса, который стирает различия между поколениями графики.

Вам не нужно думать о том, что находится в системе: современная видеокарта с Vulkan, старый ускоритель с OpenGL 1.2 или вообще только центральный процессор (Software Rendering).

• Единый интерфейс: Вы используете одни и те же команды для рисования пикселей, линий и спрайтов.

• Адаптивность: LDL сам выберет наиболее эффективный способ вывода изображения. На современной системе это будет аппаратное ускорение, а на «железе» без видеокарты оптимизированный программный растеризатор.

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

Философия: Машина времени в вашем коде

Зачем тратить силы на поддержку систем, которые многие считают «трупами»?

1. Борьба с цифровым забвением

Современный софт живет 3–5 лет. Мы выбрасываем железо не потому, что оно сломалось, а потому, что софт стал слишком тяжелым и ленивым. LDL — это протест против «запланированного устаревания». Я хочу, чтобы код, написанный сегодня, мог дышать в железе любой эпохи.

2. Инженерный аскетизм

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

3. Преемственность поколений

Мы стоим на плечах гигантов, но часто забываем их имена. LDL сохраняет возможность для диалога между эпохами. Это инструмент, который позволяет современному разработчику почувствовать «металл» старых машин, не теряя связи с современными технологиями вроде Vulkan.

Итог

LDL — это Little Directmedia Layer. Он маленький не потому, что слабый, а потому, что в нем нет ничего лишнего. Это попытка создать код, который будет принадлежать не конкретной версии ОС, а истории программирования в целом.

Один API. Один код. Тридцать лет компьютерной истории.

Скрипт намбер ван:

#!/bin/bash

FILE1="/tmp/clp.saved"

# xclip -o -selection primary > "$FILE1"
wl-paste --primary > "$FILE1"
notify-send "Diff" "Первый фрагмент сохранён"

вешаем на одно сочетание клавиш (у меня, например, для удобства, Alt+Shift+1)
(выбираем на вкус для X11 или Wayland)

Скрипт намбер ту:

#!/bin/bash

FILE1="/tmp/clp.saved"
FILE2=$(mktemp /tmp/clp.XXXXXX)

trap 'rm -f "$FILE2"' EXIT

# xclip -o -selection primary > "$FILE2"
wl-paste --primary > "$FILE2"

if [ ! -s "$FILE1" ] || [ ! -s "$FILE2" ]; then
	notify-send "Ошибка" "Нет текста для сравнения"
	exit 1
fi

meld "$FILE1" "$FILE2"

вешаем на другое сочетание клавиш (у меня, например, Alt+Shift+2)

Изолента и реактивный двигатель — вот всё, что нам нужно. Лучше, чем ничего, по крайней мере…
Первый скрипт сохраняет выделенный текст во временный файл /tmp/clp.saved.
Второй скрипт сохраняет выделенный текст в другой временный файл /tmp/clp.XXXXXX, открывает их оба в нашем любимом Meld, мы на всё это дело любуемся, сравниваем, закрываем Meld, после чего скрипт удаляет этот второй временный файл со случайным постфиксом, чтобы не болтался зря. Первый, /tmp/clp.saved пока остаётся, чтобы было удобно с одним и тем же «первовыделенным» сравнивать несколько вариантов, и его всегда можно переопределить первым скриптом.

Итого: Выделили кусок, Alt+Shift+1, выделили другой кусок, Alt+Shift+2 — смотрим, радуемся! 😁

Какие кейсы разберем:

• SSH сломался после обычной операции с архивом

• Сервер не запускается на нужном порту — без очевидной причины

• После обновления ядра система начинает вести себя странно

• Сеть в ВМ ломается после добавления интерфейса

• Балансировщики с одинаковыми конфигами дают разный результат

Обсуждение почти как на офисной кухне, только с логами и командами. А еще дарим мерч, если отправить свой кейс на разбор.

Подробности и регистрация по ссылке.

keybind = ctrl+shift+key_c=copy_to_clipboard:mixed
keybind = ctrl+shift+key_v=paste_from_clipboard
keybind = ctrl+shift+key_a=select_all
keybind = ctrl+shift+key_e=new_split:down
keybind = ctrl+shift+key_f=start_search
keybind = ctrl+shift+key_i=inspector:toggle
keybind = ctrl+shift+key_n=new_window
keybind = ctrl+shift+key_o=new_split:right
keybind = ctrl+shift+key_p=toggle_command_palette
keybind = ctrl+shift+key_q=quit
keybind = ctrl+shift+key_t=new_tab
keybind = ctrl+shift+key_w=close_tab:this

Я не программист, языков не знаю, я небольшой руководитель отдела в айти, неплохо знаю серверную архитектуру. Но у меня была простая боль: недавно завел для себя и родни сервер Hysteria 2, до этого было с VLESS на сервере и устал каждый раз руками править YAML, когда нужно:

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

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

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

Почему не SSH?

Да, можно через SSH, nano и systemctl. Но когда делаешь это регулярно — растёт шанс ошибки.

Хотелось проще: открыть Telegram, нажать пару кнопок и выдать доступ без ручного редактирования config.yaml.

Веб-панель тоже рассматривал, но бот оказался быстрее и удобнее “на ходу”.

Что умел MVP

Минимум, который был нужен:

/status — жив ли сервис /users — список пользователей add / delete / enable / disable генерация hy2:// ссылки /logs — последние логи /restart — перезапуск с подтверждением

Звучит просто. Пока не думаешь о безопасности.

Главная проблема: бот ≠ root

Первая (и плохая) идея — дать боту полный доступ: пусть сам правит YAML, дергает systemctl и читает логи.

Это почти готовый root-доступ извне.

Я сделал иначе:

Бот — это интерфейс, не исполнитель.

Бот хранит данные (SQLite) Все опасные действия делает отдельный helper на сервере Helper: генерирует YAML делает backup валидирует только потом применяет и перезапускает

В sudoers разрешены только конкретные команды helper-а, а не shell.

Безопасность (без этого смысла нет)

Сделал максимально жёстко:

deny by default доступ только по Telegram user ID (не username) админ-команды только в личке в группах — никаких опасных действий delete/apply/restart — через подтверждение audit log: кто, когда и что сделал

Бот должен быть параноидальным, а не “удобным для всех”.

Грабли, на которые я наступил

1. Права на конфиг permission denied на /etc/hysteria/config.yaml — лечится не перезапуском, а нормальными правами.

2. Cert/key Один неправильный путь — сервис не стартует. Плюс легко сломать доступ к privkey.pem.

3. URI и userpass

hy2:// и hysteria2:// формат username:password спецсимволы нужно кодировать

Очень легко получить “почти рабочую” ссылку.

4. Клиенты На iOS импорт URI иногда работает хуже, чем ручной ввод.

5. OpenWrt + sing-box Сначала “не работает”, потом “работает, но не так”, и только после настройки DNS и роутинга — всё нормально.

Что получилось

Сейчас это нормальный админ-пульт:

управляю доступами из Telegram не трогаю YAML руками опасные действия подтверждаются и главное — нет полного root-доступа у бота

Удобство появилось без видимых дыры в безопасности.

Про LLM

Да, я использовал нейронку. Но это не “магическая кнопка”.

Без продуманной архитектуры (права, границы, apply, валидация, rollback) получилась бы просто опасная игрушка.

Что бы сделал иначе сразу делал бы helper-архитектуру добавил бы audit log с самого начала разделил бы read и write операции по правам сделал бы preflight-проверки перед apply

Что дальше

Планирую:

улучшить UX, возможно добавить лёгкую веб-панель, оставить Telegram, как быстрый пульт

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

P.S. Это моя первая статья, готов ко всем минусам, хейту и так далее. Единственная цель этого поста - рассказать о боте и дать его в народ

ссылка не репу https://github.com/Ramisya4ka/hysteria-bot-manager (внутри есть очень подробное Readme)

Полная схема, которая наглядно показывает весь путь TCP-соединения в ядре Linux.

Описаны:

• все основные очереди (SYN-queue, Accept-queue, Send-Q, RX/TX-буферы);

• точки возможных дропов пакетов;

• места тюнинга ключевых параметров (tcp_max_syn_backlog, somaxconn, netdev_max_backlog, tcp_mem и другие);

• наиболее важные метрики TcpExt_*.

Если открывается сжатая картинка, то полную можно найти в гите

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

Так родился lazy-tmux, написанный на Go. Ключевые фичи:

• Сохраняет текущую сессию, конкретную сессию или все сессии целиком. Снимки сохраняют окна, панели, layout, команды (например, npm, docker-compose, редакторы) и опционально scrollback историю шела.

• Ленивое восстановление: поднимается только выбранная сессия. RAM не расходуется на всё сразу.

• Интерактивный TUI браузер с деревом сессий, окон и панелей, таблицей с активными командами, временем последнего снимка, количеством окон/панелей и статусом сессии. Поддержка fuzzy search для быстрого поиска.

• Навигация и полное управление сессиями и окнами с клавиатуры в TUI браузере сессий.

• Гибкая сортировка сессий и окон через флаги --session-sort и --window-sort

• Можно заменить встроенный TUI на fzf, использую облегчённый бинарник.

• Автосейв через фоновый демон, периодически снимающий все сессии на диск.

• Восстановление при старте tmux для автоматизации workflow.

Проект ещё молодой, но буду рад любой помощи и идеям по улучшению: GitHub issues

За моими новостями можно следить в Telegram-канале

Upd1: Linux слишком гибкий. Вот я пытался накопать библиотеку libnss3 для hl2_linux и в итоге снёс gnome и спустя 2 часа ручного восстановления и зубрения пакетов apt я вернул всё как было

Среди прочего, продемонстрирована работа ReactOS на реальном оборудовании и загрузка с установленными драйверами для видеокарт уровня Intel GMA 945, Nvidia GeForce 8800 GTS и GTX 750 Ti и AMD Radeon HD 7530G. Отдельно отмечается успешный запуск на мобильной графике, например Nvidia Quadro 1000M, где помимо 2D/3D‑ускорения также функционируют звук и сетевые подключения. В дополнительных тестах также подтверждена работа на более редких и устаревших конфигурациях, включая ноутбук с Radeon Xpress 1100, а также на высокопроизводительных видеокартах, таких как Nvidia GTX Titan X.

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

Кажется, NixOS наконец выходит из категории системы «для своих» и становится все заметнее в инженерной среде. Это закономерно: он очень точно попал в проблемы, с которыми команды массово столкнулись только в последние годы.

История началась в 2003 году, когда исследователь Элко Долстра и его коллеги в Утрехтском университете запустили проект Nix. Это исследовательский проект, который включал пакетный менеджер и собственный декларативный язык. Идея была сделать так, чтобы пакеты и зависимости собирались предсказуемо, не конфликтовали между собой и не превращали систему в хаос после очередного обновления. Чуть позже из этой логики вырос NixOS, где тот же подход применили уже ко всей операционной системе.

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

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

😏 Почему NixOS набирает популярность именно сейчас? Потому что индустрия наконец доросла до его сильных сторон. Чем больше у команды окружений, CI/CD, инфраструктуры как кода и цены ошибки, тем важнее воспроизводимость и предсказуемость. То, что раньше выглядело как нишевая экзотика, сегодня все чаще выглядит как очень здравый инженерный выбор.

Многие современные immutable‑системы по сути идут в ту же сторону, куда NixOS пошел еще много лет назад.

А если хочется не просто прочитать про Nix, а разобраться, как он работает на практике, приходите на наш открытый воркшоп.

📹 Открытый воркшоп в рамках ИнженеркаТех Плюс, 18 марта в 19:00 по МСК. Александр Сергеев из сообщества RULKC, Russian Linux Kernel Community, расскажет про Nix и функциональный подход к пакетам и сборке.

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

Зарегистрироваться тут

Неправильно выставленные разрешения на файл или каталог — один из самых распространенных векторов для эскалации привилегий в  Linux.

В блоге мы разобрали базу, которую полезно держать в голове: символьное и цифровое представление прав, разница между владельцем, группой и остальными, команды chmod и chown с практическими примерами — от chmod 755 до рекурсивной смены владельца через chown -R.

Читайте полный разбор на сайте Рег.облака.

1. Если своп находится внутри LVM, даже зашифрованного через LUKS, подсистема ядра Kernel Lockdown не даст включить гибернацию, если в UEFI включён Secure Boot. Чтобы всё это добро работало, нужно вынести своп таким образом, чтобы оно было напрямую подвязано к LUKS-контейнеру, без LVM.

2. Гибернация в режиме UEFI Secure Boot работает только внутри зашифрованного LUKS-контейнера. Если своп хранится в незашифрованном виде, подсистема Kernel Lockdown не даст включить гибернацию. Это сделано для защиты от подмены данных, а также от получения данных со свопа извне запущенного с ним экземпляра ОС.