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
Software Architect, Information security architect
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-запросы. Или что вы имели ввиду?