Релиз встраиваемой системы реального времени Embox v0.3.25

Как я понимаю разработчики в основном из России? А так же по ссылке не ясно - монолит это или микроядро?

Как я понимаю разработчики в основном из России?

Большинство разработчиков действительно из России (и стран ближнего зарубежья). Но поскольку проект открытый, то есть и из других стран.

А так же по ссылке не ясно - монолит это или микроядро?

Проект точно не монолит, хотя конечно как посмотреть. В результирующий образ включаются все в что требуется (и только то что требуется). Так что тут нужно говорить о конфигурируемом ядре (и всем образе). Причем характеристики ядра: микроядро, монолитное, и так далее, также задаются на этапе конфигурирования.

Портиторован

Что?

Портиторован

Извините, опечатка. Портирован конечно. Перенесен, аддаптирован, .. Статья на хабре по этому поводу

STM32F7diccovery

думаю оно либо dickovery, либо discovery.

Портиторован quake3
очередной релиз встраиваемой системы реального времени

божественно

STM32F7diccovery

извините, конечно STM32F7discovery

Портиторован quake3
очередной релиз встраиваемой системы реального времени

а Вы когда нибудь играли в quake в реальном времени :)

А если серьёзно, то дело в демонстрации работоспособности различных подсистем ОС, в том числе и графического стека OpenGL

realtime
quake3

Эээ, это когда скорость игры становится такой, что приходится задумываться в сторону RTOS, чтобы повысить свои шансы на победу?

Экзоядро.

Эээ, это когда скорость игры становится такой, что приходится задумываться в сторону RTOS, чтобы повысить свои шансы на победу?

:) Ну можно и так сказать.

А можно: «мы это сделали, потому что можем!»

Чем оно лучше BugurtOS?

Всегда поддерживаю, когда делают вот такие опенсорсные штуки, способные соревноваться с коммерческими костылями (которые кстати очень распространены в этой области).

А зачем OpenGL, если даже issue о поддержке PS/2 мыши висит с 2013 года открытым?

Антон, рад видеть Вас на ЛОРе. Теперь ваше детище будут сравнивать с BuguRTOS. :)

Вопрос: когда Embox ещё хостился на гуглокоде, я смутно помню, что были какие-то довольно информативные доки по примерам сборки, и даже вроде как на русском. Анонимус даже нашёл их в архиве веба. Есть ли надежда, что они будут восстановлены в более надёжном месте?

Антон, рад видеть Вас на ЛОРе

спасибо, взаимно!

теперь ваше детище будут сравнивать с BugurtOS.

это хорошо, мы только рады :)

Вопрос: когда EmBox ещё хостился на гуглокоде, я смутно помню, что были какие-то довольно информативные доки по примерам сборки, и даже вроде как на русском. Анонимус даже нашёл их в архиве веба. Есть ли надежда, что они будут восстановлены в более надёжном месте?

Работаем над новой версией документации (Репозиторий).

На самом деле, уже есть QuickStart в том числе на русском (там есть как собирать, модифицировать и запускать). И вот вот русское «руководство пользователя» выпустим.

Всегда поддерживаю, когда делают вот такие опенсорсные штуки, способные соревноваться с коммерческими костылями (которые кстати очень распространены в этой области).

спасибо, присоединяйтесь :)

А зачем OpenGL, если даже issue о поддержке PS/2 мыши висит с 2013 года открытым?

Не уверен, вроде была поддержка в каком то виде. Но в любом случае, поддержка ps/2 не является для проекта приоритетной, поскольку она не востребована в целевой нише проекта. Embox ориентирован на всякие встроенные системы. OpenGL уже в них используется, ну а quake это демонстрация возможностей и конечно ради фана. :)

Чем оно лучше BugurtOS?

Очень хорошо самому говорить чем мы лучше. Но..., на вскидку скажу:

• Embox поддерживает куда больше платформ, ведь поддерживает больше архитектур: ARM, x86, SPARC, Microblaze, MIPS, PPC, E2k
• Embox может запускать Linux приложения (собранные из исходников). Сомневаюсь (хотя может и ошибаюсь), что BugurtOS запускались Qt или тот же PJSIP.

Ну и если хотите, Embox просто другой. Все таки чем больше проектов и различных идей, тем лучше.

Нужно. Спасибо за новость.

Спасибо!

сам не пользуюсь, но по описанию — нужно!

Вроде как экзоядро.

Количеством доступных создателям ресурсов.

всякие встроенные системы. OpenGL уже в них используется

GPU поддерживающие OpenGL ES2 и выше не используют с микроконтроллерами - они стоят в разы дороже самого процессорного ядра, а на полноценных процессорах c MMU нет смысла использовать ОС для микроконтроллеров - это просто выбросить деньги на ветер так как большая часть процессора не использцется.

GPU поддерживающие OpenGL ES2 и выше не используют с микроконтроллерами

Согласен. Но Embox не ОС для микроконтроллеров, точнее не только для микроконтроллеров.

Одна из наших идей, это чтобы можно было использовать одну систему и для больших и для маленьких частей. Embox пытаемся объединить преимущества как Linux так и мелких ОС для микроконтроллеров. Вот тут немного подробнее

ну а например GPU используется в картографии, а зачем карту рисовать на Embox вот тут можно почитать.

А о каких ресурсах речь? Виртуальная память, объем флеш-памяти?

Или все таки о деньгах? Но это не характеристика проекта. Не очень понимаю с чего Вы это взяли. Нет, у Embox, действительно есть коммерческие проекты! Но ведь мы сами их получили, никто нам не спонсировал проект.

Уверен, что у BuguRTOS есть свои преимущества! судя по всему он ориентирован на микроконтроллеры, а специализация всегда позволяет получить выигрыш в определеной сфере.

Спасибо!

Но Embox не ОС для микроконтроллеров, точнее не только для микроконтроллеров

она как раз для микроконтроллеров потому что не использует MMU/виртуальную память

Embox пытаемся объединить преимущества как Linux так и мелких ОС для микроконтроллеров

у VxWorks насколько помню был хотя бы опциональный модуль для поддержки виртуальной памяти

зачем карту рисовать на Embox вот тут можно почитать

там много буков и спорных утверждений, например

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

статическая сборка всего с легкостью делается на Linux, корневая линкуется с ядром в виде initramfs, отключается поддержка подгружаемых модулей, шелл вообще не включается - никаких прав рута вы там не получите.

а Вы когда нибудь играли в quake в реальном времени

Нет, только в пошаговом варианте на celeron 266

это когда скорость игры становится такой, что приходится задумываться в сторону RTOS, чтобы повысить свои шансы на победу?

Мьсе не играл с корейцами? :)

А о каких ресурсах речь?

О человеческих.

Причем характеристики ядра: микроядро, монолитное, и так далее, также задаются на этапе конфигурирования.

что за бред в этом треде???

она как раз для микроконтроллеров потому что не использует MMU/виртуальную память

у VxWorks насколько помню был хотя бы опциональный модуль для поддержки виртуальной памяти

не уверен хотя и разработчик, но к чему в Embox вот эти куски? :)

• vmem
• mmap
• arm/mmu

там много буков и спорных утверждений, например

статическая сборка всего с легкостью делается на Linux, корневая линкуется с ядром в виде initramfs, отключается поддержка подгружаемых модулей, шелл вообще не включается - никаких прав рута вы там не получите.

действительно много букв :) Предполагается, что система то у вас нормальная, то есть есть админские права, есть доступ к shell...

Коротко, если например нельзя использовать Linux а нужно рисовать карты, ну скажем так военный планшет, то нужно же как то выходить из ситуации.

Согласен. Но Embox не ОС для микроконтроллеров, точнее не только для микроконтроллеров.

вы либо трусы либо крестик ....

насколько я понял с виртуальной памятью у вас все плохо, и embox рассчитан больше на девайсы без mmu, а я не могу что то найти девайсы с opengl и без mmu ...

а ставить embox на девайс с полноценным mmu смысла нет.

Почему на военном планшете нельзя использовать свой форк линукса вместо вашей оси? Или какой-нибудь астра линукс?

Рационализацией попахивает...

О человеческих.

Извините, не правильно Вас понял.

Мы действительно привлекли много студентов. Правда это было скорее обучение. Но в последствии, часть, действительно контрибъютила (и продолжает) в проект.

Почему на военном планшете нельзя использовать свой форк линукса вместо вашей оси?

Если можно, то следует использовать! Речь о том когда нельзя. Например, должна быть сертификация или еще по какой то причине.

Или какой-нибудь астра линукс?

астра-линукс, насколько я знаю, не поддерживает arm.

Если можно, то следует использовать! Речь о том когда нельзя. Например, должна быть сертификация или еще по какой то причине.

А чем отличается сертификация форка линукса от сертификации вашей оси?

что за бред в этом треде???

не вижу бреда, но постраюсь объяснить, что имел в виду.

• Монолитное ядро - подразумевает, что все делается в одном ядерном процессе или потоке.
• Микроядро - подразумевает запуск серверов для различных служб ядра, в виде отдельных потоков или процессов.

В Embox можно задавать множество параметров, в том числе такие как стратегию планирования или выделения памяти. Собственно это и означает что характеристики ядра задаются на этапе конфигурирования.

насколько я понял с виртуальной памятью у вас все плохо

отнюдь, Вы неправильно поняли.

а ставить embox на девайс с полноценным mmu смысла нет.

Позвольте и в этом с Вами не согласиться. :)

Тут дело не в полноценном MMU, а в выполняемой задаче.

вы либо трусы либо крестик ....

не поверите, но пытаемся совместить. :)

не уверен хотя и разработчик, но к чему в Embox вот эти куски?
* @date 28.02.2018

смотрел презентацию 2014 года - значит уже не актуально, что-то есть для работы с MMU

Предполагается, что система то у вас нормальная, то есть есть админские права, есть доступ к shell...

я не сосем понял ваши намеки - я говорил о том что Linux можно с лёгкостью обрезать по функциональности до mbox причем просто натыкать галок в конфигурационном меню, а вот чтобы mbox к Linux хоть немного приблизиться - это годы работы даже с учетом того что код берется из Linuх почти без изменений. И тут вопрос - зачем переписывать Linux если он и так уже есть :)

если например нельзя использовать Linux а нужно рисовать карты

козырный аргумент :)

А чем отличается сертификация форка линукса от сертификации вашей оси?

Объемом исходников!

Embox был изначально под это заточен, и туда включаются только используемые модули. А ядро Linux это все таки ядро Linux, как ты его не конфигурируй. Безусловно, огромное количество кода можно выключить, но базовый функционал останется. Ведь там должны выполняться все приложения!

не вижу бреда, но постраюсь объяснить, что имел в виду.

бред, монолитное ядро это значит все реализовано в ядре, следовательно работает в одном АДРЕСНОМ ПРОСТРАНСТВЕ, то есть взаимодействие между подсистемами более менее тривиальное

микроядерная ОС это когда подсистемы, драйвера и тд работают вне ядра, то есть в ОТДЕЛЬНЫХ АДРЕСНЫХ ПРОСТРАНСТВАХ, следовательно там нетривиально с IPC между ними, и архитектура подсистем вообще как из другой вселенной может быть.

ну и, возвращаясь к вопросу - что за бред в этом треде?

У вас же ведь ещё можно получить сконфигурированный код в виде исходников, до сборки, да? И его предъявить на сертификацию. Да и протестировать его тупо проще.

Насколько я понимаю, в линуксе тот же make menuconfig распространяется только на процедуру сборки.

отнюдь, Вы неправильно поняли.

из того что я бегло посмотрел - в том числе сюда - https://github.com/embox/embox/blob/master/src/mem/vmem/mmap.c - у вас с этим все плохо.

а ставить embox на девайс с полноценным mmu смысла нет.

Позвольте и в этом с Вами не согласиться. :)

дело ваше конечно, но ставить application-level OS на полноценный CPU как минимум бредово.

А чем отличается сертификация форка линукса от сертификации вашей оси?

полностью сертифицировать форк лялеха невозможно, что то мелкое по объему уже совсем другой дело.

ну и, возвращаясь к вопросу - что за бред в этом треде?

а теперь представьте. Что у вас есть код драйвера, но вы его можете поместить как в отдельный процес, так и в единый процес ядра. И сделать вы это можете просто указав опции. При указании что это отдельный сервер, будет сгенерен код обертки, прокинуты вызовы драйвера и запущен отдельный процесс, ну а для помещения в ядро драйверу ничего не нужно.

Но согласен, фантасмагория какая то:)

Да, спасибо, совершенно верно! По описанию конфигурации и описанию модулей (с зависимостями) у нас генериться код который и предоставляется на сертификацию.

а теперь представьте. Что у вас есть код драйвера, но вы его можете поместить как в отдельный процес, так и в единый процес ядра. И сделать вы это можете просто указав опции. При указании что это отдельный сервер, будет сгенерен код обертки, прокинуты вызовы драйвера и запущен отдельный процесс, ну а для помещения в ядро драйверу ничего не нужно.

а теперь удивись - в коде этого нетууу.

Но согласен, фантасмагория какая то:)

ага, именно. особенно с учетом того что подсистема в монолите != подсистема отдельным сервисом, и архитектура совсем другая. например - как ты выдерешь vfs из монолита? как ресурсы будешь хранить? выдернул vfs, а как некоторые виды POSIX IPC типа именнованных pipe будешь совмещать? или у вас серьезный трекинг зависимостей ?

ваши ответы говорят о том что вы не компетенты в этой теме.

из того что я бегло посмотрел - в том числе сюда - https://github.com/embox/embox/blob/master/src/mem/vmem/mmap.c - у вас с этим все плохо.

ну все таки не совсем, но это наш не основной вариант. Конечно, если нужна уж полностью функциональная система мы рекомендуем использовать Linux. Естественно переписывать или копировать Linux это бред. Но если требуется система где описано что и как должно выполняться, то с этим можно работать.

дело ваше конечно, но ставить application-level OS на полноценный CPU как минимум бредово.

В том то и дело, что идея не наша, есть потребность в таких устройствах. То есть приходят люди, говорят есть вот набор ПО работающий под Линукс, но мы не можем использовать его в конечном устройстве, например объем кода слишком большой для сертификации. или если сертификация не нравится, то количество ресурсов. Ну полноценный CPU c 64 МБ стоит дорого, а в небольшой Linux не влезает

На сайте астры написано, что Astra Linux SE есть для x86, arm, mips, PowerPC, zSeries, и e2k.

Ну полноценный CPU c 64 МБ стоит дорого, а в небольшой Linux не влезает

одна Qt сколько весит - это уже перекрывает в разы размер ядра да и про GPU можно не вспоминать с такой памятью

ну все таки не совсем, но это наш не основной вариант. Конечно, если нужна уж полностью функциональная система мы рекомендуем использовать Linux.

нет спасибо, лучше уж QNX.

Естественно переписывать или копировать Linux это бред.

предоставлять подобный ф-л не бред, да и лялех это уже помойка, возможно что то и стоит переделывать уже сейчас.

о есть приходят люди, говорят есть вот набор ПО работающий под Линукс, но мы не можем использовать его в конечном устройстве, например объем кода слишком большой для сертификации. или если сертификация не нравится,

сертифицировать linux не возможно, я про настоящую сертификацию если что. тем не менее это не повод к «о, мы не можем пользовать тут OS, поэтому возьмем либы, и попробуем туда прикрутить все что нам надо».

Embox для микроконтроллеров - да, все понятно, своя ниша. но зачем он на нормальном CPU не ясно, в этом смысла нет, какие б там люди не приходили, а если только микроконтроллеры - то зачем там какой либо opengl.