[Sauris 0]

а я слышал что центос для серверов, надо будет попробовать когда захочется сервер на десктопе... но наверно мне не захочется :)

Наглая и злостная дезинформация :). Центос это сборка десктопного RHEL из исходников RHEL, но не редхэтом. Удобна тем, что является копией редхэта, а значит вся поддержка кэденса, ментора, синопсиса, альтеры, и так далее (список всего, почти всего, софта для разработчиков) - действительна и для него. А gcc, так ему все равно какой дистрибутив. С ним проблем нет ни в каком.

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

 

система инициализации юзерспейс - это далеко не самое слабое звено при старте системы

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

Изменено 13 февраля, 2013 пользователем SAURIS GmbH

[sasamy 11]

Наглая и злостная дезинформация :)

 

Это же шутка была, хотя с долей правды

 

Когда все остальные звенья ликвидированы, оно становится самым слабым, причем по своей "слабости" на пару порядков перекрывает все остальное.

 

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

[Sauris 0]

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

Ну это смотря что стартовать и сколько этого чего стартовать. Многое то грузится из флеш быстро, а потом медленно инициализирует всякие сокеты, грузит всякие фирмвари, и т.п., поэтому upstart дает в этом случае серьезное преимущество из-за многозадачного параллельного старта сервисов. Конечно, можно и в рамках классического init это же реализовать, но не выгодно получается, в т.ч. из-за слишком большого количества параллеьно крутящихся скриптов.

 

Но это уже за рамками темы.

Изменено 13 февраля, 2013 пользователем SAURIS GmbH

[sasamy 11]

upstart дает в этом случае серьезное преимущество из-за многозадачного параллельного старта сервисов.

 

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

 

Конечно, можно и в рамках классического init это же реализовать, но не выгодно получается, в т.ч. из-за слишком большого количества параллеьно крутящихся скриптов.

 

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

 

#!/bin/sh

 

matchbox-desktop &

matchbox-panel --orientation south &

exec matchbox-window-manager $@

 

upstart хорош для серверов - больших и толстых и тот же RHEL его использует.

 

Но это уже за рамками темы.

 

согласен

Изменено 13 февраля, 2013 пользователем sasamy

[Sauris 0]

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

 

Во первых, для невнимательно читающих, повторюсь, если для каждого приложения требуется для чтения с диска 0.1 сек, а для инициализации 5 сек, причем инициализируемые ресурсы не пересекаются и во время их инициализации они почти не потребляют процессорного времени - то параллельная загрузка убыстряет время старта на (5-0.1)*N сек. А таких процессов есть и не один, особенно сервисы, работающие с сетевыми интерфейсами. Отношение времени чтения с диска к времени инициализации среднего сетевого демона именно такое на самом деле, что подтверждает и практика. Плюс к этому - поток на максимальной скорости из NAND в память занимает отнюдь не все процессорное время, он вообще-то в DMA идет, и тратить все это время впустую просто расточительство.

 

Во вторых, запуск с "&" хорош для себя, для дома. А мне, извините, это надо поддерживать, и унифицировать, чтобы и этому клиенту удобно было, и тому, и третьему, и чтобы это было на что-то стандартное похоже хоть как-то, и при этом грузилось хотя бы вдвое быстрее аналогичного по набору наворотов arago. Да и upstart вообще аккуратный, компактный и малоресурсожрущий, даже вместе со своей libnih, меньше этого монстра бизибокса в разы по всем параметрам, и поэтому сам по себе запускается быстрее.

 

А кто такой шибко умный, сам upstart выкинет, и позапускает что ему надо с "&", но пока таких не встретилось ни одного, всем дай все готовое и поддержи, типа чтобы их приложение на qml написать и оно заработало как им надо само по себе.

 

PS

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

Изменено 13 февраля, 2013 пользователем SAURIS GmbH

[sasamy 11]

Плюс к этому - поток на максимальной скорости из NAND в память занимает отнюдь не все процессорное время, он вообще-то в DMA идет

 

Если не секрет - какая ФС у вас используется для NAND ?

 

Во вторых, запуск с "&" хорош для себя, для дома. А мне, извините, это надо поддерживать, и унифицировать, чтобы и этому клиенту удобно было, и тому, и третьему, и чтобы это было на что-то стандартное похоже хоть как-то, и при этом грузилось хотя бы вдвое быстрее аналогичного по набору наворотов arago.

 

Тогда вы немного промахнулись, стандарт де-факто и майнстрим в Linux - systemd, upstart - это чисто убунтовская система инициализации которую разработали и поддерживают в Canonical. Собственно меня это и удивило с самого начала.

 

upstart на серверах нафиг никому не нужен.

 

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

 

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

Изменено 14 февраля, 2013 пользователем sasamy

[Sauris 0]

Если не секрет - какая ФС у вас используется для NAND ?

Секретов в линуксах не бывает :) Ну почти... На сегодня мы предлагаем и рекомендуем ubifs. Пробовали и исследовали jffs(2), yaffs. А вот logfs еще не пробовали, да и неохота пока почему-то.

 

Тогда вы немного промахнулись, стандарт де-факто и майнстрим в Linux - systemd, upstart - это чисто убунтовская система инициализации которую разработали и поддерживают в Canonical. Собственно меня это и удивило с самого начала.

Я то как раз не промахнулся, прежде чем на что-то поставить, все варианты инитов собрали, все попробовали в наших конкретных условиях, и сравнили. Против upstart-а остальные в условиях железяки "отдыхают", и это уже проверенный факт. Я не буду спорить, где-то наверняка он не оптимален, но не в нашем конкретном случае. И, честно говоря, мне все равно, кто его поддерживает. Для наших клиентов его поддерживаю я. Он же ведь GPL и open source, а значит подправить под свои нужды всегда можно. Вот со временем напрочь оторву его еще от dbus-а в версии для "совсем маленьких" систем (ключик у конфигуре --without-dbus будет), и вообще красота будет. Я ведь тоже когда-то не верил, что убунтоиды могут что-то хорошее и полезное сделать. А оказалось - могут. Собственно, осталось ждать не сильно долго, мы скоро этот наш дистр выложим со всеми репозиториями, и можно будет убедиться самому. А пока все же, если совсем официально - араго. А это в разработке.

 

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

Конечно для ембеддед! Из сетевых сервисов всем вайфай+блютуз+изернет дай, причем половине дай access point. А некоторым еще видео захвати, пожми, сколько кадров влезет, и по сокетам раздай. Оно за собой тащит весь нетфильтр (зачем? А фиг его знает, "хотим!"), и кучу сопутствующих сервисов, причем не бизибоксовского уровня, и все это надо естественно запустить, не запутавшись в "&"-ах.

Изменено 14 февраля, 2013 пользователем SAURIS GmbH

[sasamy 11]

На сегодня мы предлагаем и рекомендуем ubifs. Пробовали и исследовали jffs(2), yaffs. А вот logfs еще не пробовали, да и неохота пока почему-то.

 

тогда должен вас немного огорчить но с DMA тут не все так радужно

http://comments.gmane.org/gmane.linux.port...m.kernel/112063

http://lists.infradead.org/pipermail/linux...May/041178.html

 

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

 

буду иметь ввиду, потому что пока не нашел "золотой середины" - все приходится руками делать :) По поводу систем инициализации - на imx53 старт системы примерно одной функциональности Yocto-openembedded (sysvinit):Ubuntu(upstart):buildroot(busybox) по времени примерно соотносятся как 10:5:1 :)

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

Изменено 14 февраля, 2013 пользователем sasamy

[Sauris 0]

тогда должен вас немного огорчить но с DMA тут не все так радужно

Спасибо, намек понят, но пока что прецедентов глюка не было. У нас не atmel_nand, а omap2, вероятно, в нем нет этих проблем с дма, а дма включал (и проверял, что он включился) лично я - то есть сейчас "все включено" - dma+prefetch

Изменено 14 февраля, 2013 пользователем SAURIS GmbH

[sasamy 11]

У нас не atmel_nand, а omap2, вероятно, в нем нет этих проблем с дма, а дма включал (и проверял, что он включился) лично я - то есть сейчас "все включено" - dma+prefetch

 

А вы попробуйте отключить и сравнить скорость чтения/записи - возможно будете удивлены, иногда накладные расходы на инит chain dma или чтение маленькими кусочками с постоянными переключениями контекста от прерываний могут быть такими что данные просто так прочитать проще :)

Изменено 14 февраля, 2013 пользователем sasamy

[Sauris 0]

А вы попробуйте отключить

 

Так прежде чем включить, оно же отключено было :) И скорость, и загрузка процессора записаны....

[Enthusiast 0]

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

Если речь идет о целевом устройстве, то я бы ставил "Дженту": поддержка от 80486-х процессоров и выше, "АРМов", "Спарков", "Мипсов" и "Пауэр-Пи-Си"; гибкая настройка служб; сборка ОС самым свежим компилятором с нужными ключами оптимизации, что весьма прибавляет скорости работы. Читать придется много, но это того стоит. Успехов!

На компе я использовал среду разработки "Кдевелоп". Она заметно шустрее "Эклипса" и работает довольно устойчиво.

Изменено 22 февраля, 2013 пользователем Enthusiast

[andrew_b 14]

Удалено.

[SyncLair 0]

На компе я использовал среду разработки "Кдевелоп". Она заметно шустрее "Эклипса" и работает довольно устойчиво.

Моя рекомендация -- Qt-Creator примерно из той же песни что и Kdevelop и также быстрее "Эклипса" ибо они обра на Qt. Ещё есть CodeBlocks причём оба этих приложения портированы под Window.

 

 

А почему "благодаря"? Я вот спокойно собрал 4.7.2 с graphite (ClooG и PPL) в классическом CentOS, собралось с пол-оборота.

Если вы собрали gcc c помошью системы установки то я за вас рад, а так мне кажется вы вручную распокавали исходинки gcc, запустиили configure ну и так далее. а потом скопировали полученные файлы в дерево дистрибутива причём сам дистрибутив скорее всего ничего не знает о том что у него стоит avr-gcc

а в Gentoo этого нет ибо есть утилита которая сама генерирует пакет который сам всё это делает, а захотите пересобраить или удалить система сборки emerge за вас это всё сделает.

 

[SM 0]

а потом скопировали полученные файлы в дерево дистрибутива

У меня цель - собрать наиболее кросс-дистрибутивный SDK - поэтому я еще и инсталлятор к нему делал, чтобы не привязываться к манагерам пакетов, и он одинаково теперь ставится на убунте, дебиане, редхате и пр. И имеет внутри себя все необходимые "редкие" зависимости, типа того же ClooG/PPL, которого не найдешь днем с огнем в дистрибутивах. И ставится он не обязательно в недра системы, его можно проинсталлировать себе в ${HOME} без прав root-а и работать - то есть в дерево дистрибутива я его не то, что не ставил, а и не собирался ставить, максимум ему место если не в HOME, то в /opt/my_arm_sdk/. Да, и вот тут уже, именно БЛАГОДАРЯ центосу, причем не последнему, он не требует наличия в системе того, кто будет им пользоваться, какого нибудь супернового GLIBC, а довольствуется >=2.6.каким-то - то есть пойдет без танцев с бубном у гораздо большего количества людей, нежели, если бы я его собирал под какой нибудь свежайшей и крутейшей системой.