Боюсь вас расстроить, но в авиации используют С++ на равне с С (и ada), в частности боинг использует С++ с vxworks. Автомобили? С++ как в эмбеддеде так и и в схемах контроля «самоуправляемых машин».
Я использовал VCC — +5v (на плате дисплея стоит стабилизатор на 3.3 вольта, если его замкнуть предусмотренной перемычкой, то можно использовать питание 3.3 вольта).
Логика дисплея работает от 3.3 вольт, как и наш микроконтроллер, поэтому использовать конвертер логических уровней, как в случае с arduino uno, нам не потребуется.
Где же вы были год назад. Я так надолбался с этими китайскими экранчиками, пытаясь понять почему ничего не работает :-) Всему виной конечно невнимательность, я далеко не сразу понял что в поставке «по умолчанию на ebay» их таки надо от +5V запитывать при логике 3.3V.
> Нет, нет, я настаиваю. Какие именно на данный момент линуксы ушли от unix-way?
Разрешите мне в данном случае ответить вопросом на вопрос для понимания контекста — распихать все демоны в контейнеры docker, которые стартуют путем однострочника в runit — это unix-way?
> кухонный комбайн с возможностью пылесоса…
На глаз у меня в пакете systemd на арче около 30 бинарников. Это ваши раздельные мясорубки и пылесосы. Да, они все упакованы в один ящик, как-то так же как амазон пакует покупки. Это спорный момент, так как с одной стороны тут строгое соответствие версий, а с другой — общий цикл релиза. На данный момент последнее проекту не мешает.
> Ну опять же, и под виндой qemu /bin/bash, условно говоря, запустить можно
Аналогия не корректна. Systemd для запуска /bin/bash не намного сложнее чем runit. /bin/bash запускается полностью «нативно» во всех смыслах, которые можно вложить в это слово.
У нас в продакшене много разного интересного. Мне кажется вы больше сфокусированы на init-системе ради init-системы. Init — это просто механизм для запуска некоторого количества userspace-задач и их оркестрации.
> Проблема в том, что политика разработчиков системд прямо или косвенно направленна на то, чтоб запретить нам НЕ системд
Я этого не чувствую. Сабж впиливают как зависимость потому что он иногда предоставляет простой апи к вещам, которые ранее было более сложно делать (это касается gnome, насколько я его знаю).
Запретить? Как я ниже написал, вы вольны делать что и как угодно. Разве что с systemd эти шелл-скрипты будет как-то попроще, т.к. какая-то часть задач уже будет решена в systemd.
> Проблема системд, что давятся те, кто хотят накидать шелл-скрипт. Или перл-скрипт. Или xml
Нет, ну никто же не запрещает накидать 3-4 строки systemd-шного сервиса, в котором хоть /etc/rc.local запускайте. Никто не отбирал у вас возможность запускать что угодно когда угодно шелл или иными скриптами.
Я наверно слишком долго работаю с машинами, где давным давно забыли про unix-идеологию (это OS X и специализированные линуксы). Я не совсем понимаю как зависимость сервиса с конфигом на NFS от факта примонтирования NFS раздела — это забота менеджера пакетов.
Systemd работает. Его не интересует, какая у пользователя в голове идеология, он решает свой набор задач, и справляется, по большему счету, сносно. У меня «в голове» идеологии тоже нет, у меня есть задачи, которые надо решать, и инструменты, которые помогают в этом. И если мне проще накидать ini-конфиг, а не шелл-скрипт — я накидаю первый, запущу сервис и забуду об этом.
Меня как-то никогда не волновала проблема того что в journald тянет по зависимостям либу для QR кодов. Плюс, как я написал выше — именно интеграция вещей не относящихся к запуску демонов делает systemd интересным (зависимости не только между сервисами).
Я успел поиграться с systemd на арче (на мелкой прототипной arm-борде) и немного с coreos. Знаете, я наверно с радостью выпилил бы некоторые шелл-костыли из боевой убунты. Да, runit простой как тапок и работает, но на systemd то же самое можно сделать проще. В какой-то мере мне даже нравится интеграция journald прямо в него, хотя как journald работает внутри я могу и не одобрять.
Вы перегибаете палку, в том как писать сервисы для systemd можно разобраться за час с нуля, это не rocket science.
Да, у systemd есть проблемы, меня лично вот весьма печалят некоторые нюансы журналирования. Но в systemd замечательно просто сделаны зависимости и с ним просто построить граф зависимостей сервисов, в том числе и от разных событий, файловых систем и прочего.
Поговаривают, что в линуксе dhclinet любит записывать в ENV что-то что пришло от DHCP-сервера и потем дергать всякие разные шелл скрипты. От рута, конечно :-)
Где же вы были год назад. Я так надолбался с этими китайскими экранчиками, пытаясь понять почему ничего не работает :-) Всему виной конечно невнимательность, я далеко не сразу понял что в поставке «по умолчанию на ebay» их таки надо от +5V запитывать при логике 3.3V.
Разрешите мне в данном случае ответить вопросом на вопрос для понимания контекста — распихать все демоны в контейнеры docker, которые стартуют путем однострочника в runit — это unix-way?
> кухонный комбайн с возможностью пылесоса…
На глаз у меня в пакете systemd на арче около 30 бинарников. Это ваши раздельные мясорубки и пылесосы. Да, они все упакованы в один ящик, как-то так же как амазон пакует покупки. Это спорный момент, так как с одной стороны тут строгое соответствие версий, а с другой — общий цикл релиза. На данный момент последнее проекту не мешает.
> Ну опять же, и под виндой qemu /bin/bash, условно говоря, запустить можно
Аналогия не корректна. Systemd для запуска /bin/bash не намного сложнее чем runit. /bin/bash запускается полностью «нативно» во всех смыслах, которые можно вложить в это слово.
У нас в продакшене много разного интересного. Мне кажется вы больше сфокусированы на init-системе ради init-системы. Init — это просто механизм для запуска некоторого количества userspace-задач и их оркестрации.
> Проблема в том, что политика разработчиков системд прямо или косвенно направленна на то, чтоб запретить нам НЕ системд
Я этого не чувствую. Сабж впиливают как зависимость потому что он иногда предоставляет простой апи к вещам, которые ранее было более сложно делать (это касается gnome, насколько я его знаю).
Запретить? Как я ниже написал, вы вольны делать что и как угодно. Разве что с systemd эти шелл-скрипты будет как-то попроще, т.к. какая-то часть задач уже будет решена в systemd.
> Проблема системд, что давятся те, кто хотят накидать шелл-скрипт. Или перл-скрипт. Или xml
Нет, ну никто же не запрещает накидать 3-4 строки systemd-шного сервиса, в котором хоть /etc/rc.local запускайте. Никто не отбирал у вас возможность запускать что угодно когда угодно шелл или иными скриптами.
Systemd работает. Его не интересует, какая у пользователя в голове идеология, он решает свой набор задач, и справляется, по большему счету, сносно. У меня «в голове» идеологии тоже нет, у меня есть задачи, которые надо решать, и инструменты, которые помогают в этом. И если мне проще накидать ini-конфиг, а не шелл-скрипт — я накидаю первый, запущу сервис и забуду об этом.
Я успел поиграться с systemd на арче (на мелкой прототипной arm-борде) и немного с coreos. Знаете, я наверно с радостью выпилил бы некоторые шелл-костыли из боевой убунты. Да, runit простой как тапок и работает, но на systemd то же самое можно сделать проще. В какой-то мере мне даже нравится интеграция journald прямо в него, хотя как journald работает внутри я могу и не одобрять.
Да, у systemd есть проблемы, меня лично вот весьма печалят некоторые нюансы журналирования. Но в systemd замечательно просто сделаны зависимости и с ним просто построить граф зависимостей сервисов, в том числе и от разных событий, файловых систем и прочего.
А разве Gemfile.lock не для этого придуман?