Пересборка / 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-запросы. Или что вы имели ввиду?
Информация
В рейтинге
3 528-й
Зарегистрирован
Активность
Специализация
Архитектор программного обеспечения, Архитектор информационной безопасности
Что такое "клон", "дериватив", "форк".
Пересборка / 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-запросы. Или что вы имели ввиду?