FInit v4.0

Плюсую товарища.

Переход с инитскриптов на systemd дал ощутимую разницу во времени загрузки. И к сожалению для Oberstserj время стало меньше. Даже на одноядерном imx6.

Переход с инитскриптов на systemd дал ощутимую разницу во времени загрузки.

Огласите пожалуйста численное значение, в секундах какая разница времени загрузки?

на одноядерном imx6.

И если не секрет, чего так много запускается на таком маленьком камне, что есть «ощутимая разница»? Спасибо.

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

Тут есть нюанс, идея в том чтобы запустить остальные сервисы вроде монтирования по fstab, alsa-restore, udev, connmand и т.д. пока основное приложение продолжает инициализацию. Получается к тому моменту когда на экране появится UI, система уже завершит загрузку критических демонов. В случае одноядерной системы это не сыграло большой роли, но соседней, уже с четырьмя – systemd полностью выполнил задачу.

Для одноядерной системы польза только во времени старте приложения.

Я не помню точные цифры

Тут есть нюанс, идея в том чтобы запустить остальные сервисы

Вы же не хотите сказать, что этого нельзя добиться обычным скриптом и получить даже более прогнозируемый результат? Или хотите?

Хочу. Башескрипты в любом случае тяжелее и неповоротливее.

Хочу. Башескрипты в любом случае тяжелее и неповоротливее.

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

Звучит всё так, словно вы сами не в состоянии разобраться что и в каком порядке у вас должно загрузиться и вместо того, чтоб потратив пару часов сделать простой и понятный сценарий, который точно не будет медленнее, решили просто вкорячить «волшебный» systemd.

Хорошо, что у вас всё получилось. Но как уже и писали выше, это не эмбеддед, а херак-херак в продакшен.

Анонимус, объясни мне почему я должен помнить всё? На какие-то результаты я сослался – хотите повторяйте, хотите нет.

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

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

почему я должен помнить всё

Ну не должны конечно. Но тогда свои громкие и масштабные заявления сопровождайте пожалуйста простым вступлением «мне кажется, что X быстрее Y». Или ещё точнее так: «мне бы очень хотелось, чтоб истиной было высказывание Z».

Вот трёх строчек достаточно было чтоб первый удачный пример подвернулся, попробуйте:

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

Нет, я на своём опыте увидел разницу, а вот верите мне вы наслово или нет, это ваше собственно дело.

Я не требую довериться конечно, критическое мышление это полезно и критически относиться как к systemd, так и к sysvinit это правильно, но я со своей стороны не вижу никаких противоречий и банальной лжи.

Я вас во лжи не обвинял и даже верю вам что разница есть и даже верю что с systemd получилось быстрее.

Клоню я совсем к другому, а именно: эмбеддед тем и хорош, что устройство не должно быть очень общим и поддерживать всё на свете, как десктоп. А как раз наоборот, вполне закреплено какое есть железо и что оно исполняет, а следовательно вводить лишние уровни абстракции, КМК, ни к чему.

Вашу точку зрения понял. Высказываю своё ИМХО: чем меньше «движущихся частей», тем лучше. И чем яснее и однозначнее я могу пройти глазами сценарий, никуда не сворачивая и не заглядывая в другие проекты, тем тоже лучше для меня лично.

Я согласен, что меньше движущихся частей – лучше. Поэтому мне лично больше нравится Android init. Но он довольно специфичен для Android как такового.

bash

простой и понятный сценарий

Оксюморон, особо если все ошибки стараться отработать

Переход с инитскриптов на systemd дал ощутимую разницу во времени загрузки.

У нас скорее всего аналогично, хотя специально не замерял - железка всё-равно месяцами без перезагрузки работает. Основной мотив в нашем случае это удобство разработки - когда и на целевом устройстве, и на машине программиста софт стартует и мониторится одинаково, то это элементарно комфортнее. И меньше шансов что «в поле» какие-то сложновоспроизводимые косяки вылезут.

на целевом устройстве и на машине программиста софт стартует и мониторится одинаково

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