RTEMS, eCos, ..., применяют ли вообще на постсоветском пространстве?! Опции

[Doka]

RTEMS - http://ru.wikipedia.org/wiki/RTEMS (оф. сайт http://www.rtems.com/ )
eCos - http://en.wikipedia.org/wiki/ECos (оф. сайт http://ecos.sourceware.org/ )

обе открытые и свободные, под гуманной лицензией (у RTEMS - позволяет использовать в собственных разработках, не открывая код).

Но полистав этот подраздел форума, встретил только единичные темы по ним. В чём причина такой нераспространённости??

ведь, как я понимаю, например RTEMS, нет необходимости в MMU, а по отказоучтойчивости она (грубо) сравнима с проприетарщиной в лице QNX, VxWorks, MontaVista (грубо). Всёж была выбрана для марсохода, как-никак..

eCos - тоже активно развивается, поддержка актуальных архитектур (Cortex), периодические релизы..



Хотелось бы понять каковы ниши этих систем и какие из ОСРВ являются их "одноклассниками"
(приведенное сравнение выше - грубо, ибо неизвестны мне аппетиты этих систем до ресурсов).

[yes]

RTEMS - http://ru.wikipedia.org/wiki/RTEMS (оф. сайт http://www.rtems.com/ )
eCos - http://en.wikipedia.org/wiki/ECos (оф. сайт http://ecos.sourceware.org/ )

обе открытые и свободные, под гуманной лицензией (у RTEMS - позволяет использовать в собственных разработках, не открывая код).

Но полистав этот подраздел форума, встретил только единичные темы по ним. В чём причина такой нераспространённости??

ведь, как я понимаю, например RTEMS, нет необходимости в MMU, а по отказоучтойчивости она (грубо) сравнима с проприетарщиной в лице QNX, VxWorks, MontaVista (грубо). Всёж была выбрана для марсохода, как-никак..

eCos - тоже активно развивается, поддержка актуальных архитектур (Cortex), периодические релизы..



Хотелось бы понять каковы ниши этих систем и какие из ОСРВ являются их "одноклассниками"
(приведенное сравнение выше - грубо, ибо неизвестны мне аппетиты этих систем до ресурсов).

мы используем и то и другое, процы ARM, PPC, SPARC
большинство процев кастомизированные (то есть АЗИКи), поэтому нужен полный контроль над сорцем
знаю, что конкуренты в этой нише используют те же ОСы
eCos тоже не требует открывать код (она по LGPL вроде бы была), я не лойер, но мериканьски лойеры проверяли
http://javad.com/jgnss/

по поводу надежности - приборы работали в антарктиде автономно - резет некому было нажимать, ну и в рекламных целях их то в формулу-1 то еще куда-нибудь засовывают (журнал GPSWorld можно посмотреть)

то что AlexandrY думает про это - сильно отличается от реальности

с RTEMS лично я дело имел мало (вобщем простая С-шная ось, проект давно заморожен и используется нами как legacy support), но сравнивать что-то типа uCOS с eCos - это просто смешно, совершенно разные весовые категории (я не из теоретических соображений, а из опыта использования обоих)
для каких-то дуделок и елочных гирлянд uCOS нормально (затраты на освоение екоса избыточны), в eCOS например, есть поддержка SMP

я бы поставил eCos посредине между переключалкой и uClinux

[Doka]

мы используем и то и другое, процы ARM, PPC, SPARC
большинство процев кастомизированные (то есть АЗИКи), поэтому нужен полный контроль над сорцем
знаю, что конкуренты в этой нише используют те же ОСы
eCos тоже не требует открывать код (она по LGPL вроде бы была), я не лойер, но мериканьски лойеры проверяли

по поводу надежности - приборы работали в антарктиде автономно - резет некому было нажимать, ну и в рекламных целях их то в формулу-1 то еще куда-нибудь засовывают (журнал GPSWorld можно посмотреть)

так в том-то и дело, что операционки достойные, релизы поддерживаются в актуальном состоянии, с точки зрения лицензионной чистоты для коммерческих приложений тоже всё кузяво,
а чтобы кто-то помимо Джавада и Топкона их использовал я не слышал - вот и пытаюсь понять для себя - в чём парадокс?!

[yes]

так в том-то и дело, что операционки достойные, релизы поддерживаются в актуальном состоянии, с точки зрения лицензионной чистоты для коммерческих приложений тоже всё кузяво,
а чтобы кто-то помимо Джавада и Топкона их использовал я не слышал - вот и пытаюсь понять для себя - в чём парадокс?!

посмотрите список контрибуторов - если не из универа, то наверняка используется в приборах фирмы

также аштек (проф. магелан) программисты то оттуда, и вполне возможно тримбл - это корень зла

причина использования в аштеке (имхо) - нужна была операционка открытая, без всяких фии. а тогда (~20 лет назад) ничего кроме RTEMS и не было
а потом (~10 лет назад) проект разросся, держать его в С стало очень тяжело, поэтому перешли на С++ операционку (тоже альтернатив eCos никаких не было)

для людей свято верящих, что бездельники из университетов не в состоянии написать ничего дельного, есть eCosCentric - то же, но за дэнги

Зато бескомпромисная по функциональности - можно не прогибаться (и не работать с постоянной оглядкой) под возможности минималистичных (это не ругательство - ну цель такую авторы ставили и решили) щедулеров типа scmRTOS, uCOS.

я вообще-то не программист, мой инструмЕнт Verilog HDL. но так как делаю микропроцессорные системы, то первые коды (порты) приходится писать мне, но дальше минимальных конфигураций не иду.

смысл (и преимущество) eCos перед scmRTOS (я кстати ее уже пользовал с большим удовольствием) это возможность набрать юзерей, которые пишут юзерские задачи и их легко добавлять их в проект. то есть не нужно считать - а хватило ли битиков в слове треда на все задачки, а нужно ли юзерьский printf заменить на UART_out_data и т.п.

то есть здесь получаются преимущества Linux-а (типа отладки на ПК, легкости сборки) для маленькой cистемы - память сотни к, а не мегабайты

собственно поэтому я бы и поставил eCos посредине между Linux и scmRTOS

мне например гораздо менее понятно использование uClinux, а не eCos для систем без MMU. за минимальную возможность прохалявить (по моему опыту собрать задачку для ecos совсем немного сложнее, чем для uClinux) пользователи uClinux готовы тратить мегабайты и сотни мипсов непонятно за что.