Есть классическая проблема: изолированные процессы — хорошо для надёжности, но хочется иногда позвать функцию из соседа, как будто она лежала в той же библиотеке. Стандартные IPC — это всегда протокол: описал интерфейс, сгенерировал стабы, поднял сервер, прописал адреса. simplerpc предлагает путь короче: ты пишешь обычную функцию на Си, линкуешь библиотеку — и она автоматически становится RPC-методом, доступным другим процессам на той же машине.

Архитектура держится на трёх решениях. Во-первых, данные едут не через сокет, а по разделяемой памяти — SHMEM. Аргументы вызова лежат в общем сегменте, отображённом по одному виртуальному адресу во всех процессах, и копирования между адресными пространствами нет. Сокет используется только для сигналов: регистрация функций, передача дескриптора памяти (SCM_RIGHTS), обнаружение смерти клиента. Во-вторых, свой аллокатор — транзакционный TLSF с откатом при падении процесса. Межпроцессный мьютекс встроен прямо в структуру пула, а если владелец мьютекса погибает, следующий автоматически откатывает незавершённую транзакцию. Пул консистентен без внешнего сторожа. В-третьих, вместо стандартных примитивов синхронизации — POSIX-семафоры в разделяемой памяти и lock-free MPMC-очередь для передачи задач от клиента к воркерам.

Но самое интересное — как демон оказывается в системе. Исполняемый файл демона не лежит на диске. Он встроен в libsrpc.so в виде C-массива, записывается в анонимный memfd целиком в оперативной памяти и запускается через fexecve(). При загрузке библиотеки любым приложением автоматически форкается демон. Если процессов несколько — проигравший гонку bind() на абстрактном Unix-сокете молча завершается. Когда последний клиент отключается — демон выходит, а память исчезает вместе с последней ссылкой на memfd. Никакого PID-файла, никакого init-скрипта, никакого сервиса. Библиотека сама себя разворачивает.

Библиотека организована так: guard daemon (фоновый координатор), транспорт (Unix-сокеты и SCM_RIGHTS), аллокатор TLSF с транзакциями, сборщик мусора в разделяемой памяти с hazard pointers, RPC через X-макросы (один файл — единственный источник истины), динамическая линковка через weak alias, дескрипторы процессов и потоков, lock-free очереди и синхронизация. Всё это — в bench/ можно найти бенчмарки, если захотите сравнить сами.

Попробовать три команды: mkdir build && cd build && cmake .. && make, затем в одном терминале ./log, в другом ./app. Готово.

Ограничения: только Linux, только локальные процессы на одной машине, ранняя стадия развития — API стабильностью не отличается. Функции с переменным числом аргументов не поддерживаются, указатели осмыслены только если адресуют разделяемый пул.

Репозиторий: github, лицензия Apache-2.0. Если интересно — смотрите код на Си.

• В анонсе 6 сентября заявлены камера, микрофоны, Wi-Fi, Bluetooth и аппаратное декодирование видео, включая AV1. В официальной таблице функций есть расхождения; перед установкой проверьте свою модель.
• По анонсу, режим сна не работает, а HDMI отключён на MacBook, где он предусмотрен. GPU и полная поддержка DCP остаются незавершёнными.
• Mac Studio с M3 Ultra пока не поддерживается.

Что работает в Asahi Linux на M3

Согласно анонсу команды от 6 сентября, доступна почти вся функциональность, уже поддерживаемая на M1 и M2. Кроме камеры, встроенных микрофонов и беспроводной связи, заявлены USB со скоростью до 10 Гбит/с и аппаратное декодирование видео, включая AV1. Декодирование видеопотока и отрисовка 3D-сцен используют разные возможности чипа.

Крупные незавершённые части порта — графический процессор и полная поддержка DCP, сопроцессора управления дисплеем. По анонсу, из-за ограничений кадрового буфера, предоставляемого прошивкой, режим сна не работает, а HDMI-порт на оснащённых им MacBook отключён. Автор анонса Джеймс Каллигерос предупреждает об ограничениях графики. Ниже — перевод его слов.

Сейчас не стоит ожидать производительного или энергоэффективного 3D-ускорения.

В документации есть расхождения.
На момент подготовки новости официальная таблица M3 ещё указывает отсутствие AV1 и незавершённую поддержку USB, а сон отмечает как доступный. Перечень возможностей и ограничений выше приведён по анонсу 6 сентября. Таблица может обновляться с задержкой; перед установкой проверяйте свежие сообщения проекта.

Как попробовать экспериментальную поддержку

В официальном анонсе приведена команда для терминала macOS. Она скачивает и сразу запускает удалённый скрипт установки с включённым Expert. Убедитесь, что адрес совпадает с официальным alx.sh. Перед изменением разделов сохраните резервную копию данных и прочитайте подсказки установщика.

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

Ограничение Expert планируют снять к выходу беты Fedora Linux 45, ориентировочно через пару недель после анонса. Fedora — дистрибутив, на котором основана пользовательская версия Asahi. План зависит от отсутствия серьёзных регрессий и других блокирующих проблем; обещания одновременно исправить сон, HDMI и графику в анонсе нет.

Поддержка M3 в Asahi Linux уже пригодна для практических экспериментов. Перед установкой сопоставьте свой рабочий сценарий с ограничениями, указанными в анонсе 6 сентября, и проверьте последующие обновления проекта.

Последняя капля, как её назвали инженеры CERN (перевод редакции), знакома всем, кто держит парк старого железа: RHEL и его производные собираются с флагом компилятора -march=x86-64-v2, и процессоры без нужных инструкций перестают загружать систему. В CERN это назвали принудительным устареванием. Для админа с парком машин десятилетней давности вопрос тот же: какую ветку дистрибутивов под них выбирать.

• Мигрируют 2200 с лишним промышленных компьютеров и встраиваемых систем управления ускорителями; срок до конца 2026 года; целевая система Debian 13.
• Дата-центры и вычислительная инфраструктура экспериментов остаются на RHEL и AlmaLinux, уточнение опубликовано отдельно.
• CERN около десяти лет использовала Scientific Linux, которую сама сопровождала, затем с 2015 года CentOS.
• Рассматривали CentOS Stream как естественное продолжение, но решающим стал флаг -march=x86-64-v2 по умолчанию в RHEL.
• Названные проблемы Debian: нет стандартного инструментария для автоматической сборки и публикации пакетов и для хранения нескольких версий одного пакета.

Что такое x86-64-v2 и почему он отсекает железо

Уровни микроархитектуры x86-64-v2, v3 и v4 описывают наборы инструкций, на которые компилятор может рассчитывать. Уровень v2 требует, среди прочего, SSE4.2 и POPCNT; это процессоры примерно 2009 года и новее. RHEL 9 и производные (AlmaLinux, Rocky, CentOS Stream 9) собираются под v2, поэтому на более старых CPU ядро и пользовательские программы просто не запускаются. Промышленные контроллеры и встраиваемые машины у ускорителей меняются редко: оборудование сертифицировано, проверено годами и работает. Debian по-прежнему собирает amd64 под базовый уровень x86-64, что и делает его вариантом для такого парка.

Чего CERN не хватило в Debian

По пересказу Phoronix, инженеры назвали два пробела. Первый: в экосистеме Debian нет стандартного инструментария для автоматической сборки и публикации собственных пакетов уровня того, к чему привыкли в мире RPM (Koji, Copr, mock). Второй: инструменты репозиториев плохо поддерживают хранение нескольких версий одного и того же пакета, что нужно для контролируемого отката на промышленных системах. Оба пробела CERN закрывает своими средствами; подробности обещаны в видеозаписи доклада с MiniDebConf.

Что остаётся на RHEL

Важное уточнение, которое Phoronix добавил после публикации: миграция касается только промышленных компьютеров управления ускорителями. Дата-центры CERN и вычислительная инфраструктура экспериментов остаются на RHEL и AlmaLinux. То есть это не «CERN уходит с Red Hat», а выбор дистрибутива под конкретный класс машин со старым железом.

Что это значит для своего парка

• Проверить, проходят ли ваши серверы уровень v2: /lib64/ld-linux-x86-64.so.2 --help | grep supported на любой glibc новее 2.33 покажет поддерживаемые уровни.
• Если в парке есть машины ниже v2, ветка RHEL 9 и новее для них закрыта; варианты: Debian, Ubuntu (тоже базовый x86-64) или остаться на RHEL 8-совместимых системах до конца их поддержки.
• Для промышленных систем ключевой вопрос не дистрибутив, а инструменты сборки пакетов и отката: под Debian их придётся собирать самим, как это делает CERN.
• Debian 13 вышел летом 2025 года и будет получать обновления безопасности до 2028 года, затем LTS; для сравнения, поддержка Debian 11 закончилась 31 августа.

Слайды и видео доклада CERN с MiniDebConf на момент публикации доступны через страницу конференции, отдельного пресс-релиза организация не выпускала. На сайте мы недавно разбирали другой пример влияния сборочных флагов на скорость: Rust Coreutils 0.11 и разницу производительности бинарников в Alpine из-за libc.

Источник: Phoronix: CERN Transitioning Industrial Computers To Debian

Изображение на обложке: Debian Project, логотип Debian Open Use

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

• aish доступен во всех версиях SELECTOS; установка: sudo apt update, sudo apt install aish, запуск командой aish.
• Сценарии: не запускается сервис, закончилось место на диске, нужно проверить логи или конфигурацию.
• Агент предлагает команды и выполняет их только после согласия пользователя.
• Модель развёрнута локально на серверах Selectel; подключение других моделей обещано в будущих релизах.
• О работе на сторонних дистрибутивах компания не сообщает.

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

Автор публикации Наталия Бажан, менеджер проектов SELECTOS, описывает цикл так: администратор пишет в терминале задачу, например «сайт на nginx не открывается», агент сам смотрит состояние сервисов, порты, логи и конфигурацию, формулирует гипотезу и предлагает конкретные команды. Каждая команда показывается до выполнения, и без явного согласия оператора ничего не запускается. Это принципиальное отличие от автономных агентов: aish задуман как помощник с правом совещательного голоса.

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

Установка и ограничения

На SELECTOS установка сводится к трём командам из документации:

Агент доступен во всех версиях SELECTOS. Про установку на Ubuntu, Debian или другие российские дистрибутивы компания не пишет; пакет живёт в репозитории SELECTOS, и, по нашей оценке, за пределами этого дистрибутива его работа не гарантирована. Не сказано и о стоимости: обращения к модели идут на серверы Selectel, и остаётся вопрос, будет ли сервис бесплатным для всех пользователей SELECTOS, включая тех, кто ставит его не на серверах Selectel.

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

Что стоит проверить перед использованием на боевом сервере

1. Какие данные агент собирает для контекста и уходят ли в модель содержимое конфигураций с секретами; политика обработки в публикации не описана.
2. Права: запускать aish под учётной записью с ограниченным sudo, а не под root, пока не ясно, какие команды он склонен предлагать.
3. Журналирование: фиксировать все выполненные по подсказке агента команды, чтобы разбирать инциденты.
4. Сеть: серверы за пределами инфраструктуры Selectel должны иметь доступ к её API; адреса и порты в документации стоит уточнить.

Контекст

SELECTOS, дистрибутив Selectel на базе Debian, развивается как открытый проект с собственным репозиторием; aish добавили в него в августе 2026 года, а публичный анонс вышел сейчас. Появление терминальных агентов у хостеров укладывается в общую тенденцию: похожие ассистенты встраивают в консоли крупные облака, но там речь о зарубежных моделях и зарубежной юрисдикции данных. Редакция проверит, появится ли aish за пределами SELECTOS и раскроет ли Selectel используемую модель.

Источники: Публикация Selectel на Хабре: aish, Документация SELECTOS

Изображение на обложке: Selectel

Для тех, кто пользуется обычными GNU Coreutils, ничего не меняется, пока дистрибутив не переключится сам. Но тенденция понятна: Ubuntu уже ставит Rust-реализацию по умолчанию, и вопрос «а чем это отличается» становится практическим. Ответ версии 0.11: сообщениями об ошибках, скоростью и очередным шагом к полной совместимости с GNU.

• Новый диагностический движок на библиотеке ariadne: подсказки с указателем в 28 утилитах.
• Переменная UUTILS_DIAG принимает always, never и auto; в скриптах и пайпах по умолчанию сохраняется однострочное сообщение.
• PGO-сборки для Linux, macOS и Windows дают до 31% прироста; cp ускорен на 32,93%, join в одном сценарии в 2,5 раза быстрее GNU.
• Совместимость с тестами GNU: 653 успешных, 22 неудачных, 10 пропущенных из 685; было 645 и 28.
• Исправлены TOCTOU-проблемы в mv, cp, rm и chmod; 358 pull request от 26 новых участников.

Как выглядит новая ошибка

Идея, описанная Сильвестром Ледрю в блоге проекта, проста: GNU-утилиты десятилетиями отвечали на опечатку сухой строкой вроде «invalid field specification», и пользователь сам искал, где именно ошибся. Теперь под командой печатается сама команда, а под ней каретка, указывающая на неверный символ, и короткое объяснение. Реализовано это на библиотеке ariadne, той же, что используют некоторые парсеры на Rust.

Важная деталь для тех, кто пишет скрипты: многострочная диагностика включается только в интерактивном терминале. В пайпах и при перенаправлении вывода по умолчанию остаётся привычное однострочное сообщение, поэтому парсеры stderr не сломаются. Управляет этим переменная окружения UUTILS_DIAG со значениями always, never и auto. Попробовать без установки можно в браузерной песочнице проекта.

Скорость: «медленнее GNU теперь считается багом»

Команда прямо формулирует новую политику: «утилита, которая значительно медленнее GNU, теперь считается багом» (перевод редакции). В релизе это подкреплено PGO-сборками для Linux, macOS и Windows, которые, по замерам проекта, дают до 31% прироста. Отдельно названы cp, ускоренный на 32,93%, и join, который в одном из сценариев работает в 2,5 раза быстрее GNU-версии. Это замеры самого проекта на его наборах; на других данных разница будет иной.

Совместимость с GNU

Таблица в релизе сравнивает результаты на тестовом наборе GNU Coreutils: в 0.10.0 было 645 успешных и 28 неудачных тестов из 683, в 0.11.0 стало 653 успешных, 22 неудачных и 10 пропущенных из 685. Оставшиеся расхождения касаются редких флагов и краевых случаев, но именно они всплывают в старых скриптах, поэтому перед заменой системных утилит стоит прогнать свои сценарии.

Из исправлений безопасности названы TOCTOU-проблемы, то есть гонки между проверкой и использованием файла, в mv, cp, rm и chmod; также закрыты зависания и переполнения. Реализации kill и uptime доработаны для Windows.

Как попробовать

Проект распространяется под лицензией MIT и рассчитан на Linux, Windows, Redox и Fuchsia. Самый безопасный способ познакомиться: поставить uutils рядом с системными утилитами, а не вместо них. По README проекта, сборка из исходников выполняется через cargo, а в ряде дистрибутивов пакет называется uutils-coreutils или rust-coreutils и ставит бинарники в отдельный каталог. Точные имена пакетов зависят от дистрибутива, поэтому проверять их стоит в его репозитории.

Если ваши скрипты парсят stderr утилит, оставьте UUTILS_DIAG в значении auto: тогда в неинтерактивном режиме формат ошибок не изменится.

В релиз вошли 358 pull request от 26 новых участников; всего в проекте отметились более 1000 контрибьюторов. Редакция проверит, как изменится таблица совместимости в 0.12.

Источники: Релиз 0.11.0 на GitHub, Блог uutils: новая диагностика ошибок

Изображение на обложке: uutils

Если у вас где-то остался Proxmox VE 7 с доступным снаружи портом 8006, это тот случай, когда сначала закрывают доступ, а потом читают дальше. Атакующему достаточно сетевого доступа к API, чтобы войти под любым включённым пользователем без настроенной двухфакторной аутентификации, а к таким по умолчанию относится root@pam.

• Уязвим пакет libpve-access-control версий от 7.0-7 до 8.0.4 не включительно: это Proxmox VE 7.0–7.4 и начальный VE 8.0.
• Исправление вошло в libpve-access-control 8.0.4 ещё 20 июля 2023 года; ни один поддерживаемый релиз Proxmox VE сейчас не уязвим.
• Уязвимость требует доступа к API на порту 8006 напрямую или через reverse proxy и затрагивает только пользователей без 2FA.
• Proxmox VE 7 снят с поддержки в июле 2024 года, патча для ветки не будет; есть только временная правка одного файла.
• Единственное надёжное решение по advisory: обновиться до поддерживаемой версии Proxmox VE.

Кто затронут и что сделать в первую очередь

Проверка занимает одну команду на каждом узле:

Если версия от 7.0-7 включительно и ниже 8.0.4, узел уязвим. Дальше по цепочке: доступен ли порт 8006 из недоверенных сетей, есть ли пользователи без двухфакторной аутентификации, и что показывают журналы входов за последние дни. Proxmox указывает, что пользователи с любой настроенной 2FA не затронуты, поэтому включение второго фактора для всех учётных записей закрывает дыру даже без обновления пакета.

Advisory описывает уязвимый endpoint как POST /api2/json/access/ticket. Это тот самый вызов, через который веб-интерфейс и клиенты получают билет сессии. Проблемный параметр tfa-challenge задуман для второго шага двухфакторного входа, но старый код принимал его от кого угодно и при определённых условиях переходил к выдаче билета, не проверив пароль.

Почему исправление есть с 2023 года, а advisory вышел только сейчас

Уязвимый путь в коде был закрыт 20 июля 2023 года в libpve-access-control 8.0.4, и произошло это, по описанию Proxmox, как побочный эффект переработки механизма 2FA, а не как осознанное исправление уязвимости. Тогда проблему не квалифицировали как дыру в безопасности, поэтому исправление не переносили в ветку Proxmox VE 7. Ветка 7 завершила жизненный цикл в июле 2024 года, и обновлений для неё уже не выпускают.

Так уязвимость прожила больше двух лет в установках, которые никто не обновлял. Proxmox пишет, что узнала о проблеме сейчас, «через много независимых сообщений за последние два дня, которые также сообщают об эксплуатации в реальных атаках» (перевод редакции). Что именно делали атакующие после входа, в advisory не описано; независимого подтверждения масштаба атак на момент публикации нет.

Временная защита, если обновиться сегодня нельзя

Для тех, кто не может сразу мигрировать, Proxmox предлагает ручную правку: добавить вызов verify_ticket(...) в файл AccessControl.pm в указанном в advisory месте. После правки компания рекомендует проверить результат через grep: вхождений должно быть ровно три. Точный фрагмент кода и место вставки приведены в самом advisory; копировать его по памяти не стоит.

Ручная правка защищает только от этого конкретного обхода. Proxmox называет переход на поддерживаемый релиз «единственным долговременным исправлением»: в снятой с поддержки ветке остаются и другие незакрытые проблемы.

Что проверить в журналах

• Успешные входы под root@pam и другими пользователями без 2FA с незнакомых адресов в журнале pveproxy и в системном журнале аутентификации.
• Новые пользователи, токены API и изменения в правах доступа, которых никто не создавал.
• Неожиданные виртуальные машины, контейнеры, задачи резервного копирования и изменения в хранилищах.
• Исходящие соединения с узла к неизвестным адресам: после входа с правами root@pam атакующий получает полный контроль над гипервизором.

По нашей оценке, именно узлы «поставили и забыли» с открытым 8006 на публичном адресе и составляют группу риска.

Идентификатор CVE в advisory на момент публикации не указан. Редакция проверит, появится ли он, и есть ли у Proxmox дополнительные данные о характере атак.

Источник: Proxmox Security Advisory PSA-2026-00043-1 на форуме Proxmox

Изображение на обложке: Proxmox Server Solutions

Практическая проблема в том, что Bullseye — не экзотика. Это образы VPS у хостеров, базовые слои Docker-образов, которые никто не пересобирал два года, и «тот сервер, который просто работает». Задача на сентябрь простая: найти их все и решить, куда переезжать.

• LTS Debian 11 длился с 15 августа 2024 по 31 августа 2026 года для amd64, i386, arm64 и armhf; всего Bullseye прожил пять лет.
• С сентября Debian не выпускает для него обновления безопасности; часть пакетов могут поддерживать сторонние компании через платный Extended LTS.
• Debian 12 Bookworm получает LTS до 30 июня 2028 года (amd64, i386, arm64, armhf, ppc64el); Debian 13 Trixie вышел 9 августа 2025 года.
• Проверка одной командой: cat /etc/debian_version, ищите 11.x; в образах — grep по Dockerfile на bullseye.
• Путь обновления: 11, затем 12, затем 13, по одному мажорному шагу, с бэкапом перед каждым.

Чем LTS отличается от обычной поддержки

Стабильный выпуск Debian живёт три года под присмотром команд Security и Release. После этого дистрибутив передают в LTS — проект, который ведут волонтёры и заинтересованные компании, а не основные команды Debian; так описывает его вики проекта. LTS добавляет ещё два года обновлений безопасности, но уже не для всех архитектур и не для всех пакетов. Для Bullseye этот срок закончился.

Starting in September, Debian will not provide further security updates for Debian 11.

После LTS есть ещё одна ступень — Extended LTS. Это не часть Debian: несколько компаний за деньги продолжают чинить ограниченный набор пакетов для клиентов, которым переезд обходится дороже. Полного покрытия там нет, и рассчитывать на него как на бесплатную отсрочку не стоит.

Где искать Bullseye у себя

Три типичных места. Первое: старые VPS и физические серверы, поставленные в 2021–2023 годах. Второе: Docker-образы с базой debian:bullseye, python:3.x-bullseye или node:xx-bullseye, которые собраны один раз и с тех пор только тегаются заново. Третье: встроенные системы и Raspberry Pi, где Raspberry Pi OS на базе Bullseye стоял по умолчанию до конца 2023 года.

Куда обновляться

Прямого пути с 11 на 13 нет: Debian поддерживает обновление только на следующий мажорный выпуск. Значит, сначала bullseye на bookworm, потом при желании bookworm на trixie. Debian 12 Bookworm — безопасный промежуточный вариант: у него LTS до 30 июня 2028 года, а из архитектур в LTS заявлены amd64, i386, arm64, armhf и ppc64el. Для второго шага есть отдельные release notes Trixie. Для Docker-образов проще: сменить тег базового образа на bookworm или trixie и пересобрать.

• Сделайте снимок или бэкап, затем apt update && apt full-upgrade в текущей версии, чтобы уйти с чистой точки.
• Сторонние репозитории (Docker, PostgreSQL, nginx) перед обновлением отключите, как советуют release notes, а после перехода подключите их версии для bookworm.
• Замените bullseye на bookworm в /etc/apt/sources.list и файлах в sources.list.d; для Bookworm секция non-free-firmware добавляется отдельно.
• apt update && apt upgrade --without-new-pkgs, затем apt full-upgrade, перезагрузка, проверка сервисов.
• В CI запретите тег bullseye в базовых образах линтером Dockerfile, чтобы он не вернулся через полгода.

Любое зеркало Debian продолжит раздавать пакеты Bullseye, но новых обновлений безопасности от проекта в них не появится, так что «репозиторий работает» не означает «сервер защищён». При заказе нового VPS выбирайте образы Debian 12 или 13, если хостер ещё предлагает 11.

Что дальше

Следующий такой рубеж — 30 июня 2028 года, когда закончится LTS у Bookworm, то есть меньше чем через два года. Если вы переезжаете сейчас, разумно сразу планировать повтор процедуры к этой дате и держать обновление ОС в регулярном графике, а не как аварийную операцию раз в пять лет.

Источники: Debian 11 Long Term Support reaching end-of-life (Debian News), Debian LTS Wiki, Release notes Debian 12: upgrading

Изображение на обложке: Debian Project

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

• Окно инцидента около 33 часов: с 28 августа 20:57 UTC до 30 августа 06:10 UTC; активный перехват шёл двумя волнами общей длиной около 22 часов с перерывами, маршрут постоянно менялся.
• Поддельный маршрут /24 был специфичнее легитимного /16 Hetzner; все 368 peers RIPE RIS видели его хотя бы в один момент за окно инцидента; медианное число перенаправленных peers во время активной волны — 266 (около 72%).
• Через перехваченный трафик атакующий прошёл проверку Let's Encrypt и получил технически валидный сертификат для доменов Virtualizor.
• Вредоносное обновление подтверждено для Virtualizor; для других продуктов Softaculous таких пакетов не подтверждено. Индикатор компрометации: служба java-jre-update.service; выпущена версия 3.2.9.9 с инструментом устранения последствий и cleaning script, подпись пакетов обещана.
• Клиент обновлений не проверял подпись пакета; компания не может составить полный список затронутых серверов.

Как работает угон маршрута

BGP — протокол, по которому сети-операторы сообщают друг другу, через кого достижимы те или иные диапазоны IP-адресов. Доверие в нём во многом строится на честном слове: если кто-то объявляет, что диапазон живёт у него, соседи обычно верят. А если объявленный диапазон меньше (специфичнее) настоящего, маршрутизаторы предпочитают именно его. Так и произошло: Hetzner (AS24940) легитимно объявляет 162.55.0.0/16, атакующий объявил внутри него 162.55.80.0/24, и более точный маршрут победил.

В объявлении фигурировали AS62390 (NexonHost) и AS6204 (Zet.net), а в конце пути был оставлен Hetzner как видимый источник, чтобы подмена выглядела правдоподобно. По публичным данным RIPE RIS все 368 peers видели маршрут хотя бы в один момент за окно инцидента, а медианное число перенаправленных peers во время активной волны составляло 266. Перехват шёл двумя волнами общей продолжительностью около 22 часов с паузой примерно в 11 часов между ними, и для отдельных сетей он был прерывистым: маршрут то появлялся, то исчезал.

Почему сертификат оказался настоящим

Let's Encrypt подтверждает владение доменом, обращаясь к нему по HTTP. Если в этот момент трафик к домену идёт на сервер атакующего, проверка проходит, и сертификат выдаётся ему. Именно это и случилось: компания пишет, что злоумышленник получил «технически действительный TLS-сертификат для наших доменов» (перевод редакции). Браузеры и клиенты обновлений видели зелёный замок и доверяли ответам подменённого сервера.

The attacker obtained a technically valid TLS certificate for our domains.

Дальше сработало самое слабое звено: клиент обновлений Virtualizor доверял серверу по TLS и не проверял подпись самого пакета. Правильная схема, при которой пакет подписан офлайн-ключом разработчика и проверяется на сервере клиента, не спасла бы от перехвата трафика, но сделала бы подмену пакета невозможной. Компания обещала внедрить подпись для всех пакетов; срок и реализацию она не назвала.

Кого это задело

По словам компании, вредоносный пакет получила «горстка серверов», а не вся база пользователей Virtualizor. При этом Softaculous прямо признаёт: «Мы не можем составить окончательный список затронутых серверов» (перевод редакции), потому что подмена происходила на сетевом уровне и следов на стороне компании не оставила. Для Softaculous, Webuzo и других продуктов вредоносных пакетов не подтверждено, но те же адреса использовались и для их обновлений. Индикатор компрометации, который называет компания, — служба java-jre-update.service в системе. Softaculous выпустила Virtualizor 3.2.9.9 с инструментом устранения последствий и отдельный cleaning script, но просит при обнаружении индикатора не удалять службу самостоятельно, а связаться с поддержкой.

Что делать администратору

• Если у вас Virtualizor: обновитесь до 3.2.9.9, поищите службу java-jre-update.service и при её наличии свяжитесь с поддержкой Softaculous, как просит компания; проверять стоит, даже если обновления вы не запускали, автообновление могло сработать само.
• Сверьте по логам, не обращался ли сервер к 162.55.80.0/24 между 28 августа 20:57 UTC и 30 августа 06:10 UTC.
• Смените учётные данные панели, API-ключи и пароли, которые могли пройти через клиентскую зону или биллинг в этот период.
• Для собственных систем обновлений: подписывайте пакеты отдельным ключом и проверяйте подпись на клиенте; TLS защищает канал, но не содержимое.
• Если управляете своей сетью: включите RPKI Origin Validation и задайте свои ROA с точной длиной префикса. Оговорка: атакующий оставил Hetzner видимым origin, и без строгого maxLength в ROA такой маршрут ROV не отбросит.

Что дальше

Компания продолжает расследование; индикатор компрометации, версия 3.2.9.9 и cleaning script уже опубликованы. Открытых вопросов два: почему сети-транзиты пропустили объявление чужого /24 без проверки и когда и как будет внедрена обещанная подпись пакетов. Пока её нет, любой повторный угон маршрута снова превратится в атаку на цепочку поставок.

Источник: Security incident: BGP hijacking (Virtualizor)

Изображение на обложке: скриншот bgp.tools

Линкер склеивает скомпилированные объектные файлы в исполняемый файл, и на больших проектах это минуты ожидания при каждой пересборке. mold появился в 2021 году именно как ответ на это: по свежему бенчмарку автора он в 4,9 раза быстрее lld по медиане. Но проекты, которые собираются через сложные линкер-скрипты GNU ld, вроде ядра Linux, до сих пор были для него закрыты; 3.0 должна это изменить.

• mold переписывают на Rust; новая версия выйдет как mold 3.0, дата не названа.
• Цель: поддержка линкер-скриптов, чтобы mold собирал всё, что умеет GNU ld, включая ядра и прошивки.
• Текущий mold написан на C++20; по бенчмарку августа 2026 года он быстрее lld в 4,9 раза, а wild в 1,9 раза по медиане.
• Debug-сборка Chromium 145 на Threadripper 7980X: lld 16,64 с, wild 3,98 с, mold 1,65 с; TensorFlow 2.21: lld 50,73 с, mold 3,15 с.
• Текущий mold продолжает работать как замена ld и lld; включается флагом -fuse-ld=mold или через .cargo/config.toml.

Зачем линкеру скрипты

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

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

We are rewriting the mold linker in Rust. This will be mold 3.0.

Насколько mold быстрее сегодня

Автор обновил бенчмарки в README репозитория в августе: девять крупных программ, медиана трёх запусков после прогрева, два стенда — Threadripper 7980X с 64 ядрами и Apple M1 Ultra, у которого использовались 16 производительных ядер. Сравнивались lld, wild (ещё один линкер на Rust) и mold. Результаты на Threadripper выглядят так.

На Chromium 145 lld тратит 16,64 секунды, wild 3,98, mold 1,65. На TensorFlow 2.21 разрыв ещё больше: 50,73 секунды у lld против 3,15 у mold. На Apple M1 Ultra картина ровнее: debug-сборка Clang 21 линкуется за 2,96 секунды у mold, 4,40 у lld и 2,78 у wild, то есть в этом тесте конкурент на Rust слегка впереди, хотя на большинстве остальных задач M1-стенда mold быстрее. Артефакты бенчмарка опубликованы на Zenodo, их можно повторить.

Почему Rust, если и так быстро

В сообщении Уэямы причин не названо. Из README видно другое: текущий mold требует GCC 10.2 или Clang 16 и написан на C++20, а конкурент wild с самого начала на Rust и на части задач уже догоняет. Переписывание с добавлением линкер-скриптов означает во многом новую кодовую базу, и выбор языка для неё делается один раз. Всё остальное — предположения, и мы их не делаем.

Как включить mold сегодня

Для C и C++ с GCC или Clang достаточно флага компоновки -fuse-ld=mold. Для Rust README предлагает настройку в .cargo/config.toml:

• Проекты с собственными линкер-скриптами (ядра, прошивки, загрузчики) пока остаются на GNU ld; ждите mold 3.0.
• Если пользуетесь wild, сравните на своём проекте: на M1 Ultra он выигрывает лишь в части тестов, по общей медиане бенчмарка mold быстрее в 1,9 раза.
• mold распространяется под лицензией MIT через GitHub и пакеты дистрибутивов; наличие пакета в репозиториях Astra Linux и РЕД ОС проверяйте отдельно, в README они не перечислены.

Что дальше

mold используется в проде с 2021 года, и текущая C++-версия никуда не денется до выхода 3.0. Следить стоит за двумя сигналами: появится ли в репозитории ветка на Rust с первыми тестами линкер-скриптов и объявит ли какой-нибудь дистрибутив о планах сделать mold линкером по умолчанию. Второе и будет настоящей новостью.

Источники: Сообщение Руи Уэямы в X, Репозиторий mold с бенчмарками

Изображение на обложке: Tproger по данным README mold

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

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

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

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

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

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

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

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

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

Вот настройка certbot:

История софта

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

Первый стек и оптимизация

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

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

Из интересных моментов, где мне пришлось немного больше возиться, чем с остальными сервисами это nextcloud настройка:

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

Synapse требовал слишком много ресурсов, впустую расходовал оперативку домашнего ПК и усложнял конфиг Nginx. При этом реальной пользы для семьи он не приносил. Для критических алертов инфраструктуры и повседневного общения проще и эффективнее оказалось использовать Telegram. (плюс алертинг настроен именно через него) В итоге я полностью выпилил Synapse из стека, освободив ресурсы.

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

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

Так я пришел к декларативному подходу и Ansible. Теперь вся конфигурация описывается в виде плейбуков и ролей, отражающих конечное желаемое состояние серверов. Конфиденциальные данные перенесены в файл secrets.yml, а хрупкие конструкции автоматизированы через шаблоны Jinja2. Проект стал идемпотентным: если шаги уже выполнены, Ansible их просто пропускает.

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

Также благодаря Ansible я удобно реализовал переносимость проекта. Так как я решил не использовать тома docker, и вместо этого храню все в папках, чтобы перенести старые данные проекта нужно просто скопировать папку apps-data и положить ее в нужное место и все само заработает после повторного развертывания проекта. В Ansible выделяется отдельная пауза для этого.

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

Главная проблема при бэкапе работающих Docker-контейнеров — риск скопировать базу данных в «битом» или неконсистентном состоянии, если в момент создания архива в нее шла активная запись. Чтобы решить эту проблему, я задействовал механизм хуков в конфигурации Borgmatic.

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

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

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

Изначально для домашней страницы я написал кастомную минималистичную HTML-панель с Glassmorphism-дизайном. Выглядело это красиво, но добавлять новые сервисы вручную через постоянную правку исходного кода было крайне неудобно.

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

Заключение

Постарался подробно рассказать о структуре проекта и как я к этому пришел, очень много я не добавил, если пост зайдет, то я обязательно более подробно пройдусь по некоторым моментам: как я настраивал Matrix и на каком моменте я решил его убрать, как собирал локальный amnezia контейнер-клиент, что нового я добавил в релизе 1.4.0 и другое.

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Это моя первая статья на этом сайте и в то же время первый личный проект, которому я отдал так много времени (3 месяца). Буду рад вашему фидбеку в комментариях!

На конференции Open Source Summit India 2026 в Мумбаи Кроах-Хартман выступил с докладом «Rust and Linux: How the Rust Language is Going to Help Linux Succeed». В нём он признался, что поначалу относился к языку скептически и считал, что всё необходимое уже есть в C. Сейчас он считает иначе: Rust действительно делает программирование интереснее и безопаснее.

• Грег Кроах-Хартман назвал Rust постоянной частью Linux, а не временным экспериментом.
• По его оценке, около 80% уязвимостей ядра за последние 25 лет можно было бы поймать на этапе компиляции Rust.
• Linux получает около 13 CVE в день и почти 9 изменений в час на протяжении десяти лет и более.
• Binder — ключевой механизм IPC Android — уже имеет параллельную реализацию на Rust, а C-версия скоро уйдёт.
• Git и ряд других крупных проектов также движутся в сторону Rust.

От скептицизма к поддержке

Кроах-Хартман рассказал, что несколько лет назад друг советовал ему попробовать Rust, но он отмахнулся: C казался достаточным. Со временем он изменил мнение. «Он был прав. Я должен был сделать это тогда. Rust на самом деле весёлый. Он заставляет программирование быть весёлым», — сказал мейнтейнер.

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

Масштаб проблемы

Linux развивается с огромной скоростью. Кроах-Хартман привёл цифры: ядро набирает примерно девять изменений в час уже больше десяти лет, а количество публично раскрываемых уязвимостей держится на уровне около 13 CVE в день. Большая часть из них — не сложные атаки, а простые ошибки в C-коде.

Я видел каждую CVE ядра за последние 25 лет. Думаю, 80% исчезли бы просто потому, что Rust поймал бы их.

Что уже меняется в ядре

Rust постепенно становится обязательным выбором для отдельных подсистем. Кроах-Хартман отметил, что новые драйверы некоторых подсистем будут приниматься только на Rust. Яркий пример — Binder, межпроцессный механизм Android, от которого зависят миллиарды устройств. В ядре уже существуют параллельные реализации Binder на C и Rust, и C-версия «скоро исчезнет».

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

Контекст:
Binder — это механизм межпроцессного взаимодействия (IPC) в Android. Он позволяет приложениям и системным сервисам безопасно обмениваться данными. Переписывание Binder на Rust напрямую влияет на безопасность и стабильность почти всех Android-устройств.

Выводы

Позиция Кроах-Хартмана — ещё один сигнал того, что Rust перешёл из разряда «перспективного языка» в разряд инфраструктурного инструмента. Если оценка в 80% CVE верна, массовый переход на Rust в ядре может существенно снизить количество исправлений безопасности и освободить время мейнтейнеров для сложных логических задач.

Источник: Slashdot.

Рувеб — Windows в тарифе и бюджетный старт.

UFO.Hosting — своя панель VMmanager и широкий выбор ОС.

Timeweb Cloud — масштабируемое облако с почасовой оплатой.

PSB Hosting — зарубежные локации и безлимитный трафик.

Selectel — корпоративное облако с 152-ФЗ и экосистемой сервисов.

RUVDS — быстрый старт, низкая цена входа и тест на 3 дня.

Кому нужен кроссплатформенный VPS

Разработчики и системные администраторы часто работают сразу с двумя экосистемами: Linux доминирует в вебе, DevOps и контейнерах, а Windows остаётся стандартом для корпоративного ПО, 1С, MS SQL и тестирования десктопных приложений. Кроссплатформенный VPS избавляет от необходимости заводить отдельные аккаунты у разных провайдеров: Linux- и Windows-машины управляются из одной панели, а переключение между ОС занимает минуты.

1. Рувеб — Windows в тарифе

Российский провайдер с собственными серверами в Москве и Амстердаме. Позиционируется как недорогой хостинг с прозрачными тарифами: минимальный Linux-VPS стоит меньше 400 ₽ в месяц, а лицензия Microsoft для Windows-шаблонов уже включена в стоимость.

Кейсы клиентов и кому подойдёт

По данным компании, типичный сценарий — совместное использование Linux и Windows на одном аккаунте: Linux-VPS работает как хост для сайта и Telegram-ботов, а Windows-машина используется для удалённого доступа и запуска ПО, которого нет под Linux. Также провайдер подходит разработчикам, которым нужен недорогой Ubuntu-сервер для production и отдельный Windows-VPS для тестирования совместимости.

Что можно развернуть

• Linux: AlmaLinux 8/9/10, CentOS Stream 9, CentOS 9 VMBitrix, Debian 11/12/13, Ubuntu 22.04/24.04, FreeBSD 14, Mikrotik CHR.
• Windows: Windows Server 2016/2019/2022, Windows 11.
• Панели управления: ISPmanager для AlmaLinux, Debian, Ubuntu; FastPanel для AlmaLinux 8 и Debian 11 (ISPmanager оплачивается отдельно).
• Доступ: root по SSH для Linux, RDP из коробки для Windows, веб-консоль для аварийного доступа.

Инфраструктура и экосистема

Серверы размещены в дата-центрах DataHouse в Москве и в Амстердаме, оба соответствуют уровню Tier 3. Виртуализация — KVM, диски — SSD и NVMe в зависимости от линейки. Провайдер работает по 152-ФЗ, зарегистрирован в реестре хостинг-провайдеров и предоставляет закрывающие документы для юрлиц.

Отзывы и репутация

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

Поддержка и каналы связи

Техническая поддержка работает через систему тикетов и онлайн-чат на сайте круглосуточно. Доступен бесплатный звонок по России по номеру 8(800) 505-93-34. Среднее время первого ответа — 10–30 минут. Для корпоративных клиентов и крупных проектов возможно закрепление персонального менеджера.

Тарифы, ограничения и условия

• Linux: KVMv-NANO — 1 CPU, 0,5 ГБ RAM, 12 ГБ SSD — 393 ₽/мес; KVMv-LIGHT — 2 CPU, 4 ГБ RAM, 80 ГБ SSD — 1672 ₽/мес.
• Windows: лицензия Microsoft входит в стоимость; Windows 11 доступна на тарифах от 1422 ₽/мес при оплате за год.
• Скидки за предоплату: 3 месяца — 5%, 6 месяцев — 10%, год — 15%, два года — 25%.
• Тестовый период: 6 дней для Linux, 3 дня для Windows; активируется после пополнения баланса на 300 ₽.
• Трафик: до 50 000 ГБ/мес на полной скорости по Fair Use Policy, далее возможно временное снижение скорости.
• Бэкапы: вручную в панели, 1 ₽ за 1 ГБ; снапшоты бесплатны, но требуют аренду места.
• Ограничения: на тарифах NANO, MICRO и посуточных по умолчанию закрыты исходящие порты 25 и 465.

2. UFO.Hosting — своя панель VMmanager

Российский провайдер с собственной панелью управления на базе VMmanager. Отличается большим списком шаблонов ОС — от AlmaLinux и Astra Linux до Windows 10/11 и FreeBSD ZFS. Подходит тем, кому важна гибкость выбора операционной системы.

Кейсы клиентов и кому подойдёт

Провайдер описывает типичные сценарии: бухгалтерская фирма разворачивает 1С:Предприятие на Windows Server 2022 с RDP для нескольких сотрудников; разработчик держит production на Linux, а для тестирования Windows-сборок поднимает отдельный VPS. Также UFO.Hosting удобен для проектов, где нужны нестандартные дистрибутивы или десктопная Windows.

Что можно развернуть

• Linux: AlmaLinux 8/9/10, CentOS 7/8 Stream/9 Stream/10 Stream, Oracle Linux 8/9, Rocky Linux 8/9/10, Ubuntu 20.04/22.04/24.04, Debian 11/12/13, FreeBSD 13/14 ZFS, Astra Linux CE.
• Windows: Windows Server 2016/2019/2022 (включая Datacenter, Core, RUS, GPT), Windows 10/11.
• Панели: Vesta, Hestia, CyberPanel, Virtualmin, ISPmanager; первый месяц ISPmanager бесплатно, далее 400 ₽/мес.
• Доступ: SSH с ключами для Linux, RDP из коробки для Windows, VNC-консоль в панели, мультипользовательский RDP на Windows Server.

Инфраструктура и экосистема

Оборудование расположено в московском дата-центре IXcellerate уровня Tier 3. Виртуализация — KVM, диски — NVMe. В одном личном кабинете доступны VPS/VDS, выделенные серверы, домены, SSL-сертификаты и DNS-хостинг. Провайдер зарегистрирован в реестре хостинг-провайдеров, работает по 152-ФЗ, но сертификации ФСТЭК не имеет.

Отзывы и репутация

Публичные агрегированные рейтинги в предоставленных источниках не указаны. Компания позиционирует себя как провайдер с активацией серверов до 15 минут и помощью в миграции сайтов.

Поддержка и каналы связи

Техническая поддержка работает круглосуточно через онлайн-чат на сайте и тикет-систему в биллинге. Телефонная поддержка доступна в будни с 9:00 до 18:00. Поддержка в Telegram не осуществляется. Есть база знаний; выделенный менеджер для B2B планируется.

Тарифы, ограничения и условия

• Linux: тариф Naos — 1 CPU, 1 ГБ RAM, 25 ГБ NVMe — от 577 ₽/мес при оплате за 3 месяца; Brachium — 2 CPU, 4 ГБ RAM, 60 ГБ NVMe — от 977 ₽/мес.
• Windows: доступна для установки от тарифа Brachium, стоимость — от 1025 ₽/мес.
• Лицензия Windows: не входит в стоимость, ОС предоставляется в Trial-версии; для легального использования лицензию приобретают самостоятельно.
• Скидки за предоплату: 3 месяца — 5%, 6 месяцев — 10%, год — 15%.
• Тестовый период: 3 дня на любой VPS-тариф; требуется верификация аккаунта (email, телефон, KYC).
• Трафик: 32 ТБ/мес, после превышения скорость ограничивается до 100 Мбит/с; на выделенных серверах трафик безлимитный.
• Бэкапы: ежедневные — 525 ₽/мес, еженедельные — 262,5 ₽/мес; восстановление через панель или поддержку.
• Ограничения: VPN запрещён, так как он заменяет сетевые настройки; исходящий SMTP-порт 25 закрыт по умолчанию.

3. Timeweb Cloud — масштабируемое облако

Крупнейший российский облачный провайдер с собственной инфраструктурой VAPI Stack. Подходит для проектов, которым нужно масштабирование ресурсов, API, Terraform и возможность загружать собственные образы.

Кейсы клиентов и кому подойдёт

Timeweb Cloud ориентирован на разработчиков, SaaS-стартапы и компании, которым нужна гибкая инфраструктура. Почасовая оплата позволяет запускать тестовые окружения на короткий срок, а API и Terraform упрощают автоматизацию. Провайдер также подходит для размещения сайтов, интернет-магазинов, баз данных и CI/CD-конвейеров.

Что можно развернуть

• Linux: Ubuntu, Debian, CentOS, Astra Linux CE, собственные образы.
• Windows: Windows Server, готовые образы в маркетплейсе.
• Инструменты управления: панель Timeweb Cloud, API, Terraform, CLI, Cloud-init.
• Дополнительно: бэкапы, снапшоты, образы дисков, DDoS-защита, балансировщики, Kubernetes, managed-базы данных.

Инфраструктура и экосистема

Серверы размещены в дата-центрах Tier 3 в России (Москва, Санкт-Петербург, Новосибирск), Казахстане (Алматы), Германии (Франкфурт) и Нидерландах (Амстердам). Виртуализация — KVM, диски — NVMe. Дата-центры сертифицированы по ISO и PCI DSS, инфраструктура соответствует 152-ФЗ. Провайдер заявляет о 150 000+ клиентах и статусе лауреата Премии Рунета.

Отзывы и репутация

На страницах услуг публикуются недавние отзывы пользователей: клиенты отмечают скорость работы серверов, удобство панели и оперативность поддержки. Провайдер заявляет о доступности серверов на уровне 99,98% по SLA с финансовыми гарантиями.

Поддержка и каналы связи

Поддержка работает 24/7 через чат, мессенджеры, социальные сети, тикеты и телефон. Провайдер бесплатно помогает с миграцией данных с других площадок и предлагает услуги администрирования.

Тарифы, ограничения и условия

• Linux: VPS с предустановленной Ubuntu — от 169 ₽/мес при оплате за год или от 477 ₽/мес помесячно; типовой тариф Cloud MSK 40 — 2 CPU, 2 ГБ RAM, 40 ГБ NVMe — 882 ₽/мес.
• Windows: Windows Server доступен в конфигураторе; точные цены уточняйте на сайте.
• Лицензия Windows: условия лицензирования Microsoft уточняйте в поддержке.
• Оплата: почасовой биллинг, минимальный платёж — 50 ₽.
• Тестовый период: возможность бесплатного тестирования рассматривается индивидуально.
• Трафик: безлимитный на всех тарифах.
• Бэкапы: 6 ₽/ГБ/мес; образы — 3 ₽/ГБ/мес; снапшоты бесплатны, один на сервер, хранятся 7 дней.
• Ограничения: диск можно увеличить, но не уменьшить; для уменьшения — обращение в поддержку.

4. PSB Hosting — зарубежные локации

Международный хостинг-провайдер с фокусом на Европу и США. Подходит для проектов, где важна география серверов, безлимитный трафик и анонимная оплата криптовалютой.

Кейсы клиентов и кому подойдёт

PSB Hosting ориентирован на пользователей, которым нужны серверы за пределами России: международные SaaS-платформы, сервисы с аудиторией в Европе и США, VPN-инфраструктура и проекты, где критична скорость отклика для зарубежных пользователей. Клиенты сами выбирают конфигурацию под свои задачи.

Что можно развернуть

• Linux: Ubuntu, Debian, CentOS, AlmaLinux, Rocky Linux, Oracle Linux, FreeBSD, Astra Linux.
• Windows: Windows Server 2016/2019/2022, Windows 10/11.
• Предустановленное ПО: Docker, Django, WordPress, OpenVPN, WireGuard, FastPanel, HestiaCP.
• Доступ: root по SSH для Linux, RDP из коробки для Windows, веб-консоль в панели.

Инфраструктура и экосистема

Серверы расположены в дата-центрах класса Tier 3+ и 4 в Амстердаме, Франкфурте, Хельсинки и Нью-Йорке. Платформа построена на процессорах AMD и Intel с DDR5-памятью и NVMe-дисками; для высоконагруженных задач есть линейка HI-CPU VPS на базе AMD Ryzen 7950X. Провайдер предоставляет подсеть /64 IPv6 на всех тарифах и полноценную панель управления DNS-записями доменов.

Отзывы и репутация

На сайте размещены ссылки на отзывы на площадках OtzyvMarketing.ru (4,8), In-Scale.ru (5,0), Aff1.ru (5,0) и 101Poisk.ru (4,89). Публичных агрегированных рейтингов на независимых площадках в предоставленных источниках не указано.

Поддержка и каналы связи

Техническая поддержка работает круглосуточно через тикеты и Telegram. Время ответа зависит от загрузки. Для B2B-клиентов доступен персональный менеджер. Документация включает API и базу знаний.

Тарифы, ограничения и условия

• Цены: конкретные тарифы в предоставленных источниках не указаны; стоимость не зависит от выбора ОС. Уточняйте на сайте.
• Лицензия Windows: покупается отдельно.
• Оплата: почасовая; принимаются карты России, СНГ и ЕС, Qiwi, криптовалюта (Bitcoin, Ethereum, Litecoin, USDT).
• Тестовый период: не предоставляется.
• Трафик: безлимитный на всех тарифах; порт до 10 Гбит/с, на VPS выделяется до 300 Мбит/с.
• Бэкапы: платно; неограниченное количество резервных копий; восстановление через панель.
• Ограничения: запрещён неправомерный контент; порт 25 открывается через службу поддержки; мультипользовательский RDP — 1 сессия.

5. Selectel — корпоративное облако с 152-ФЗ

Крупный российский облачный провайдер для команд, которым важны не только Linux- и Windows-серверы, но и инфраструктура вокруг них: сети, бэкапы, мониторинг, хранение данных и требования к персональным данным. Selectel подходит для проектов, где VPS быстро перерастает в полноценную облачную инфраструктуру.

Кейсы клиентов и кому подойдёт

Selectel стоит рассматривать компаниям, которые держат production и staging в одном облаке, работают с персональными данными или хотят запускать Linux- и Windows-серверы рядом с управляемыми сервисами. Это вариант для SaaS, внутренних корпоративных систем, CI/CD-инфраструктуры и проектов, которым нужны предсказуемые российские дата-центры.

Что можно развернуть

• Linux: Ubuntu, Debian, Fedora CoreOS, CentOS, SelectOS, Astra Linux, Alma Linux, Rocky Linux, Fedora, Oracle Linux.
• Windows: образы Windows доступны в каталоге облачных серверов; также можно использовать собственные образы, включая лицензированное ПО Microsoft, приобретённое у другого провайдера.
• Инфраструктура: виртуальные машины, сетевые диски, бэкапы, балансировщики, S3, базы данных, Kubernetes и инструменты мониторинга.
• Доступ: управление через панель Selectel; для автоматизации доступны облачные API и типовые сценарии DevOps-инфраструктуры.

Инфраструктура и экосистема

На официальной странице облачных серверов Selectel подчёркивает моментальное масштабирование, соответствие 152-ФЗ и размещение виртуальных выделенных серверов в дата-центрах уровня Tier III. Вокруг серверов есть отдельные сервисы хранения, резервного копирования, сетевой связности и информационной безопасности.

Отзывы и репутация

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

Поддержка и каналы связи

На сайте указаны канал продаж sales@selectel.ru и телефон 8 800 555-06-75. Для действующих клиентов поддержка и управление услугами доступны через личный кабинет Selectel.

Тарифы, ограничения и условия

• Цены: рассчитываются в конфигураторе облачных серверов и зависят от vCPU, RAM, дисков, региона и дополнительных сервисов.
• Лицензия Windows: условия зависят от выбранного образа и лицензии; можно использовать собственные лицензированные образы Microsoft.
• Оплата: облачная модель с гибкой конфигурацией ресурсов; итоговую стоимость нужно проверять в панели перед запуском сервера.
• Трафик: условия зависят от сетевой конфигурации и выбранных сервисов.
• Бэкапы: доступны отдельные сервисы резервного копирования и сетевые диски; стоимость зависит от объёма хранения.
• Ограничения: это более инфраструктурный вариант, чем простой VPS-хостинг, поэтому для маленьких проектов конфигуратор может быть избыточен.

6. RUVDS — быстрый старт и тест на 3 дня

Российский VPS-провайдер для быстрого запуска виртуального сервера без длинной настройки инфраструктуры. RUVDS подойдёт, если нужно недорого проверить идею, поднять Linux-сервер для небольшого сервиса или взять Windows-VPS под RDP и прикладное ПО.

Кейсы клиентов и кому подойдёт

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

Что можно развернуть

• Linux: VPS-линейки для веб-сервисов, ботов, тестовых стендов и небольших backend-проектов.
• Windows: отдельная линейка VPS Windows для задач с RDP, корпоративным ПО и Windows-приложениями.
• Производительность: доступны варианты с быстрыми NVMe-дисками.
• Доступ: стандартные сценарии SSH для Linux и RDP для Windows; управление сервером через личный кабинет провайдера.

Инфраструктура и экосистема

На официальной странице RUVDS указывает 22 дата-центра уровня Tier III в 9 странах, отдельные линейки для Windows и быстрых NVMe-серверов, а также помощь с аттестацией по ФСТЭК для инфраструктурных задач с повышенными требованиями.

Отзывы и репутация

В подборку RUVDS добавлен как массовый VPS-провайдер с низкой стартовой ценой и тестовым периодом. Независимые пользовательские рейтинги в рамках этой правки отдельно не сравнивались.

Поддержка и каналы связи

На сайте указан бесплатный телефон 8 (800) 775-97-42 и круглосуточный формат связи. Для рабочих инцидентов условия реакции стоит проверять в SLA и правилах выбранного тарифа.

Тарифы, ограничения и условия

• Цены: VPS Start — от 139 ₽/мес; итог зависит от выбранной линейки и конфигурации.
• Тестовый период: новым пользователям доступен бесплатный тест на 3 дня для сервера стоимостью до 3000 ₽.
• Лицензия Windows: условия зависят от выбранной Windows-линейки и конфигурации.
• Трафик и диски: параметры зависят от тарифа; для задач с дисковой нагрузкой есть NVMe-линейка.
• Бэкапы: условия резервного копирования нужно проверять в панели и описании конкретного тарифа.
• Ограничения: минимальная цена полезна для старта, но производительные Windows-сценарии потребуют более дорогой конфигурации.

Сравнение по ключевым критериям

Ниже — текстовое сравнение по ценам, лицензиям, смене ОС и условиям для всех шести участников.

Цены и лицензии

Минимальный Linux-VPS: Рувеб — 393 ₽/мес; UFO.Hosting — от 577 ₽/мес; Timeweb Cloud — от 169 ₽/мес при оплате за год; PSB Hosting — уточняется на сайте; Selectel — рассчитывается в конфигураторе облачных серверов; RUVDS — VPS Start от 139 ₽/мес. Windows-VPS: Рувеб — от 1422 ₽/мес с включённой лицензией; UFO.Hosting — от 1025 ₽/мес, но лицензию нужно покупать отдельно; Timeweb Cloud, PSB Hosting, Selectel и RUVDS — по конфигуратору или Windows-линейке.

Лицензия Windows: у Рувеб она включена в стоимость тарифа. У UFO.Hosting ОС предоставляется в Trial-версии, у PSB Hosting — покупается отдельно, у Timeweb Cloud условия уточняются в поддержке. У Selectel можно использовать Windows-образы и собственные лицензированные образы Microsoft; у RUVDS условия зависят от выбранной Windows-линейки.

Смена ОС и управление

Смена ОС: у Рувеб и Timeweb Cloud доступна переустановка с потерей данных; у UFO.Hosting — через панель за ~20 минут; у PSB Hosting — через панель с пересозданием сервера; у Selectel и RUVDS сценарий зависит от выбранного образа и обычно решается созданием или пересозданием сервера. Панель: Рувеб использует сторонний биллинг, UFO.Hosting — собственный VMmanager, Timeweb Cloud, PSB Hosting, Selectel и RUVDS — собственные панели или конфигураторы.

Трафик, бэкапы и поддержка

Трафик: Timeweb Cloud и PSB Hosting предлагают безлимитный трафик; Рувеб — до 50 ТБ/мес по Fair Use Policy; UFO.Hosting — 32 ТБ/мес с ограничением скорости после превышения; Selectel и RUVDS зависят от выбранной конфигурации и сетевых условий тарифа. Бэкапы: у всех провайдеров платные или тарифицируются по объёму; Timeweb Cloud и PSB Hosting также предлагают снапшоты, Selectel выделяет резервное копирование в отдельный сервис. Поддержка: у всех участников есть официальные каналы связи, но формат SLA и скорость реакции лучше проверять перед заказом.

Вывод

Для бюджетного старта с готовой Windows-лицензией подойдёт Рувеб: минимальный Linux-VPS дешевле 400 ₽, а Windows 11 уже включена в тариф. Если важен широкий выбор ОС и собственная панель VMmanager — смотрите на UFO.Hosting, но учитывайте, что лицензию Microsoft придётся покупать отдельно. RUVDS стоит рассмотреть, когда нужен самый быстрый вход, тест на 3 дня и отдельная Windows-линейка.

Timeweb Cloud выигрывает у масштабируемости, API и почасовой оплаты: это вариант для растущих проектов и команд с DevOps-практиками. Selectel сильнее в корпоративных сценариях, где нужны 152-ФЗ, Tier III, бэкапы и смежные облачные сервисы. PSB Hosting стоит рассмотреть, если нужны зарубежные локации, безлимитный трафик и оплата криптовалютой — но конкретные тарифы и условия лицензирования лучше уточнить перед заказом.

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

Макхост — низкий порог входа и российские документы.

UFO.Hosting — широкая линейка VPS и выделенных серверов.

SmartApe — гибкие конфигурации и быстрый старт.

PSB Hosting — зарубежные локации и безлимитный трафик.

FirstVDS — бюджетный массовый вариант для простых проектов.

Hetzner Cloud — иностранная облачная альтернатива с ограничениями для РФ.

Как мы выбирали

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

1. Макхост — низкий порог входа

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

Кейсы клиентов и кому подойдёт

• Сайты-визитки и лендинги на минимальной конфигурации с 1 CPU и 1 GB RAM.
• Интернет-магазины на популярных CMS и телеграм-боты: по данным провайдера, часто выбирают KVM-2 с 2 GB RAM.
• 1С:Предприятие и корпоративные сайты с модулем синхронизации: рекомендуют конфигурации от 4 GB RAM.
• VPN-серверы личного использования и небольшие тестовые окружения.

Что можно развернуть

• Операционные системы: Ubuntu, Debian, AlmaLinux, CentOS Stream.
• Панели управления: ISPmanager, FastPanel; на тарифах VPS первый месяц ISPmanager 6 в подарок.
• Готовые образы и стеки: WordPress, 1С, Docker, LAMP, почта, DNS, SSL.
• SSH и root-доступ для произвольной настройки окружения.

Инфраструктура и экосистема

• Виртуализация KVM с гарантированными ресурсами.
• Дата-центры: DataPro в Москве и площадка в Амстердаме.
• Диски: NVMe и DDR4 на всех VPS-тарифах, кроме самого дешёвого KVM-NEW с SSD.
• Сеть: порт до 1 Гбит/с, безлимитный трафик на всех тарифах, кроме KVM-NEW (2 ТБ).
• Соответствие 152-ФЗ, реестр хостинг-провайдеров; закрывающие документы для юрлиц.

Отзывы и репутация

На странице VPS у Макхоста указана средняя оценка 5 на основе 13 оценок. Пользователи отмечают круглосуточную поддержку и быструю помощь в сложных ситуациях; провайдер позиционирует себя как лидер авторитетных рейтингов.

Поддержка и каналы связи

• Каналы: тикет-система и онлайн-чат на сайте.
• Среднее время первого ответа: 10–20 минут.
• Для корпоративных клиентов и крупных проектов возможен персональный менеджер.
• База знаний, блог со статьями и платное администрирование VPS при необходимости.

Тарифы, ограничения и условия

• Стартовый KVM-NEW: 1 CPU, 0.6 GB RAM, 5 GB SSD, 2 ТБ трафика — 143 ₽/мес.
• Популярный KVM-2: 1 CPU, 2 GB RAM, 30–60 GB NVMe — от 693 ₽/мес при оплате за год.
• Топовый VPS KVM-12: 6 CPU, 12 GB RAM, 180–360 GB NVMe — от 3465 ₽/мес при оплате за год.
• Скидки за предоплату: 3%, 6%, 12%, 24% за 3, 6, 12, 24 месяца соответственно.
• Тестовый период: 3 дня с активационным платежом 290 ₽, который остаётся на балансе.
• Апгрейд без пересоздания сервера, обычно с кратковременной перезагрузкой.

Официальный сайт: Макхост

2. UFO.Hosting — широкая линейка

UFO.Hosting предлагает виртуальные и выделенные серверы в России с акцентом на широкую линейку конфигураций и NVMe-диски. Подходит тем, кто рассматривает и VPS, и bare-metal в одном кабинете.

Кейсы клиентов и кому подойдёт

• Небольшие проекты и сайты-визитки на тарифе Naos с 1 CPU и 1 GB RAM.
• Интернет-магазины, корпоративные сайты и телеграм-боты с вебхуками на Brachium с 2 CPU и 4 GB RAM.
• 1С:Предприятие и нагруженные CMS: рекомендуют от 4 CPU и 8 GB RAM.
• Проекты, которым нужны выделенные серверы без соседей.

Что можно развернуть

• Операционные системы: различные дистрибутивы Linux и Windows (ISO-образы доступны на старших тарифах).
• Панели управления: ISPmanager, Vesta, Hestia, Cyberpanel, Virtualmin.
• Готовые шаблоны ПО в зависимости от выбранной ОС.
• Дополнительные IP-адреса, аренда подсетей, настройка BGP.

Инфраструктура и экосистема

• Виртуализация KVM; процессоры Intel Xeon E5-2697A v4.
• Дата-центр IXcellerate в Москве, сертифицированный Tier III+.
• NVMe-диски в RAID10 на VPS/VDS; Enterprise SSD на выделенных серверах.
• Сеть: порт до 10 Гбит/с на ноде, 32 ТБ трафика в месяц на VPS (далее ограничение 100 Мбит/с); на выделенных серверах — без ограничений.
• Работа по 152-ФЗ, реестр хостинг-провайдеров; документы для юрлиц через ЭДО.

Отзывы и репутация

Публичные отзывы и агрегированные рейтинги в предоставленных материалах не указаны. Провайдер акцентирует внимание на Tier III+ инфраструктуре и запуске серверов до 15 минут.

Поддержка и каналы связи

• Каналы: онлайн-чат на сайте и тикет-система в биллинге 24/7; телефон в будни с 9:00 до 18:00.
• Среднее время первого ответа: не более 30 минут в любое время суток.
• База знаний в блоге ufo.hosting/blog.
• Продажи и поддержка готовы консультировать B2B-клиентов.

Тарифы, ограничения и условия

• Минимальный VPS Naos: 1 vCPU, 1 GB RAM, 25 GB NVMe — 605.85 ₽/мес.
• Популярный Brachium: 2 vCPU, 4 GB RAM, 60 GB NVMe — 1025.85 ₽/мес.
• Топовый VPS Intercrus: 32 vCPU, 64 GB RAM, 510 GB NVMe — 16 800 ₽/мес.
• Выделенный сервер Восток-1: 2x E5-2697v4, 384 GB RAM ECC, 4x960 GB Enterprise SSD — 43 050 ₽/мес.
• Скидки за предоплату: 5%, 10%, 15% за 3, 6, 12 месяцев.
• Тестовый период: 3 дня на VPS после полной верификации аккаунта; на выделенных серверах — обсуждается персонально.
• Апгрейд тарифа из личного кабинета без пересоздания сервера, вступает в силу после перезагрузки.

Официальный сайт: UFO.Hosting

3. SmartApe — гибкие конфигурации

SmartApe делает ставку на гибкость: кроме фиксированных линеек есть полностью конфигурируемые тарифы, где можно менять ресурсы под задачу. Провайдер использует процессоры Intel Xeon Platinum, AMD EPYC и AMD Ryzen.

Кейсы клиентов и кому подойдёт

• Лендинги и сайты-визитки на минимальных конфигурациях с 2 CPU и 1 GB RAM.
• WordPress, корпоративные сайты и интернет-магазины до 10 тыс. посетителей в сутки.
• Bitrix, CRM, ERP и 1С: рекомендуют от 4 CPU и 8 GB RAM.
• Нагруженные API, базы данных и высоконагруженные проекты на конфигурируемых тарифах.

Что можно развернуть

• Linux- и Windows-серверы, панели управления ISPmanager, Hestia и другие.
• Готовые стеки под Docker, базы данных, веб-приложения.
• Автоматическое развёртывание сервера за 1–2 минуты; бесплатная помощь с переносом сайтов при использовании ISPmanager или Hestia.

Инфраструктура и экосистема

• Виртуализация KVM с изоляцией и гарантированными ресурсами.
• Процессоры: Intel Xeon E5-2696 v4, Intel Xeon Platinum, AMD EPYC, AMD Ryzen 9.
• Диски: серверные NVMe SSD или HDD + SSD-кэш, RAID-10.
• Дата-центры: DataPro Moscow I, II, III в России; Host-Telecom в Чехии; Partner Group в Израиле; уровни Tier III и Tier IV.
• Сеть: безлимитный трафик на всех VPS, канал до 200 Мбит/с.
• SLA 99.9%, заявленный фактический uptime 99.982%.
• Соблюдение 152-ФЗ, договор на обработку персональных данных.

Отзывы и репутация

Публичные отзывы и рейтинги в предоставленных материалах не указаны. Провайдер акцентирует внимание на показателях NVMe-хранилища: до 680 тыс. IOPS на чтение и до 185 тыс. IOPS на запись.

Поддержка и каналы связи

• Каналы: тикеты в личном кабинете, онлайн-чат, телефон.
• Среднее время первого ответа: 10–15 минут.
• Раздел помощи на smartape.ru/help.
• Персональный менеджер обсуждается индивидуально для B2B.

Тарифы, ограничения и условия

• Минимальные тарифы: HDD S1 (2 CPU, 1 GB RAM, 50 GB HDD+SSD) — 345 ₽/мес; NVMe X1 (2 CPU, 1 GB RAM, 10 GB NVMe) — 495 ₽/мес; Turbo R1 AMD Ryzen (2 CPU, 1 GB RAM, 20 GB NVMe) — 645 ₽/мес.
• Топовый VPS NVMe X64: 24 CPU, 64 GB RAM, 640 GB NVMe — 11 870 ₽/мес.
• Скидки за предоплату: 5%, 15%, 30%, 50% за 3, 6, 12, 24 месяца.
• Тестовый период: 10 дней без привязки банковской карты, нужно подтверждение номера телефона.
• Резервное копирование со стороны провайдера не предусмотрено; можно настроить самостоятельно или заказать FTP-хранилище.
• Апгрейд фиксированных тарифов — по запросу в поддержку с перезагрузкой; конфигурируемые тарифы меняются в личном кабинете.

Официальный сайт: SmartApe

4. PSB Hosting — зарубежные локации

PSB Hosting ориентирован на международные дата-центры и широкий выбор операционных систем. Подходит проектам, которым важны европейские и американские площадки, безлимитный трафик и подсеть IPv6 /64 на всех тарифах.

Кейсы клиентов и кому подойдёт

• Сайты и веб-приложения, ориентированные на аудиторию в Европе и США.
• VPN-серверы, прокси и сетевые сервисы благодаря безлимитному трафику и IPv6 /64.
• Проекты на Node.js, Django, Docker, WordPress и других стеках.
• Разработчики, которым нужна нестандартная ОС или загрузка собственного ISO.

Что можно развернуть

• Операционные системы: Ubuntu, Debian, CentOS, Windows, Astra Linux, AlmaLinux, Rocky Linux, FreeBSD, Oracle Linux; можно загрузить свою ОС через ISO.
• Предустановленное ПО: Docker, LAMP, Keitaro, FastPanel, Node.js, Portainer, WordPress, Django, Outline, OpenVPN, Wireguard, HestiaCP, VestaCP, Bitrix.
• Полноценная панель управления DNS-записями доменов.

Инфраструктура и экосистема

• Виртуализация KVM, NVMe-диски.
• Дата-центры: euNetworks в Амстердаме, Frankfurt 1 Data Center в Германии, Digita в Хельсинки, Long Island Interconnect в Нью-Йорке.
• Сеть: порт до 10 Гбит/с, безлимитный трафик, подсеть /64 IPv6 на всех тарифах.
• SLA 99.7%; мониторинг состояния сервера встроен в панель.
• Договор на обработку персональных данных; оплата картами РФ, СНГ, ЕС и криптовалютой.

Отзывы и репутация

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

Поддержка и каналы связи

• Каналы: тикеты и Telegram 24/7.
• Время ответа зависит от загрузки; поддержка работает круглосуточно.
• Документация и API на сайте.
• Персональный менеджер доступен для B2B-клиентов.

Тарифы, ограничения и условия

• Популярная конфигурация: 4 vCPU, 8 GB RAM, 100 GB SSD — $25/мес.
• Скидки за предоплату: 5%, 10%, 15% за 3, 6, 12 месяцев.
• Бесплатного тестового периода нет.
• Резервные копии платные, создаются ежедневно; количество не ограничено.
• Апгрейд без потери данных с перезагрузкой сервера.
• Сервер выделяется за 5–10 минут после установки ОС.

Официальный сайт: PSB Hosting

5. FirstVDS — бюджетный VPS/VDS для простого старта

FirstVDS — российский VPS/VDS-провайдер с готовыми тарифами и быстрым запуском сервера. Он подходит для простых веб-проектов, тестовых окружений и задач, где важны понятная стартовая цена, российские площадки и базовые дополнительные услуги.

Кейсы клиентов и кому подойдёт

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

Что можно развернуть

• Linux/VDS для сайтов, блогов, небольших баз данных и веб-приложений.
• Windows-серверы: на сайте есть отдельная линейка VDS для Windows Server 2019 и 2022.
• Дополнительные услуги: S3, автоматическое резервное копирование, администрирование, DDoS-защита, мониторинг сайтов.

Инфраструктура и экосистема

На официальной странице FirstVDS указаны серверы в России, Нидерландах и Казахстане, запуск готового сервера за 2 минуты, отдельные линейки VDS Форсаж, CPU.Турбо, VDS Atlant, Storage и GPU. Это вариант для тех, кто хочет выбрать готовую линейку, а не собирать конфигурацию вручную.

Тарифы и ограничения

• Стартовая цена на сайте: VPS/VDS от 249 ₽/мес.
• Плюс: круглосуточный бесплатный телефон 8 800 775-38-37 и большое количество отзывов на сайте.
• Особенность: параметры под конкретный сценарий лучше дополнительно проверять в конфигураторе и на тестовой конфигурации.

Официальный сайт: FirstVDS

6. Hetzner Cloud — зарубежное облако для международных проектов

Hetzner Cloud — европейский облачный провайдер с API и дата-центрами в Германии, Финляндии, США и Сингапуре. Он подходит для международных проектов, тестовых окружений и команд, которым важны автоматизация, сети, firewalls и понятная облачная модель. Для российских юридических и регуляторных требований условия нужно проверять отдельно.

Кейсы клиентов и кому подойдёт

• Тестовые окружения, личные проекты, международные веб-сервисы и инфраструктура для разработчиков.
• Команды, которым нужны API, CLI, Terraform/Ansible-интеграции, private networks и firewalls.
• Проекты с аудиторией в Европе, США или Азии, где российская юрисдикция и документы не критичны.

Что можно развернуть

• Linux-дистрибутивы: Ubuntu, Debian, Fedora и другие образы.
• One-click apps: Docker, WordPress, Nextcloud, GitLab, Grafana, Jitsi Meet, WireGuard и другие.
• Облачная инфраструктура с networks, firewalls, load balancers, API, CLI и интеграциями для CI/CD.

Инфраструктура и экосистема

Hetzner описывает shared cloud как вариант для разработки, тестов, личных сайтов, небольших баз данных и веб-серверов со средней нагрузкой. Dedicated cloud рассчитан на бизнес-приложения и устойчивую высокую нагрузку. На сайте также указаны GDPR, ISO/IEC 27001 для дата-центров в Германии и Финляндии, 99,9% uptime и поддержка 24/7 по email.

Тарифы и ограничения

• Цены и конфигурации зависят от выбранной страны, валюты и типа cloud-сервера; в статье лучше считать их отдельно в калькуляторе Hetzner.
• Плюс: зрелая европейская облачная экосистема и сильная автоматизация.
• Особенность: иностранная юрисдикция и документы отличаются от российских провайдеров, поэтому для проектов с персональными данными и 152-ФЗ условия нужно проверять отдельно.

Официальный сайт: Hetzner Cloud

Сравнение по ключевым критериям

Минимальный вход: у Макхоста самый дешёвый стартовый тариф — 143 ₽/мес, но с ограниченным трафиком и SSD. SmartApe предлагает старт от 345 ₽/мес с двумя ядрами и HDD+SSD-кэшем; FirstVDS начинается от 249 ₽/мес и подходит как бюджетная точка входа. UFO.Hosting, PSB Hosting и Hetzner Cloud стоит считать по конфигурации и требованиям к географии.

Популярные конфигурации: Макхост и UFO.Hosting выделяют тарифы с 2 GB RAM для магазинов и CMS; у SmartApe стартовый NVMe-тариф даёт 2 CPU и 1 GB RAM; у PSB Hosting популярный тариф — 4 CPU и 8 GB RAM за $25/мес. FirstVDS удобен для простых стартовых задач, а Hetzner Cloud — для международных проектов и команд, которым нужны API, сети и автоматизация.

Диски и трафик: у каждого провайдера разные акценты по дискам, портам, бэкапам и ограничениям. FirstVDS даёт массовую VPS/VDS-линейку и дополнительные сервисы вроде S3, бэкапов и мониторинга. Hetzner Cloud силён по API, сетям, firewalls и included traffic; его условия нужно пересчитывать отдельно под регион и валюту.

Тестовый период: SmartApe даёт 10 дней без карты, Макхост и UFO.Hosting — 3 дня с условиями, PSB Hosting — не предусмотрен. Для FirstVDS и Hetzner Cloud тестовый период и условия пробного запуска лучше проверять на момент заказа.

География и документы: Макхост, UFO.Hosting и SmartApe подтверждают работу по 152-ФЗ и наличие российских площадок; PSB Hosting работает только из зарубежных дата-центров и предлагает оплату криптовалютой. FirstVDS имеет российские и зарубежные площадки. Hetzner Cloud работает в иностранной юрисдикции, поэтому для проектов с персональными данными россиян нужно заранее проверить документы, обработку данных и требования 152-ФЗ.

Выводы

Выбор VPS начинается с честной оценки нагрузки: 1 CPU и 1 GB RAM хватит для статического лендинга или простого бота, но для CMS с плагинами, интернет-магазина или 1С стоит закладывать минимум 2 CPU и 4 GB RAM, а лучше — тестировать реальную нагрузку на выбранной панели.

Если важен минимальный бюджет и российские документы — смотрите на Макхост. Если нужна широкая линейка от VPS до выделенных серверов в одном кабинете — на UFO.Hosting. Для гибкого подбора ресурсов под растущую нагрузку подойдёт SmartApe. Если проект ориентирован на зарубежную аудиторию и нужен безлимитный трафик — PSB Hosting.

FirstVDS подойдёт для недорогих и простых запусков с российскими и зарубежными площадками. Hetzner Cloud — для международной инфраструктуры, где важны API, сети и дата-центры за пределами России; юридические и регуляторные требования нужно проверять отдельно.

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

• Виртуальный хостинг — сайты соседствуют на одном сервере, управляет провайдер. Дешёвый старт, но ограниченная конфигурация.
• VPS и VDS — почти всегда синонимы: изолированные виртуальные серверы с root-доступом и гарантированными ресурсами.
• Выделенный сервер — отдельное железо, максимум контроля и цены, требует администрирования.
• В подборке: Интернет Хостинг Центр, UFO.Hosting, SpaceWeb, PSB Hosting, AdminVPS и FirstVDS.

Как мы выбирали участников

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

1. Интернет Хостинг Центр — гибкие конфигурации

Российский провайдер, у которого VPS и VDS — это одна услуга. Можно выбрать виртуализацию под задачу (KVM или Virtuozzo), собрать конфигурацию от минимальной до высоконагруженной и расти внутри одной платформы до выделенного сервера.

Кейсы клиентов и кому подойдёт

• Небольшой сайт компании на WordPress с 300–500 посетителей в сутки спокойно живёт на виртуальном хостинге; при росте трафика переходят на VPS.
• Интернет-магазин на 1С-Битрикс с 500–1000 пользователями в день переносят на VPS/VDS, когда подключают CRM и платёжные системы.
• Разработчик с несколькими проектами берёт VPS/VDS под API, базу данных и тестовые окружения — виртуальный хостинг здесь слишком ограничен.

Что можно развернуть

На виртуальном хостинге — сайты на PHP 5.2–8.2 с MySQL, панели IHC, cPanel или ISPmanager. На VPS/VDS — любые Linux-дистрибутивы, Windows, WireGuard, MikroTik Router, панели ispmanager/FastPanel, VPN-шаблоны, CMS вроде 1С-Битрикс.

Инфраструктура и экосистема

Дата-центры Tier III в Москве (DataPRO и IXcellerate Moscow One) и в Амстердаме. Виртуализация — KVM или Virtuozzo. Защита от DDoS входит во все тарифы, IPv6-сети /64 доступны за доплату. Есть партнёрская программа с выплатами до 50% от привлечённых оплат.

Отзывы и репутация

На сайте публикуются отзывы с внешних площадок: средняя оценка 4,8 по 20 оценкам. Клиенты отмечают стабильную работу и скорость техподдержки.

Поддержка и каналы связи

Тикеты через личный кабинет, онлайн-чат на сайте, Telegram @IHC_Support_Bot, телефоны в Москве, Санкт-Петербурге и бесплатный номер для регионов. Первый ответ обычно приходит за 10–30 минут в рабочее время. Для корпоративных клиентов доступно сопровождение через отдел продаж и аккаунт-менеджеров.

Тарифы, ограничения и условия

• Виртуальный хостинг: тариф IHC-2 — от 123 ₽/мес при оплате за год или 147 ₽/мес помесячно; 2 сайта, 2 ГБ SSD, 150 МБ под БД, домен .RU в подарок при оплате за 2 года.
• VPS/VDS: минимальная конфигурация ssdVPS:1 — 1 ГБ RAM, 20 ГБ SSD, 1 CPU, безлимитный трафик со снижением скорости после 20 ТБ — от 317 ₽/мес за год или 380 ₽/мес помесячно.
• Типовая конфигурация для небольшого проекта — 2 ГБ RAM, 1–2 CPU, 30–45 ГБ NVMe — от 609 ₽/мес за год или 700 ₽/мес помесячно.
• Тестовый период: 7 дней на виртуальном хостинге, 3 дня на VPS/VDS; для активации нужно пополнить баланс на 100 ₽, которые можно вернуть или потратить.
• Бэкапы: место под резервные копии — от 52,5 ₽/мес за 5 ГБ; снапшоты зависят от платформы.
• Работа по 152-ФЗ, есть реестр хостинг-провайдеров; закрывающие документы для юрлиц доступны.

Официальный сайт: ihc.ru

2. UFO.Hosting — космическая экосистема

Провайдер, который объединяет VPS/VDS, выделенные серверы, защиту сайтов, DNS-хостинг, аренду IP, лицензии ISPmanager и домены в одном личном кабинете. Для UFO.Hosting VPS и VDS — два названия одной услуги; разница только в терминологии.

Кейсы клиентов и кому подойдёт

• Интернет-магазин с трафиком 10–50 тыс. посетителей в день — VPS даёт стабильность при пиковых нагрузках и возможность настроить SSL, СУБД и кэширование.
• Веб-студии и агентства выбирают VPS/VDS ради изоляции ресурсов: проблемы одного клиента не влияют на соседние проекты.
• CRM-системы, лендинги с формами заявок и приложения с умеренной нагрузкой — удобно масштабировать RAM и CPU без переплаты за железо.
• Выделенные серверы берут под крупный e-commerce с интенсивным чтением/записью, проекты с жёсткими требованиями к безопасности и задачи с огромными объёмами дисков.

Что можно развернуть

VPS/VDS на Linux и Windows, панели Vesta, Hestia, CyberPanel, Virtualmin, ISPmanager. Можно поднять веб-серверы, базы данных, VPN, контейнеры, игровые серверы, DNS-зоны, а рядом заказать защиту сайта от DDoS L7 и внешнее FTP-хранилище.

Инфраструктура и экосистема

Серверы стоят в дата-центре IXcellerate в Москве, соответствующем Tier III. Сеть ноды VPS/VDS — 10 Гбит/с, распределяется между серверами по тарифу. Доступны обычные конфигурации на Intel Xeon, Hi-CPU на Ryzen и Storage-линейка с расширенным хранилищем.

Отзывы и репутация

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

Поддержка и каналы связи

Техподдержка 24/7 через онлайн-чат на сайте и тикет-систему в биллинге. Телефонная поддержка работает в будни с 9:00 до 18:00; Telegram не используется. Фактическое время ответа — не более 30 минут в любое время суток. Есть база знаний и блог.

Тарифы, ограничения и условия

• Минимальная конфигурация VPS/VDS Naos (Intel Xeon E5-2697A v4) — 1 vCore, 1 ГБ RAM, 25 ГБ NVMe — 605,85 ₽/мес.
• Типовая конфигурация Brachium (Intel Xeon E5-2697A v4) — 2 vCore, 4 ГБ RAM, 60 ГБ NVMe — 1025,85 ₽/мес.
• Скидки за предоплату: 3 месяца — 5%, 6 месяцев — 10%, 12 месяцев — 15%.
• Тестовый период — до 3 дней на любой тариф VPS; требуется верификация аккаунта (email, телефон, KYC). На выделенные серверы — до 3 дней по договорённости.
• Трафик безлимитный с порогом 32 ТБ/мес; после превышения скорость ограничивается 100 Мбит/с.
• Root-доступ полный. На тарифах Naos и Haedus выбор ОС ограничен списком провайдера; на остальных можно ставить любую ОС.
• Бэкапы платные: ежедневные — 525 ₽/мес, еженедельные — 262,5 ₽/мес; снапшотов нет, есть услуга бэкапов.
• Работа по 152-ФЗ, сертификатов ФСТЭК нет; есть реестр хостинг-провайдеров. Для юрлиц — договор и ЭДО, постоплата недоступна.

Официальный сайт: ufo.hosting

3. SpaceWeb — посуточная тарификация

Один из старейших российских хостеров, у которого можно начать с виртуального хостинга, перейти на VPS/VDS с посуточной оплатой и докупать IP, SSL и защиту от DDoS. Удобен тем, кто хочет платить только за фактическое потребление ресурсов VPS.

Кейсы клиентов и кому подойдёт

• Лендинг, блог или сайт-визитка с небольшой посещаемостью — хватит виртуального хостинга с автоустановкой CMS.
• Интернет-магазин и корпоративный сайт на 1С-Битрикс — тарифы повышенной мощности с выделенными CPU и приоритетной поддержкой.
• Проект с непредсказуемой нагрузкой — VPS/VDS с посуточной тарификацией и изменением ресурсов «на лету».

Что можно развернуть

На хостинге — WordPress, Joomla, Drupal, 1С-Битрикс, OpenCart, MODx, Laravel, Django и другие CMS и фреймворки. Поддерживаются PHP 5.x–8.4, MySQL 8/5.7, PostgreSQL 14.4, Perl, Python, Ruby. На VPS/VDS — Ubuntu, Debian, CentOS, AlmaLinux, Rocky Linux, панели Hestia, FASTPANEL, ISPmanager, Docker.

Инфраструктура и экосистема

Дата-центры Tier III в Санкт-Петербурге, Москве и Амстердаме. Собственная SPA-панель управления, VNC-консоль, DNS-редактор, статистика, логи, бэкапы и снапшоты. На всех сайтах включена изоляция для защиты от вредоносного ПО и защита от DDoS L3-4; защиту L7 можно докупить от 290 ₽/мес.

Отзывы и репутация

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

Поддержка и каналы связи

Email, телефон, онлайн-чат и ВКонтакте. Среднее время ответа: 1–2 минуты по телефону, в чате и ВКонтакте; до 60 минут по почте. Поддержка помогает с переносом проектов, диагностикой и администрированием серверов с ISPmanager.

Тарифы, ограничения и условия

• Виртуальный хостинг: тариф «Старт» — 1 ГБ NVMe SSD, 1 база данных, ∞ FTP и почтовых ящиков, 120 CP — 149 ₽/мес; «Взлёт» — 311 ₽/мес, «Ракета» — 530 ₽/мес, «Космос» — 755 ₽/мес.
• VPS/VDS: посуточная тарификация, параметры CPU/RAM/диска меняются «на лету»; конкретную стоимость конфигурации проверяйте в калькуляторе на сайте.
• Тестовый период: 14 дней на виртуальном хостинге и на VPS/VDS.
• Ежедневное резервное копирование включено на хостинге; резервные копии VPS — от 45 ₽/мес за 3 копии.
• Дополнительный IP — 130 ₽/мес, SSL GlobalSign — от 1 900 ₽/год, домен .RU — 179 ₽/год.
• Работа с юрлицами через договор оферты, безналичные платежи и ЭДО.

Официальный сайт: spaceweb.ru

4. PSB Hosting — зарубежные локации

Провайдер с фокусом на VPS в Европе и США: Amsterdam, Frankfurt, Helsinki, New York. Не предлагает виртуальный хостинг в привычном понимании, зато даёт полный root, /64 IPv6 на всех тарифах, неограниченные резервные копии и оплату криптовалютой.

Кейсы клиентов и кому подойдёт

• Небольшие интернет-магазины на WordPress или 1С-Битрикс, лендинги, корпоративные сайты и блоги.
• Проекты с Telegram-ботами, API-сервисами и другой автоматизацией.
• Команды, которым важны зарубежные локации и гибкие способы оплаты, включая криптовалюту.

Что можно развернуть

VPS под Linux, Windows или FreeBSD с предустановленным ПО: Bitrix, Django, Docker, FastPanel, HestiaCP, Keitaro, LAMP, Node, OpenVPN, Outline, Portainer, VestaCP, WireGuard, WordPress. Подходит под сайты, backend-приложения, VPN, корпоративные системы, базы данных и тестовые среды.

Инфраструктура и экосистема

Серверы размещены в дата-центрах euNetworks (Amsterdam), Frankfurt 1 Data Center, Digita (Helsinki) и Long Island Interconnect (New York). Оборудование — AMD и Intel с DDR5 и NVMe, RAID 10. Безлимитный трафик, порт ноды 10 Гбит/с, на VPS выделяется 300 Мбит/с. Полноценная панель управления DNS-записями доменов.

Отзывы и репутация

На сайте указаны рейтинги на независимых площадках: OtzovikMarketing.ru — 4,8, In-Scale.ru — 5,0, Aff1.ru — 5,0, 101Poisk.ru — 4,89. Провайдер позиционируется как решение для бизнеса, разработки и высоконагруженных проектов.

Поддержка и каналы связи

Поддержка работает круглосуточно через тикеты и Telegram; время ответа зависит от загрузки. Есть документация и API. Для B2B-клиентов предусмотрен менеджер.

Тарифы, ограничения и условия

• VPS: минимальный тариф на странице VPS — от 8 USD; есть High-CPU VPS на AMD Ryzen 7950X.
• Почасовая оплата доступна; скидки за предоплату: 3 месяца — 5%, 6 месяцев — 10%, 12 месяцев — 15%.
• Бесплатного тестового периода нет.
• Безлимитный трафик, порт VPS — 300 Мбит/с; можно установить любую ОС; полный root-доступ.
• Бэкапы платные, снапшоты есть.
• IPv6-подсеть /64 на всех тарифах, неограниченное количество резервных копий.
• Не работает по 152-ФЗ, сертификатов ФСТЭК нет, в реестре отечественного ПО нет. Оплата картами РФ/СНГ/ЕС и криптовалютой.

Официальный сайт: psb.hosting

5. AdminVPS — VPS и хостинг в одном кабинете

Провайдер с виртуальным хостингом, VPS/VDS, выделенными серверами, доменами, SSL и дополнительными сервисами в одном аккаунте. В подборке он закрывает сценарий, когда проекту нужен обычный хостинг для сайта и отдельный VPS под приложение, базу данных или тестовую среду.

Кейсы клиентов и кому подойдёт

• Сайты на CMS и небольшие магазины, которые начинают с виртуального хостинга и постепенно переходят на VPS.
• Команды, которым нужны домены, SSL, хостинг и серверы в одном личном кабинете.
• Проекты, где важна российская площадка и возможность подобрать конфигурацию VPS под нагрузку.

Что можно развернуть

На виртуальном хостинге — сайты на популярных CMS и почту на домене. На VPS/VDS — Linux-серверы под сайты, backend, базы данных, тестовые окружения и сервисы с root-доступом. В экосистеме также есть домены, SSL-сертификаты, резервное хранилище, объектное хранилище и защита от DDoS.

Инфраструктура и экосистема

На странице VPS в России указано размещение в Москве, процессоры Intel Xeon Gold и AMD EPYC, NVMe-диски, тарифы с портом от 100 Мбит/с до 1 Гбит/с и включённым месячным трафиком. В меню также есть VPS в Германии, Нидерландах, Польше, Испании, Беларуси, Казахстане, Финляндии, Великобритании и Франции.

Отзывы и репутация

На странице VPS указана агрегированная оценка 4,9 и несколько сотен отзывов. Провайдер позиционируется как универсальная площадка для сайтов, серверов и сопутствующих услуг.

Поддержка и каналы связи

Поддержка работает круглосуточно через тикет-систему в личном кабинете. Отдел продаж доступен по телефону и через запрос на сайте.

Тарифы, ограничения и условия

• VPS/VDS в России: конфигуратор стартует от 500 ₽/мес; в готовых тарифах есть Lite с 1 CPU, 1 ГБ RAM и 15 ГБ NVMe.
• Виртуальный хостинг и CMS-хостинг доступны отдельными услугами.
• В тарифах VPS указаны месячные пакеты трафика; на младшем Lite — 1 ТБ и порт 100 Мбит/с.
• Бэкапы зависят от тарифа: для части тарифов платно, для части включены.
• Есть скидки за предоплату на 6, 12 и 24 месяца.
• На странице указано соответствие требованиям РФ по 152-ФЗ.

Официальный сайт: adminvps.ru

6. FirstVDS — готовые VDS/VPS-конфигурации

Провайдер с фокусом на виртуальные серверы: готовые VDS/VPS, отдельные линейки для высоких CPU-частот, storage-сценариев, GPU и Windows. В подборке это вариант для тех, кто выбирает именно VPS/VDS и сопутствующие услуги, а не классический shared-хостинг.

Кейсы клиентов и кому подойдёт

• Небольшие сайты и сервисы, которым нужен отдельный сервер вместо виртуального хостинга.
• Разработчики, которым важны готовые Linux-образы, SSH-доступ и быстрый запуск сервера.
• Проекты, где позже могут понадобиться Windows-серверы, storage-линейка или зарубежная локация.

Что можно развернуть

На VPS/VDS доступны Linux-дистрибутивы Debian, Ubuntu, FreeBSD, CentOS и Alma, платная Windows, панели ispmanager и дополнительные IP. В линейке есть VDS для Windows, VDS в Нидерландах и Алматы, storage-серверы, GPU-серверы и объектное хранилище S3.

Инфраструктура и экосистема

На сайте указаны дата-центры в России, Нидерландах и Казахстане. Для VDS в Москве доступны каналы до 100 Мбит/с с безлимитным трафиком или до 1 Гбит/с с пакетом 32 ТБ в месяц; для Амстердама и Казахстана условия отличаются.

Отзывы и репутация

FirstVDS работает как отдельный бренд виртуальных серверов и указывает награды отраслевой премии ЦОДы.рф. На сайте также опубликованы пользовательские отзывы и раздел базы знаний.

Поддержка и каналы связи

На сайте указан бесплатный круглосуточный телефон 8 800 775-38-37, база знаний и служба поддержки. Для серверов доступны дополнительные услуги администрирования и технического сопровождения.

Тарифы, ограничения и условия

• Готовые VDS/VPS — от 249 ₽/мес; запуск сервера заявлен за несколько минут.
• Бесплатно с сервером: 1 выделенный IP-адрес, ispmanager 6 lite на 1 месяц, установка ОС на выбор и полный SSH-доступ.
• Тестовый период предоставляется по согласованию.
• Windows тарифицируется отдельно: на странице указано 680 ₽/мес за 1 ядро, недоступно для VDS в Амстердаме и Алматы.
• Для VDS в Москве возможен канал до 100 Мбит/с с безлимитным трафиком или до 1 Гбит/с с лимитом 32 ТБ/мес.
• Дополнительные услуги: бэкап, мониторинг, BitNinja, DDoS-защита, домены, SSL и DNS-хостинг.

Официальный сайт: firstvds.ru

Сравнение по ключевым критериям

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

• Минимальный виртуальный хостинг: ИХЦ — от 123 ₽/мес (при оплате за год), SpaceWeb — от 149 ₽/мес; AdminVPS предлагает виртуальный/CMS-хостинг отдельной линейкой; UFO.Hosting, PSB Hosting и FirstVDS в подборке рассматриваются прежде всего как VPS/VDS-провайдеры.
• Минимальный VPS/VDS: ИХЦ — от 317 ₽/мес (за год), UFO.Hosting — 605,85 ₽/мес, SpaceWeb — цена в калькуляторе с посуточной тарификацией, PSB Hosting — от 8 USD, AdminVPS — от 500 ₽/мес в конфигураторе, FirstVDS — от 249 ₽/мес.
• Виртуализация: ИХЦ — KVM/Virtuozzo на выбор; UFO.Hosting — Intel Xeon и Ryzen линейки; SpaceWeb — собственная облачная платформа; PSB Hosting — KVM; AdminVPS и FirstVDS предлагают готовые VPS/VDS-линейки с Linux-образами.
• Трафик: ИХЦ и PSB Hosting — безлимитный (у ИХЦ снижение скорости после 20 ТБ); UFO.Hosting — безлимитный с порогом 32 ТБ; SpaceWeb — параметры уточняйте в конфигураторе; AdminVPS указывает месячные пакеты трафика; FirstVDS разделяет безлимитный канал 100 Мбит/с и пакеты трафика на более быстрых каналах.
• Root и ОС: полный root у всех шести; ИХЦ и PSB Hosting позволяют загружать собственные ISO; UFO.Hosting ограничивает список ОС на младших тарифах; у FirstVDS Windows и панели управления идут как платные дополнения.
• Бэкапы: SpaceWeb включает ежедневные бэкапы на хостинге; ИХЦ и PSB Hosting — платно; UFO.Hosting — платная услуга резервного копирования; AdminVPS и FirstVDS предлагают бэкапы как тарифную или дополнительную опцию.
• Тестовый период: SpaceWeb — 14 дней на хостинге и VPS; ИХЦ — 7 дней хостинг / 3 дня VPS; UFO.Hosting — до 3 дней VPS; FirstVDS — по согласованию; PSB Hosting — нет; условия AdminVPS зависят от акции и выбранной услуги.
• Дата-центры: ИХЦ — Москва + Амстердам; UFO.Hosting — Москва; SpaceWeb — Москва, Санкт-Петербург, Амстердам; PSB Hosting — Amsterdam, Frankfurt, Helsinki, New York; AdminVPS предлагает VPS в разных странах; FirstVDS указывает Россию, Нидерланды и Казахстан.
• Юридика: ИХЦ, UFO.Hosting, SpaceWeb и AdminVPS работают с российской юридической рамкой; PSB Hosting ориентирован на зарубежные локации; для FirstVDS условия документов и лицензий зависят от выбранных услуг.

Вывод

Виртуальный хостинг остаётся самым простым стартом для сайта-визитки, блога или небольшого магазина: не нужно администрировать сервер, всё настроено провайдером. VPS/VDS стоит брать, когда проекту нужна изоляция, root-доступ, нестандартное ПО или рост нагрузки. Выделенный сервер — следующий шаг, когда виртуализация уже не тянет задачу.

Если приоритет — российская юридика и плавный рост от хостинга до железа, смотрите на Интернет Хостинг Центр или SpaceWeb. Если важна экосистема из доменов, защиты и серверов в одном кабинете — UFO.Hosting или AdminVPS. Если нужен недорогой вход именно в VPS/VDS — можно сравнить FirstVDS с базовыми тарифами других участников. Если нужны зарубежные локации и гибкая оплата — PSB Hosting. Перед покупкой всегда берите тестовый период и проверяйте реальную производительность под вашей нагрузкой.

Что такое NixOS

NixOS — это дистрибутив Linux, в котором всё системное окружение описывается декларативно на языке Nix и воспроизводится из одного конфигурационного файла. Каждая сборка помещает зависимости в /nix/store, что даёт атомарные откаты и воспроизводимость, но при этом легко разрастается размер.

Одна из удобных фич — команда nixos-rebuild build-vm: она превращает конфигурацию в виртуальную машину. Но иногда нужен не «тонкий» образ, привязанный к хосту, а самодостаточный ISO, который можно записать на флешку или загрузить в облаке.

• Базовый NixOS ISO занимает 458 МБ: 416 МБ — squashfs с пользовательским окружением, 26 МБ — initrd, 13 МБ — ядро.
• Главные «тяжеловесы» внутри образа: модули ядра (144 МБ), Python 3 (128 МБ), systemd (60 МБ), Perl (56 МБ), GRUB (около 62 МБ).
• Отключение Nix, документации, SSH, firewall и лишних зависимостей сокращает ISO до 197 МБ.
• Замена Perl-активации на экспериментальные system.etc.overlay и services.userborn даёт финальный размер около 183 МБ.
• Это игрушечный эксперимент: для десктопа и сервера такие отсечения небезопасны, но полезны как источник идей.

От VM к ISO за несколько строк

Минимальная виртуальная машина на NixOS собирается из файла примерно такого вида:

Запуск: $(nix-build basic-vm.nix --attr vm --no-out-link)/bin/run-nixos-vm. При этом /nix/store монтируется с хоста, поэтому VM «тонкая». Для независимого ISO импортируем модуль iso-image.nix и собираем атрибут isoImage:

ISO собирается, загружается в QEMU, но размер сразу бросается в глаза.

458 МБ — из чего они сложились

Автор примонтировал полученный ISO и посмотрел распределение места. Вот ключевые цифры:

• 416 МБ — сжатый nix-store.squashfs с пользовательским окружением.
• 26 МБ — начальная загрузочная среда initrd.
• 13 МБ — ядро Linux.
• 3 МБ — загрузчик isolinux.

При распаковке squashfs картина ещё интереснее:

• 144 МБ — модули ядра (linux-6.18.35-modules).
• 128 МБ — Python 3.13.
• 60 МБ — systemd.
• 56 МБ — Perl.
• ~62 МБ суммарно — две копии GRUB (UEFI + BIOS).

Поскольку ISO собирается локально, все пакеты из него есть и в хостовом /nix/store. Это позволяет использовать nix why-depends, чтобы найти, кто тащит каждую зависимость.

Отключаем Nix, документацию и лишние сервисы

Первый очевидный шаг — отказаться от демона Nix внутри ISO, ведь мы строим автономный образ, а не полноценную NixOS для работы с пакетами. Достаточно двух опций:

Результат: 384 МБ. Экономия скромная, потому что часть зависимостей Nix всё ещё тянется через сервис register-nix-paths. Он регистрирует содержимое хранилища ISO при загрузке — но Nix-то мы уже убрали. Отключаем и его:

Теперь ISO уменьшился до 360 МБ, а зависимость от Boost исчезла полностью.

SSH: модуль без выключателя

Следующий кандидат на удаление — OpenSSH-клиент. Проблема в том, что модуль programs/ssh.nix добавляет его в environment.corePackages, а отдельного переключателя programs.ssh.enable нет.

Попытка полностью исключить модуль через disabledModules ломает другие модули, например Plasma 6, которые ожидают существования опций programs.ssh. Выход — подменить опцию «пустышкой», не затрагивающей реальную конфигурацию:

Параллельно автор убрал firewall, documentation.man.enable и принудительно очистил environment.defaultPackages.

GRUB: зачем две копии загрузчика

ISO-пресет NixOS включает сразу и UEFI-, и BIOS-версии GRUB — отсюда около 62 МБ. Чёткого флага для отключения одной из них нет, поэтому автор пошёл грубым путём: сбросил system.extraDependencies и environment.systemPackages, оставив только environment.corePackages, чтобы shell хотя бы стартовал.

Ядерные модули: четверть образа

Модули ядра весили 144 МБ — больше, чем весь Alpine ISO. NixOS не предоставляет удобного способа ограничить их набор для runtime, поэтому автор просто удалил папку модулей из системы после сборки:

Это полностью отключает динамическую загрузку модулей. Если что-то нужно — оно должно оказаться в boot.initrd.kernelModules или availableKernelModules. После этого образ уменьшился до 197 МБ.

Perl: заменяем активацию системы

Perl в образе нужен только для скриптов активации: настройки /etc и создания пользователей. В nixpkgs уже есть экспериментальные замены — system.etc.overlay и нативный менеджер пользователей userborn.

Оба механизма помечены как экспериментальные, но в контексте «самодельного минимального ISO» это уже не самая безумная идея. Финальный размер: 183 МБ.

Что получилось и стоит ли повторять

За несколько итераций образ сократился с 458 МБ до 183 МБ — почти в 2,5 раза. При этом система всё ещё загружается, автор смог залогиниться под root, правда разрешение экрана перестало переключаться.

Важно: конфигурация выше — это не рецепт для продакшена. Отсутствие Nix, SSH, модулей ядра и Perl-активации ломает массу сценариев. Результат интересен скорее как демонстрация границ NixOS, чем как готовый шаблон.

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

Выводы

Эксперимент показывает, что NixOS позволяет не только собирать сложные системы, но и жёстко урезать их — иногда в ущерб удобству. Главный инструмент здесь не волшебная опция, а последовательный анализ: смотреть, что занимает место, находить виновника через nix why-depends и решать, готовы ли вы от него отказаться.

«At some point I just kept going because I got curious.»

Если захотите повторить — начните с отключения Nix и документации, а дальше решайте, какие модули и пакеты действительно нужны в вашем live-образе. Исходный материал — в блоге автора: I can haz smoller NixOS ISOs?.

В Linux 7.2 код расширяемого планировщика sched_ext изначально появился в виде файлов ext_arena.c, ext_cid.c, ext_types.h и других прямо в kernel/sched.

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

Новый pull request перенёс файлы в kernel/sched/ext/; Торвальдс уже принял эту реструктуризацию.

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

На прошлой неделе в основную ветку Linux 7.2 попал основной набор изменений sched_ext — фреймворка, который позволяет реализовывать политики планирования в пользовательских программах BPF. К патчам не было претензий по функциональности, но Торвальдса возмутила организация файлов.

Вместо того чтобы создать поддиректорию kernel/sched/ext/, авторы добавили в kernel/sched несколько файлов с префиксом ext_: ext_arena.c, ext_arena.h, ext_cid.c, ext_cid.h и ext_types.h.

Please don't do this disgusting thing. There's a reason we have subdirectories: it's to group files together and separate them out. Using name prefixing instead of directories is disgusting and wrong. If you have this many random sched-ext files, it damn well should be cleaned up and not be this kind of mess. I've pulled this, but under protest. Proper hierarchical filesystems have been available since 1965.

Как исправили

В ответ разработчики отправили новый pull request, который перекладывает все sched_ext-файлы в отдельную директорию kernel/sched/ext/. Торвальдс уже принял реструктуризацию.

Почему это важно

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

Выводы

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

Источники

• Phoronix: "Disgusting" Linux sched_ext Source Code Restructured
• Письмо Линуса Торвальдса в lkml
• Коммит реструктуризации в git.kernel.org

Выход — поднять собственное S3-совместимое хранилище на том же VPS, где крутится staging. MinIO реализует API Amazon S3, понимает те же SDK и presigned URL, но стоит ровно столько, сколько стоит диск сервера. Один и тот же код приложения работает и с MinIO на dev, и с R2 в проде — меняются только переменные окружения.

Что такое MinIO и почему он подходит для staging

MinIO — это open-source сервер объектного хранилища, написанный на Go. Он поддерживает основные операции S3: бакеты, объекты, multipart upload, versioning, lifecycle, шифрование SSE-S3, CORS и IAM-политики. Для приложения он выглядит как обычный S3-эндпоинт, поэтому подходит почти любой SDK: AWS SDK, boto3, minio-js, aws-sdk-go.

На staging важно не столько масштабирование, сколько идентичность поведения продакшена. Если в проде R2 или S3, а в staging — локальная файловая система, вы тестируете не тот код. MinIO закрывает этот разрыв: тот же PutObjectCommand, те же presigned URL, те же ошибки SignatureDoesNotMatch.

• MinIO — полноценный S3-совместимый сервер, который можно развернуть в Docker на VPS за 10–15 минут.
• Для staging это экономия на хранении тестовых файлов и единый код с продакшеном.
• HTTPS и домен лучше отдавать reverse proxy — Traefik или NGINX — с Let’s Encrypt.
• Presigned URL позволяют загружать и скачивать файлы напрямую из браузера, не проксируя байты через бэкенд.
• Root-ключи MinIO нельзя отдавать приложению: создавайте отдельного пользователя с IAM-политикой только на нужный бакет.

Архитектура: прод против staging

В продакшене обычно используется управляемое хранилище: AWS S3, Cloudflare R2, Yandex Object Storage, Hetzner Object Storage. Там работают репликация, резервное копирование и чужой дежурный. В staging достаточно одного MinIO-контейнера на сервере с регулярным зеркалированием в дешёвое холодное хранилище.

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

Важно: виртуальный хостинг bucket.example.com в MinIO работает, но на staging проще включить path-style и не мучиться с DNS-записями под каждый бакет.

Что понадобится

• VPS с Linux, публичным IP и открытыми портами 80/443.
• Два A-записи: minio-staging.example.com и minio-console.example.com.
• Docker и Docker Compose v2.
• Reverse proxy с TLS — в примере Traefik v2 + Let’s Encrypt.
• Около 10 ГБ свободного места под тестовые данные.

Разворачиваем MinIO в Docker Compose

Минимальный docker-compose.staging.yml заводит один контейнер, внешнюю сеть для Traefik и именованный том для данных.

Два параметра критичны для presigned URL. MINIO_SERVER_URL говорит серверу, на каком публичном домене подписывать ссылки. Без него ссылка будет подписана для http://minio:9000 и браузер отклонит подпись. MINIO_BROWSER_REDIRECT_URL нужен для корректных редиректов веб-консоли.

Прокидываем HTTPS через Traefik

Добавляем лейблы к сервису minio, чтобы Traefik маршрутизировал API и консоль на разные порты и автоматически выпускал сертификаты.

Проверяем здоровье сервера с локальной машины: curl -I https://minio-staging.example.com/minio/health/live должен вернуть HTTP 200.

Cloudflare: для поддомена с API лучше выключить оранжевое облако. Бесплатный тариф Cloudflare обрезает тело запроса на 100 МБ и может убирать S3-заголовки, из-за чего ломается подпись.

Бакеты, политики и отдельный пользователь для приложения

После запуска создаём бакет и отдельного IAM-пользователя. Делать это root-ключами приложения — плохая идея: root может удалить всё.

Теперь создаём пользователя staging-app и IAM-политику, ограничивающую права только этим бакетом.

Логин staging-app и его секрет — это и есть S3_ACCESS_KEY и S3_SECRET_KEY для приложения.

Код приложения не меняется

Пример на AWS SDK v3 для Node.js. Обратите внимание на forcePathStyle: true: без него SDK попытается обратиться к bucket.minio-staging.example.com, и запрос уйдёт в никуда.

Переменные для staging:

Для продакшена — только другой набор значений, код идентичен.

Presigned URL: загрузка и скачивание без проксирования

Presigned URL — это обычный HTTPS URL с короткой подписью в query string. Кто угодно может выполнить ровно то действие, на которое выдана подпись: PUT для загрузки или GET для скачивания. Бэкенд проверяет права, подписывает URL и отдаёт клиенту — сам файл идёт напрямую в MinIO.

Загрузка из браузера

Важный подводный камень: Content-Type, который браузер отправляет при PUT, должен точно совпадать с тем, что было передано в PutObjectCommand. Иначе MinIO вернёт SignatureDoesNotMatch.

Скачивание приватных файлов

Почему это лучше проксирования: при прямой загрузке через ваше API все байты проходят через приложение, съедая CPU, RAM и пропускную способность. С presigned URL трафик идёт между клиентом и MinIO — бэкенд только подписывает ссылку.

CORS, lifecycle и безопасность

Несколько команд, которые стоит выполнить сразу после создания бакета.

CORS для браузерных загрузок

Автоудаление старых тестовых файлов

Шифрование данных в покое

И ещё раз: root-ключи храните в менеджере секретов и используйте только для mc admin. Консоль MinIO, если она доступна из интернета, закрывайте IP-allowlist или базовой авторизацией на уровне Traefik.

Бэкапы и мониторинг

Staging не должен хранить что-то ценное, но периодическое зеркалирование в дешёвое холодное хранилище спасает от случайного удаления. Команда mc mirror синхронизирует бакет в Backblaze B2, Yandex Object Storage или другой S3-совместимый бэкенд.

Для метрик MinIO отдаёт Prometheus-экспортёр по пути /minio/v2/metrics/cluster. В Grafana можно импортировать дашборд ID 13502 и сразу видеть занятое место, RPS, задержки и ошибки.

Типичные проблемы

• SignatureDoesNotMatch при PUT — браузер отправил Content-Type, отличный от подписанного. Проверьте заголовок PUT.
• Подписанная ссылка работает локально, но не в браузере — не задан MINIO_SERVER_URL. Ссылка подписана для внутреннего http://minio:9000.
• 403 после Cloudflare — бесплатный тариф Cloudflare модифицирует заголовки. Переведите A-запись в режим DNS-only.
• CORS preflight failed — на бакете не настроены CORS-правила.
• Консоль редиректит на http://minio:9001 — не задан MINIO_BROWSER_REDIRECT_URL.

Выводы

Self-hosted MinIO на staging — это не попытка заменить облако, а способ сделать тестовую среду дешевле и ближе к продакшену. Тот же API, те же SDK, те же presigned URL, но без счетов за хранение битых файлов и ночных сбросов базы.

Ключевые моменты, которые стоит запомнить: всегда указывайте MINIO_SERVER_URL для корректных подписей, не используйте root-ключи в приложении, включайте path-style на staging и настраивайте lifecycle, чтобы мусор не копился.

Самое дорогое в staging — не железо, а различия в кодовых путях между dev и prod. MinIO помогает убрать одну из этих разниц почти бесплатно.

Источник: freeCodeCamp — How to Self-Host an S3-Compatible Object Store with MinIO on Your Staging Server.

EROFS (Enhanced Read-Only File System) — это доступная с Linux 4.19 файловая система только для чтения, заточенная под производительность и компактное хранение образов контейнеров, систем Android и, всё чаще, AI-моделей.

• Linux 7.2 получил два ключевых улучшения EROFS: разреженные pcluster и оптимизированное отображение chunk-based inode.
• Поддержка sparse-данных помогает экономить место при копировании в overlayfs и корректно работать с SEEK_HOLE.
• Удалён устаревший бэкенд FSCACHE — его функциональность заменяют файловые монтирования и fanotify.
• Патчи подготовил мейнтейнер EROFS Гао Сян из Alibaba.

Зачем нужна поддержка разреженных данных

Разреженные (sparse) файлы содержат пустые участки, которые не занимают место на диске. EROFS уже умеет прозрачно сжимать нули, но для AI-датасетов важно именно сохранять дыры: иначе overlayfs при копировании «вверх» распределит под них реальное пространство, а системный вызов SEEK_HOLE не найдёт ни одной «дыры».

Мейнтейнер EROFS Гао Сян из Alibaba пояснил в патчах, что новый код отмечает целые pcluster как «дыры» двумя разными способами. Это особенно полезно для огромных AI-датасетов, где нулевые или неинициализированные фрагменты встречаются часто.

Оптимизация ввода-вывода и удаление FSCACHE

Помимо sparse-поддержки, EROFS в Linux 7.2 получила оптимизированное отображение запросов для inode на основе чанков. Разработчики сообщают, что новый код erofs_map_chunks() делает ввод-вывод более эффективным, хотя точных бенчмарков в анонсе не приводится.

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

Итог

Обновления EROFS в Linux 7.2 делают эту файловую систему более удобной для больших AI-датасетов: разреженные данные теперь не превращаются в лишние мегабайты при копировании, а ввод-вывод для chunk-based inode стал эффективнее. Для разработчиков, которые используют EROFS в контейнерных и ML-окружениях, это повод проверить свои сборки ядра.

Источник: Phoronix.

Компания incident.io, которая делает платформу для управления инцидентами и дежурствами, опубликовала разбор того, как её команда измеряет надёжность продукта On-call. Главный тезис: мерять нужно не то, что контролируешь, а то, что чувствует клиент.

incident.io сводит надёжность on-call к двум вещам: приём алертов и доставка уведомлений дежурным.

Вместо uptime API они меряют «хорошие минуты»: долю времени, когда ошибка приёма алертов ниже 10%.

За сбои сторонних провайдеров отвечает сам сервис: active-active redundancy для SMS/звонков.

Пользовательские задержки в escalation-цепочках вычитаются из общей задержки, чтобы измерять реальное время обработки.

Цель SLO — 99,99% в месяц для приёма алертов и для задержки уведомлений менее 5 минут.

Две метрики, которые на самом деле важны

У on-call продукта много функций: расписания дежурств, запросы замены, escalation-цепочки. Но с точки зрения надёжности incident.io оставляет только две критические операции: приём алертов и своевременная доставка уведомлений.

Для них выбраны два SLI — индикатора уровня сервиса: доступность приёма алертов и доля уведомлений, доставленных быстрее 5 минут. Внутренний SLO для обоих — 99,99% в месяц.

Приём алертов: измеряйте «хорошие минуты»

Классический SLI для HTTP API — доля ответов без ошибок:

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

incident.io наблюдает трафик на уровне GCP load balancer — ближе к клиенту, чем application layer. Но и здесь есть шум: кратковременные сетевые блики, которые самолечатся за секунды. Чтобы не гоняться за каждым пиком, они меряют не запросы, а минуты:

Месяц делится на минуты. Минутка считается «хорошей», если доля ошибок в ней меньше 10%. Такой подход мотивирует и клиентов строить отказоустойчивую отправку алертов — с retries и backoff.

Третьи стороны: «не наша вина» не работает

Со стороны уведомлений вопрос сложнее: когда останавливать таймер? Простой ответ — когда уведомление передано провайдеру вроде Twilio или APNs. Если провайдер упал, разве это вина сервиса?

incident.io считает, что вина не важна — важен результат. Для SMS и звонков они используют двух провайдеров active-active: если один не справляется, срабатывает другой. Этот пробел они закрыли после инцидента в октябре 2025 года, когда единственный telecom-провайдер попал под AWS-аутедж.

Для push-уведомлений на iOS есть только один APNs, поэтому полную redundancy не построишь. Выход — подталкивать пользователей настроить несколько каналов: push, SMS и звонок одновременно. Так уведомление считается доставленным, когда его подтвердил хотя бы один провайдер.

Пользовательские задержки: как мерить то, что спрятано

Продукт позволяет гибко настраивать escalation. Например: сначала push и SMS, через 2 минуты — звонок. Если мерить время от алерта до звонка наивно, получится ложная задержка в те самые 2 минуты.

incident.io вычитает все намеренные задержки из общего времени:

Это означает: если звонок должен был прийти через 2 минуты, а пришёл через 7, — реальная задержка 5 минут, а не 7. «Это сложно мерить» не проходит краснолицый тест: компания сама рекомендует многоуровневые уведомления, поэтому должна нести ответственность и за их надёжность.

А что в России?

У нас типичная картина: Prometheus + Alertmanager шлют алерты в Telegram-бот или корпоративный мессенджер. Часто дежурство сводится к «если бот молчит — значит, всё нормально». Но мало кто меряет, доходит ли уведомление до человека, а не просто уходит ли HTTP-запрос.

Из статьи incident.io можно вынести три практических шага для российских команд:

1. Меряйте доставку уведомлений, а не только отправку. Если дежурный не подтвердил получение — это инцидент для мониторинга.
2. Стройте redundancy каналов. Telegram, SMS через провайдера, звонок — минимум два независимых пути.
3. Учитывайте настроенные задержки в SLO. Иначе вы будете наказывать себя за собственные best practices.

Ещё один момент: российские облачные провайдеры и telecom-операторы тоже падают. Поэтому active-active между двумя SMS-провайдерами или fallback на звонок — не перестраховка, а норма.

Выводы

Подход incident.io — хороший пример того, как техническая метрика перестраивается в метрику клиентского опыта. Вместо «наш API работает» — «алерт дошёл и дежурный его увидел вовремя». Вместо «провайдер виноват» — «у нас есть fallback». Вместо «это сложно мерить» — «мы меряем честно».

Customer outcomes matter more than any individual piece of the machine.

Источник: incident.io — Customers over control: how we measure On-call reliability.

Если у вас есть дежурства, пересмотрите свои SLO: они меряют опыт пользователя или просто красивые цифры для дашборда?

Service Topology — это не статическая схема из вики, а динамическая карта связей между сервисами. Она обновляется по мере того, как меняется трафик, появляются новые зависимости или старые исчезают. Карта показывает не только «кто с кем говорит», но и контекст: уровень доступности, бизнес-домен, владельца и текущее состояние здоровья.

Если тема микросервисов для вас новая, начните с базового разбора «Что такое микросервисы», а если выбираете архитектуру для проекта — сравните варианты в материале «Монолит или микросервисы». Авторский разбор внутреннего устройства Netflix читайте в статье «Разработчик изучал систему рекомендаций Netflix месяцами».

• Netflix объединила три источника данных: eBPF-сетевые потоки, IPC-метрики и распределённые трейсы.
• Каждый источник строит свой граф; общий вид получается параллельным слиянием слоёв.
• Карта обновляется почти в реальном времени и отвечает на запросы быстрее секунды.
• Инженеры используют её для поиска причин сбоев, оценки зоны поражения и планирования изменений.
• Подход можно перенести в любую распределённую систему, где нужно понимать зависимости.

Почему обычной наблюдаемости мало

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

Инженеру в три часа ночи приходится мысленно склеивать данные из разных источников. Это медленно, чревато ошибками и добавляет стресса. Netflix проанализировала тысячи обращений в поддержку за четыре года и увидела повторяющиеся вопросы: кто мои upstream и downstream, что упадёт вместе со мной, почему сервис отображается в панели мониторинга как Unknown (неизвестный сервис). Ответы на них требовали единого представления о зависимостях.

Три источника данных Service Topology

Главный вывод Netflix: ни один источник не рассказывает всю историю. Поэтому система строит три независимых графа и объединяет их по запросу.

Сетевые потоки eBPF

На сетевом уровне Netflix собирает потоки ядра через eBPF. Это даёт полноту: сюда попадают все соединения, независимо от того, инструментирован сервис или нет. Слой показывает связи между кластерами и приложениями такими, какими они есть на самом деле. Недостаток — не хватает прикладного контекста: видно, что сервис А достучался до IP-адреса сервиса Б, но неизвестно, какой конкретно endpoint вызывался.

IPC-метрики

На прикладном уровне собираются метрики межпроцессного взаимодействия. Когда сервис обращается к другому через gRPC, GraphQL или REST, он фиксирует endpoint, ошибки, задержки и протокол. Этот слой даёт детали, которых нет у сетевого: какой именно путь вызывается и с какой вероятностью ошибки. Ограничение очевидно: если сервис не отправляет метрики, его вызовов здесь не будет.

Распределённые трейсы

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

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

Как собирают Service Topology

Приём и обработка потоков

За кулисами работает конвейер, который держит миллионы событий в секунду. Потоки сетевых логов читаются из Kafka в нескольких регионах AWS. Для обработки Netflix использует Apache Pekko Streams — форк Akka, который разбивает нагрузку по группам автомасштабирования и сам управляет обратным давлением.

Восстановление прямых связей

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

Готовая топология хранится в графовой базе Netflix — абстракции поверх распределённого хранилища «ключ — значение». Она заточена под быстрый обход графа в несколько хопов. Поверх базы — gRPC-API с фильтрами по уровню доступности и домену, постраничным выводом больших выборок и ответом менее чем за секунду.

Хранение и API

Отдельно стоит возможность «путешествия во времени». Система не хранит каждый момент отдельно, а накапливает данные в скользящих окнах. Это позволяет спросить «как выглядела топология вчера в полночь» без взрыва объёмов хранения.

Что даёт инженерам

Интерфейс и API дают инженерам несколько рабочих сценариев — от ручного расследования до автоматических проверок.

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

Как перенести в свою систему

Не каждая компания работает в масштабе Netflix, но логика подхода универсальна. Если у вас десятки сервисов, уже появляется эффект «тысячи кусочков пазла». Начать можно с малого: собрать список зависимостей из существующих источников и периодически сверять его с реальным трафиком.

Чек-лист для первых шагов:
1. Выберите один настоящий источник связей: логи балансировщика, агент на хосте или метрики вызовов.
2. Не пытайтесь сразу построить идеальную модель — начните с автоматически обнаруженных рёбер.
3. Добавьте контекст: владельца сервиса, уровень критичности и домен.
4. Сделайте карту доступной программно, а не только в интерфейсе — инцидент-боты и скрипты будут благодарны.
5. Проверяйте актуальность: в динамичной среде карты, устаревшие на несколько часов, быстро теряют ценность.

Для иллюстрации вот минимальный скрипт, который строит рёбра графа из логов балансировщика:

Часто задаваемые вопросы

Выводы

Service Topology — не просто красивая картинка для панели мониторинга. Это операционная основа, которая ускоряет расследования, снижает риск изменений и даёт автоматическим системам общую картину инфраструктуры. Netflix называет её knowledge graph foundation — фундаментом для интеллектуальной автоматизации, в том числе для автоматического поиска первопричины сбоев.

Service topology provides the knowledge graph foundation that makes this kind of intelligent automation possible.

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

Источники

• From Silos to Service Topology: Why Netflix Built a Real-Time Service Map

CentOS (Community Enterprise Operating System) — это бесплатный клон Red Hat Enterprise Linux (RHEL), собираемый сообществом из открытых исходников. Он обеспечивает бинарную совместимость (то есть программы из RHEL запускаются без пересборки) с коммерческим дистрибутивом, но не требует подписки. Для многих компаний это был способ запускать единую серверную платформу везде, платя только за ту часть инфраструктуры, где критически важна техподдержка вендора.

В недавнем интервью The Register Куртцер, основатель CentOS, рассказал, как хобби-проект биохимика вырос в экосистему, которая определила судьбу корпоративного Linux на два десятилетия. Мы переплавили его рассказ в разбор того, почему CentOS был не врагом Red Hat, а, парадоксально, одним из главных факторов ее успеха.

CentOS появился в 2004 году как ответ сообщества на прекращение развития Red Hat Linux в пользу платной RHEL (для домашних пользователей его заменила Fedora) и переход к платной RHEL.

Основатель Грегори Куртцер пришел в мир Linux из биохимии и геномики, вдохновившись идеей открытого кода.

Первым успешным клоном RHEL был White Box Enterprise Linux, но он не выдержал нагрузки популярности.

К 2014 году CentOS стал настолько важен, что Red Hat официально спонсировала проект, наняв его небольшую команду.

Поворот к CentOS Stream в декабре 2020 года привел к рождению Rocky Linux и AlmaLinux — новых наследников идеи бесплатного RHEL-клона.

Красная шляпа бросает вызов сообществу

В 2003 году Red Hat приняла решение, которое взбесило тысячи пользователей. Компания свернула разработку Red Hat Linux — дружелюбной к домашним пользователям системы — в пользу корпоративной Red Hat Enterprise Linux. Бизнес-логика была безупречной: стабильность, сертификации, платная поддержка. Но сообщество восприняло это как предательство. Особенно после слов тогдашнего CEO Мэттью Сулика, который заявил, что для домашних пользователей Windows — «вероятно, правильная линейка продуктов». Эта фраза стала мемом и катализатором.

Параллельно с этим на почтовом списке рассылки уже зародилось движение rebuild — энтузиасты пересобирали исходные пакеты RHEL в независимые дистрибутивы. Среди них были VA Linux, компания Atipa (где работал Роки МакГо, впоследствии увековеченный в названии Rocky Linux), Джон Моррис с White Box Enterprise Linux и Дэвид Парсли с Tao Linux. Первым взорвал интернет именно White Box: после упоминания на Slashdot на него обрушился такой поток пользователей, что Моррис не справился с инфраструктурной нагрузкой и отказался от лидерства.

Из Caos в CentOS

Грегори Куртцер к тому моменту уже создал свой дистрибутив — Caos (Community Assembled Operating System). Работая в лаборатории Беркли при Министерстве энергетики США, он скучал по экосистеме Debian и менеджеру пакетов apt. «Почему вокруг RPM-мира нет такого же сообщества?» — задавался он вопросом. Ответом стал Caos: некоммерческий проект с собственными сборщиками и зеркалами, использовавший Red Hat как базу, но с расширенным набором пакетов сообщества.

Когда Red Hat закрыла бесплатную линейку, команда Caos оказалась в уникальном положении: у нее уже была инфраструктура для сборки и распространения. «Мы уже имели своих сборщиков, свои зеркала, мы уже собирали пакеты из Red Hat Linux и RHEL», — вспоминает Куртцер. Несколько членов команды предложили запустить проект, который станет преемником идеи свободного enterprise-дистрибутива. Так родился CentOS.

Почему версия 3, а не 1

Любопытный факт: CentOS версии 1 и 2 никогда не существовало. Проект стартовал сразу с третьей версии, потому что наиболее острой потребности в версии 3 и не существовало RHEL 1. «CentOS 3 разрабатывался почти полностью Роки», — отмечает Куртцер. Релиз состоялся 19 марта 2004 года. Позже Tao Linux и White Box мирно передали своих пользователей CentOS, предоставив планы миграции.

Как CentOS стал де-факто стандартом

Куртцер уверен: CentOS не был конкурентом Red Hat, а, напротив, помогал ей выживать. Модель подписки RHEL делала операционную систему дорогой для масштабирования. Организации выстроили двухуровневую стратегию: CentOS на основной массе серверов, RHEL — на критически важных узлах, где нужна валидация и поддержка. «Без CentOS большинство компаний, вероятно, перешли бы на Debian и Ubuntu, потому что никто не станет платить за поддержку всей инфраструктуры, построенной на бесплатном продукте», — считает основатель.

Переломный момент произошел на конференции по супервычислениям в Фениксе в середине 2000-х. Куртцер разговаривал с вендором, как к ним подошел незнакомец и спросил: «Почему вы не поддерживаете CentOS?» Это был первый раз, когда кто-то извне требовал поддержки проекта, не будучи частью узкого круга разработчиков. «Я подумал: вау, это круто», — вспоминает он. Вскоре CentOS начал появляться в резюме и вакансиях, а к началу 2010-х он был буквально повсюду.

Red Hat берёт под крыло — и отпускает

К 2014 году CentOS поддерживала крошечная команда энтузиастов, работавших бесплатно на благо индустрии. Red Hat предложила им официальное спонсорство и зарплаты. Многие увидели в этом попытку поглощения, но Куртцер был прагматичен: «Они жертвовали личной жизнью ради сообщества. Это была справедливая возможность получить работу и не отказываться от домашней жизни». На несколько лет ситуация стабилизировалась: задержки релизов сократились, документация улучшилась.

Однако в декабре 2020 года Red Hat объявила о повороте к CentOS Stream — платформе непрерывного выпуска, находящейся upstream относительно стабильного RHEL. Фактический конец поддержки CentOS Linux 8 наступил в конце 2021 года. Сообщество восприняло это как конец CentOS: «Общий консенсус заключался в том, что CentOS умер, и его заменяет какая-то rolling beta», — говорит Куртцер. Блог-пост с анонсом собрал рекордное количество комментариев, большинство из которых были гневными.

Роки возвращается: рождение Rocky Linux

К тому времени Куртцер управлял компанией CIQ, занимавшейся высокопроизводительными вычислениями. Его команда уже задумывалась над планом Б на случай исчезновения CentOS. Поэтому в течение двух часов после публикации блога он написал: «Привет всем, я основатель CentOS. Я собираюсь воссоздать проект. Присоединяйтесь ко мне в Slack». За четыре-шесть недель туда вошло более 10 000 человек. Платформа не справлялась с лимитом в 10 000 сообщений, но этого хватило, чтобы сформировать команды: релиз-инженерия, тестирование, брендинг, веб-разработка.

«У нас были футболки и мерч задолго до того, как появился код», — смеется Куртцер. Первые майки гласили: Rocky Linux с пометкой early supporter в скобках. Так появился Rocky Linux. За ним последовал AlmaLinux и ряд других клонов. Куртцер сравнивает конкуренцию между дистрибутивами с футбольными соперничествами, но подчеркивает: «Если что-то случится с Alma, на месте Rocky; если с Rocky — Alma; если с обоими, есть Oracle (при этом Oracle Linux также доступен бесплатно для использования). Это гарантирует стабильность экосистемы».

Выводы

История CentOS — это не просто хронология технических релизов. Это пример того, как бизнес-модель вендора порождает экосистему, которую сам вендор не в состоянии контролировать. Red Hat создала превосходный enterprise-продукт, но ее ценообразование оставило нишу, которую заполнили энтузиасты. В итоге CentOS не отнял у Red Hat клиентов — он подготовил рынок, приучил инженеров к RPM-стеку и сделал миграцию на платную поддержку логичным следующим шагом.

Сегодня, когда Rocky Linux и AlmaLinux продолжают дело пересборки RHEL, мы видим тот же принцип: открытые исходники нельзя вернуть в бутылку. Сообщество всегда найдет способ превратить код, «просто лежащий на сервере», в полноценную операционную систему. И, возможно, главный урок истории Куртцера в том, что иногда для создания чего-то масштабного достаточно просто не мешать.

Я искренне верю, что CentOS был очень полезен для RHEL в целом, учитывая выбор именно такой бизнес-модели.

Источники: интервью Грегори Куртцера изданию The Register.

В IPv6 каждый сетевой интерфейс получает link-local адрес из диапазона fe80::/10 (первые 10 бит фиксированы, остальное — адрес интерфейса). Если у машины два интерфейса — например, Ethernet и Wi-Fi — оба будут в одном и том же префиксе. Вопрос: как операционная система понимает, к какому именно интерфейсу адресовать пакет? Ответ — зоны (scopes).

В IPv6 зона интерфейса записывается через %: fe80::4%eth0. Это нужно, чтобы различать link-local адреса на разных сетевых интерфейсах.

В URL зона попадает внутрь квадратных скобок: [fe80::4%eth0]:80. Но символ % в URL — это начало percent-encoding, поэтому парсер ломается.

Решение — экранировать % как %25: [fe80::4%25eth0]:80. Это поведение зафиксировано в RFC 6874.

Проблема затрагивает не только Go, но и nginx, Python requests и браузеры. Поддержка зон в HTTP-клиентах остаётся фрагментарной.

Как зоны работают в IPv6

Зона (или scope ID) — это механизм, позволяющий ядру отличать адреса из пересекающихся диапазонов. Для link-local адресов fe80::/10 он критичен: без него роутинговая таблица не поймёт, через какой интерфейс отправлять трафик.

Формат зоны зависит от ОС. В Linux это имя интерфейса — eth0, wlan0, ens192. В Windows — числовой идентификатор интерфейса. Полный адрес выглядит так:

Квадратные скобки отделяют хост от порта — иначе двоеточия IPv6-адреса спутаются с разделителем порта.

Конфликт зон и URL

Теперь вставим этот адрес в URL. На первый взгляд всё просто:

Но попробуем распарсить его в Go:

Получаем ошибку:

Что произошло? В URL любой символ, не входящий в разрешённый набор, должен быть percent-encoded. Пробел превращается в %20, кириллица — в последовательности вроде %D0%90. Парсер видит %e и пытается декодировать его как hex-последовательность. et — не валидный байт, поэтому URL отклоняется.

Почему Go падает и как это чинить

С точки зрения стандарта Go ведёт себя корректно. RFC 3986 определяет URL-грамматику, а RFC 6874 специально дополняет её для IPv6-зон: символ % перед zone ID должен быть сам закодирован как %25.

Правильный URL выглядит так:

Проверяем в Go:

Вывод:

Go корректно декодирует %25 обратно в % при извлечении хоста. То есть библиотека поддерживает RFC 6874, но требует от вызывающего кода заранее закодировать зону.

RFC 6874: это не баг, а фича

В RFC 6874 формально описан синтаксис IPv6-адресов с зонами в литералах URL. Ключевой фрагмент:

То есть зона записывается не как %eth0, а как %25eth0. Это выглядит ужасно с точки зрения пользовательского опыта, но таково решение стандартизации: совместимость с существующей URL-грамматикой важнее эргономики.

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

И действительно, та же проблема есть и в других инструментах:

• nginx — тикет #623, созданный более десяти лет назад; проблема отсутствия поддержки link-local адресов с зонами до сих пор актуальна.
• Python requests — issue #6808: даже при ручном кодировании % как %25 библиотека некорректно обрабатывает IPv6-зоны в URL, потому что urllib3 декодирует %25 обратно в %.
• Браузеры — draft Schinazi объясняет, почему зоны ломают концепцию origin, и рекомендует использовать mDNS вместо прямого указания link-local адресов в URI.

Что делать разработчику

Если ваше Go-приложение работает с локальными IPv6-адресами — например, подключается к сервисам в Docker-сети, IoT-устройствам или внутренним API через link-local — учитывайте следующее:

1. Перед передачей IPv6-адреса с зоной в url.Parse всегда экранируйте % как %25.
2. Используйте net.JoinHostPort для сборки host:port — он корректно оборачивает IPv6 в скобки, но не кодирует зону. Дополнительное кодирование остаётся на вас.
3. Если адрес приходит от пользователя, валидируйте его до парсинга: зона должна содержать только допустимые символы (имя интерфейса в Linux, числовой ID в Windows).
4. Тестируйте на реальных интерфейсах с разными зонами, чтобы убедиться, что кодирование работает корректно в вашей среде.

На заметку:
Если вы пишете HTTP-клиент для embedded-устройств или промышленных контроллеров, которые общаются через link-local IPv6, ручное кодирование зоны — не костыль, а необходимость. Большинство библиотек не делают этого автоматически.

FAQ

Выводы

IPv6-зоны — редкий, но живучий граничный случай. Если вы пишете сетевой код на Go, который должен работать в гетерогенных средах — Docker, Kubernetes, embedded-системы, промышленные сети — знайте, что fe80::1%eth0 в URL превращается в fe80::1%25eth0. Это не баг парсера, а требование стандарта RFC 6874.

Инкапсулируйте кодирование зоны во вспомогательную функцию и всегда прогоняйте IPv6-адреса через неё перед сборкой URL. Экономия пяти минут сейчас обернётся часом отладки в продакшене, когда сервис внезапно не сможет достучаться до соседнего контейнера по link-local.

Источники:
• Xe Iaso — IPv6 zones in Go URLs
• RFC 6874 — Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
• draft-schinazi-httpbis-link-local-uri-bcp-03 — IPv6 Link-Local URIs

TSC (Time Stamp Counter) — это высокоточный счётчик тактов процессора, появившийся ещё во времена Intel Pentium. Он позволяет ядру измерять время с минимальными накладными расходами и используется в задачах от профилирования до планирования процессов.

Ранее код ядра содержал альтернативные пути для систем без TSC, поскольку поддержка распространялась на процессоры i486 и другие старые чипы, где счётчик отсутствовал. Теперь, когда эти архаичные платформы исключены из кодовой базы, мейнтейнеры подготовили патч, который делает TSC обязательным через систему конфигурации ядра (Kconfig).

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

Ядро Linux готовится сделать TSC безусловным требованием для x86-процессоров.

Решение стало возможно благодаря снятию поддержки устаревших чипов: Intel 486, AMD K5 и AMD Elan.

Патч уже находится в подготовительной ветке ядра и ожидается в цикле разработки Linux 7.2.

Удаление альтернативных ветвей кода упростит кодовую базу.

Что изменится для x86-процессоров в Linux

Для современного железа — ничего: все актуальные x86-процессоры (от Intel Core и Xeon до AMD Ryzen и EPYC) давно имеют TSC. Изменение затронет только разработчиков, которые всё ещё собирают ядро для ретро-совместимости.

Поддержка Intel 486 держалась в ядре десятилетиями из-за принципа максимальной совместимости, но в 2025–2026 годах мейнтейнеры начали массовую чистку legacy-кода. Удаление non-TSC путей — логичное продолжение этого процесса: раз чипов без счётчика больше не поддерживают, зачем тащить обходные механизмы?

Выводы

Отказ от альтернативных ветвей кода без TSC — ещё один шаг к чистке legacy-кода в Linux. Упрощение архитектуры x86-платформы ускорит дальнейшую разработку ядра и снизит нагрузку на мейнтейнеров, которые больше не будут тестировать редкие конфигурации без счётчика тактов.

Источник: Phoronix

Vim Classic — это форк текстового редактора Vim, поддерживаемый без помощи генеративного ИИ. Проект возглавляет известный разработчик open source Дрю Дево (Drew DeVault). Цель форка — сохранить и поддерживать классическую версию Vim, которую считают стабильной и предсказуемой.

Релиз Vim Classic 8.3.0 основан на Vim 8.2.0148. Разработчики консервативно перенесли (бэкпортировали) исправления ошибок и патчи безопасности из последующих версий оригинального Vim. При этом в форке намеренно не используется Vim9 script — относительно новый диалект скриптования, который появился в Vim 9 и вызвал дискуссии в сообществе.

Vim Classic 8.3.0 — стабильный LTS-форк классического Vim от Drew DeVault.

Основан на Vim 8.2.0148 с бэкпортом багфиксов и патчей безопасности.

В форке намеренно нет Vim9 script — только классический синтаксис.

Отдельные плагины могут быть несовместимы из-за отсутствия новых фич.

Проект рекомендуется для энтузиастов, готовых к возможным рискам.

Почему появился форк

В 2022 году Bram Moolenaar выпустил Vim 9 с новым диалектом Vim9 script. Он обещал прирост производительности в 10–100 раз по сравнению с классического скриптования. При этом новый диалект не обеспечил полную обратную совместимость, поэтому для полного использования преимуществ плагины желательно адаптировать. Часть сообщества восприняла это как разрыв с традициями.

Drew DeVault, создатель платформы SourceHut и автор оконного менеджера Sway, предложил альтернативу: взять проверенную базу Vim 8.2, аккуратно добавить важные исправления и выпустить её как Vim 8.3 — ту версию, которой, по его мнению, мог бы быть Vim без революционных изменений.

Что внутри Vim Classic 8.3

• Стабильная кодовая база Vim 8.2.0148.
• Перенесённые патчи безопасности (CVE, выявленные между версиями 8.2 и современным Vim).
• Сохранение классического скриптового движка без Vim9 script.
• Поддержка благотворительности в Уганде (charityware), как и в оригинальном Vim.

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

FAQ

Выводы

Vim Classic 8.3.0 — интересный эксперимент для тех, кто ценит стабильность и привычный интерфейс классического Vim. Форк не пытается заменить оригинал, а предлагает альтернативную ветку развития без спешки и революций.

Мы представляем альтернативную историю, в которой Vim 8.3 был выпущен без Vim9 script.

Источник: vim-classic.org

Wine (Wine Is Not an Emulator) — это open-source реализация Windows API, позволяющая запускать Windows-программы на Unix-подобных системах без виртуализации и ощутимой потери производительности.

Версия 11.10 интегрирует WineHQ свежий релиз VKD3D 2.0. Библиотека, вышедшая на прошлой неделе, получила улучшенную обработку HLSL-шейдеров, более корректную работу с legacy-байткодом Direct3D, доработки эффектов и интеграции DXIL. Также добавлена экспериментальная поддержка генерации шейдеров в Metal Shading Language для устройств Apple — это отдельный upstream-проект, не связанный с VKD3D-Proton от Valve/CodeWeavers, который используется в Steam Play (Proton).

Помимо графики, разработчики реализовали поддержку XPath без привязки к внешней библиотеке libxml2 — теперь соответствующие операции выполняются встроенными средствами. Кроме того, в релиз вошли многочисленные улучшения совместимости с VBScript.

Wine 11.10 — developmental-релиз от 29 мая 2026 года.

Обновление VKD3D до 2.0 для Direct3D 12 поверх Vulkan.

Экспериментальная поддержка Metal Shading Language для Apple-устройств.

Нативная реализация XPath без зависимости от libxml2.

17 исправлений багов для конкретных игр и приложений.

Что нового в Wine 11.10

VKD3D 2.0 и Direct3D 12

VKD3D — это официальная upstream-реализация Direct3D 12 через Vulkan от команды Wine. Версия 2.0 приносит:

• улучшенную обработку HLSL-шейдеров;
• лучшую поддержку legacy-байткода Direct3D;
• новые возможности эффектов и улучшенную интеграцию DXIL;
• экспериментальную генерацию шейдеров в Metal Shading Language для macOS и iOS.

Важно: для игр на Linux через Steam продолжает использоваться VKD3D-Proton — downstream-форк от Valve и CodeWeavers, который развивается отдельно и оптимизирован под игровые сценарии.

XPath без libxml2

Wine 11.10 получил собственную реализацию языка запросов XPath для работы с XML-документами. Ранее для этой функциональности требовалась внешняя библиотека libxml2, теперь зависимость устранена — это упрощает сборку и снижает поверхность для потенциальных проблем совместимости.

VBScript и исправления

Релиз содержит ряд улучшений совместимости с VBScript — языком сценариев Microsoft, который до сих пор используется в унаследованных корпоративных приложениях и системах администрирования Windows.

Также закрыто 17 известных ошибок, влияющих на работу конкретных игр и программ. Полный список доступен в официальном анонсе на WineHQ.org.

FAQ

Выводы

Wine 11.10 — типичный двухнедельный developmental-релиз: без революций, но с важными инкрементальными улучшениями. Обновление VKD3D до 2.0, нативная поддержка XPath и доработки VBScript делают слой совместимости чуть более зрелым и самодостаточным.

Wine продолжает закрывать разрыв между Windows-экосистемой и открытыми платформами — не через эмуляцию, а через тщательную реализацию нативных API.

Источник: Phoronix. Подробности и загрузки — на WineHQ.org.

Fragnasia — самостоятельная логическая ошибка в подсистеме XFRM ESP-in-TCP ядра Linux. Используя её, атакующий может записывать произвольные байты в кэш страниц доступных только для чтения файлов (page cache), в том числе системных бинарников, и таким образом, например, подменить содержимое /usr/bin/su, чтобы получить оболочку с правами root.

CVE-2026-46300 затрагивает все ядра Linux до 13 мая 2026 года.

Уязвимость позволяет локальному пользователю получить root без состояния гонки.

Эксплойт PoC уже опубликован исследователем William Bowling (Zellic).

Fragnasia относится к классу Dirty Frag, но это отдельный баг с отдельным патчем.

Временная мера: выгрузить модули esp4, esp6, rxrpc (ломает IPsec и AFS).

Что такое Fragnasia и как она связана с Dirty Frag

Уязвимость была раскрыта Уильямом Боулингом, руководителем направления assurance в компании Zellic, 13 мая 2026 года. Вместе с отчётом он опубликовал рабочий proof-of-concept эксплойт: он записывает примитив memory-write в ядро, затем через него портит page cache бинарника /usr/bin/su, чтобы получить root-оболочку.

Fragnasia принадлежит к новому классу уязвимостей Dirty Frag, который был раскрыт неделей ранее. Dirty Frag объединяет баги в том же XFRM-коде, позволяющие модифицировать защищённые системные файлы в памяти. Однако в отличие от оригинального Dirty Frag, который цепляет два отдельных CVE (CVE-2026-43284 и CVE-2026-43500) через состояние гонки, Fragnasia — самостоятельный баг, требующий отдельного патча.

Fragnasia — член класса уязвимостей Dirty Frag. Это отдельный баг в ESP/XFRM, отличный от dirtyfrag, с собственным патчем. Однако он находится в той же поверхности атаки, и митигация для него такая же, как для dirtyfrag. Он злоупотребляет логической ошибкой в подсистеме Linux XFRM ESP-in-TCP для произвольной побайтовой записи в page cache файлов только для чтения — без какой-либо состояния гонки.

Как работает эксплойт Fragnasia: технические детали CVE-2026-46300

Ошибка находится в подсистеме XFRM — фреймворке трансформации пакетов ядра Linux, используемом для реализации IPsec. Конкретно затронут путь обработки ESP-пакетов поверх TCP-соединений (ESP-in-TCP). Логический баг позволяет выйти за пределы разрешённых операций записи и изменить содержимое страниц в page cache — включая страницы, отображённые из файлов, которые открыты только на чтение (O_RDONLY).

Механизм эксплойта PoC: злоупотребляя этим примитивом записи, атакующий перезаписывает page cache системного бинарника /usr/bin/su. Поскольку запись происходит в памяти (а не на диске), после перезагрузки бинарник восстанавливается. Для сервера с непрерывной работой это сценарий полного захвата: root-доступ без следов на диске.

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

Полная защита — обновление ядра до версии, выпущенной 13 мая 2026 года или позже. Дистрибутивы Linux уже выпускают патчи. Если обновление невозможно немедленно, применяйте временную митигацию:

Важно: выгрузка модулей сломает AFS (распределённая файловая система) и IPsec VPN. Оцените последствия перед применением в продакшне.

Эти же команды используются для митигации Dirty Frag — они отключают уязвимые модули ядра и запрещают их повторную загрузку через /etc/modprobe.d/dirtyfrag.conf.

1. Проверьте версию ядра: uname -r
2. Обновитесь через менеджер пакетов: apt upgrade / dnf upgrade / yum update
3. Перезагрузите систему для загрузки нового ядра
4. Если обновление невозможно — выгрузите esp4, esp6, rxrpc командами выше

Контекст: волна уязвимостей класса Dirty Frag

Раскрытие Fragnasia происходит на фоне нескольких недавних серьёзных уязвимостей в ядре Linux:

• Dirty Frag (CVE-2026-43284 + CVE-2026-43500) — предшественник Fragnasia, раскрыт неделей ранее. Публичный PoC эксплойт доступен.
• Copy Fail — ещё одна уязвимость повышения привилегий, сейчас активно эксплуатируется в атаках. 1 мая 2026 CISA добавило её в каталог известных эксплуатируемых уязвимостей (KEV) и обязало федеральные агентства США закрыть её до 15 мая.
• Pack2TheRoot — уязвимость в демоне PackageKit, присутствовавшая незамеченной десять лет. Закрыта в апреле 2026.

Все три уязвимости — локальное повышение привилегий до root. Наличие публичных PoC для Fragnasia и Dirty Frag делает их особенно опасными для систем с ненадёжными локальными пользователями (shared hosting, контейнерные среды).

Итого

Fragnasia — третья за месяц серьёзная уязвимость повышения привилегий в ядре Linux, и первая в новом классе Dirty Frag с публичным PoC без состояния гонки. Обновите ядро в первую очередь на серверах с доступом нескольких пользователей, в контейнерных окружениях (если namespace-изоляции недостаточно) и там, где уже применялась митигация для Copy Fail.

Подробнее — в материале BleepingComputer. База уязвимостей NVD: CVE-2026-46300 на NIST.

Если верить статистике, сейчас ежедневно создается около 402,74 миллионов терабайт данных.

Согласитесь, довольно внушительная цифра.

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

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

Мы решили перейти на гибкое объектное хранилище S3 – чтобы централизовано хранить и управлять текстами, креативами, отчетами и другими маркетинговыми материалами с удобным доступом внутри команды, ведь S3 позволяет хранить файлы любого типа и объема и масштабируется автоматически. Осталось только выбрать ПО для хранения файлов в облаке, к которому можно подключить S3.

Ранее у нас был опыт использования Nextcloud, однако его функционал, подобный швейцарскому ножу (встроенные календарь, конференции, таск-трекер и т. д.), оказался слишком объемен для нашей, по сути, скромной задачи – удобного и стабильного хранения файлов.

Вот почему мы подыскали аналог Nextcloud – ownCloud. В отличие от более функционального Nextcloud, ownCloud заточен исключительно на работу с файлами. И при этом он поддерживает подключение облачного объектного хранилища S3. Поэтому для нас в сравнении Nextcloud vs ownCloud выбор был очевиден.

В этой статье я расскажу, какие возможности есть у ownCloud, почему это ПО может быть полезно и как настроить связку ownCloud и S3. Если вы хотите организовать безопасное, контролируемое хранение и обмен данными на работе или дома, то этот материал будет для вас полезен.

Что может ownCloud

Для начала – буквально несколько слов об ownCloud и его возможностях.

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

OwnCloud позволяет:

1. получать доступ к данным из любой точки мира и хранить файлы на собственном сервере – под вашим полным контролем;
2. синхронизировать данные между устройствами – доступ к файлам возможен с компьютеров (Windows, macOS, Linux), смартфонов (iOS, Android) и через браузер, изменения на одном устройстве мгновенно появляются на всех остальных;
3. делиться файлами и папками по ссылке, настраивая права доступа, пароли и срок действия ссылок;
4. совместно работать с документами, отслеживать историю изменений и возвращаться к любой предыдущей версии файла.

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

Сегодня ownCloud используют компании (Philips, Nationwide, Zeppelin и др.) в самых разных сферах (IT, машиностроение, медицина и т. д.).

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

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

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

Для каких задач мы используем ownCloud и S3

1. Централизованное управление материалами

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

В итоге каждый член команды может видеть версии файлов (это важно для правок), нет хаоса в почте и мессенджерах.

2. Безопасное взаимодействие с подрядчиками

Связка ownCloud и S3 позволяет выгружать внешним специалистам материалы и получать результаты работ без прямого доступа к внутренней сети компании. Мы создали папку с публичной ссылкой, но жесткими ограничениями – паролем, сроком жизни ссылки в течение нескольких дней и разрешением на загрузку файлов без права просмотра папки.

На практике это работает так: менеджер создает ссылку и отправляет подрядчику, подрядчик переходит по ссылке и загружает архив с готовыми материалами, файл попадает в ownCloud, а его содержимое сохраняется в S3. Таким образом, подрядчик не видит, какие еще файлы лежат в папке, а мы контролируем, кто, что и когда загрузил.

3. Долгосрочный архив креативов и отчетов

По закону (152-ФЗ в РФ или GDPR в Европе) компания обязана хранить персональные данные клиентов, а также отчеты о рассылках и рекламных акциях на протяжении определенного времени.

Для решения этой задачи мы настроили правило: файлы старше 90 дней автоматически перемещаются в S3 Glacier (холодное хранилище) – этот класс снижает стоимость хранения, а если, например, юристу понадобится скачать какой-нибудь отчет спустя 2–3 года, он просто выгрузит его из ownCloud буквально за 5–10 минут.

Теперь – в деталях и по шагам о том, как начать использовать ownCloud в связке с S3.

Как развернуть ownCloud и подключить S3

OwnCloud удобно использовать с объектным хранилищем S3 – таким образом можно:

1. масштабировать систему – S3 расширяется автоматически и не имеет ограничений по объему и количеству размещаемых данных и файлов;
2. оптимизировать затраты – можно платить не за дорогую конфигурацию виртуального сервера с большим объемом диска, а лишь за фактически занимаемое место, по модели pay as you go (оплата по мере потребления);
3. повысить надежность хранения – за счет встроенной в S3 тройной репликации данных (файлы хранятся в 3 копиях и размещаются на независимых серверах в разных стойках для абсолютной сохранности данных).

Итак, разберем, как настроить связку ownCloud и S3.

Разработчики ownCloud предлагают два варианта установки. Можно скачать ownCloud и установить его вручную или использовать Docker-контейнеры. Мы выберем второй вариант.

Для размещения ownCloud в нашем примере создадим виртуальный сервер на базе готового решения Docker.

Можно подключиться к серверу по SSH или с помощью терминала в панели управления.

Для размещения файлов создайте бакет объектного хранилища S3. Реквизиты доступа к нему будут в карточке бакета в панели:

Создайте директорию для размещения конфигурационных файлов проекта и перейдите в нее:

Затем вставьте в файл docker-compose.yml следующее содержимое с помощью любого текстового редактора:

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

Теперь необходимо отредактировать эти строки:

1. ownCloud_DOMAIN и ownCloud_TRUSTED_DOMAINS – укажите домен (так как ownCloud будет размещен за обратным прокси, указывать рабочий порт здесь не требуется);
2. ADMIN_USERNAME – логин администратора;
3. ADMIN_PASSWORD – пароль администратора.

Обратите внимание! Изменение ADMIN_USERNAME и ADMIN_PASSWORD уже после развертывания контейнеров не возымеет эффекта. Изменить пароль администратора вы можете в настройках пользователя в веб-интерфейсе.

Далее необходимо указать параметры подключения к S3.

• ownCloud_OBJECTSTORE_BUCKET – имя бакета S3;
• ownCloud_OBJECTSTORE_ENDPOINT – эндпоинт хранилища (например, https://s3.ru1.storage.beget.cloud);
• ownCloud_OBJECTSTORE_REGION – регион (ru1 для Beget);
• ownCloud_OBJECTSTORE_KEY – Access key бакета;
• ownCloud_OBJECTSTORE_SECRET – Secret key бакета.

Сохраните файл.

Остается лишь добавить файл конфигурации для Caddy – обратного прокси, через который пользователи будут получать доступ к ownCloud.

Создайте директорию config:

После чего создайте в ней файл конфигурации Caddyfile. Добавьте в него следующее содержимое, указав вместо ownCloud.betutorial.ru ваш домен ownCloud:

Обратите внимание! Caddy выпустит SSL-сертификат на домен автоматически.

Все запросы к домену будут проксироваться в контейнер ownCloud_server.

На этом настройка конфигурационных файлов завершена, можно запускать контейнеры:

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

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

Выполните вход со стандартными доступами.

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

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

Теперь проверим работу объектного хранилища – перейдем на главную страницу и загрузим файлы:

Файлы также появились и в объектном хранилище:

Обратите внимание! Файлы, которые вы удалите в ownCloud, будут перемещены в корзину и останутся в S3. Для их полного удаления очистите корзину ownCloud.

Чтобы делиться паролями с новыми пользователями, необходимо настроить отправку почты в ownCloud, сделать это можно в разделе Settings>General.

В нашем примере мы настроим отправку через SMTP:

После указания данных введите тестовый email и нажмите “Send email”. Если отправка успешна, вы получите уведомление об этом:

А на почтовый ящик поступит письмо:

На этом настройка завершена – можно начинать работать с файлами, используя связку ownCloud и S3.

Заключение

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

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

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

Уязвимость CVE-2026-31431 по прозвищу Copy Fail — это локальный privilege escalation в ядре Linux с CVSS 7.8. Исследователи опубликовали подробное описание и рабочий PoC; mainline-фикс влит 1 апреля 2026 года, но ни Ubuntu, ни Amazon, ни SUSE до сих пор не выпустили обновлённый пакет ядра.

Под ударом — все основные дистрибутивы с ядром, собранным с 2017 года. Эксплойт цепляет AF_ALG-сокет с системным вызовом splice(), выполняет произвольную 4-байтовую запись в страницу page-cache, затем подменяет байты в /usr/bin/su — и запускает root-шелл.

CVE-2026-31431 (Copy Fail) — локальный privesc в ядре Linux, CVSS 7.8. Опубликован 29 апреля 2026 года, есть рабочий PoC.

Дыра в модуле algif_aead — часть userspace crypto API ядра. Появилась в 2017 году с коммитом 72548b093ee3.

Затронуты ядра 2017–2026. Подтверждено: Ubuntu 24.04 (6.17), Amazon Linux 2023 (6.18), RHEL 10.1 (6.12), SUSE 16 (6.12). Ubuntu 26.04 «Resolute» и новее — нет.

Патчей нет ни у кого. Mainline-фикс — коммит a664bf3d603d от 1 апреля, но Ubuntu, Amazon, SUSE на 30 апреля статус — «No fix available».

Что делать сейчас: отключить модуль algif_aead через modprobe.d, в контейнерах — блокировать AF_ALG-сокеты через seccomp-профиль.

Что такое AF_ALG и где это в системе

AF_ALG — это семейство сокетов в ядре Linux, через которое userspace-программы получают доступ к криптографическому API ядра без libcrypto. Открываете сокет с типом AF_ALG, говорите ядру «дай мне AES-GCM», передаёте данные через обычный read/write — и получаете шифрованные обратно. Никаких прав и привилегий не требуется: интерфейс задумывался для удобства, чтобы криптографию можно было дёргать из любой программы.

Уязвимый компонент — модуль algif_aead, обработчик AEAD-операций (Authenticated Encryption with Associated Data — это AES-GCM, ChaCha20-Poly1305 и подобные алгоритмы). В нём в 2017 году появилась оптимизация: вместо того чтобы копировать данные пользователя в служебный буфер, ядро стало работать прямо со страницами page-cache — кэшем файловой системы. Идея была разумной: убрать лишнюю копию, ускорить шифрование больших файлов. Через девять лет выяснилось, чем это обернулось.

Технический разбор: четыре байта в чужой странице

Атака собирается из двух примитивов. Первый — AF_ALG-сокет, который из-за оптимизации 2017 года готов писать результат шифрования в любую page-cache-страницу, переданную в scatterlist назначения. Второй — системный вызов splice(), через который непривилегированный процесс может протолкнуть в этот scatterlist страницу из произвольного файла, который разрешено читать.

Контролировать запись на байт получается так: исследователи подбирают входные данные для AEAD-операции так, чтобы первые четыре байта зашифрованного результата совпали с нужным значением. Эти четыре байта ядро без проверок пишет в указанную страницу — а страница, благодаря splice(), оказывается куском исполняемого файла. Цель — /usr/bin/su: в нужное место кода вставляется четыре байта, которые превращают проверку пароля в return 0. После этого su root пускает любого пользователя без пароля.

Mainline-фикс — коммит a664bf3d603d, влитый 1 апреля 2026 года, — отменяет ту самую оптимизацию 2017 года: модуль снова работает через служебный буфер, и страницы page-cache в scatterlist назначения больше не попадают.

На дистрибутивах с включённым AF_ALG это даже не эксплойт в классическом смысле. Это корректное использование документированного интерфейса ядра — просто результат корректного использования оказывается «root».

Кого это касается

Подтверждённые исследователями системы (с конкретной версией ядра, на которой воспроизвели PoC):

• Ubuntu 24.04 LTS — ядро 6.17.0-1007-aws
• Amazon Linux 2023 — ядро 6.18.8-9.213.amzn2023
• RHEL 10.1 — ядро 6.12.0-124.45.1.el10_1
• SUSE Linux Enterprise 16 — ядро 6.12.0-160000.9-default

Все остальные дистрибутивы с ядром, собранным между 2017 и текущим релизом, скорее всего, тоже уязвимы: Debian, Arch Linux, Fedora, Rocky Linux, AlmaLinux, Oracle Linux, плюс embedded-сборки. Не затронуто только ядро Ubuntu 26.04 «Resolute» и новее.

Статус патчей у вендоров на 30 апреля 2026 года:

• Ubuntu 20.04–24.04 — патча нет
• Amazon Linux 2023 — патча нет
• SUSE Linux Enterprise — патча нет
• Red Hat Enterprise Linux — статус неизвестен

В первую очередь под угрозой — Kubernetes-кластеры и CI/CD-раннеры, где запускаются чужие контейнеры или скрипты: им достаточно AF_ALG-сокета, доступного по умолчанию, чтобы получить root на ноде. Облачные ВМ, где соседствуют разные пользователи и где shared-tenancy не отключён, тоже в группе риска.

Что делать прямо сейчас

Отключить модуль algif_aead

CERT-EU рекомендует отключать модуль персистентно — через modprobe.d и сразу же выгрузить из памяти, если он уже загружен:

После этого попытка загрузить модуль вернётся ошибкой, и приложения не смогут открыть AF_ALG-сокет с типом aead. На dm-crypt/LUKS, kTLS, IPsec/XFRM, OpenSSL, GnuTLS, NSS и SSH это никак не повлияет — все они работают через другие интерфейсы. Под удар попадают только программы, которые явно настроены на afalg-движок или открывают сокеты aead/skcipher/hash напрямую. Проверить, кто использует, можно так:

Заблокировать AF_ALG в контейнерах через seccomp

Эксплойт начинается с открытия AF_ALG-сокета, поэтому в контейнерах достаточно запретить системный вызов socket() для этого семейства. CERT-EU рекомендует это делать на всех контейнеризованных нагрузках вне зависимости от того, пропатчено ядро или нет — это работает и как mitigation, и как defense-in-depth. Минимальный seccomp-профиль:

Значение 38 — это константа AF_ALG в linux/socket.h. Профиль подключается через --security-opt seccomp=... в Docker и Podman, в Kubernetes — через securityContext.seccompProfile.

Выводы

Copy Fail — типовая история про оптимизацию ради скорости, которая девять лет хранила в себе одну из самых удобных лазеек к root. Ничего сложного для атакующего, ничего сильно ломающегося при mitigation — а вендоры всё равно опаздывают с патчами. До тех пор, пока в apt update или dnf upgrade не появится новое ядро, защита лежит на админах: один modprobe-блок и один seccomp-профиль закрывают вектор полностью.

Источники: CERT-EU Security Advisory 2026-005, copy.fail — описание и PoC исследователей, трекеры вендоров: Ubuntu, SUSE, Red Hat.

Проверьте свои ноды и контейнеры прямо сейчас — пропатченных ядер для большинства дистрибутивов всё ещё нет, и ситуация не изменится в ближайшие сутки.

Релиз замыкает двухлетний LTS-цикл: между Ubuntu 24.04 LTS «Noble Numbat» и 26.04 LTS вышли три промежуточных релиза (24.10, 25.04, 25.10), и именно в них Canonical обкатал большую часть изменений — от замены классических GNOME-приложений на Rust-варианты до Wayland-only сессии и NTSYNC-драйвера для Windows-игр в Proton. К моменту LTS эти переходы уже прошли стадию «сыро» — в 26.04 они приходят готовыми.

Ядро и безопасность: Linux 7.0 как дефолтное ядро, post-quantum подписи модулей (ML-DSA), OpenSSH 10.2p1 с гибридным обменом ключами mlkem768x25519-sha256.

Десктоп: GNOME 50 на Wayland-only сессии, GIMP 3.0, LibreOffice 25.8, Firefox 149, Thunderbird 140 «Eclipse».

Rust в ядре системы: новый монитор ресурсов Resources (с трекингом NPU), PDF-вьюер Papers, просмотрщик картинок Loupe, терминал Ptyxis с интеграцией podman и distrobox — все переписаны на Rust.

Железо: официальный ARM64 desktop ISO с поддержкой Snapdragon X Elite, полноценный Wayland на NVIDIA, apt install rocm для AMD GPU из коробки.

Поддержка: security-обновления до 2031 года, до 2036 года — с Ubuntu Pro ESM.

Rust въехал в базовые утилиты — и это главное изменение

Главный технический сдвиг 26.04 — системные утилиты GNOME переписываются на Rust. Это не эксперимент энтузиастов, а дефолт новой LTS. Вот что поменялось на вашем рабочем столе:

• Resources заменяет System Monitor и Power Statistics. Группирует процессы в приложения, трекает использование GPU (включая видеокодеры), NPU, частоты CPU/GPU/памяти. Написан на Rust с GTK 4.
• Papers пришёл на смену Evince как дефолтный PDF-вьюер. Перенесён на GTK4 и частично переписан на Rust.
• Loupe вместо Eye of GNOME для картинок — чистый Rust поверх библиотеки Glycin.
• Ptyxis заменяет GNOME Terminal. Из интересного — прямая интеграция с podman, toolbox и distrobox (вкладка сразу в контейнере), session-save для восстановления вкладок после перезапуска.
• gst-thumbnailers генерирует превью для видео и аудио — через Rust-биндинги к GStreamer. Лучше находит «интересные» кадры, чем Totem.

Параллельно ядро Linux 7.0 окончательно признало Rust-драйверы как часть основного дерева ядра — они собираются вместе с остальными модулями без отдельных галок в конфиге. Это тот момент, когда «Rust в Linux» перестаёт быть новостью и становится инфраструктурой.

Wayland-only, ARM64 desktop и NVIDIA

Ubuntu 26.04 окончательно выкидывает X.org-сессию из GDM — десктоп GNOME запускается только под Wayland. Приложения под X.org продолжат работать через XWayland-слой совместимости, а если нужен именно X11 — остаются сессии KDE on X11, Xfce, MATE, i3 и другие.

Для NVIDIA это первый LTS с полной поддержкой Wayland — включая то, что раньше ломало композитор: XID-ошибки GPU, suspend/resume, Secure Boot-модули. Работает без возни.

Отдельный пункт — первый в истории Ubuntu официальный ARM64 Desktop ISO. Прицел на виртуальные машины, ACPI+EFI-платформы и устройства на Snapdragon (включая Snapdragon X Elite). Это запуск Ubuntu Desktop как гражданина первого класса на ARM-ноутбуках с UEFI.

Для AMD ROCm теперь ставится прямо из репозиториев Ubuntu — одной командой sudo apt install rocm. До 26.04 нужно было подключать сторонний репо от AMD и следить за версией — теперь это стандартный deb-пакет.

Серверная часть: OpenSSH, post-quantum и разблокировка DSA

OpenSSH прыгнул с 9.6p1 в 24.04 LTS до 10.2p1. Главные изменения — про криптографию следующих десяти лет:

• Поддержка гибридного post-quantum обмена ключами mlkem768x25519-sha256 — по умолчанию. Это та самая защита от «harvest now, decrypt later».
• Предупреждение при подключении без post-quantum-алгоритмов — чтобы администраторы видели устаревающие SSH-конфиги.
• Слабый DSA-алгоритм подписи удалён. Если у вас где-то остались DSA-ключи — не обновляйте хосты без миграции на ed25519 или RSA.
• PerSourcePenalties штрафует IP, которые не дожимают аутентификацию — мягкий встроенный fail2ban.
• Хост-ключи DSA больше не генерируются при установке.

На уровне ядра появились post-quantum подписи модулей через ML-DSA — CA для kernel modules защищён от будущих квантовых атак. Не ваша ежедневная боль, но LTS со сроком до 2036 обязана это учитывать.

Игры под Windows и ускорение видео

Для пользователей Steam Play и Wine в Ubuntu 26.04 — новый драйвер NTSYNC, эмулирующий примитивы синхронизации Windows NT. На синтетических тестах даёт заметный прирост FPS в играх, использующих многопоточность через WaitForSingleObject и подобные API.

Hardware-accelerated video encoding и decoding теперь включены по умолчанию для AMD и Intel через VA-API — никаких дополнительных пакетов. JPEG XL поддерживается из коробки.

Для Windows-пользователей, которые ставят Ubuntu рядом — улучшен dual boot с BitLocker. Установщик теперь видит зашифрованные разделы и корректно рядом с ними размещается.

Как обновиться и что проверить до апдейта

Путь обновления с точки зрения Canonical:

1. С Ubuntu 24.04 LTS (Noble Numbat) — прямое обновление через do-release-upgrade, Canonical запустит автоматическое предложение через пару недель после релиза.
2. С Ubuntu 25.10 (Questing Quokka) — тоже прямое обновление.
3. С Ubuntu 22.04 LTS (Jammy Jellyfish) — только через промежуточный апгрейд до 24.04 LTS, и уже потом на 26.04 LTS.
4. С Ubuntu 25.04 (EOL с января 2026) — сначала на 25.10, затем на 26.04 LTS. Либо — чистая переустановка.
5. Требования: для десктопа нужен двухъядерный 2 GHz, минимум 4 ГБ RAM и 25 ГБ свободного места. Если меньше — смотрите в сторону Xubuntu или Lubuntu.

Что стоит проверить до нажатия кнопки:

• Кастомные X11-утилиты, которые вы использовали годами, — под Wayland не все работают. Если зависите от autokey, xbindkeys или специфичных скриншотилок — протестируйте в live-сессии сначала.
• Кастомные сборки ядра или out-of-tree модули — Linux 7.0 требует обновления драйверов.
• DSA-ключи в SSH — мигрируйте на ed25519 до апдейта.
• NVIDIA-сетапы с проприетарным драйвером — Canonical обещает полный Wayland, но протестировать на своём железе безопаснее отдельно.

Выводы

Ubuntu 26.04 LTS — это не «ещё один LTS с обновлёнными пакетами». Это точка, в которой Canonical одновременно закрывает три длинных перехода: Wayland-only на десктопе, Rust в системных утилитах и официальная ARM64-платформа для десктопа. Плюс криптография нового поколения в SSH и ядре, которая закладывает основу на десятилетие вперёд — как раз под срок поддержки LTS.

Если вы в продакшне на 22.04 LTS — теперь двигаться через 24.04 LTS к 26.04 LTS без спешки, но планово: 22.04 LTS теряет стандартную поддержку в апреле 2027. Если на 24.04 LTS — обновление посимпатичнее, потому что промежуточные релизы пропустили большую часть «переходных болей».

Источники: Ubuntu 26.04 LTS release notes, Summary for LTS users, The Linux Kernel Archives.

Недавно я много думала про терминал, и вчера мне стало интересно: что вообще происходит со всеми этими «control codes» — Ctrl-A, Ctrl-C, Ctrl-W и так далее? Я собрала таблицу всех 33 ASCII control characters и того, что они делают на моей машине (macOS). Оговорок там миллион, но ниже я расскажу, что это всё значит и какие есть нюансы.

• В ASCII всего 33 control-кода: A–Z (26 штук) плюс 7 дополнительных (@, [, \, ], ^, _, ?). Сделать Ctrl-1 как шорткат невозможно.
• Коды обрабатываются в трёх разных местах: OS terminal driver (например, Ctrl-C → SIGINT), библиотека readline (Ctrl-A, Ctrl-E) или само приложение (emacs использует Ctrl-X).
• Ctrl-M = Enter, Ctrl-I = Tab — поэтому их нельзя использовать как отдельные шорткаты без спец-настройки эмулятора.
• Режим терминала — canonical или noncanonical — определяет, кто обрабатывает Backspace, Ctrl-W и Ctrl-U: OS или сама программа. Разбор обоих режимов — в теле статьи.
• Утилита stty -a показывает текущие маппинги OS-кодов, а stty sane лечит «сломанный» терминал.
• Backspace на разных системах посылает либо байт 127, либо 8 — отсюда исторические войны и конфигурации через stty erase.

Коды обрабатываются в разных местах

Первое, что меня удивило: 33 control-кода делятся (очень условно) на три категории в зависимости от того, где они обрабатываются.

• Обрабатываются OS terminal driver — например, когда ОС видит байт 3 (Ctrl-C), она посылает сигнал SIGINT текущей программе.
• Передаются приложению как есть, и приложение делает с ними что хочет. Внутри этой группы ещё три подгруппы: соответствуют реальной клавише (Enter → байт 13, Tab, Backspace); используются библиотекой readline для редактирования строки (Ctrl-A, Ctrl-E, Ctrl-W); используются конкретными приложениями (Ctrl-X в emacs).

Никакой логики в том, какой код к какой категории относится, нет — просто так исторически сложилось.

Почему именно 33 — и почему «Ctrl-1» не существует

Ещё один сюрприз: control-кодов всего 33 штуки — буквы A–Z плюс семь дополнительных символов (@, [, \, ], ^, _, ?). Это значит, что если вы хотите сделать Ctrl-1 шорткатом в терминальном приложении — такого шортката просто не существует. На моей машине Ctrl-1 — это ровно то же самое, что нажать 1, а Ctrl-3 эквивалентно Ctrl-[.

Ctrl+Shift+C тоже не control-код — это комбинация, которую обрабатывает сам эмулятор терминала. В Linux Ctrl+Shift+X часто используется эмулятором для копирования, открытия новой вкладки или вставки — до TTY они не доходят.

Я всё время использую Ctrl+Left Arrow, но это тоже не control-код — это ANSI escape sequence (ESC[1;5D, где ESC — это сам байт 27 = Ctrl-[), совсем другая история.

Это устроено совсем не так, как шорткаты в GUI, где можно сделать Ctrl+любая клавиша.

Официальные ASCII-имена бесполезны

Каждый из 33 control-кодов имеет имя в ASCII (например, байт 3 — это ETX). Но эти имена придумывали не для компьютеров, а для телеграфа. Когда коды перешли в UNIX-терминалы, половина из них сменила смысл. В итоге ASCII-имена сегодня бесполезны в 50% случаев — проще вообще игнорировать их, чем пытаться понять, какие имена ещё соответствуют оригинальному значению.

Почему Ctrl-M и Ctrl-I — это Enter и Tab

Ctrl-M буквально идентичен Enter, а Ctrl-I — это Tab. Это делает их почти непригодными для шорткатов.

Некоторые всё равно используют Ctrl-I и Ctrl-M как шорткаты, но для этого надо настроить эмулятор терминала, чтобы он обрабатывал эти нажатия иначе, чем по умолчанию. Основной вывод: если пишете терминальное приложение — не используйте Ctrl-I и Ctrl-M как шорткаты.

Как узнать, какой именно код посылается

Пока я писала этот разбор, мне пришлось много экспериментировать с разными комбинациями клавиш. Я написала маленький Python-скрипт echo-key.py, который распечатывает получаемые байты. Наверняка есть более официальный способ, но мне удобнее иметь скрипт, который можно подкрутить под себя.

Оговорка: canonical vs noncanonical mode

Два кода — Ctrl-W и Ctrl-U — я в таблице пометила как «обрабатываются OS». На самом деле это не всегда так — зависит от режима терминала.

В canonical mode (построчный ввод) программа получает ввод только после нажатия Enter — до этого OS сама обрабатывает Backspace, Ctrl-W и другие правки. В noncanonical mode (посимвольный ввод) программа получает каждое нажатие сразу, и коды Ctrl-W и Ctrl-U проходят в программу, которая обрабатывает их как хочет.

Примеры программ в canonical mode:

• Любые неинтерактивные утилиты вроде grep или cat.
• git, по моему опыту.

В noncanonical mode:

• python3, irb и другие REPL.
• Ваш шелл.
• Любой полноэкранный TUI (less, vim).

Оговорка: все OS-коды настраиваются через stty

Я написала «Ctrl-C посылает SIGINT», но технически это не обязательно так. Все коды, которые обрабатывает OS terminal driver, плюс Backspace, можно переназначить утилитой stty. Текущие маппинги смотрят через stty -a.

Я лично ни разу ничего не переопределяла через stty и не могу придумать, зачем бы мне это делать — это рецепт для путаницы и катастрофы. Но когда я спросила в Mastodon, люди назвали такие сценарии:

• Починить сломанный терминал через stty sane.
• Настроить работу Backspace: stty erase ^H.
• Включить поток управления: stty ixoff.
• Некоторые даже переназначают SIGINT на другую клавишу, например на DELETE.

Оговорка: сигналы можно отключить

• Если режим терминала ISIG (флаг, разрешающий сигналы от Ctrl-C и Ctrl-Z) выключен, OS вообще не посылает сигналы. Vim, например, отключает ISIG при запуске.
• На macOS и других BSD-системах есть дополнительный control-код Ctrl-T, который посылает SIGINFO.

Какие режимы ставит программа, можно посмотреть через strace: режимы терминала устанавливаются системным вызовом ioctl.

Комбинация режимов, которую ставит vim при запуске, по сути и есть так называемый «raw mode» — подробности в man cfmakeraw.

Конфликтов очень много

Раз кодов всего 33, конфликтов за один и тот же код — навалом. По умолчанию Ctrl-S замораживает экран, но если выключить этот flow-control, readline использует Ctrl-S для forward search.

Другой пример: Ctrl-T на моей машине то посылает SIGINFO, то переставляет местами два последних символа, то делает что-то совсем третье — в зависимости от того, установлен ли в программе ISIG и использует ли она readline (или имитирует его поведение).

Backspace, «другой» Backspace и историческая боль

В таблице я пометила байт 127 как «backspace», а байт 8 как «другой backspace». История оказалась настолько запутанной, что именно этот пункт собрал больше всего откликов в Mastodon.

Вот как это работает на моей машине:

1. Я нажимаю клавишу Backspace.
2. В TTY уходит байт 127, в ASCII он называется DEL.
3. OS terminal driver и readline оба замапили 127 на «удалить символ» — работает и в canonical, и в noncanonical mode.
4. Предыдущий символ исчезает.

Если нажать Ctrl+H, в readline-приложении это сработает как Backspace, а в программе без readline (например, cat) просто напечатается ^H.

У кого-то шаг 2 другой: клавиша Backspace посылает байт 8 вместо 127, и чтобы она работала, надо настроить OS через stty erase ^H. В Debian Policy Manual есть целый раздел про конфигурацию клавиатуры — по моему пониманию, его написали в 90-х, когда царила путаница с тем, что должен делать Backspace, и нужен был какой-то стандарт, чтобы всё заработало.

На разных машинах всё по-разному

Я почти наверняка упустила ещё десяток способов, которыми «как это работает на моей машине» может отличаться от «как это работает у других», и в моих описаниях тоже могут быть неточности. По stty -a у меня есть ещё три экзотических маппинга — Ctrl-O как «discard», Ctrl-R как «reprint» и Ctrl-Y как «dsusp» — но на практике они редко что-то делают и чаще всего проходят в приложение как есть.

Честно говоря, это необязательно знать

Мне кажется, содержимое этого поста интересное, но не обязательно полезное. Я использовала терминал каждый день последние 20 лет, не зная почти ничего из этого — я просто знала на практике, что делают Ctrl-C, Ctrl-D, Ctrl-Z, Ctrl-R, Ctrl-L (ну и Ctrl-A, Ctrl-E, Ctrl-W), и не задумывалась о деталях. Этого почти всегда хватало, кроме случая, когда я возилась с xterm.js.

От редакции: знание это становится практическим в одном-двух сценариях, и их стоит держать в голове. Во-первых, когда терминал «ломается» — ввод не виден, Enter работает странно — вместо перезапуска шелла поможет stty sane или reset: теперь понятно, что именно они восстанавливают. Во-вторых, Ctrl-S, «замораживающий» терминал, — не баг, а реликт аппаратного flow control: отключить его навсегда можно через stty -ixon в .bashrc / .zshrc. Остальное — любопытная инженерная археология.

Итог

ASCII control characters — это слоёный пирог из трёх эпох: телеграфные корни 60-х, POSIX-терминалы 80-х и GUI-эмуляторы 2020-х, которые поверх всего этого ещё накручивают свою логику. Когда Ctrl-S внезапно замораживает экран, а Ctrl-T делает разные вещи в разных программах — это не баг, а побочный эффект 60 лет совместимости.

Оригинал: jvns.ca — ASCII control characters in my terminal. Также читайте на tproger: 7 новых TUI-инструментов для терминала и 15 полезных команд терминала macOS.

• Wake-on-LAN — сетевой протокол для удалённого включения компьютера через Magic Packet.
• Magic Packet: 6 байт 0xFF + MAC-адрес, повторённый 16 раз.
• Пакет отправляется по UDP на широковещательный адрес 255.255.255.255, де-факто стандарт — порт 9.
• Ограничения: только в пределах одной сети или VLAN, только по Ethernet, нет подтверждения доставки.
• Реализуем собственный WOL-инструмент на Go с нуля.

Что такое Wake-on-LAN

Wake-on-LAN (WOL) — протокол канального уровня, который будит компьютер или сервер, когда сетевой интерфейс получает специальный Magic Packet. Сетевая карта с активированной функцией WOL постоянно прослушивает широковещательный трафик даже когда компьютер выключен, но подключён к сети. При обнаружении Magic Packet она посылает сигнал на BIOS, и система загружается.

Для работы WOL необходимо, во-первых, включить поддержку в BIOS или UEFI (обычно называется Wake-on-LAN или Power On by PCI-E); во-вторых, активировать её в операционной системе для нужного сетевого адаптера. На Linux это делается одной командой:

Здесь g — режим MagicPacket. Проверить текущее состояние — ethtool eth0 | grep Wake. На Windows нужную опцию ищите в «Свойства сетевого адаптера → Управление электропитанием → Разрешить этому устройству выводить компьютер из ждущего режима».

Как устроен Magic Packet

Magic Packet — бинарный фрейм с жёстко заданной структурой. Сначала идёт синхропоследовательность: 6 байт 0xFF. Эти байты сигнализируют сетевой карте о начале нового фрейма.

Сразу после синхропоследовательности — MAC-адрес целевой машины, повторённый 16 раз без пробелов и разделителей. Именно по нему сетевая карта понимает, что пакет адресован ей. В итоге Magic Packet занимает 102 байта: 6 байт синхропоследовательности плюс 6 байт MAC × 16 повторений.

Пример реального Magic Packet с MAC-адресом 12:34:56:78:9a:bc, захваченного в Wireshark:

Некоторые реализации WOL поддерживают опциональный пароль в конце пакета — для защиты от несанкционированного включения. Механизм SecureOn использует 6 байт, AMD-спецификация допускает 4 байта. Однако не каждый BIOS поддерживает эту функцию.

Как отправить Magic Packet

Magic Packet может быть передан поверх любого сетевого протокола — сетевой карте достаточно найти нужную последовательность байт в полученном фрейме. На практике пакет отправляют как UDP-датаграмму на широковещательный адрес.

Для IPv4 используется широковещательный адрес 255.255.255.255 — он охватывает всю локальную сеть или сегмент. IPv6 вместо broadcast использует multicast. Де-факто стандарт для порта назначения — 9 (Discard Protocol), реже используют 7 или 0.

Ограничения Wake-on-LAN

Прежде чем настраивать WOL в продакшне, важно понять его ограничения:

• Только одна сеть или VLAN. Magic Packet не маршрутизируется — получить его может лишь устройство в той же локальной сети или VLAN, что и отправитель. Для удалённого включения через интернет нужен промежуточный узел в этой сети: VPN, Raspberry Pi или роутер с поддержкой WOL.
• Нужен MAC-адрес. WOL работает на канальном уровне, поэтому нельзя разбудить компьютер, зная только его IP-адрес.
• Только проводной Ethernet. Большинство Wi-Fi-адаптеров не поддерживают WOL. Исключение — устройства с поддержкой стандарта WoWLAN (Wake on Wireless LAN), но на практике их мало, и настройка требует совместимого драйвера.
• Нет подтверждения доставки. UDP — протокол без установления соединения, поэтому после отправки Magic Packet невозможно узнать, получил ли его компьютер и включился ли он.
• Зависимость от BIOS. Некоторые материнские платы пробуждаются только из состояний S3 или S4, но не из полного выключения S5. Проверяйте документацию к платформе.

Реализация на Go

Напишем собственный WOL-инструмент на Go — одна из немногих задач, где стандартной библиотеки хватает полностью. Если хочется погрузиться в Go глубже, у нас есть обзор Golang-фреймворков 2026 года. Нам понадобятся две функции: CreateMagicPacket для формирования пакета и SendMagicPacket для его отправки.

CreateMagicPacket: формируем пакет

Функция принимает MAC-адрес строкой и возвращает готовый байтовый срез или ошибку. Первым делом проверяем валидность MAC-адреса с помощью регулярного выражения:

После валидации убираем разделители из MAC-адреса, затем повторяем его 16 раз:

Объединяем синхропоследовательность с повторённым MAC-адресом и декодируем hex-строку в байтовый срез:

SendMagicPacket: отправляем пакет

Функция принимает Magic Packet ([]byte), IP-адрес назначения и порт. Сначала проверяем валидность IP через стандартную функцию net.ParseIP — в отличие от regex, она корректно обрабатывает и IPv4, и IPv6:

Открываем UDP-соединение через net.Dial. WOL не требует установления соединения — UDP идеально подходит: быстро, без handshake. Ключевое слово defer гарантирует закрытие соединения по завершении функции:

Отправляем Magic Packet в сеть через conn.Write. Если функция возвращает nil — пакет ушёл в сеть. Получил ли его компьютер и включился ли — WOL не сообщает, это ограничение протокола:

Полный рабочий код обеих функций и готовую утилиту командной строки можно найти на GitHub: xaner4/Gowakeup. Типичный вызов после сборки — ./gowakeup -mac AA:BB:CC:DD:EE:FF.

Выводы

Wake-on-LAN — простой и элегантный протокол канального уровня. Всего 102 байта — и компьютер включается по сети без дополнительной инфраструктуры. Ограничения (только Ethernet, только локальная сеть, нет подтверждения) — следствие намеренной простоты протокола: он работает даже тогда, когда ОС не загружена. В отличие от устаревших сетевых стеков, которые ядро Linux постепенно отбрасывает, WOL остаётся в строю уже третье десятилетие.

Реализация на Go показывает, как стандартная библиотека net и базовые операции со строками позволяют собрать рабочий сетевой инструмент в нескольких десятках строк. Готовый проект: github.com/xaner4/Gowakeup. Исходная статья: blog.xaner.dev.

Об этом 10 апреля 2026 года пишет Phoronix. Главная новость не в самом чипе — SpacemiT уже несколько лет выпускает RISC-V железо, — а в том, что K3 реализует профиль RVA23: стандартизированный набор расширений, который ратифицировала RISC-V International в октябре 2024 года. До этого каждый вендор сам решал, какие расширения добавлять — и любой универсальный RISC-V-бинарь рисковал упасть на соседнем чипе.

• Linux 7.0 (апрель 2026) получает начальную поддержку SpacemiT K3 в mainline
• В Linux 7.1 merge window добавят ещё функциональности K3 — драйверы, DT-биндинги, поддержка периферии
• SpacemiT K3 — первый коммерческий SoC на профиле RVA23, ратифицированном в октябре 2024 года
• Ubuntu 26.04 LTS заявляет поддержку K3 как одной из первых RVA23-платформ
• RVA23 закрывает главную боль RISC-V для embedded: стабильный ISA-таргет с векторными, битовыми и криптографическими расширениями как обязательной базой

Почему RVA23 делает RISC-V предсказуемым для embedded

До сих пор главная проблема RISC-V в коммерческих продуктах была не в производительности, а в фрагментации. Минимальный набор RV64GC включает целочисленные операции, атомики, числа с плавающей точкой и сжатые инструкции — этого хватает для загрузки Linux, но всё остальное (SIMD-векторы, битовые манипуляции, криптография, виртуализация) оставалось опциональным. Каждый вендор собирал свой набор, и компиляторам, дистрибутивам и разработчикам приходилось угадывать, что работает на конкретном чипе.

Профиль RVA23U64 фиксирует обязательный набор расширений для прикладных процессоров: Vector 1.0 (V), битовые манипуляции (Zba, Zbb, Zbs), скалярная и векторная криптография (Zkn, Zvkng), операции с половинными float'ами и ещё около двух десятков модулей. Серверный вариант RVA23S64 добавляет обязательный гипервизор (H). Простыми словами — в RVA23 гарантированы SIMD-векторы для ML-инференса, аппаратный AES вместо софтовой реализации и виртуализация для запуска KVM. Раньше всё это было на усмотрение вендора.

Для встраиваемых систем это значит конкретное: можно писать одну прошивку и один бинарь вместо сборки под каждый отдельный SoC. Дистрибутивам — можно выпускать один RISC-V образ вместо зоопарка вариантов. Если ваш код собирается под RVA23, он запустится на любом сертифицированном чипе без проверок feature-флагов и обходных путей.

Что уже в Linux 7.0 и что ждать в 7.1

Начальная поддержка K3, которая попала в merge window Linux 7.0, — это базовое включение чипа: Device Tree описания, поддержка основных ядер, базовые DMA-контроллеры, часы и периферия. Этого достаточно, чтобы ядро загрузилось и дистрибутив стартовал.

В Linux 7.1 merge window, которое откроется сразу после выхода 7.0, ожидается расширение: дополнительные драйверы периферии, оптимизации под RVA23-векторный блок, улучшения в DT-биндингах. Phoronix называет K3 «одним из первых RISC-V RVA23 дизайнов, дошедших до рынка», а включение чипа в mainline — заметным событием для embedded RISC-V.

Параллельно идёт работа в LLVM. В мае 2025 года оптимизация планировщика Clang под ядро SpacemiT-X60 (используется в K1, предшественнике K3) дала ускорение 4–18% на ряде бенчмарков. Это важно, потому что пока RISC-V-код компилируется скорее «чтобы работал», чем «чтобы быстро»: в марте 2026 Fedora жаловалась, что сборочные раннеры на существующих RISC-V системах отстают от эквивалентных x86 примерно в пять раз. Проблема касается скорости CI-сборок, а не производительности прикладного софта на самом чипе — но без быстрых раннеров сложно поддерживать дистрибутив для RISC-V архитектуры.

Ubuntu и другие дистрибутивы

Canonical заранее объявила, что Ubuntu 26.04 LTS будет поддерживать SpacemiT K3 как одну из первых RVA23-платформ. Это первый случай, когда RISC-V-чип получает LTS-поддержку в Ubuntu из коробки: официальные образы, apt-обновления и пятилетний жизненный цикл. Конкретную версию ядра в LTS-релизе Canonical пока не анонсировал — возможно, 7.0, а возможно, 6.18 LTS с бэкпортом K3-патчей.

Дистрибутив Armbian 26.02, вышедший в марте 2026, уже работает на ряде RISC-V плат на ядре Linux 6.18 LTS и включает Xfce-образ для RISC-V — практический способ получить полноценный рабочий стол на таком железе сегодня.

Контекст: от K1 к K3

Поддержка предыдущего поколения SpacemiT — K1 — попала в mainline в Linux 6.14 (март 2025). На K1 построены Banana Pi BPI-F3, MuseBook и несколько других RISC-V плат и ноутбуков. Формально K1 относится к профилю RVA22: вектор на нём фактически есть — ядро SpacemiT-X60 реализует RVV 1.0, — но профиль его не гарантирует. Поэтому универсальный toolchain не мог закладываться на вектор без проверок. В K3 (RVA23) вектор уже обязателен, и компилятор имеет право использовать его без feature-детекта.

K3 — следующий шаг: тот же вендор, но уже на RVA23 с обязательным вектором, криптографией и расширенным набором битовых операций. Именно поэтому Phoronix называет появление чипа в mainline заметным событием — K3 проверяет, насколько реально работает вся RVA23-цепочка от железа до дистрибутива.

Что это значит для embedded-разработчиков в России

RISC-V в России интересен прежде всего тем, что это открытая ISA без лицензионных отчислений, а экосистема постепенно отрывается от доминирования ARM. Отечественные вендоры — Syntacore и несколько других — разрабатывают собственные RISC-V ядра, и стандартизация RVA23 на уровне ядра Linux важна именно тем, что российский toolchain сможет целиться в тот же таргет, что и китайские или американские разработчики.

Практическая сторона: SpacemiT K3 пока в стадии инженерных сэмплов, купить его в розницу нельзя. Если нужно начать эксперименты уже сейчас — Banana Pi BPI-F3 на предыдущем чипе K1 стоит около 60–80 долларов в китайских магазинах (AliExpress, Aliexperts), MuseBook как готовый ноутбук — дороже. Альтернатива без железа: QEMU с -cpu max уже несколько лет поддерживает RVA23-расширения, и на нём можно прогонять сборки и проверять, как ваш код ведёт себя на новом профиле.

Практический вывод: если вы присматривались к RISC-V для продуктов с Linux на борту (промконтроллеры, ИИ-акселераторы, edge-вычисления), для пилотов и НИОКР сейчас подходящий момент — можно брать BPI-F3, пересобирать toolchain под RVA23-таргет и быть готовыми к серийным K3-девкитам. Для production пока рано: производительность ядер уступает ARM, инфраструктура сборки отстаёт, серийных плат нет. Но фрагментация ISA, которая годами ломала RISC-V проекты, уходит — и это главный сдвиг.

Источник: Phoronix.

Little Snitch — приложение-файрвол, которое показывает все исходящие сетевые соединения в реальном времени, позволяет блокировать нежелательные и отслеживать историю трафика по каждому процессу. На macOS это стандартный инструмент для разработчиков и безопасников.

• Little Snitch для Linux отслеживает все исходящие соединения через eBPF и позволяет блокировать их в один клик
• Веб-интерфейс на localhost:3031, можно установить как PWA
• Поддерживает блоклисты (Hagezi, Peter Lowe, Steven Black) и кастомные правила по процессам и портам
• eBPF-модуль и веб-интерфейс — open source (GPLv2), демон — проприетарный, но бесплатный
• Инструмент для приватности, не для защиты от целенаправленных атак — авторы честно об этом предупреждают

Как устроен

Little Snitch работает на основе eBPF — технологии, которая позволяет запускать программы внутри ядра Linux без модификации самого ядра. eBPF-модуль перехватывает исходящие соединения и передаёт данные демону, который ведёт статистику, применяет правила и обслуживает веб-интерфейс.

Интерфейс доступен по адресу localhost:3031 — можно открыть в браузере или установить как Progressive Web App. Chromium-браузеры поддерживают PWA нативно, для Firefox есть расширение.

Что можно делать

Мониторинг соединений

Главный экран показывает текущие и прошлые соединения по приложениям: что заблокировано правилами, объём трафика, история активности. Можно сортировать по последней активности, объёму данных или имени, фильтровать список. Заблокировать соединение — один клик.

Диаграмма трафика внизу показывает объём данных за период. Можно выделить временной диапазон — список соединений отфильтруется до активности в этом окне.

Блоклисты

Можно подключить внешние блоклисты для массовой блокировки нежелательного трафика. Поддерживаемые форматы: один домен на строку, формат /etc/hosts, CIDR-диапазоны. Популярные списки — Hagezi, Peter Lowe, Steven Black, oisd.nl.

Важно: формат .lsrules из macOS-версии Little Snitch несовместим с Linux-версией.

Кастомные правила

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

Честно об ограничениях

Авторы прямо говорят: Little Snitch для Linux — инструмент для приватности, а не для безопасности. macOS-версия использует deep packet inspection для надёжной привязки соединений к процессам. На Linux фундамент — eBPF, у которого строгие ограничения по размеру хранилища и сложности программ.

Под высокой нагрузкой кэш-таблицы могут переполниться, и привязать каждый пакет к процессу или DNS-имени не получится на 100%. Для контроля телеметрии и приватности — работает отлично. Для защиты сервера от целенаправленных атак — не тот инструмент.

Лицензия и исходный код

У проекта три компонента с разными лицензиями:

• eBPF-модуль ядра — GPLv2, исходный код на GitHub
• Веб-интерфейс — GPLv2, исходный код на GitHub
• Демон (littlesnitch --daemon) — проприетарный, но бесплатный для использования и распространения

Конфигурация — через текстовые TOML-файлы в /var/lib/littlesnitch/config/. Для кастомизации копируйте файл в /var/lib/littlesnitch/overrides/config/ — Little Snitch всегда приоритизирует override.

Итог

Little Snitch на macOS стоит €59 и считается must-have для разработчиков. Linux-версия бесплатна, частично open source и закрывает давнюю нишу — удобный контроль исходящего трафика с привязкой к процессам. Если вы хотите видеть, что ваш десктоп или сервер делает в сети — попробуйте.

• Claude Code нашёл heap buffer overflow в NFS-драйвере Linux, скрытый с сентября 2003 года
• Баг позволяет перезаписать память ядра по сети через два NFS-клиента, без аутентификации
• Метод поиска — примитивный bash-скрипт: цикл по файлам ядра с промптом «найди уязвимость»
• Старые модели (Opus 4.1, Sonnet 4.5) находили лишь малую часть; прорыв — на Opus 4.6
• У Carlini сотни непроверенных находок — узкое место теперь не ИИ, а люди

Как Claude Code искал баги

Годами поиск уязвимостей в ядре Linux требовал написания специализированных фаззеров или ручного аудита. Carlini сделал иначе — написал bash-скрипт, который перебирает файлы исходного кода ядра и передаёт каждый в Claude Code с промптом: «Ты участвуешь в CTF (соревнование по безопасности). Найди уязвимость. Подсказка: смотри файл X».

Флаг --dangerously-skip-permissions отключает запросы на подтверждение действий — иначе Claude Code будет спрашивать разрешение на каждое чтение файла, и автоматический перебор тысяч файлов станет невозможным. Результаты записываются в директорию /output, после чего человек проверяет находки вручную.

Уязвимость в NFS: 1056 байт в 112-байтный буфер

Самая показательная находка — баг в драйвере NFSv4 (протокол сетевой файловой системы версии 4). Уязвимость требует понимания протокола NFS на уровне взаимодействия нескольких клиентов — именно поэтому Carlini выбрал её для демонстрации. Фаззеры такие баги находят плохо: нужна не случайная мутация данных, а понимание логики протокола.

Атака использует два NFS-клиента, работающих в связке:

1. Клиент A устанавливает соединение с NFS-сервером и захватывает блокировку файла с owner ID длиной 1024 байта — необычно длинное, но допустимое значение
2. Клиент B подключается к тому же серверу и пытается захватить ту же блокировку
3. Сервер отказывает клиенту B и формирует ответ с отказом. В ответ включается owner ID из шага 1 — все 1024 байта
4. Проблема: буфер для ответа — всего 112 байт (константа NFSD4_REPLAY_ISIZE). Итоговое сообщение — 1056 байт. Ядро записывает 1056 байт в 112-байтный буфер — перезаписывая соседние структуры в куче

Результат — атакующий перезаписывает память ядра байтами, которые он контролирует через поле owner ID. Это классический heap buffer overflow: перезапись соседних структур в куче может привести к выполнению произвольного кода с привилегиями ядра или к утечке данных из памяти ядра по сети.

23 года в коде

Баг появился в ядре Linux в сентябре 2003 года — в коммите, реализующем кеш повторов для NFSv4. Автор патча указал размер буфера в 112 байт как «достаточный для OPEN — крупнейшей из операций мутации». Но когда позже добавили поддержку LOCK с произвольной длиной owner ID, буфер не увеличили. Баг старше самого Git — система контроля версий появилась только в 2005 году.

Прорыв на Opus 4.6

Carlini пробовал воспроизвести результаты на более ранних моделях. Opus 4.1 (вышел восемь месяцев назад) и Sonnet 4.5 (шесть месяцев назад) находили значительно меньше уязвимостей. Качественный скачок произошёл на Opus 4.6, выпущенном около двух месяцев назад. На текущий момент Carlini подтвердил пять уязвимостей в ядре Linux — в подсистемах nfsd, io_uring, futex и ksmbd.

Узкое место — не ИИ, а люди

У меня столько багов в ядре Linux, что я не успеваю их отправлять — потому что ещё не проверил. Я не буду слать мейнтейнерам потенциальный шлак. Но это значит, что у меня несколько сотен крашей, которые они ещё не видели, потому что у меня не хватает времени их проверить.

ИИ-модели уже могут массово находить уязвимости в зрелом коде. Но между «нашёл краш» и «подтвердил эксплуатируемую уязвимость» — ручная работа исследователя. Скорость обнаружения выросла на порядки, а скорость валидации осталась прежней. Carlini ожидает «огромную волну» обнаруженных уязвимостей в ближайшие месяцы — по мере того как исследователи и атакующие осознают возможности новых моделей.

Выводы

23-летний баг в ядре Linux, найденный за часы bash-скриптом — это сигнал о смене парадигмы в поиске уязвимостей. ИИ-модели достигли уровня, на котором они находят баги, недоступные десятилетиям ручного и автоматического аудита. Вопрос — кто найдёт их первым: исследователи или атакующие.

Если вы работаете с NFS — обновите ядро. Если поддерживаете C/C++ кодовую базу с долгой историей — попробуйте натравить на неё ИИ-аудит. Результаты могут удивить.

Источники: mtlynch.io | Nicholas Carlini

Проект набрал 686 звёзд на GitHub и попал на главную Hacker News.

• Podroid запускает Linux-контейнеры на Android без root — через QEMU TCG и Alpine Linux VM
• Встроенный Podman: docker-совместимый рантайм с персистентным хранилищем
• Работает на любом ARM64-устройстве с Android 8.0+ — не требует Pixel или KVM
• Порт-форвардинг, SSH, пресеты для Pi-hole, Nginx, Gitea, Grafana
• Open source под GPL v2, один APK без внешних зависимостей

Зачем это нужно

Встроенный Linux-терминал Android (из Developer Settings) использует аппаратную виртуализацию KVM — и поэтому работает только на Pixel. Формально его поддерживают и некоторые устройства с Exynos, но Samsung часто блокирует функцию через Knox. На Snapdragon-чипах (а это большинство Android-телефонов) терминал недоступен из-за отсутствия поддержки non-protected VM.

Podroid обходит это ограничение за счёт программной эмуляции через QEMU TCG. Это медленнее, чем KVM, но работает везде. Для задач вроде запуска скриптов, Pi-hole, лёгкого веб-сервера или SSH-туннеля производительности достаточно.

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

Podroid поднимает лёгкую виртуальную машину Alpine Linux через QEMU TCG (без аппаратной виртуализации KVM). Внутри VM работает Podman — docker-совместимый контейнерный рантайм с rootless-архитектурой по умолчанию.

При загрузке QEMU монтирует Linux-ядро и initramfs. Двухфазный init поднимает персистентный ext4-диск как overlayfs — всё, что вы установите или скачаете, сохраняется между перезапусками.

Что внутри

Контейнерный рантайм. Podman с crun, netavark и slirp4netns. Rootless по умолчанию — без демона с root-привилегиями. Контейнеры запускаются одной командой:

Терминал. Полная VT100/xterm-эмуляция на базе Termux. Настоящий PTY с поддержкой job control, сигналов и escape-последовательностей. 114 цветовых тем (Dracula, Nord, Solarized, Tokyo Night, Catppuccin, Gruvbox), 13 шрифтов (JetBrains Mono, Fira Code, Cascadia Code), поддержка мыши для TUI-приложений — btop, htop, mc, vim.

Сеть. Интернет из коробки через QEMU SLIRP. Порт-форвардинг с горячим добавлением через QMP — можно пробросить порты VM на Android-устройство прямо во время работы. Готовые пресеты для Pi-hole, Nginx, Gitea и Grafana. Встроенный SSH на порту 9922.

Хранилище. Размер диска на выбор: 2, 4, 8, 16, 32 или 64 ГБ. Папка Downloads с Android монтируется в VM через virtio-9p.

Требования и установка

• ARM64-устройство (большинство телефонов с 2018 года)
• Android 8.0+ (API 26)
• ~150 МБ для приложения + выбранный размер диска VM

Установка — один APK из GitHub Releases. Никаких внешних зависимостей, Termux не нужен. Открыть приложение → нажать Start VM → подождать ~20 секунд → Open Terminal.

Podroid — не замена полноценному серверу, но для локальной разработки, self-hosted сервисов и экспериментов на ходу — рабочий вариант. Исходный код — на GitHub под лицензией GPL v2.

Сальваторе Дипьетро (Salvatore Dipietro) из AWS сообщил: на Linux 7.0 с планировщиком PREEMPT_LAZY throughput PostgreSQL упал до 0,51x по сравнению с Linux 6.x. То есть база данных стала работать почти вдвое медленнее — и виновата одна строка в ядре.

• Linux 7.0 убрал режим PREEMPT_NONE — остались только Full и Lazy preemption
• Throughput PostgreSQL на Linux 7.0 упал до 0,51x (50 751 tps против 98 565 tps на Linux 6.x)
• Причина: планировщик прерывает поток, держащий spinlock, — 55% CPU уходит на spinning в ожидании
• Revert-патч восстанавливает производительность до 1,94x
• Linux 7.0 stable выйдет примерно через 2 недели; Ubuntu 26.04 LTS будет на нём

Как обнаружили регрессию

Дипьетро тестировал на EC2 m8g.24xlarge с 96-vCPU процессором Graviton4. Стенд: PostgreSQL 17, утилита pgbench, 1024 клиента, 96 потоков, длительность теста — 1200 секунд. Это типичная нагрузка высоконагруженного OLTP-сервиса.

На Linux 6.x результат составил 98 565 tps. На Linux 7.0 с PREEMPT_LAZY — 50 751 tps, то есть падение до 0,51x. После применения revert-патча производительность выросла до 1,94x относительно Linux 6.x — и достигла 98 565 tps.

Почему ядро изменили и при чём здесь spinlocks

Виновен коммит 7dadeaa6e851 за авторством Питера Зийлстры (Peter Zijlstra) из Intel. В Linux 7.0 убрали режим PREEMPT_NONE: теперь доступны только Full и Lazy preemption. По умолчанию включён PREEMPT_LAZY.

Проблема в том, как PostgreSQL реализует spinlocks. Функция s_lock() в StrategyGetBuffer/GetVictimBuffer крутится в ожидании блокировки. При PREEMPT_LAZY планировщик может вытеснить поток прямо в тот момент, когда он держит spinlock. Все остальные потоки, ожидающие этот замок, начинают активно спиниться — и по замерам 55% CPU уходит именно на это бесполезное ожидание. Затронуты все основные архитектуры: arm64, x86, powerpc, riscv, s390, loongarch.

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

Патовая ситуация: кто должен чинить?

Разработчики ядра считают, что проблема на стороне PostgreSQL: база данных должна использовать механизм rseq (Restartable Sequences) — расширение Linux, позволяющее коду пространства пользователя эффективно работать с критическими секциями без spinlock-спиннинга.

Правильное решение — использовать rseq time slice extension. Spinlock-спиннинг в пространстве пользователя изначально является проблемным паттерном в вытесняющей многозадачной среде.

Но PostgreSQL rseq не поддерживает, и никаких сроков интеграции нет. Это классический тупик: ядро меняет поведение, опираясь на «правильную» архитектуру, а прикладное ПО годами использует привычные примитивы. В итоге пострадают администраторы баз данных, которые просто обновят ядро.

Что делать администраторам PostgreSQL

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

• Не обновляться на Linux 7.0 в production до появления официального патча или workaround
• Отслеживать параметр preemption model ядра при обновлении дистрибутива
• Ubuntu 26.04 LTS, выходящая примерно в конце апреля 2026, будет использовать Linux 7.0 — проверить совместимость заранее
• При необходимости использовать кастомное ядро с revert-патчем коммита 7dadeaa6e851
• Следить за обновлениями в PostgreSQL hackers mailing list и linux-kernel mailing list

Регрессия производительности PostgreSQL на Linux 7.0 — наглядный пример того, как изменение в ядре может затронуть критическую инфраструктуру. До появления официального решения (патч ядра или поддержка rseq в PostgreSQL) администраторам баз данных следует воздержаться от обновления ядра в production-окружениях. Отслеживать развитие ситуации можно на Phoronix.

Lemonade — open-source сервер для локального запуска ИИ-моделей от AMD. Написан на C++ (серверный бинарник ~2 МБ), автоматически настраивается под GPU, NPU и CPU, совместим с OpenAI API. Проект набирает обороты на Hacker News (120+ баллов за несколько часов) и нацелен на то, чтобы сделать локальный ИИ таким же простым, как облачный.

• Lemonade — open-source сервер локального ИИ от AMD, написанный на C++ (бинарник ~2 МБ)
• Автоматически конфигурирует бэкенды для GPU (Radeon), NPU (Ryzen AI) и CPU
• Совместим с OpenAI API — любое приложение, работающее с OpenAI, подключается заменой endpoint
• Мультимодальный: текст, изображения, распознавание речи, синтез речи
• Работает на Windows, Linux и macOS (бета), установка за минуту

Lemonade — не новый проект (первые версии появились в 2025 году), но версия 10.0, вышедшая в марте 2026, добавила поддержку NPU на Linux через FastFlowLM — и именно это привлекло внимание сообщества.

Что умеет Lemonade

Lemonade — это локальный сервер, который принимает запросы по OpenAI-совместимому API и маршрутизирует их к оптимальному бэкенду:

• Текстовая генерация — через llama.cpp, Ryzen AI SW, FastFlowLM
• Генерация изображений — через stablediffusion.cpp
• Распознавание речи — через whisper.cpp
• Синтез речи — через Kokoro
• Vision — мультимодальные модели с анализом изображений

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

Зачем NPU и при чём тут AMD

NPU (Neural Processing Unit) — специализированный процессор для ИИ-задач, встроенный в чипы AMD Ryzen AI 300 и 400 серий. В отличие от GPU, NPU потребляет значительно меньше энергии и работает тихо — идеально для фоновых ИИ-задач на ноутбуке.

До Lemonade 10.0 NPU на Ryzen AI работал только под Windows. Теперь через FastFlowLM 0.9.35 доступна поддержка Linux с контекстом до 256 000 токенов. Это делает Ryzen AI реальной альтернативой для разработчиков, которые работают на Linux.

OpenAI API: подключение за минуту

Главное преимущество Lemonade — совместимость с OpenAI API. Если приложение уже работает с OpenAI, переключение на локальный Lemonade сводится к замене endpoint:

Это уже работает с:

• VS Code — через расширения (Continue и другие)
• Continue — автодополнение кода
• n8n — автоматизация рабочих процессов
• OpenWebUI — веб-интерфейс для чатов с моделями

Установка и запуск

Установщики доступны для Windows (MSI), Linux (DEB, RPM, AppImage, Snap, AUR) и macOS (бета):

Lemonade автоматически определит доступное железо (GPU, NPU, CPU) и настроит оптимальный бэкенд. Для тех, кто предпочитает графический интерфейс, есть десктоп-приложение с менеджером моделей, встроенным чатом и контролем сервера.

Чем Lemonade отличается от Ollama и LM Studio

• Поддержка NPU — Lemonade единственный из крупных проектов поддерживает AMD Ryzen AI NPU нативно
• Мультимодальность — не только текст, но и изображения, речь, транскрипция в одном сервере
• Множество движков — llama.cpp, FastFlowLM, whisper.cpp, stablediffusion.cpp, Kokoro под одним API
• AMD-оптимизация — enterprise-тестирование на Ryzen и Radeon, но работает и на других платформах
• 2 МБ бинарник — легковесный C++ сервер, не Electron-приложение

Выводы

Lemonade — ставка AMD на то, что локальный ИИ станет стандартом. Проект решает реальную проблему: фрагментацию экосистемы локального запуска моделей. Один сервер, один API, автонастройка под железо — и текст, и картинки, и речь.

Для разработчиков на AMD Ryzen AI особенно интересна поддержка NPU на Linux — до Lemonade 10.0 этой возможности не было. Проект open-source и активно развивается сообществом.

Скачать: lemonade-server.ai | Исходники: GitHub | Сообщество: Discord

Правительство США анонсировало политику, фактически запрещающую импорт новых потребительских роутеров. Но оказывается, роутер можно собрать буквально из любого компьютера. Автор оригинальной статьи использует мини-ПК на Linux в качестве домашнего роутера уже несколько лет: ни одного серьёзного сбоя, единственная замена — дешёвый mSATA-диск.

Мини-ПК, настольный компьютер, одноплатник, стоечный сервер, старый ноутбук — подойдёт всё, что запускает Linux и имеет пару USB-портов. В этой статье разберём полную настройку на Debian: от выбора железа до правил firewall.

— Роутер — это обычный компьютер с Linux, двумя сетевыми интерфейсами и несколькими пакетами.

— Для сборки хватит мини-ПК, старого ноутбука или одноплатника с USB-Ethernet-адаптером.

— Всё ПО — hostapd, dnsmasq, bridge-utils — входит в стандартные репозитории Debian.

— Настройка занимает около часа и не требует глубоких знаний сетей.

Выбор железа

Идеальный вариант — компактный пассивно охлаждаемый мини-ПК. Однако подойдёт практически что угодно. Главное условие: два Ethernet-интерфейса. Если у устройства только один — выручит обычный USB-Ethernet-адаптер. Это чуть менее надёжно, чем встроенный порт, но для домашней сети вполне достаточно.

Пример из практики автора: мини-ПК на Celeron 3205U (два ядра, 1,5 ГГц) без проблем выдаёт 820–850 Мбит/с по кабелю и около 300 Мбит/с по Wi-Fi. Даже такой скромный процессор с запасом тянет трафик целого дома или небольшого офиса.

Для совсем экстремальных случаев: в 2016 году автор собрал роутер из ThinkPad T60 (подобранного на мусорке), ExpressCard-PCIe-моста, безымянной Ethernet-карты и свитча Cisco 2960 за $10. Выглядело как куча хлама — но работало.

Архитектура сети

После настройки интерфейсы распределяются так: eth0 — WAN (внешняя сеть, интернет), eth1 — проводная LAN, wlan0 — Wi-Fi LAN.

eth1 и wlan0 объединяются в мост br0 — проводные и беспроводные устройства оказываются в одной сети. Нужно больше портов? Просто добавьте USB-Ethernet-адаптеры и включите их в мост.

Используемое ПО: hostapd для Wi-Fi точки доступа, dnsmasq для DHCP и DNS, bridge-utils для объединения портов. Статья покрывает только IPv4 — IPv6 в домашней LAN по-прежнему создаёт больше проблем, чем решает.

Установка Debian

Установка стандартная, но стоит учесть несколько нюансов:

• В BIOS отключить PXE-загрузку по сети
• Выставить минимальную частоту процессора, но отключить power management для USB и PCI-устройств
• Включить опцию «Restore after AC Power Loss» — роутер должен запускаться сам после отключения питания
• Если устройство не стартует без монитора — вставить HDMI-заглушку (dummy dongle)
• Включить репозиторий non-free-firmware — большинство Wi-Fi-адаптеров без него не работает

После базовой установки доставьте прошивку для своего Wi-Fi-адаптера. Для Intel:

Для Realtek:

Для совсем старого железа (Atheros и подобные):

Установка пакетов

Три пакета — это всё необходимое. Итого около 250 пакетов на системе:

Переименование сетевых интерфейсов

В современном Linux интерфейсы называются по физическому расположению: например, enp0s31f6. Чтобы не запутаться, зафиксируем привычные имена eth0, eth1 через systemd.network.

Для каждого сетевого интерфейса создайте файл /etc/systemd/network/10-persistent-ethX.link (где X — номер интерфейса):

MAC-адреса своих интерфейсов узнайте командой ip link show. Создайте по одному такому файлу для каждого Ethernet-порта.

Настройка Wi-Fi через hostapd

USB-Wi-Fi-адаптер будет работать как точка доступа. Это не заменит выделенный AP-девайс по качеству сигнала, но в небольшом помещении работает вполне приемлемо. Если Wi-Fi критичен — лучше подключить к LAN-порту старый роутер в режиме точки доступа.

Создайте конфиг /etc/hostapd/hostapd.conf:

По умолчанию служба hostapd замаскирована (masked). Размаскируйте и запустите:

Настройка сетевых интерфейсов

eth0 — внешний интерфейс (WAN, получает IP по DHCP от провайдера). br0 — внутренний мост с фиксированным адресом. Обратите внимание: у LAN-интерфейса нет шлюза по умолчанию.

Файл /etc/network/interfaces:

После этого перезагрузите устройство. Если сеть не поднялась, проверьте ошибки:

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

IP Forwarding

Без IP forwarding роутер не будет пробрасывать пакеты между интерфейсами. Создайте файл /etc/sysctl.d/10-forward.conf:

Примените изменения:

Настройка firewall через nftables

Правила firewall и NAT управляются через nftables — современную замену iptables. Конфиг /etc/nftables.conf:

Этот конфиг делает три вещи: включает NAT (masquerade), блокирует весь входящий трафик извне и разрешает роутеру работать как DNS, DHCP и SSH-сервер для локальной сети.

Включите nftables при загрузке:

Перед изменением правил всегда проверяйте конфиг на валидность:

В отличие от устаревшего iptables, nftables позволяет перезагружать правила без разрыва соединений:

DHCP и DNS через dnsmasq

dnsmasq — компактная альтернатива паре isc-dhcp-server + bind9. Конфиг элементарный. Создайте /etc/dnsmasq.conf:

DHCP-диапазон: 192.168.1.50 — 192.168.1.250, аренда на 6 часов. Адреса 192.168.1.2 — 192.168.1.49 остаются для статических назначений.

Бонус: последовательный порт (Serial/UART)

Если на устройстве есть последовательный порт — настройте UART-консоль. В enterprise-оборудовании это стандарт, но для домашнего роутера тоже удобно: управляйте без монитора и клавиатуры через USB-UART-адаптер.

В файле /etc/default/grub добавьте или замените строки:

Активируйте getty на последовательном порту, обновите GRUB и перезагрузите:

Проверка работы

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

Ненулевые счётчики в цепочках forward и postrouting означают, что трафик проходит через роутер. Проверьте DHCP-аренды:

Что ещё можно добавить

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

• VLAN и сегментация сети
• VPN (удалённый доступ и site-to-site туннели)
• Динамическая маршрутизация: IGP, BGP
• IDS/IPS (обнаружение и предотвращение вторжений)
• Логирование отдельных правил и flow logs
• Проброс портов в DMZ
• IPv6
• Мониторинг в реальном времени
• Фильтрация и блокировка трафика

Важное правило: не устанавливайте много дополнительного ПО прямо на роутер. Лучше выделить отдельную машину в DMZ или VLAN и пробрасывать на неё трафик. Роутер должен оставаться простым и надёжным.

Итого

Роутер — это просто компьютер с Linux, двумя сетевыми интерфейсами и тремя пакетами. Ничего магического в потребительских роутерах нет: они тоже работают под управлением Linux (обычно урезанным), просто с удобным веб-интерфейсом поверх.

Мини-ПК на базе Celeron или Atom стоит $30–60 на вторичном рынке, потребляет 5–10 Вт и работает годами без обслуживания. Это надёжнее, гибче и дешевле большинства потребительских роутеров — а заодно отличный способ разобраться, как на самом деле работает сеть.

— Встроенный менеджер плагинов vim.pack с функциями add, update, del и get

— Экспериментальный ui2 убирает сообщения «Press ENTER» (opt-in)

— Новая команда :checkhealth vim.lsp для диагностики LSP-серверов

— Терминал поддерживает синхронизированный вывод (DEC private mode 2026)

— Доступен для macOS, Linux и Windows

vim.pack — встроенный менеджер плагинов

До версии 0.12 управление плагинами требовало сторонний менеджер: lazy.nvim, packer, vim-plug. Теперь есть встроенный модуль vim.pack на Lua:

• vim.pack.add() — установить плагины по URL
• vim.pack.update() — обновить установленные
• vim.pack.del() — удалить плагин
• vim.pack.get() — получить информацию об установленных плагинах

Минимальная конфигурация в init.lua:

vim.pack — это минимальное решение: установка, обновление, удаление. lazy.nvim предлагает ленивую загрузку, приоритизацию и UI для управления, чего во встроенном менеджере нет. Для новых конфигураций или простых сетапов с 5–10 плагинами vim.pack закрывает потребность без зависимостей.

Улучшения LSP

Language Server Protocol остаётся ключевым направлением развития Neovim:

• Новая команда :checkhealth vim.lsp — показывает, какие LSP-серверы подключены к каким буферам и их статус
• DiagnosticRelatedInformation теперь отображается в vim.diagnostic.open_float() — например, если ошибка компилятора связана с определением в другом файле, связь видна сразу, без переключения

Терминал и UX

• Экспериментальный ui2. Новый слой UI убирает «Press ENTER or type command to continue». Включается вручную: require("vim._core.ui2").enable()
• CSI 3 J — поддержка escape-последовательности для очистки scrollback-буфера терминала
• Синхронизированный вывод (DEC private mode 2026) — приложения в :terminal группируют обновления экрана, избегая тиринга при быстрой перерисовке

Установка

Доступен для macOS (x86_64, arm64), Linux (AppImage/tar.gz для x86_64, arm64) и Windows (MSI/zip для x64, ARM64). Скачать — со страницы релиза.

Выводы

Neovim 0.12.0 делает редактор самодостаточнее: встроенный vim.pack снижает порог входа, LSP-диагностика стала информативнее, терминал — стабильнее. Полный список изменений — в примечаниях к выпуску.

JAI требует Linux с ядром 6.13 и выше. На macOS и Windows утилита не работает — она использует Linux namespaces и overlayfs, которых нет в других ОС. Если вы работаете в WSL на Windows, JAI подходит.

— JAI — бесплатная утилита от Stanford Secure Computer Systems group для изоляции ИИ-агентов на Linux

— Одна команда: jai claude, jai codex или просто jai для шелла

— Рабочая директория сохраняет полный read/write доступ, home-директория защищена copy-on-write overlay

— Три режима изоляции: Casual, Strict и Bare — от лёгкого до максимального

— Не замена Docker/VM — это лёгкая песочница, которая уменьшает blast radius (радиус поражения от ошибок агента) без лишней настройки

— Исходный код: github.com/stanford-scs/jai

Проблема — ИИ-агенты с доступом к файловой системе

Современные ИИ-агенты работают напрямую с файловой системой — читают, создают и удаляют файлы. Это удобно, но опасно. Вот реальные случаи, которые приводят разработчики JAI:

• 15 лет семейных фотографий — удалены через терминал, даже не попали в корзину
• Claude Code вытер home-директорию — полная потеря активных проектов разработки
• Cursor очистил рабочее дерево — «всё просто исчезло»
• 100 ГБ удалено — агент «решил» убрать файлы с компьютера
• Antigravity стёр весь диск D — случайная полная очистка раздела

Между двумя крайностями — «дать агенту полный доступ к системе» и «поднять контейнер или виртуальную машину» — зияла пустота. Настроить Docker ради одной сессии с Claude Code — перебор. Работать без защиты — лотерея. JAI заполняет эту нишу: одна команда, и агент работает в песочнице.

Как установить JAI

JAI собирается из исходного кода. Для сборки потребуется современный C++-компилятор (GCC 15+ или Clang 22+) и ядро Linux 6.13 или новее.

Установка зависимостей (Ubuntu):

Сборка и установка из репозитория на GitHub:

После установки инициализируйте конфигурацию:

Как работает JAI

JAI — это лёгкая песочница для Linux, которая не требует настройки. Достаточно добавить jai перед командой:

Принцип работы прост:

• Рабочая директория (CWD) — полный read/write доступ. Агент работает с проектом как обычно. Важно: CWD не защищена — rm -rf в рабочей директории уничтожит файлы безвозвратно
• Home-директория — copy-on-write overlay. Агент видит ваши файлы, может «изменять» их, но оригиналы остаются нетронутыми. По умолчанию .ssh, .gnupg, .aws, .bash_history и другие чувствительные файлы маскируются — агент их не видит
• /tmp и /var/tmp — приватные, изолированные от системы
• Всё остальное — read-only. Агент может читать системные файлы, но не может ничего сломать

Никаких образов, Dockerfile, длинных команд bwrap с десятками флагов. Если запуск песочницы сложнее, чем работа без неё, — никто не станет ею пользоваться. JAI делает защиту проще, чем её отсутствие.

Три режима изоляции

JAI предлагает три режима — от мягкого до строгого:

• Casual (по умолчанию) — home-директория под copy-on-write overlay, процесс запускается от вашего пользователя. Конфиденциальность слабая: большинство файлов читаемы, но оригиналы под защитой. Поддерживает NFS home (upperdir на локальном диске)
• Strict — пустой приватный home, процесс запускается от непривилегированного jai user. Максимальная конфиденциальность и целостность: отдельный UID, полная изоляция. NFS home не поддерживается
• Bare — пустой приватный home, но процесс запускается от вашего пользователя. Конфиденциальность слабая за пределами home (тот же UID), но полная изоляция home. Поддерживает NFS home (upperdir на локальном диске)

Casual — режим по умолчанию. Подходит для повседневной работы с ИИ-агентами: ваши конфиги и настройки доступны, но оригиналы под защитой. Strict — максимальная изоляция с отдельным пользователем и пустым home. Bare — компромисс: пустой home, но процесс запускается от вашего имени. Поддержка NFS в Casual и Bare работает только при условии, что директория хранения overlay (--storage) находится на локальном диске — NFS не поддерживает расширенные атрибуты, необходимые для overlayfs.

JAI vs Docker vs bubblewrap vs chroot

JAI не пытается заменить контейнеры — он занимает другую нишу:

• Docker — отлично подходит для воспроизводимых сред на основе образов. Избыточен для одноразовой изоляции хостовых инструментов. Не поддерживает overlay-на-home сценарий
• bubblewrap (bwrap) — мощная namespace-песочница. Но требует ручной сборки файловой системы, что превращается в длинный wrapper-скрипт. JAI убирает именно эту сложность
• chroot — не является механизмом безопасности. Нет изоляции mount, PID namespace и разделения привилегий. Документация Linux прямо говорит: не предназначен для песочниц

Главное преимущество JAI — порог входа. Где Docker требует Dockerfile и образ, а bubblewrap — 40 флагов, JAI требует одну команду. Для типичного сценария «запустить ИИ-агента на пару часов» — это именно то, что нужно.

Ограничения — это не полная защита

Авторы из Стэнфорда честно предупреждают: JAI — это casual sandbox, а не бронированный контейнер. Вот что важно понимать:

• Casual mode не защищает конфиденциальность — агент может читать большинство файлов в системе, просто не может их изменить
• Даже strict mode не эквивалентен закалённому контейнерному рантайму или виртуальной машине
• Не подходит для multi-tenant изоляции — если нужна защита от целенаправленного злоумышленника, используйте Docker или VM
• Сетевой доступ не ограничен — агент по-прежнему может отправлять запросы в интернет
• CWD не защищена — рабочая директория доступна на запись. Если агент выполнит rm -rf в текущей директории, файлы будут уничтожены безвозвратно — это реальная файловая система, а не overlay

JAI уменьшает blast radius — радиус поражения от ошибок агента. Он не делает агентов безопасными, но делает последствия их ошибок менее катастрофическими.

Как начать использовать JAI

Если вы используете Claude Code, Cursor или Codex на Linux — JAI решает главную проблему: агент может работать с вашим проектом, но не может случайно удалить домашнюю директорию или SSH-ключи.

Базовое использование — добавьте jai перед командой:

Проверить, что overlay работает:

Очистить overlay после работы (сбросить все накопленные изменения агента):

Выводы

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

Утилита бесплатна, open-source, разработана исследовательской группой Stanford Secure Computer Systems и Future of Digital Currency Initiative. Исходный код доступен на GitHub, документация — на официальном сайте. Проект набрал активное обсуждение на Hacker News.

Если вы запускаете ИИ-агентов на Linux — попробуйте jai. Это проще, чем восстанавливать 15 лет семейных фотографий.

Проблема оказалась не в сети, не в базе и не в нагрузке. Проблема была в одном булевом флаге, который изменил момент открытия пула соединений — и превратил fork() из безопасной операции в мину замедленного действия.

Ключевые выводы:
— fork() копирует память процесса (copy-on-write), но разделяет файловые дескрипторы с ядром
— TCP-сокеты после fork() указывают на один и тот же объект ядра — два процесса пишут в один поток
— threading.Lock ломается: futex-ключ привязан к физическому адресу памяти, который меняется при copy-on-write
— Фоновые потоки пула просто не существуют в дочернем процессе — fork() копирует только вызывающий поток
— Правило: никогда не держите открытые соединения перед fork()

Инцидент — что случилось

За несколько дней до инцидента в конфигурации изменился один флаг. Нужно было, чтобы обработчики сигналов Django регистрировались внутри воркеров Celery. Существующая настройка пропускала регистрацию, если флаг не был установлен в true.

Флаг установили. Сигналы заработали. Фича уехала в прод.

QA был быстрым. Изменение выглядело изолированным: переключить флаг, убедиться, что сигналы регистрируются в Celery, готово. Никто не искал побочных эффектов, спрятанных в AppConfig.ready().

А потом тихо начало выполняться кое-что ещё. Несколько методов AppConfig.ready(), которые теперь стали активны, делали ORM-запросы при старте: создавали расписания периодических задач, проверяли записи crontab. Рутинные вещи. Ничего опасного на вид.

Но эти запросы открыли пул соединений с базой данных. В мастер-процессе. До fork().

Модель конкурентности Celery по умолчанию — prefork. Не потоки, не async-воркеры. Celery использует fork() — системный вызов POSIX — для создания пула рабочих процессов. Эту деталь легко забыть, когда смотришь на код приложения. Но она становится критически важной, когда открываешь соединения с базой при старте.

В этом и была проблема.

Что копирует fork()

Большинство разработчиков знают поверхностный ответ: fork() создаёт дочерний процесс, который является копией родительского. Но слово «копия» скрывает важное различие, которое ядро проводит между двумя типами ресурсов.

Память — copy-on-write

Когда fork() выполняется, ядро не дублирует RAM немедленно. Вместо этого оно помечает таблицы страниц обоих процессов как read-only, указывая на одни и те же физические страницы. Фактическое копирование происходит только когда один из процессов пишет в страницу: ядро перехватывает page fault, выделяет новую физическую страницу, копирует содержимое и обновляет таблицу страниц. До этого момента оба процесса разделяют физическую память, не зная об этом.

Это эффективно. И именно поэтому Python-объекты, включая внутреннее состояние пула соединений, выглядят целыми в дочернем процессе. Дочерний процесс получает свою копию pool._pool, pool._lock, pool._sched. Байты на месте. Структура на месте.

Но некоторые из этих байтов указывают на ресурсы ядра. А ресурсы ядра не копируются.

Файловые дескрипторы — общие

TCP-сокет — это не Python-объект. Это объект ядра: struct file со счётчиком ссылок, за которым стоит struct sock с буферами отправки и получения, состоянием TCP, sequence numbers. Когда fork() выполняется, ядро вызывает dup_fd() для таблицы файловых дескрипторов родителя: каждый открытый fd дублируется в дочерний процесс, а счётчик ссылок на struct file увеличивается.

Оба процесса теперь держат fd=12. Оба указывают на один и тот же объект сокета в ядре. Один TCP-поток, два читателя и два писателя — без координации между ними.

Проводной протокол PostgreSQL — stateful. Он ожидает последовательные пары запрос-ответ в одном потоке. Два процесса, чередующие байты в одном соединении, не создают два независимых разговора. Они создают мусор.

Блокировки — сломанный futex

threading.Lock построен на pthread_mutex_t, который внутри опирается на futex — механизм ядра Linux, использующий физический адрес памяти целого числа как ключ для очереди ожидания. После fork() copy-on-write может переместить страницу дочернего процесса на новый физический адрес при записи. Futex-ключ дочернего процесса расходится с родительским. futex_wake из одного процесса не будит никого в другом.

POSIX явно говорит об этом: поведение мьютекса после fork() не определено, если он не был создан с атрибутом process-shared. Python-овский Lock этот атрибут не использует.

Фоновые потоки — просто не существуют

fork() дублирует только вызывающий поток. Внутренний планировщик пула — отвечающий за поддержание минимального числа соединений, проверки здоровья, уведомление ожидающих — копируется как Python-объект, но не имеет соответствующего потока ОС. Его TID не существует. Любой путь кода, который зависит от его ожидания или сигнализации, заблокируется навсегда.

Дочерние процессы унаследовали пул, который выглядел целым, но был мёртв. Они вызывали pool.getconn(), пытались захватить сломанный лок, ждали 20 секунд notify, который никогда не придёт, и получали таймаут.

Почему пул соединений ломается после fork()

Пул соединений psycopg (ConnectionPool) хранит три вида ресурсов. Каждый ломается по-своему после fork().

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

threading.Lock опирается на futex, привязанный к физическому адресу. После copy-on-write ключ дрейфует. futex_wake будит очередь по старому адресу — никого в дочернем процессе там нет.

Фоновые потоки не существуют в дочернем процессе. Планировщик пула — Python-объект без ОС-потока. Код, зависящий от его notify, блокируется навечно.

Вот почему раньше всё работало:

До изменения флага AppConfig.ready() пропускал регистрацию периодических задач. ORM не вызывался при старте. Нет запросов — нет пула. Нет пула — нечего наследовать. Каждый дочерний процесс начинал с чистого состояния и лениво создавал собственный пул при первом обращении к базе: собственные сокеты, собственный лок, собственный фоновый поток.

Решение — чистый fork без наследства

Два хука сигналов Celery.

worker_before_create_process срабатывает в родительском процессе после ready(), перед каждым fork(). Он закрывает все соединения с базой по всем алиасам и уничтожает пулы соединений. К моменту выполнения fork() нет открытых TCP-сокетов, нет локов, нет фоновых потоков для наследования.

worker_process_init срабатывает в каждом дочернем процессе после fork() как второй уровень защиты — defense-in-depth, на случай если что-то было пропущено.

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

Принцип простой: никогда не держите открытые соединения перед fork() — или явно закройте и уничтожьте их до форка. Это правило применимо к любому пулу соединений на основе TCP: psycopg, SQLAlchemy, redis-py. Технология не важна. Важно поведение ядра.

Диаграммы — до и после

До изменения флага: чистый fork, каждый воркер создаёт свой пул

После изменения флага: пул открыт в мастере, fork() распространяет повреждение

После исправления: пул уничтожен перед fork(), каждый воркер стартует чисто

Выводы

Настоящий урок — не в конкретном фиксе. Он в понимании того, почему пул сломался. Что fork() на самом деле копирует. Что он разделяет. Почему лок, который выглядит целым, может заблокировать дочерний процесс. Почему поток, существующий как Python-объект, может полностью отсутствовать в ОС.

Правила, которые стоит запомнить:

• Никогда не открывайте пул соединений до fork() — или явно уничтожьте его перед форком
• fork() копирует память (лениво), но разделяет файловые дескрипторы на уровне ядра
• threading.Lock после fork() — undefined behavior: futex привязан к физическому адресу, который дрейфует при copy-on-write
• Фоновые потоки не дублируются — fork() копирует только вызывающий поток
• Это правило касается любого пула TCP-соединений: psycopg, SQLAlchemy, redis-py — поведение ядра одинаково

Невидимая часть — это взаимодействие между последовательностью запуска Django и моделью процессов Celery. Две системы, каждая из которых хорошо понятна по отдельности, делают неожиданное на стыке.

Адаптированный перевод статьи What fork() Actually Copies Даниэля Бастоса (Daniel Bastos).

Мы все там были. Выучили ls, cd и grep — и на этом остановились. Терминал стал местом, где мы живём, но обустроить его мы так и не удосужились. Мы миримся с тем, что какие-то действия требуют 40 нажатий, хотя авторы шелла решили нашу проблему ещё в 1989 году.

Вот подборка приёмов, которые не то чтобы секретные — но которым почему-то не учат. Разделим их на две группы: универсальные (работают почти в любом POSIX-шелле) и для Bash/Zsh (интерактивные фишки).

TL;DR: Ctrl+W удаляет слово, Ctrl+U — строку до курсора, Ctrl+R ищет по истории, !! повторяет предыдущую команду (незаменимо для sudo !!), а cd - возвращает в предыдущую директорию. Начните хотя бы с этих пяти.

Универсальные: работают (почти) везде

Эти приёмы опираются на стандартные привязки клавиш Emacs-стиля через Readline. Даже если вы подключились по SSH к роутеру 2009 года выпуска или минимальному Alpine-контейнеру — они будут работать.

Замена Backspace

• Ctrl+W — удалить слово перед курсором. Набрали /var/log/nginx/, а нужно было /var/log/apache2/? Одно нажатие вместо 7 Backspace
• Ctrl+U — вырезать всё от курсора до начала строки. Набрали длинную команду rsync, но сначала нужно проверить директорию? Ctrl+U вырезает, а Ctrl+Y вставляет обратно
• Ctrl+K — то же самое, но вырезает от курсора до конца строки
• Ctrl+A и Ctrl+E — прыжок в начало и конец строки. Забудьте про Home и End — они далеко от домашнего ряда
• Alt+B и Alt+F — перемещение по словам назад и вперёд. Быстрый аналог стрелок (на Mac нужно настроить Option как Meta в терминале)

Терминал показывает иероглифы?

Случайно сделали cat на бинарник — и терминал превратился в месиво символов? Наберите вслепую reset и нажмите Enter. Терминал восстановится. Альтернатива — stty sane.

Экстренные выходы

• Ctrl+C — отменить текущую команду. Ваш аварийный выход, когда что-то зависло
• Ctrl+D — отправить EOF. Если командная строка пуста — разлогинит из шелла. Осторожнее!
• Ctrl+L — очистить экран, не прерывая набор текущей команды. Удобнее, чем clear

Прыгаем между директориями

cd - — переключение между двумя последними директориями. Вы в /usr/local/etc/postfix, перешли в /var/log посмотреть логи — cd - вернёт обратно. Как кнопка «последний канал» на пульте.

pushd и popd — если cd - это переключатель, то pushd это стек. pushd /etc перейдёт в /etc, запомнив предыдущую директорию. popd снимет её со стека и вернёт вас.

Мгновенная очистка файла и последний аргумент

> file.txt — очищает файл, сохраняя права и не прерывая процессы. $_ — последний аргумент предыдущей команды:

Страховка для скриптов

• -e — останов при ошибке (нюансы с if и пайпами)
• -u — ошибка при несуществующей переменной. Спасёт от rm -rf /usr/local/${OPECHATKA}/*
• -o pipefail — ошибка в любом звене пайпа = ошибка всей цепочки

Bash и Zsh: зона комфорта

Поиск по истории и «sudo !!»

Ctrl+R — обратный поиск по истории. Начните вводить часть команды — шелл найдёт её. !! — повторить предыдущую команду. Классика: получили «Permission denied» — sudo !!.

Редактор, brace expansion и процессы

Ctrl+X, Ctrl+E — открывает текущую команду в $EDITOR. fc — то же для предыдущей команды. Esc+. — вставляет последний аргумент прямо на месте курсора. Брейс-экспаншн для быстрых операций:

Спасти процесс от обрыва SSH

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

Источник: Shell Tricks That Actually Make Life Easier — Hofstede Blog

Новые фичи, интеграции, поддержка Kubernetes и облаков сделали продукт мощнее... и заметно тяжелее. Это стало проблемой для serverless, IoT и контейнеров.

Вместо того чтобы урезать функциональность, команда решила «переломить кривую роста». За полгода (v7.60.0 → v7.68.0) им удалось сократить размер Go-бинарников до 77%.

Аудит зависимостей: минус 36 МБ одной правкой

Первый шаг — полный разбор зависимостей. С помощью go list, goda и go-size-analyzer разработчики искали пакеты, которые подтягиваются в бинарник случайно.

В одном случае trace-agent тащил 526 пакетов Kubernetes из-за одной функции, которая фактически не использовала k8s-код. Перенос ее в отдельный пакет позволил компилятору выбросить все лишнее — минус 36 МБ.

И таких случаев нашли десятки.

Разблокировка «скрытой» оптимизации линкера

Вторая находка дала еще ~20% выигрыша. В Go есть оптимизация method dead code elimination, но она отключается, если используется reflect.MethodByName с динамическими именами (например, в text/template).

Команда нашла проблемные вызовы через -dumpdep и утилиту whydeadcode, пропатчила зависимости и даже форкнула text/template, чтобы отключить динамические вызовы методов. Результат — еще минус около 100 МБ.

Удаление plugin = минус 245 МБ

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

Выяснилось, что зависимость приходила через containerd, хотя агент ее не использовал. После добавления build-тега и обновления зависимостей, основной Linux amd64-бинарник «похудел» на 245 МБ.

Итог

• Security Agent: −77%
• Process Agent: −74%
• Trace Agent: −74%
• Общий .deb: 1,22 ГБ → 688 МБ

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

По данным участников рынка, трафик к kernel.org и ряду европейских репозиториев убивается на ТСПУ-узлах — оборудовании, установленном Роскомнадзор у операторов связи.

Под блокировку попали репозитории

Проблема затронула команды, работающие над Astra Linux, РЕД ОС и Alt Linux. Сначала инженеры подозревали локальные сбои или проблемы магистральных провайдеров.

Но трассировка показала: пакеты обрываются именно на инфраструктуре фильтрации трафика.

По оценкам экспертов, причина заключается в попытке точечно ограничить протоколы обхода блокировок и замедления Telegram. Под «ковровую» фильтрацию, вероятно, попали IP-диапазоны CDN-сетей, где размещаются зеркала Linux Kernel Archives.

Абсурд цифровой изоляции

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

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

Зависимость от глобального open source

Инцидент напомнил о фундаментальной реальности: российские ОС — это дистрибутивы на базе Linux. Их безопасность и актуальность напрямую зависят от международных репозиториев и глобального open-source сообщества.

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

Об этом Миллер написал на своем личном сайте, отметив, что уже более 30 лет остается фактически единственным мейнтейнером одного из ключевых инструментов Unix- и Linux-систем.

Что произошло

До февраля 2024 года разработку sudo спонсировала компания Quest Software (позже — One Identity). После завершения сотрудничества и ухода Миллера из компании, финансирование прекратилось. С тех пор поддержка проекта ведется без стабильного источника дохода.

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

Почему это проблема

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

За последние годы в ней неоднократно находили серьезные уязвимости, включая баги, позволявшие локальным пользователям получать root-доступ. Некоторые из них существовали в коде более 10 лет.

Именно из-за регулярных проблем с безопасностью в экосистеме появился sudo-rs — новая реализация утилиты на Rust, ориентированная на безопасную память. В Ubuntu 25.10 она уже используется по умолчанию.

Что будет дальше

Миллер подчеркивает, что не планирует бросать sudo, но и не видит очевидного преемника. После истории с закладкой в xz-utils, он с осторожностью относится к передаче проекта сторонним разработчикам.

При этом он считает, что в долгосрочной перспективе именно sudo-rs станет основной версией инструмента. Он уже даже сотрудничает с командой этого проекта.

Компилятор написан на Rust, насчитывает около 100 000 строк кода и может собирать Linux 6.9 для архитектур x86, ARM и RISC-V.

Как это вообще произошло

В эксперименте использовалась модель Claude Opus 4.6, запущенная в режиме так называемых agent teams. Это подход, при котором несколько экземпляров ИИ работают параллельно над одним репозиторием и сами решают, какие задачи брать дальше.

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

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

Процесс длился почти две недели и включал около 2000 сессий Claude Code. Общая стоимость эксперимента составила примерно $20 000.

Что умеет получившийся компилятор

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

• собирает Linux 6.9;
• компилирует крупные проекты вроде SQLite, Redis, FFmpeg и QEMU;
• проходит около 99% тестов из GCC torture test suite;
• способен скомпилировать и запустить DOOM — неофициальный, но показательный бенчмарк.

Важный момент: у ИИ не было доступа к интернету, то есть делалось в рамках имеющейся «базы знаний» модели.

Где начинаются ограничения

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

• нет собственного ассемблера и линковщика — они частично заимствуются у GCC;
• кодовая база нестабильна: новые изменения часто ломают старые части;
• 16-битный x86-код (нужный для загрузки Linux) реализован «читерски» — через вызов GCC.

Сами авторы также подчеркнули, что модель уперлась в потолок своих возможностей — дальнейшее развитие компилятора становится все менее предсказуемым.

Причина не в идеологии open-source и не в желании «поковыряться в Терминале». Все куда прозаичнее и ближе — за последние годы сама Windows сильно изменилась.

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

Обновления без согласия и баги без решений

Ключевой переломный момент — крупное обновление Windows 11 24H2. Оно установилось автоматически, несмотря на отложенные апдейты, и принесло с собой критический баг: Google Chrome начинал «ломаться» визуально, если оказывался под другим окном, а иногда это приводило к полной блокировке системы.

Откат обновления не сработал, переустановка Windows проблему не решила. Единственным «рабочим» вариантом оказался переход на Insider-сборку. А это, на минуту, нестабильный канал обновлений, который Microsoft обычно не рекомендует для основной системы.

Позже выяснилось, что проблема связана с конфликтом драйверов NVIDIA и механизмом Multiplane Overlay (MPO). При этом NVIDIA и Microsoft публично перекладывали ответственность друг на друга, а пользователь оставался без реального решения.

Реклама и контроль вместо системы для работы

Помимо багов, автор отдельно отмечает изменения в философии Windows:

• полноэкранные рекомендации и реклама OneDrive, Edge и Copilot;
• сложности с созданием локальной учетной записи без обходных путей;
• невозможность «заморозить» стабильную конфигурацию без риска, что следующий апдейт все сломает.

В результате Windows, по его словам, перестала быть «удобной по умолчанию». Система стала требовать столько же ручной настройки, сколько Linux — но без контроля над результатом.

Переход на Linux: больно, но чинится

В качестве основной системы разработчик выбрал CachyOS — производительный дистрибутив на базе Arch Linux. Переход оказался не идеальным: были проблемы со сном системы и работой драйверов NVIDIA. Но ключевое отличие от Windows — эти проблемы удалось решить.

Что в итоге

Автор подчеркивает: Linux все еще не универсален. В креативных задачах, 3D-моделировании и некоторых играх ограничения остаются. Но главное изменение — ощущение контроля над системой.

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

И именно это, как он считает, сегодня подталкивает все больше разработчиков и пользователей смотреть в сторону Linux.

Линус Торвальдс закоммитил файл Project continuity — формальный план действий на случай, если он больше не сможет выполнять роль главного мейнтейнера проекта.

Переживать не стоит — пока что речи о скором уходе или передаче власти «наследнику» не идет. Документ скорее фиксирует то, как сообщество должно действовать в кризисной ситуации — внезапной и без предварительной подготовки.

Ранее подобные вопросы в Linux решались негласно и на уровне доверия, но теперь процесс впервые описан письменно.

Почему это вообще понадобилось

Linux — распределенный проект с сотнями мейнтейнеров, но финальная точка принятия решений по-прежнему сходится в одном месте: в основном репозитории ядра.

Исторически эту роль выполняет сам Торвальдс. Именно он принимает изменения в mainline и определяет, что считается «официальным» Linux.

В коммите напрямую упоминается релиз 4.19 в 2018 году — момент, когда Торвальдс временно отошел от проекта.

Тогда стало очевидно, что даже при развитой системе мейнтейнеров отсутствие одного человека создает управленческую неопределенность. Новый документ — попытка эту неопределенность устранить.

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

Если кратко, Linux не переходит под контроль одного нового лидера автоматически. Вместо этого запускается процесс коллективного управления.

Организатор последнего Linux Maintainers Summit обязан в течение 72 часов собрать обсуждение с участниками саммита и Technical Advisory Board (TAB) Linux Foundation.

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

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

Если саммит давно не проводился, состав участников определяет TAB. Через две недели после встречи, сообщество получает публичное разъяснение дальнейших шагов через официальную рассылку kernel.org.

Эксплойт умещается в одну строку, а сама проблема незаметно прожила в коде почти 11 лет — с мая 2015 года. О находке сообщило издание The Register.

Уязвимости присвоен идентификатор CVE-2026-24061, уровень опасности — 9,8 балла по CVSS.

В чем суть бага

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

Проблема возникла из-за правок 2015 года в telnetd (версия 1.9.3). Сервер передает имя пользователя в системную утилиту /usr/bin/login, которая поддерживает флаг -f.

Этот флаг сообщает, что пользователь уже аутентифицирован и проверку пароля можно пропустить.

После тех изменений telnetd стал брать имя пользователя из переменной окружения USER — без проверки и экранирования. В итоге атакующий может подставить туда значение -f root и получить root-доступ.

Как выглядит эксплуатация

Эксплойт действительно тривиален и помещается в одну строку:

Если сервер уязвим, подключение сразу происходит от имени суперпользователя — без ввода пароля. По словам Стивена Фьюэра из Rapid7, эксплуатация проблемы «элементарна и гарантированно приводит к полному root-доступу».

Почему это особенно неприятно

• баг существовал почти 11 лет и попал в код вместе с «исправлением» другой ошибки;
• атака не требует подбора паролей или сложной подготовки;
• уязвимость работает до аутентификации;
• telnet-серверы до сих пор доступны в интернете.

По данным сервиса GreyNoise, за последние сутки зафиксированы попытки эксплуатации CVE-2026-24061 как минимум с 21 уникального IP-адреса.

Что рекомендуют делать

Рекомендации ожидаемые, но все еще актуальные:

• обновить GNU InetUtils до версии с исправлением;
• по возможности полностью отказаться от telnet в пользу SSH;
• временно отключить telnetd;
• если отключение невозможно — закрыть порт 23/TCP для всех, кроме доверенных IP.

Но если в UNIX это скорее философия с оговорками, то в PatchworkOS идея доведена почти до абсолюта. Здесь файлами считаются не только данные, но и процессы, события, таймеры и даже взаимодействие с ядром.

Проект носит исследовательский характер и не претендует на роль универсальной ОС для повседневного использования.

Как работает «все — файл» в PatchworkOS

В PatchworkOS файловая система — это главный интерфейс ко всему, что происходит в системе.

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

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

Сам автор проекта описывает PatchworkOS как систему, где файловая и процессная модели слиты воедино, а граница между «данными» и «поведением» намеренно размыта.

Минимум абстракций и максимум прозрачности

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

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

Норберг отдельно отмечает, что его операционка — это не Linux-дистрибутив и не попытка конкурировать с существующими ОС.

Ограничения и честные предупреждения

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

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