Embox v0.5.10

,hjrth

Исправлено.

bugurtos хватит всем

Прикольно, конечно, но я о такой первый раз слышу, нужно почитать что это.

Perl на эмбеддеде это просто шикарно.

Интересно, насколько он там доступен? Неужели работает даже CPAN? Или это просто возможность запустить какое-то небольшое подмножество команд и модулей?

И какие еще поддерживаются ЯП непосредственно на самом девайсе с этой осью? Lua? JavaScript? Bash?

С другой стороны, вероятно, на обычном большом Linux компе можно использовать часть обычных компиляторов типа Free Pascal, у которых есть соответствующие аппаратные targets?

Кстати, кто какие знает транспайлеры из других ЯП в Perl?

Типа пишешь прогу на Basic, а она компилируется в Perl, такое бывает?

https://perthon.sourceforge.net/

Типа пишешь прогу на Basic, а она компилируется в Perl, такое бывает?

О! Месье знает толк в извращениях!

https://docstore.mik.ua/orelly/perl/prog/ch06_04.htm

осталось откопать unununium и перекомпилить его в перл

А ты местных новостей особо не читатель, я смотрю.

third-party: add picocom

Я правильно понимаю, picocom прям внутри прошивки будет?

Но зачем?

Обратно я могу себе представить, пишешь какую-нибудь лаконичную строкодробилку на Перле, а она компилируется в сишечку…

Спасибо, не заметил! :(

Интересно, насколько он там доступен? Неужели работает даже CPAN? Или это просто возможность запустить какое-то небольшое подмножество команд и модулей?

Да, это все таки не полноценный Perl хотя и вполне работоспособный. Сделано это через App-Staticperl. Сделано, чтобы затащить полноценный unixbyte. Мы все больше смотрим в сторону утилит для тестирования и сравнения, хотя и Embox это не про универсальность.

И какие еще поддерживаются ЯП непосредственно на самом девайсе с этой осью? Lua? JavaScript? Bash?

Lua, JavaScript (duktape), Ruby (mruby), TCL, Lisp (chibi-scheme)

Bash (dash) затаскивали, но он жирный для наших целей. Думаем сделать какой нибудь легкий аналог. Сейчас в командном интерпретаторе нет даже циклов и условных выражений

Я правильно понимаю, picocom прям внутри прошивки будет?

Это из Pull Reqeust а? Он давно висит на самом деле, но в последнее время думаем доделать, действительно появился ряд задач, когда удобно отлаживаться на плате через терминал, а uart ы у нас как /dev/ttyS и так видны

Bash (dash) затаскивали, но он жирный для наших целей. Думаем сделать какой нибудь легкий аналог. Сейчас в командном интерпретаторе нет даже циклов и условных выражений

Обычно все первым делом busybox затаскивают

Порой бывает удобно, все таки иметь возможность всегда хорошо. И да, мы не прямо Perl используем а App-Staticperl

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

но он оказался не достаточно конфигурируемым для наших целей

Вот это поворот, я думал там всё мыслимое и немыслимое можно настроить через конфигуратор

можно сказать, что мы развиваем свой набор core utils

А не смотрели в сторону toybox?

там всё мыслимое и немыслимое можно настроить через конфигуратор

Можно, отличный проект! Но у нас, как говорится, своя атмосфера:) Коротко мы все вместе конфигурируем в статике, и получаем запуск на 32кб флеш и 4 кб ОЗУ https://habr.com/ru/companies/embox/articles/537408/

А не смотрели в сторону toybox?

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

https://habr.com/ru/companies/embox/articles/537408/

В конце статьи говорится:

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

А в начале:

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

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

В общем то статья не отвечает на поставленные в её начале вопросы, а показывает лишь искусственный, малополезный пример использования.

Спасибо за замечание. Постараемся писать более корректно. Но я с Вами не согласен. Да мы честно пишем, что в данной статье рассмотрен пример использования, который не расскрывает преимущества Embox, а только показывает довольно крайний случай. Но есть куча других статей, где рассматриваются примеры работ на более мощных микроконтроллерах, и да на них не встает Linux, или это будет из пушки по воробьям причем с существенными ограничениями. Пример, VoIP телефон https://habr.com/ru/companies/embox/articles/538416/, который уместили во внутреннюю память микроконтроллер. Ну и конечно, стоит посмотреть другие статьи из нашего блога:) Например, https://habr.com/ru/companies/embox/articles/440390/

Спасибо!

только показывает довольно крайний случай.

Ну так а в начале статьи ставится вопрос «Но возникает естественный вопрос насколько Embox позволяет экономить ресурсы по сравнению с тем же Linux?». Очевидно, что этот вопрос предполагает сравнивать на более-менее рабочих сценариях. Ведь нельзя говорить «я запустил хэллоу ворлд, а линукс тут вообще не заработал, значит, моя ОС экономит ресурсы относительно линукса». Совсем не значит, помимо данного конкретного хэллоу ворлда, который на линуксе никто и не запускает.

Пример, VoIP телефон

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

Ведь вряд ли такие телефоны кто-то будет реально выпускать.

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

Или вот еще пример https://habr.com/ru/companies/embox/articles/547582/ естественно, это демка, промышленное решение другое.

Очевидно, что этот вопрос предполагает сравнивать на более-менее рабочих сценариях.

Повторюсь, наверное не совсем точно выразились, мы не хотели сравнивать с Линукс, понятно что по ресурсам мы не сопостовимы, скорее хотелось показать, а вот есть интерфейс POSIX какой то шел, и многие считают что нужно взять большую плату, но есть задачи которые требуют легких платформ (низкопотребляющих) и тогда берут мелкую ОС, мы же говорим о том, что в большинстве случаев, даже микроконтроллера сейчас достаточно чтобы удобно разрабатывать. Кросс-платформенно например https://habr.com/ru/companies/embox/articles/573244/

Но зачем?

Я не любитель синтаксиса Perl. Использую его только для однострочников вместо sed и т.п.

Преимущества Perl с моей точки зрения:

Perl доступен на очень многих системах (в т.ч. BSD, Illumos и т.п.) и работает достаточно предсказуемо и повторяемо, это некая хорошо отлаженная окаменелость, где нет неожиданных сюрпризов и неожиданностей. Очень богатый либами CPAN. Их можно сначала заюзать из Python (не на Embox ессно), а потом через Python даже из VB.NET.

У меня сложилось впечатление, что Perl менее подконтролен корпорациям «нового прекрасного мира» в отличии, например, от Python, и поэтому, несмотря на извратный синтаксис Perl (отчасти IMHO больше похожий на Bash и т.п.), от перловки намного менее вероятно получить какую-нибудь какаху в духе новостей «нового прекрасного мира».

Именно поэтому теперь он рекламируется массам вкатышей как «legacy диназаврус», дабы не портить настроение кое-кому.

IMHO наибольшую ценность в Perl представляет коллекция работ в CPAN и относительно высокий уровень программистов, кто писал и пишет на Perl, особенно по сравнению с большой частью питонистов.

Обратно я могу себе представить, пишешь какую-нибудь лаконичную строкодробилку на Перле, а она компилируется в сишечку…

Настоящий native компилятор Perl:

http://www.autoparallel.com/products/compiler.html

https://github.com/wbraswell/rperl

несмотря на извратный синтаксис Perl (отчасти IMHO больше похожий на Bash и т.п.)

Человек, сравнивающий Perl с Bash, не знает толком ни Perl, ни Bash. Это всё равно что с PHP сравнивать, сходство чисто поверхностное в отдельных моментах.

Лично мне синтаксис Bash и Perl кажется ущербным.

Программирование на Bash я знаю достаточно хорошо, на Perl только немного, например могу делать несложные плагины для CMS http://www.webgui.org/

Преимущество скрипта на Bash - это тесная интеграция с shell.

IMHO в качестве ЯП Bash так же ужасен как и Perl :)

Мне нравится синтаксис VB.NET и C#, а не вот эти все синтаксические окаменелости :)

Но с другой стороны в Perl нравится его большая доступность на разных OS, окаменелая хорошая повторяемость и предсказуемость его работы на них. Свободный community, богатый либами CPAN.

Очевидно, что этот вопрос предполагает сравнивать на более-менее рабочих сценариях. Ведь нельзя говорить «я запустил хэллоу ворлд, а линукс тут вообще не заработал, значит, моя ОС экономит ресурсы относительно линукса». Совсем не значит, помимо данного конкретного хэллоу ворлда, который на линуксе никто и не запускает.

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

IMHO в качестве ЯП Bash так же ужасен как и Perl

По-моему, они отличаются как земля и небо

Я про стилистику синтаксиса Bash и Perl.

Насколько она, с моей точки зрения, ужасна по сравнению с VB.NET и C#.

Пример:

The shell's test uses =, !=, < etc for string comparisons and -eq, -ne, -lt etc for numeric comparisons. 

This is the reverse of Perl, which uses eq , ne , lt for string comparisons, and == , !=, < etc for numeric comparisons.

Получается, формально ты прав, семантика Bash и Perl где-то полностью противоположна.

Но, с моей точки зрения, в нормальных ЯП типа VB.NET и C# вообще нет всех этих ужасных -eq, -ne, -lt, etc. :)

Там операторы и операции сравнения одинаковые для любых типов переменных.

Там операторы и операции сравнения одинаковые для любых типов переменных.

Это более-менее приемлемо только в языках с явной типизацией. Если типизация динамическая или повсеместный вывод типов (как в OCaml), то операторы должны быть разными.

Это не какая-то стилистическая финтифлюшка, это реально помогает.

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

Можно по-подробнее про безопасность? Мне KasperskyOS попадался. Это тоже эмбеддед ос, ну а на безопасность она заточена очень сильно. Позволяет политики создавать просто мега-навороченные, вплоть до «в такой-то фазе луны мы эту операцию не позволяем делать чаще, чем раз в секунду». Вроде как, предоставляемые ими политики математически верифицируемы на предмет соответствия ТЗ.

Кто нить может с каспером сравнить грамотно?

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

Кстати, тут же, вроде, и многозадачность кооперативная, и аппаратного MMU нет. Я бы поостерёгся про безопасность говорить. :) Но мож ошибаюсь.

Выпускают.

Так а… это ж самое интересное. :) Можно ли ссылку на аппарат? Всё таки как-то меня гложат сомнения, что производители телефонов стремятся взять контроллер за 2 копейки с 512К оперативки. По-моему, современные смартфоны не в эту сторону движутся.

(низкопотребляющих) и тогда берут мелкую ОС

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

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

У Embox другой подход. Но он тоже «Secure By Design». Коротко, если у вас статически собранный код, только необходимые вызовы, то и векторов атак у вас будет куда меньше. Причем, поскольку ядро (и все остальное) у вас перестраивается каждый раз, даже адреса стандартных библиотек разные, у вас нет возможности запускать стороннее ПО, для этого нужно как то узнать изначальную конфигурацию

Следовательно если происходит утечка пароля и злоумышленик получил рутовый доступ, то в Embox он может сделать только то что уже заложенно в систему, а в Линукс он так или иначе, может сделать больше.

По-моему, современные смартфоны не в эту сторону движутся.

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

Ну опять же, ведь низкое энергопотребление нынче обеспечивается агрессивным пауер менеджментом,

Вы говорите про сегмент мобильных систем где прекрасно живет Линукс. ARM Cortex-A в разы больше потребляет чем ARM Cortex-M! Прибавьте внешнюю память и так далее. Поймите, Embox не пытается занять место Линукс. Если интересно, прочитайте статью Про место Embox в мире embedded, я уже давал ссылку выше.

В относительно мощных десктопных процессорах есть даже аппаратное ускорение виртуализации, а толку, по крайне мере на x86. Дырявое :(

Это более-менее приемлемо только в языках с явной типизацией. Если типизация динамическая

В VB.NET и даже VBA возможна динамическая типизация? И что там про операции сравнения?

Кто нить может с каспером сравнить грамотно?

Close source неведомое нечто, еще якобы и «математически верифицируемы»? Внимание, верифицируемые КЕМ?

Почему сорцы микроядра seL4 открыты? Почему открыты сорцы OpenBSD? Наверно, они дураки, ведь надо обеспечивать security through obscurity как в Windows, KasperskyOS, Astra Linux и т.п.?

У Embox другой подход. Но он тоже «Secure By Design». Коротко, если у вас статически собранный код, только необходимые вызовы, то и векторов атак у вас будет куда меньше.

Это не другой подход: в каспере, вроде, тоже статические конфигурации. И плюс ещё политики.

даже адреса стандартных библиотек разные, у вас нет возможности запускать стороннее ПО

Ну вы ж понимаете, что это не панацея. Стороннее не запустить, как и у каспера. Но зато, если сломать имеющееся (а какое ПО не содержит уязвимости?), то как раз тут и вступают в дело политики безопасности. Которых у вас, как я понял, нет.

Следовательно если происходит утечка пароля и злоумышленик получил рутовый доступ, то в Embox он может сделать только то что уже заложенно в систему

Хакерам, обычно, и этого хватает. :) Как я понимаю, хакер, в вашем случае, получает полный доступ к памяти ядра (ММУ-то нет), и, соответственно, ко всей аппаратуре и к любым данным пользователя, которые есть на девайсе.

Я не к тому, что это всё плохо, или хорошо. Просто надо вещи своими именами называть, и мне кажется, что о секьюрности, в вашем случае, говорить рановато. Но могу ошибаться.

ARM Cortex-A в разы больше потребляет чем ARM Cortex-M!

Мне кажется, не совсем корректно так сравнивать. Если нет нормального пауерменеджмента, то да. А если есть?

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

Ок, ну я по тому и просил ссылку на изделия, чтобы понять, о чём конкретно тут речь. :)

Это не другой подход: в каспере, вроде, тоже статические конфигурации. И плюс ещё политики.

Главные отличия IMHO при прочих равных условиях:

KasperskyOS - на базе микроядра, что хорошо для безопасности.

KasperskyOS - проприетарный, что плохо для безопасности.

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

Я перл люблю всем сердцем и даже чуть что пишу на нём (на перле, не на сердце), но мне всегда казалось, что он привносит такой оверхед, что с rtos и всякими встраиваемыми сочетаться не может. Опять же, а что с ним там делать? Им хорошо текстовую и смешанную информацию обрабатывать и агрегировать для представления в удобочитаемом/машиннообрабатываемом виде. А тут получается, скажем, контроллер вагона будет выдавать сводку по данным?

Close source неведомое нечто

Ну… обещают открыть, когда созреет. Пока он и не продаётся особо, а лишь для ознакомления предоставляется всем желающим. Вот если реально будут пытаться массово продавать, и не откроют - тогда я с вами соглашусь. А пока - обещания радужные.

Внимание, верифицируемые КЕМ?

Пока, как я понимаю, только ими самими. Но они и не бьют себя пяткой в грудь, это всё пока лишь демка, если я правильно понял.

Ну в контроллер вагона (как и другую систему реального времени) вряд-ли стоит ставить perl. Но системами реального времени не ограничивается применение Embox так что это включается по желанию :)

то как раз тут и вступают в дело политики безопасности. Которых у вас, как я понял, нет.

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

Как я понимаю, хакер, в вашем случае, получает полный доступ к памяти ядра (ММУ-то нет), и, соответственно, ко всей аппаратуре и к любым данным пользователя, которые есть на девайсе.

Кто такое сказал? И как он получает доступ, даже если MMU нет? Он может пользоваться только командами которые заявлены. Никакого доступа к памяти, если этого не предусмотренно.