bootc тут не «обязательная глава», потому что это про другой слой задачи: bootc в первую очередь меняет транспорт и упаковку артефакта (OCI-образ/registry), а статья объясняет базовую механику OSTree как "git-подобной доставки дерева" и практику поднятия своего ostree-репо. Это как предъявлять к статье про HTTP претензию «не хватает QUIC»: полезно, но это отдельная тема, иначе текст расползётся в "всё обо всём" и сразу.
bootc в отличии от ostree-rpm занимает более жёсткую позицию: система должна апдейтиться из образа, а как только вы начинаете "мутировать" систему локально (layering и т.п.), bootc upgrade скорее скажет «я не понимаю, как это обновлять». Это прямо проговорено в документации про взаимоотношения bootc и rpm-ostree.
То есть "rpm-ostree полумера" = "rpm-ostree допускает локальную сборку состояния на клиенте", а bootc пытается это запретить как класс (или вынести в другие механизмы).
rpm-ostree по определению гибрид: образная модель + пакетный мир, включая client-side layering. Это фича для сценариев, где вам нужно чуть-чуть управляемой мутабельности (особенно на рабочих станциях или при постепенной миграции). Примечательно, что даже Fedora-доки сегодня описывают bootc upgrade и rpm-ostree upgrade как взаимозаменяемые операции "в общем случае" — то есть речь не о "замене плохого на хорошее", а о переразделении интерфейсов и workflow.
Flatpak действительно использует OSTree "под капотом", но это аргумент не в сторону "заголовок шире", а в сторону "OSTree — не только про ОС". У OSTree есть ценность как формата/хранилища/модели распространения контента, и она не исчезает только потому, что для доставки ОС кому-то удобнее OCI. В статье, кстати, ровно это и делается: разделяется OSTree как технологию от rpm-ostree как инструмента и от философии immutable.
Пересборка / rebuild: берём чужую базу и делаем максимально похожую систему под своим брендом. Часто это делается ради совместимости: "чтобы софт/драйверы/инструменты вели себя как в RHEL-мире".
Дериватив: система из того же семейства (Debian/RHEL/…), но со своими репозиториями, политикой сборки, патчами, документацией, поддержкой. Может сохранять совместимость, но это уже не просто "перепаковали".
Форк: проект отделился и развивается самостоятельно со своим курсом. Он может оставаться совместимым или нет — важно, что развитие идёт независимо.
Клон: "похоже на оригинал почти во всём, а добавленной ценности мало". Это скорее оценка, чем технический диагноз.
Фраза "по мотивам" вообще честная: так можно описать половину Linux-мира.
Про "ничего ценного не увидел". Это нормальная реакция, если смотреть глазами домашнего пользователя или человека с опытом Arch/Ubuntu на десктопе: cloud-ОС для кластера действительно выглядит странно ("и что я с ней буду делать?").
Но ценность таких систем обычно видна в другой роли: когда ты DevOps/SRE и "живёшь в облаках", Kubernetes и GitOps. Там важны не "огромная пакетная база и ручная настройка на хосте", а минимальный хост, одинаковые ноды, меньше дрейфа, атомарные обновления/откаты (OSTree) и то, что приложения едут в контейнерах через CI/CD. Поэтому "не увидел ценности" часто означает "это не мой класс задач".
Фраза «мы не пересобираем чужие дистрибутивы» означает конкретную вещь: НАЙС.ОС не использует бинарные репозитории Fedora/RHEL, не берёт их SRPM как базу и не наследует их релизный цикл. Система собирается из upstream-исходников (ядро, glibc, GCC, systemd и т.д.) по собственной сборочной политике, с собственными spec-файлами, патчами и репозиториями.
CONFIG_BUILD_SALT — это не версия ядра и не маркер Fedora, а строка соли из .config, используемая для идентификаторов ABI. Реальная версия определяется uname -r и vermagic модулей — у нас это Linux 6.6.x.fc38 — артефакт bootstrap-конфига, а не Fedora kernel и не EOL-зависимость.
Инсталлятор. Но вы же писали что это 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). Исходные коды компонентов под свободными лицензиями предоставляются получателям бинарников в порядке, предусмотренном соответствующими лицензиями
OSTree-режим да, похоже на Atomic/uBlue (deployments + rollback). Fedora ↔ НАЙС.ОС rebasing — не целевой/неподдерживаемый сценарий: разные подписи/репы/база. Это абсолютно разные ОС. Нормальная практика — миграция через контейнеры/перенос данных или переключение режимов внутри НАЙС.ОС.
У вас в "разборе" есть несколько правильных наблюдений (да, у 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-вариант, а потом объявил "атомарности нет в принципе" — это как зайти в ресторан через аварийный выход и написать рецензию, что "входа не существует".
1. Про 1200 договоров и 800+ клиентов Эти цифры отражают историю проекта, но они связаны с ранними этапами, когда мы работали в партнёрстве с другой компанией. В рамках этого сотрудничества:
Мы занимались технической реализацией, включая разработку, внедрение и поддержку,
А партнёр выступал в роли юридического лица, оформлял договоры с клиентами и занимался коммерческой стороной.
Фактически, NiceOS тогда ещё не существовал как отдельный продукт — это была внутренняя разработка в составе совместных проектов. Поэтому все финансовые показатели, включая выручку, оставались на стороне нашего партнёра.
Цифры с потолка? Ну, это интересная гипотеза! 😄 Возможно, вам стоит подать резюме в качестве аудитора — кто знает, вдруг найдёте нестыковки.
2. Про выручку и самостоятельное развитие Когда мы решили выделить NiceOS в отдельное направление, процесс начался практически с нуля:
Использовали свое юридическое лицо, на которое перенесена интеллектуальная собственность.
Мы построили свою инфраструктуру: репозитории, систему сборки, документацию.
Работа с клиентами началась уже под собственным брендом, с новыми договорами и совершенно другим подходом к развитию.
В этой ситуации отсутствие значительной выручки в первые годы — закономерно. Проект теперь строится на собственной основе, и мы постепенно набираем обороты, не стремясь сразу перепрыгнуть на уровень крупных вендоров.
3. Про переход от партнёрства к самостоятельности Важно понимать, что в прошлом мы находились в «тени» партнёра, который был лицом наших совместных проектов. Это дало нам:
Опыт работы с масштабными задачами,
Глубокое понимание потребностей клиентов,
Базу, на которой мы смогли построить собственный продукт.
Теперь, выделившись в отдельное направление, мы полностью контролируем продукт NiceOS, его развитие и взаимодействие с клиентами.
Этот переходный период — часть пути, который был нужен, чтобы из партнёрского проекта вырастить самостоятельное решение. Да, у нас ещё нет миллионов в выручке, но мы уверенно движемся вперёд, строя продукт, который решает конкретные задачи.
Попасть в реестр отечественного ПО — это процесс, требующий времени и сил. Да, раньше у нас не было цели сертификации, потому что проект работал в ограниченных рамках. Но с изменением рынка мы поняли, что это важно для пользователей, и пошли по этому пути. Признание 2023–2024 годов — это результат, а не старт работы.
4. Про участие в инновационных кластерах и реестрах С момента выделения в отдельное направление наше юр лицо, развивающее NiceOS, стало частью экосистемы поддержки высокотехнологичных проектов:
Московский инновационный кластер: Мы являемся его участником, что открывает доступ к образовательным и финансовым инструментам, а также возможностям коллаборации с другими технологическими компаниями.
Реестр стартапов и высокотехнологичных компаний г. Москвы: Наше включение в этот реестр подтверждает статус компании как инновационного игрока, что особенно важно для клиентов и партнёров, выбирающих проекты с локальной спецификой.
Эти шаги подчёркивают, что NiceOS не просто нишевой продукт, а часть экосистемы технологического развития Москвы, с возможностями для дальнейшего масштабирования и улучшения.
Спасибо за ваш интерес и вопросы — они помогают лучше раскрыть нашу историю и показать, как проект прошёл путь от партнёрства до самостоятельности! 😊
Спасибо за ожидание, проект V — про Virtualization, Versatility и Value для пользователей, а не про громкие буквы в названии. Спасибо за вдохновение, будем держать вас в курсе! 😅
О, вы нашли наш таймлайн! Спасибо, что обратили на него внимание. 😄 Теперь давайте проясним пару моментов:
НАЙС ОС — не "новичок". Таймлайн показывает этапы развития проекта: каждое обновление связано с улучшениями и адаптацией под новые потребности. Например, в 2010 году основой стал Linux 2.6.32, который тогда был стандартом для стабильных серверов. Дальше мы шаг за шагом добавляли функции — от поддержки Btrfs до работы с контейнерами и виртуализацией через KVM.
Почему о нас мало слышали раньше? NiceOS начиналась как внутренняя разработка для ограниченных сценариев (например, внутренние серверы или специфические проекты). Мы не стремились в массы, поэтому могли быть незаметны. Но с появлением тренда на импортозамещение мы поняли, что опыт можно трансформировать в продукт, полезный для других. Так что, в некотором смысле, да — мы "вышли из тени".
"Прыжки в вагон" или планомерная работа? История, как видно из таймлайна, началась задолго до изменения мировой ситуации. Мы развивались, адаптировались и совершенствовались — как многие дистрибутивы Linux. Да, масштаб несравним с гигантами вроде RHEL или Ubuntu, но наша работа идёт годами, пусть и без широкой огласки.
"Смешно про прибыль". Признаемся честно, мы не стремимся стать монстрами индустрии с многомиллионными бюджетами. NiceOS остаётся нишевым решением, ориентированным на стабильность, безопасность и локальные требования. Смеяться можно, но давайте помнить, что многие open-source проекты тоже начинались с небольших идей и ограниченных ресурсов.
В итоге, мы рады, что даже скептические комментарии обращают внимание на детали! Таймлайн помогает показать, что наш проект развивается не "на хайпе", а через долгую работу. 😊
Но мы всё-таки решили, что лучше сосредоточиться на технологии, функционале и реальной пользе, чем на маркетинговых трюках с буквами. Хотя идея заманчиво «патриотичная», мы верим, что качественный продукт должен говорить сам за себя — даже если его имя остаётся простым и нейтральным, как NiceOS.
Тем не менее, спасибо за креативный совет! Если когда-нибудь будем запускать маркетинговую кампанию, может, добавим V... ну, хотя бы в шрифт логотипа. 😄
Ну и какое бы вы кодовое имя дали серверной ОС - S?
Честно говоря, представить заказчика для подобного проекта действительно может быть сложно, если смотреть с позиции массового рынка. Но, как и многие специализированные решения, наша работа ориентирована на конкретные задачи, где стандартные дистрибутивы либо избыточны, либо не соответствуют требованиям (например, ГОСТ, сертификация, или необходимость глубокого контроля за системой).
Такие заказчики — это, как правило:
организации, которые работают с критической инфраструктурой (и где импортозамещение не просто тренд, а требование);
компании, которым нужен полный контроль над системой и возможность кастомизации без зависимости от внешнего вендора;
учебные центры или внутренние подразделения, где хотят стандартизировать окружение для обучения или разработок.
Да, это нишевые сценарии, и массовое применение здесь никто не обещает. Но в этом и суть нашего подхода: делаем не "для всех", а под специфические задачи. 😊
Спасибо за критику — она мотивирует думать о чёткости формулировок и привносить больше конкретики! 🙌
Вы абсолютно правы: строго говоря, мы не создавали операционную систему с нуля, а взяли Linux-ядро и существующую экосистему, чтобы на её основе собрать дистрибутив, который решает конкретные задачи. Но здесь как раз и был наш вызов — превратить эту сборку в полноценное решение: от оптимизации состава пакетов до автоматизации сборки, тестов и развёртывания.
Мы постарались честно описать все этапы, включая выбор готовых компонентов и внесение изменений, чтобы показать, что подобные проекты — это не магия, а работа над тем, чтобы система была удобной, надёжной и отвечала специфическим требованиям.
Спасибо за плюс и за то, что оценили статью! 👍 Надеемся, она окажется полезной для тех, кто планирует подобные проекты.
В ISO-образе используется Syslinux в качестве загрузчика, а для самой системы — GRUB. Система действительно рассчитана на работу через BIOS, а не U-Boot. Архитектура процессора — x86-64, что подтверждается требованиями к оборудованию (2 ГБ ОЗУ и 20 ГБ дискового пространства). Для работы желательно использовать более современный процессор с поддержкой этой архитектуры.
Если рассматривать современный подход с RSC и React Cache, идея выделения GET-запроса в отдельный компонент полностью реализуема. Это не только работает, но и упрощает код, делая его более декларативным и предсказуемым. React Cache может работать с любыми асинхронными функциями, включая те, которые выполняют GET-запросы. Или что вы имели ввиду?
Information
Rating
Does not participate
Registered
Activity
Specialization
Архитектор программного обеспечения, Архитектор информационной безопасности
bootc тут не «обязательная глава», потому что это про другой слой задачи: bootc в первую очередь меняет транспорт и упаковку артефакта (OCI-образ/registry), а статья объясняет базовую механику OSTree как "git-подобной доставки дерева" и практику поднятия своего ostree-репо. Это как предъявлять к статье про HTTP претензию «не хватает QUIC»: полезно, но это отдельная тема, иначе текст расползётся в "всё обо всём" и сразу.
bootc в отличии от ostree-rpm занимает более жёсткую позицию: система должна апдейтиться из образа, а как только вы начинаете "мутировать" систему локально (layering и т.п.),
bootc upgradeскорее скажет «я не понимаю, как это обновлять». Это прямо проговорено в документации про взаимоотношения bootc и rpm-ostree.То есть "rpm-ostree полумера" = "rpm-ostree допускает локальную сборку состояния на клиенте", а bootc пытается это запретить как класс (или вынести в другие механизмы).
rpm-ostree по определению гибрид: образная модель + пакетный мир, включая client-side layering. Это фича для сценариев, где вам нужно чуть-чуть управляемой мутабельности (особенно на рабочих станциях или при постепенной миграции). Примечательно, что даже Fedora-доки сегодня описывают
bootc upgradeиrpm-ostree upgradeкак взаимозаменяемые операции "в общем случае" — то есть речь не о "замене плохого на хорошее", а о переразделении интерфейсов и workflow.Flatpak действительно использует OSTree "под капотом", но это аргумент не в сторону "заголовок шире", а в сторону "OSTree — не только про ОС". У OSTree есть ценность как формата/хранилища/модели распространения контента, и она не исчезает только потому, что для доставки ОС кому-то удобнее OCI. В статье, кстати, ровно это и делается: разделяется OSTree как технологию от rpm-ostree как инструмента и от философии immutable.
Что такое "клон", "дериватив", "форк".
Пересборка / rebuild: берём чужую базу и делаем максимально похожую систему под своим брендом. Часто это делается ради совместимости: "чтобы софт/драйверы/инструменты вели себя как в RHEL-мире".
Дериватив: система из того же семейства (Debian/RHEL/…), но со своими репозиториями, политикой сборки, патчами, документацией, поддержкой. Может сохранять совместимость, но это уже не просто "перепаковали".
Форк: проект отделился и развивается самостоятельно со своим курсом. Он может оставаться совместимым или нет — важно, что развитие идёт независимо.
Клон: "похоже на оригинал почти во всём, а добавленной ценности мало". Это скорее оценка, чем технический диагноз.
Фраза "по мотивам" вообще честная: так можно описать половину Linux-мира.
Про "ничего ценного не увидел".
Это нормальная реакция, если смотреть глазами домашнего пользователя или человека с опытом Arch/Ubuntu на десктопе: cloud-ОС для кластера действительно выглядит странно ("и что я с ней буду делать?").
Но ценность таких систем обычно видна в другой роли: когда ты DevOps/SRE и "живёшь в облаках", Kubernetes и GitOps. Там важны не "огромная пакетная база и ручная настройка на хосте", а минимальный хост, одинаковые ноды, меньше дрейфа, атомарные обновления/откаты (OSTree) и то, что приложения едут в контейнерах через CI/CD. Поэтому "не увидел ценности" часто означает "это не мой класс задач".
Фраза «мы не пересобираем чужие дистрибутивы» означает конкретную вещь:
НАЙС.ОС не использует бинарные репозитории Fedora/RHEL, не берёт их SRPM как базу и не наследует их релизный цикл. Система собирается из upstream-исходников (ядро, glibc, GCC, systemd и т.д.) по собственной сборочной политике, с собственными spec-файлами, патчами и репозиториями.
CONFIG_BUILD_SALT— это не версия ядра и не маркер Fedora, а строка соли из.config, используемая для идентификаторов ABI. Реальная версия определяетсяuname -rиvermagicмодулей — у нас это Linux 6.6.x.fc38— артефакт bootstrap-конфига, а не Fedora kernel и не EOL-зависимость.Инсталлятор. Но вы же писали что это 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). Исходные коды компонентов под свободными лицензиями предоставляются получателям бинарников в порядке, предусмотренном соответствующими лицензиями
OSTree-режим да, похоже на Atomic/uBlue (deployments + rollback). Fedora ↔ НАЙС.ОС rebasing — не целевой/неподдерживаемый сценарий: разные подписи/репы/база. Это абсолютно разные ОС. Нормальная практика — миграция через контейнеры/перенос данных или переключение режимов внутри НАЙС.ОС.
У вас в "разборе" есть несколько правильных наблюдений (да, у 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 не доказывает ни инновации, ни их отсутствие.
Логические ошибки или теханализ?
Кстати, установив ОС, вы согласились с лицензией.
1. Про 1200 договоров и 800+ клиентов
Эти цифры отражают историю проекта, но они связаны с ранними этапами, когда мы работали в партнёрстве с другой компанией. В рамках этого сотрудничества:
Мы занимались технической реализацией, включая разработку, внедрение и поддержку,
А партнёр выступал в роли юридического лица, оформлял договоры с клиентами и занимался коммерческой стороной.
Фактически, NiceOS тогда ещё не существовал как отдельный продукт — это была внутренняя разработка в составе совместных проектов. Поэтому все финансовые показатели, включая выручку, оставались на стороне нашего партнёра.
Цифры с потолка? Ну, это интересная гипотеза! 😄 Возможно, вам стоит подать резюме в качестве аудитора — кто знает, вдруг найдёте нестыковки.
2. Про выручку и самостоятельное развитие
Когда мы решили выделить NiceOS в отдельное направление, процесс начался практически с нуля:
Использовали свое юридическое лицо, на которое перенесена интеллектуальная собственность.
Мы построили свою инфраструктуру: репозитории, систему сборки, документацию.
Работа с клиентами началась уже под собственным брендом, с новыми договорами и совершенно другим подходом к развитию.
В этой ситуации отсутствие значительной выручки в первые годы — закономерно. Проект теперь строится на собственной основе, и мы постепенно набираем обороты, не стремясь сразу перепрыгнуть на уровень крупных вендоров.
3. Про переход от партнёрства к самостоятельности
Важно понимать, что в прошлом мы находились в «тени» партнёра, который был лицом наших совместных проектов. Это дало нам:
Опыт работы с масштабными задачами,
Глубокое понимание потребностей клиентов,
Базу, на которой мы смогли построить собственный продукт.
Теперь, выделившись в отдельное направление, мы полностью контролируем продукт NiceOS, его развитие и взаимодействие с клиентами.
Этот переходный период — часть пути, который был нужен, чтобы из партнёрского проекта вырастить самостоятельное решение. Да, у нас ещё нет миллионов в выручке, но мы уверенно движемся вперёд, строя продукт, который решает конкретные задачи.
Попасть в реестр отечественного ПО — это процесс, требующий времени и сил. Да, раньше у нас не было цели сертификации, потому что проект работал в ограниченных рамках. Но с изменением рынка мы поняли, что это важно для пользователей, и пошли по этому пути. Признание 2023–2024 годов — это результат, а не старт работы.
4. Про участие в инновационных кластерах и реестрах
С момента выделения в отдельное направление наше юр лицо, развивающее NiceOS, стало частью экосистемы поддержки высокотехнологичных проектов:
Московский инновационный кластер: Мы являемся его участником, что открывает доступ к образовательным и финансовым инструментам, а также возможностям коллаборации с другими технологическими компаниями.
Реестр стартапов и высокотехнологичных компаний г. Москвы: Наше включение в этот реестр подтверждает статус компании как инновационного игрока, что особенно важно для клиентов и партнёров, выбирающих проекты с локальной спецификой.
Эти шаги подчёркивают, что NiceOS не просто нишевой продукт, а часть экосистемы технологического развития Москвы, с возможностями для дальнейшего масштабирования и улучшения.
Спасибо за ваш интерес и вопросы — они помогают лучше раскрыть нашу историю и показать, как проект прошёл путь от партнёрства до самостоятельности! 😊
Спасибо за ожидание, проект V — про Virtualization, Versatility и Value для пользователей, а не про громкие буквы в названии. Спасибо за вдохновение, будем держать вас в курсе! 😅
О, вы нашли наш таймлайн! Спасибо, что обратили на него внимание. 😄 Теперь давайте проясним пару моментов:
НАЙС ОС — не "новичок".
Таймлайн показывает этапы развития проекта: каждое обновление связано с улучшениями и адаптацией под новые потребности. Например, в 2010 году основой стал Linux 2.6.32, который тогда был стандартом для стабильных серверов. Дальше мы шаг за шагом добавляли функции — от поддержки Btrfs до работы с контейнерами и виртуализацией через KVM.
Почему о нас мало слышали раньше?
NiceOS начиналась как внутренняя разработка для ограниченных сценариев (например, внутренние серверы или специфические проекты). Мы не стремились в массы, поэтому могли быть незаметны. Но с появлением тренда на импортозамещение мы поняли, что опыт можно трансформировать в продукт, полезный для других. Так что, в некотором смысле, да — мы "вышли из тени".
"Прыжки в вагон" или планомерная работа?
История, как видно из таймлайна, началась задолго до изменения мировой ситуации. Мы развивались, адаптировались и совершенствовались — как многие дистрибутивы Linux. Да, масштаб несравним с гигантами вроде RHEL или Ubuntu, но наша работа идёт годами, пусть и без широкой огласки.
"Смешно про прибыль".
Признаемся честно, мы не стремимся стать монстрами индустрии с многомиллионными бюджетами. NiceOS остаётся нишевым решением, ориентированным на стабильность, безопасность и локальные требования. Смеяться можно, но давайте помнить, что многие open-source проекты тоже начинались с небольших идей и ограниченных ресурсов.
В итоге, мы рады, что даже скептические комментарии обращают внимание на детали! Таймлайн помогает показать, что наш проект развивается не "на хайпе", а через долгую работу. 😊
Спасибо! : )
Спасибо за шутку, оценили! 😊
Но мы всё-таки решили, что лучше сосредоточиться на технологии, функционале и реальной пользе, чем на маркетинговых трюках с буквами. Хотя идея заманчиво «патриотичная», мы верим, что качественный продукт должен говорить сам за себя — даже если его имя остаётся простым и нейтральным, как NiceOS.
Тем не менее, спасибо за креативный совет! Если когда-нибудь будем запускать маркетинговую кампанию, может, добавим V... ну, хотя бы в шрифт логотипа. 😄
Ну и какое бы вы кодовое имя дали серверной ОС - S?
Спасибо за комментарий! 😄
Честно говоря, представить заказчика для подобного проекта действительно может быть сложно, если смотреть с позиции массового рынка. Но, как и многие специализированные решения, наша работа ориентирована на конкретные задачи, где стандартные дистрибутивы либо избыточны, либо не соответствуют требованиям (например, ГОСТ, сертификация, или необходимость глубокого контроля за системой).
Такие заказчики — это, как правило:
организации, которые работают с критической инфраструктурой (и где импортозамещение не просто тренд, а требование);
компании, которым нужен полный контроль над системой и возможность кастомизации без зависимости от внешнего вендора;
учебные центры или внутренние подразделения, где хотят стандартизировать окружение для обучения или разработок.
Да, это нишевые сценарии, и массовое применение здесь никто не обещает. Но в этом и суть нашего подхода: делаем не "для всех", а под специфические задачи. 😊
Спасибо за критику — она мотивирует думать о чёткости формулировок и привносить больше конкретики! 🙌
Спасибо за комментарий! 😊
Вы абсолютно правы: строго говоря, мы не создавали операционную систему с нуля, а взяли Linux-ядро и существующую экосистему, чтобы на её основе собрать дистрибутив, который решает конкретные задачи. Но здесь как раз и был наш вызов — превратить эту сборку в полноценное решение: от оптимизации состава пакетов до автоматизации сборки, тестов и развёртывания.
Мы постарались честно описать все этапы, включая выбор готовых компонентов и внесение изменений, чтобы показать, что подобные проекты — это не магия, а работа над тем, чтобы система была удобной, надёжной и отвечала специфическим требованиям.
Спасибо за плюс и за то, что оценили статью! 👍 Надеемся, она окажется полезной для тех, кто планирует подобные проекты.
В ISO-образе используется Syslinux в качестве загрузчика, а для самой системы — GRUB. Система действительно рассчитана на работу через BIOS, а не U-Boot. Архитектура процессора — x86-64, что подтверждается требованиями к оборудованию (2 ГБ ОЗУ и 20 ГБ дискового пространства). Для работы желательно использовать более современный процессор с поддержкой этой архитектуры.
Если рассматривать современный подход с RSC и React Cache, идея выделения GET-запроса в отдельный компонент полностью реализуема. Это не только работает, но и упрощает код, делая его более декларативным и предсказуемым. React Cache может работать с любыми асинхронными функциями, включая те, которые выполняют GET-запросы. Или что вы имели ввиду?