Снова здравствуйте, уважаемые хабровчане.
В последнее время мы ( или только я ) слышим про новые отечественные операционные системы, которые обещают перевернуть игру. обычно я просто скипаю но про НАЙС.ОС сложно молчать.
Их лендинг - это просто фулл хаус из модных слов: Мы не пересобираем чужие дистрибутивы Атомарные обновления Immutable-подход Secure Supply Chain Ready for Production.
Как человек, привыкший к Arch и FreeBSD, я напрягся, когда увидел слова Инновационная ОС и Госреестр в одном предложении. Особенно когда заявлено, что система не является форком, а представляет собой минимальную базу, созданную с нуля. Я решил не верить маркетингу, а скачать ISO, запустить виртуалку и проверить: действительно ли перед нами Русский CoreOS/Talos?
Акт 1. Мы не пересобираем чужие дистрибутивы
Первое, что бросается в глаза на сайте - громкое заявление:
«NiceOS — не ещё один Linux. Мы не пересобираем чужие дистрибутивы...»
Звучит амбициозно. Заходим на их GitHub. В описании репозитория niceos-docker-image читаем:
«No systemd, tiny deps, tdnf as the package manager...»
Ого, tdnf (Tiny DNF) - это пакетный менеджер из VMware Photon OS. Неужели реально взяли и собрали что-то свое ( Но мы же вроде не пересобираем чужое ) на базе Photon?
Качаю ISO НАЙС.ОС 5.2. Запускаю установку.
И что я вижу?
Это Anaconda. Стандартный до боли знакомый инсталлятор Red Hat / Fedora / CentOS.
Ладно, инсталлятор можно взять готовый. Загружаемся в систему.
cat /etc/os-release
NAME="NiceOS"
ID_LIKE="rhel centos fedora"
CPE_NAME="cpe:/o:niceos:niceos:5::baseos"
Строка ID_LIKE="rhel centos fedora" - Система сама признается, что она RHEL-совместимая. Пакетный менеджер внутри - обычный dnf, Система инициализации - systemd.
Вывод №1: Это форк RHEL/CentOS.
Акт 2. Миф об Иммутабельности
На сайте и в документации нам продают киллер-фичу:
«Immutable-подход — базовая система защищена от случайных изменений... Атомарные обновления... Обновления не ломают систему».
Неизменяемость означает, что корень файловой системы (/ или /usr) смонтирован в режиме Read-Only. Вы физически не можете удалить системные файлы, не переведя систему в специальный режим. Так работают Fedora Silverblue, SteamOS, Talos, И много че еще.
Проверяем НАЙС.ОС:
mount | grep " / "
Вывод: /dev/sda3 on / type ext4 (rw,noatime)
Read-Write. Обычная, записываемая файловая система.
Но может, там стоит какая-то хитрая защита на уровне ядра или SELinux, которая не дает трогать систему?
Проводим главный тест на иммутабельность. Слабонервным отойти от экранов)))).
rm -rf /*
Система начала удалять сама себя. Через минуту я получил Kernel panic, потому что удалил init.
Вывод №2: Заявления об Immutable и Атомарности - ложь.
Акт 3. Франкенштейн в продакшене
Ладно, допустим, это просто RHEL. RHEL - это надежно, стабильно, скучно.
Но давайте посмотрим на версии пакетов, которые они предлагают для Критической инфраструктуры.
На сайте гордо указано:
GCC 14.3.0
Glibc 2.41
Systemd 257.6
Это Bleeding Edge.
В стабильном RHEL 9 используется GCC 11 и Glibc 2.34.
Glibc 2.41 - это новейшая библиотека, которая может быть несовместима со старым rорпоративным софтом (Oracle DB, проприетарные драйверы, 1C).
Вы теряете стабильность Enterprise-дистрибутива (новые пакеты = новые баги)
Вы теряете совместимость (софт, сертифицированный под RHEL, может не запуститься на Glibc 2.41).
Вывод №3: Это свежак, это не надежно
Акт 4. GPL ? не, не слышали
При установке нас встречает EULA (Лицензионное соглашение). И там есть прекрасный пункт 2:
«ПОЛЬЗОВАТЕЛЮ запрещается: ...декомпилировать, дизадсемблировать или иным образом пытаться получить исходный код...»
дистрибутив состоит из Ядра Linux, Glibc, Systemd, Coreutils. Всё это - программное обеспечение под лицензией GNU GPL.
Лицензия GPL запрещает накладывать ограничения на изучение и модификацию кода.
Пункт 6 лицензии GPLv2 гласит: «You may not impose any further restrictions on the recipients' exercise of the rights granted herein».
Запрещая декомпиляцию ядра Linux, ООО «НАЙС СОФТ ГРУПП» прямо нарушает лицензию авторов ядра. Более того, я ( возможно плохо рыл ) не нашел в открытом доступе ни SRPM-пакетов, ни сборочных скриптов для их ISO.
GitHub проекта заполнен форками чужих утилит и Docker-файлами, но исходного кода самой ОС там нет.
Акт 5. Сертификаты и Суверенность
Ну и вишенка на торте. Зачем вообще всё это нужно?
В документации прямым текстом сказано про Russian Trusted Root CA.
На эту тему у меня есть крутая статья
И еще одна даже по круче
Итоги
Что мы имеем в сухом остатке?
НАЙС.ОС - это пересборка (форк) RHEL/CentOS/Fedora, несмотря на заявления об обратном.
Иммутабельности нет. несмотря на заявления об обратном.
Атомарности нет. несмотря на заявления об обратном.
Стабильность под вопросом. Смесь Enterprise-базы и Bleeding-edge пакетов (GCC 14) — это бомба замедленного действия для совместимости.
Нарушение лицензий. EULA запрещает то, что разрешает GPL. Исходники закрыты.
Иновации. Они не удосужились создать отдельную "компанию" в Github
Выводы делайте сами, удачки.
Комментарии (13)
t0kashi
16.12.2025 02:54Благодарю автора! Это совершенно справедливое распедаливание гос-вайб-кодеров.
DenisArd
16.12.2025 02:54По поводу лицензии - справедливости ради у них есть оговорка про компоненты под открытыми лицензиями, т.е. запреты декомпиляции/модификации на компоненты под GPL не распространяются, речь только о проприетарных компонентах. Другой вопрос, есть ли в дистрибутиве хоть что-то самописное, а не форкнутое из открытых источников...
DTGP
16.12.2025 02:54У вас в "разборе" есть несколько правильных наблюдений (да, у NiceOS RPM-стек; да, слова вроде immutable нужно объяснять), но ключевые выводы уехали из-за подмен понятий и "проверок", которые проверяют не то, что вы предполагаете.
1) "Похоже на Anaconda → значит RHEL/CentOS/Fedora"
Похоже ≠ является.
В NiceOS используется NiceOSInstaller. Это не Anaconda и не “анаконда-совместимость”.
То, что UX-шаги выглядят привычно ("язык → диск → сеть → пароль"), не является доказательством конкретного установщика. У серверных ОС 90% установщиков выглядят одинаково, потому что задачи одинаковые.
Вывод "это форк RHEL" из "похоже на Anaconda" логически не следует. И отдельно: это не Anaconda.
2)
ID_LIKE="rhel centos fedora"— это не "форк"ID_LIKE— стандартное поле/etc/os-release. Его смысл прагматичный: подсказать внешним скриптам/инсталляторам/агентам, к какому семейству по пакетной модели и стандартным путям ближе система.Если воспринимать
ID_LIKEкак "ДНК-тест", придётся объявить "форками" кучу дистрибутивов, которые ставятID_LIKEчтобы не ломались установщики агентского софта, Ansible-ролей, hardening-скриптов и т.п.RHEL-совместимость по интерфейсам/пакетной модели ≠ форк. Это ровно "мы ближе к этому семейству, чем к Debian".
3) "Миф об иммутабельности":
mountпоказываетrw→ "всё ложь"Здесь вы смешали два режима, а проверили один.
В NiceOS два сценария установки:
обычный RPM-режим (mutable): да,
/может бытьrw— это нормально;OSTree/rpm-ostree (atomic updates): системный слой развёртывается как deployment и обновляется/откатывается транзакционно, а не через "пачку rpm поверх".
Если вы хотите проверять именно "атомарность/rollback", тестировать надо OSTree-признаками, а не
mount | grep " / ".Минимальный "правильный" набор проверок для OSTree-режима:
rpm-ostree status(видны deployments)sudo rpm-ostree upgrade→ перезагрузкаsudo rpm-ostree rollback→ перезагрузка(по ситуации)
sudo rpm-ostree rebase <REMOTE>:<BRANCH>
А ваш "главный тест"
rm -rf /*— это тест "может ли root уничтожить FS", а не тест atomic updates. Даже в системах с "immutable"-философией root почти всегда может сломать/etcи/var(и должен иметь такую возможность), вопрос в управляемости системного слоя и откатах.Отдельно: "immutable как у Talos" (жёсткий RO-root + отсутствие привычного шелла/SSH) и "atomic updates через OSTree" — это разные модели. Часто их путают, но они не обязаны совпадать.
4) "GCC/Glibc/Systemd новые → значит ненадёжно и не enterprise"
Это слишком примитивная связка.
Да, RHEL 9 сознательно консервативен по базовым версиям — это их стратегия. Но из этого не следует "всё новое = не enterprise". "Enterprise" — это не "древнее", а "предсказуемое": процесс обновлений, тестирование, откаты, прозрачные артефакты.
И главное: вы сами почти проговариваете, но не учитываете выводом — в NiceOS базовый паттерн container-first:
хост — минимальная, управляемая платформа,
прикладное (1C/пр. зависимости) — в контейнерах/образах с тем userspace, который им нужен.
В таком подходе вопрос "какая glibc на хосте" теряет критичность для прикладного софта, потому что прикладной стек живёт в своём образе. Общим остаётся в первую очередь kernel ABI и инфраструктурные интерфейсы. Именно поэтому "совместимость со старым корпоративным софтом" решается не "заморозкой всего хоста навечно", а изоляцией прикладного окружения.
5) GPL/EULA и "где исходники на GitHub"
Две разные вещи:
GitHub не является обязательным местом публикации исходников по GPL.
Но если вы распространяете бинарники GPL-компонентов, вы обязаны выполнять условия соответствующих лицензий (исходники/предложение исходников/патчи в требуемом формате).
Корректная позиция тут не "мы никому ничего не должны", а:
"на open-source компоненты действуют их лицензии".
Это снимает спор на уровне фактов, а не эмоций.
6) Russian Trusted Root CA
Тут у вас эмоциональная подача, а вопрос чисто утилитарный: в российских контурах часто нужно, чтобы TLS из коробки доверял цепочкам, с которыми работают банки/гос-сервисы/корп-PKI. Это не "инновация" и не "заговор", это совместимость.
При этом вопрос доверия решается просто: trust store управляемый. Не доверяете — уберите конкретные корни/замените стор/используйте корпоративную PKI. Ровно так же, как люди живут с сотнями "западных" корневых в любой ОС: наличие корня ≠ "автоматическое доверие всему миру", это лишь список возможных якорей доверия. Почему вы доверяете все западным сертификатам по умолчанию?
7) "Почему не создана отдельная "компания" на GitHub"
Организация на GitHub — вопрос удобства, а не критерий качества ОС. Критерии качества — это проверяемые вещи: модель обновлений, обновляемость артефактов, политика безопасности, документация, воспроизводимость, а не организация на GitHub.
Разборы в целом полезны. Но если заявляется "проверка", то она должна тестировать тот режим, про который делается вывод: RPM-установка и OSTree-deployment — разные сценарии, и проверять их нужно по-разному. Иначе получается не аудит, а набор ассоциаций "похоже на X → значит X", что для инженерной дискуссии слабовато.
Итого:
1) "НАЙС.ОС — форк RHEL/CentOS/Fedora"
Нет.
2) "Иммутабельности нет"
Автор проверил не тот режим и сделал "вывод". Его тест — это буквально: "можно ли root’ом сломать Linux". Можно. Почти везде.
В NiceOS заявляется поддержка OSTree/атомарного подхода и контейнерная модель (база стабильна, прикладное — в контейнерах). Это другой слой, чем "/ смонтирован rw".
3) "Атомарности нет"
Атомарность в OSTree/rpm-ostree мире — это не "/ всегда read-only", а то, что обновление готовит новый deployment и переключение происходит при перезагрузке, с возможностью отката.
Если человек установил/тестировал RPM-вариант, а потом объявил "атомарности нет в принципе" — это как зайти в ресторан через аварийный выход и написать рецензию, что "входа не существует".
4) "Стабильность под вопросом: enterprise + bleeding edge (GCC 14, glibc 2.41…)"
В документации NiceOS OSTree ровно так и позиционируется: иммутабельная база + контейнеры/Kubernetes как основной паттерн.
5) "Нарушение лицензий: EULA запрещает то, что разрешает GPL. Исходники закрыты"
Неверное прочтение EULA.
6) "Инноваций нет: не сделали "компанию" на GitHub"
Это аргумент уровня "у вас неправильная аватарка". Наличие/отсутствие GitHub-org не доказывает ни инновации, ни их отсутствие.
Логические ошибки или теханализ?
Кстати, установив ОС, вы согласились с лицензией.
alprk
16.12.2025 02:54ну т.е. там можно установить в другом режиме и поучить подобие ublue с rpm-ostree? А ребейзнуться с Fedora Kionite/Silverblue (и обратно) возможно?
DTGP
16.12.2025 02:54OSTree-режим да, похоже на Atomic/uBlue (deployments + rollback). Fedora ↔ НАЙС.ОС rebasing — не целевой/неподдерживаемый сценарий: разные подписи/репы/база. Это абсолютно разные ОС. Нормальная практика — миграция через контейнеры/перенос данных или переключение режимов внутри НАЙС.ОС.
maisvendoo
16.12.2025 02:54как Не пересборка RHELL оказалась RHEL
А потом мы удивляемся, чего это Линус Торвальдс так некачественно относится к российским разработчикам. Может причина как раз в этом?
iwram
Считаю статью неполной т.к. нет отдельного пункта про "нескучные обои". Требую на уровне законодательства ввести обязательное требование обозревать обои во всех новых дистрибутивах!