Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 26
Считаю статью неполной т.к. нет отдельного пункта про "нескучные обои". Требую на уровне законодательства ввести обязательное требование обозревать обои во всех новых дистрибутивах!
Благодарю автора! Это совершенно справедливое распедаливание гос-вайб-кодеров.
BolgenOS?
По поводу лицензии - справедливости ради у них есть оговорка про компоненты под открытыми лицензиями, т.е. запреты декомпиляции/модификации на компоненты под GPL не распространяются, речь только о проприетарных компонентах. Другой вопрос, есть ли в дистрибутиве хоть что-то самописное, а не форкнутое из открытых источников...
Надеюсь авторы сего "творения" на вас не накатят жалобу в прокуратуру
Это Bleeding Edge.
просто федора
У вас в "разборе" есть несколько правильных наблюдений (да, у 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 не доказывает ни инновации, ни их отсутствие.
Логические ошибки или теханализ?
Кстати, установив ОС, вы согласились с лицензией.
ну т.е. там можно установить в другом режиме и поучить подобие ublue с rpm-ostree? А ребейзнуться с Fedora Kionite/Silverblue (и обратно) возможно?
Что за......... кого вы тут надурить пытаетесь? 1 аргумент они сами в своей статье на хабре пишут: "Мы создавали kickstart-файл... Anaconda... потом перепрофилировали Photon Installer"), выглядит как Anaconda Text Mode и ведет себя как Anaconda - это форк Anaconda или Photon Installer (который тоже форк), я вскрыла ваше ISO и там код Photon Installer!
2 аргумент если у вас: Пакетный менеджер dnf, Система сборки на rpmbuild и .spec файлах (они сами признались в статье), systemd, Структура файловой системы RHEL, И ID_LIKE=rhel.
То вы RHEL-совместимый дистрибутив. То есть клон/форк/дериватив
3 аргумент бред, я качал именно это, вы сами не понимаете что говорите! прямым языком написано же что я скачал именно НАЙСОС 5.2 minimal - ГОСТ-криптография · 2 режима: RPM и OSTree · контролируемые обновления! и я не нашел функцию смены режима, потому что ее НЕТУ! не на этапе установки НИГДЕ!
4 аргмуент "На хосте пофиг какая версия, всё равно приложения в Докере...." мда, без слов
Вы распространяете ISO публично. Значит, ссылка на Source RPM (SRPM) должна быть доступна публично или по первому требованию БЕЗ регистрации и СМС.
Где ссылка?
В статье вы пишете: "Храним весь код... на внутреннем GitLab".
Это нарушение GPL. Вы обязаны предоставить код получателю бинарника. Я скачал бинарник. Дайте код. Прямо сейчас! дайте мне в личку телеграма @zarazaexe и я отменю аргумент! но на 50%
Сомнительно (кол-во srpm), но попытка была https://packages.niceos.ru/?path=niceos%2F5.2%2Fsrpm . Технические неполадки должно быть, в результате чего отображаются не все пакеты /s
Инсталлятор. Но вы же писали что это anaconda. Оказалось нет? "Это Anaconda. Стандартный до боли знакомый инсталлятор Red Hat / Fedora / CentOS."
Инсталлятор — это один компонент (как Calamares/Anaconda/Subiquity и т.п.).
Дистрибутив — это репозитории, политика сборки, набор spec-файлов, патч-сеты, ключи подписи, модель обновлений, состав базового userspace и т.д.
"DNF/RPM/systemd/FHS/ID_LIKE=rhel ⇒ вы RHEL-клон"
RPM/dnf/spec — это формат пакетов и tooling. Его используют разные системы, и это не "RHEL".
systemd — де-факто стандарт в Linux-мире на сегодняшний день.
FHS/структура файловой системы — общий стандарт; совпадение с RHEL — ожидаемо. Кстати, что такое FHS?
OSTree обычно не "переключается галочкой" в одном и том же ISO как режим "туда-сюда".
На практике это либо отдельный профиль установки/образ, либо заранее выбранная модель обновлений для конкретной линии поставки либо самостоятельный деплой. Вы читали документацию? Сделайте самостоятельный deploy OSTree под ваши задачи и тестируйте.
«SRPM должны быть публично без регистрации, иначе нарушение GPL»
GPL требует, чтобы получатель бинарника мог получить соответствующий исходный код (в формах, разрешённых лицензией: например, сопровождать бинарник исходниками или дать письменное предложение предоставить исходники и т.п.). GPL не требует, чтобы весь код всегда лежал публично "для всех". https://www.gnu.org/licenses/gpl-faq.en.html
"Дайте код прямо сейчас в личку Telegram…"
Исходники выдаются официальным каналом (публичный каталог SRPM/почта поддержки), потому что:
нужно однозначно фиксировать состав запроса (какой пакет/версия),
и давать воспроизводимую ссылку/архив именно на ту версию, которая актуальна на данный момент.
То есть, вы запрашиваете конкретную версию - получаете исходники и воспроизводите все 1 в 1.
"В статье вы пишете: "Храним весь код... на внутреннем GitLab"." - это требования безопасной разработки по методологии ФСТЭК, а не разработка ОС "на коленке".
Хранение исходных кодов и артефактов сборки в контуре разработки — практика безопасной разработки и управления цепочкой поставки. Это формализовано регуляторно: порядок сертификации процессов безопасной разработки установлен приказом ФСТЭК России №240 (с изменениями по приказу №230). Исходные коды компонентов под свободными лицензиями предоставляются получателям бинарников в порядке, предусмотренном соответствующими лицензиями
Я вытащил конфиг вашего ядра из вашего же ISO.
Строка 30:
CONFIG_BUILD_SALT="6.6.13-100.fc38.x86_64"
fc38 - это Fedora 38. Вы взяли ядро Fedora 38 которая находится в EOL, закончено.
в статье не слова плохого о systemd, а на сайте всего 1 кнопка скачать ISO образ, вы меня за дурочка принимаете? зачем писать на сайте "Мы не пересобираем чужие дистрибутивы" если вы пересобираете RHEL а точнее FEDORA
Фраза «мы не пересобираем чужие дистрибутивы» означает конкретную вещь:
НАЙС.ОС не использует бинарные репозитории Fedora/RHEL, не берёт их SRPM как базу и не наследует их релизный цикл. Система собирается из upstream-исходников (ядро, glibc, GCC, systemd и т.д.) по собственной сборочной политике, с собственными spec-файлами, патчами и репозиториями.
Система собирается из upstream-исходников (ядро, glibc, GCC, systemd и т.д.) по собственной сборочной политике, с собственными spec-файлами, патчами и репозиториями.
Ок, вы сами патчите ядро. Где, согласно GPL, по которой ядро предоставляется исходники ваших патчей?
давать воспроизводимую ссылку/архив именно на ту версию, которая актуальна на данный момент
Кто мешает это делать? Давать ссылки на исходники актуальных версий, модифицированных вами с помощью патчей, GNU-компонент?
Лицензия ничтожна в части нарушения других лицензий.
как Не пересборка RHELL оказалась RHEL
А потом мы удивляемся, чего это Линус Торвальдс так некачественно относится к российским разработчикам. Может причина как раз в этом?
Ознакомился внимательно со статьёй и с аргументами оппонентов. Ну не Fedora 38 (согласен с оппонентами), но и не оригинальная ОС (согласен с автором). Можно тут кидаться словами "форк" и "дериватив" и долго спорить об этом, но проще это называется, как оно бывает в титрах фильма, "по мотивам произведений такого-то". В итоге, на фоне других ОС, чьи создатели ставят перед собой схожие благородные цели, ничего ценного в этой конкретной не увидел
Что такое "клон", "дериватив", "форк".
Пересборка / rebuild: берём чужую базу и делаем максимально похожую систему под своим брендом. Часто это делается ради совместимости: "чтобы софт/драйверы/инструменты вели себя как в RHEL-мире".
Дериватив: система из того же семейства (Debian/RHEL/…), но со своими репозиториями, политикой сборки, патчами, документацией, поддержкой. Может сохранять совместимость, но это уже не просто "перепаковали".
Форк: проект отделился и развивается самостоятельно со своим курсом. Он может оставаться совместимым или нет — важно, что развитие идёт независимо.
Клон: "похоже на оригинал почти во всём, а добавленной ценности мало". Это скорее оценка, чем технический диагноз.
Фраза "по мотивам" вообще честная: так можно описать половину Linux-мира.
Про "ничего ценного не увидел".
Это нормальная реакция, если смотреть глазами домашнего пользователя или человека с опытом Arch/Ubuntu на десктопе: cloud-ОС для кластера действительно выглядит странно ("и что я с ней буду делать?").
Но ценность таких систем обычно видна в другой роли: когда ты DevOps/SRE и "живёшь в облаках", Kubernetes и GitOps. Там важны не "огромная пакетная база и ручная настройка на хосте", а минимальный хост, одинаковые ноды, меньше дрейфа, атомарные обновления/откаты (OSTree) и то, что приложения едут в контейнерах через CI/CD. Поэтому "не увидел ценности" часто означает "это не мой класс задач".
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
НАЙС.ОС — как Не пересборка RHELL оказалась RHEL