Что должна уметь современная система инициализации?

Опять?

systemd никогда не был системой инициализации.

</thread>

Что должна уметь современная система инициализации?

она должна уметь то же, что и много лет назад - загружать систему
А из современных требований такие:
1) Не быть продажной шлюхой
2) Не строить из себя торвальдс-знает что
3) Быстро загружать систему
4) Должна присутствовать фича с приоритетами
5) Должны отсутствовать Поттеринг и его агенты

Не благодарите... хотя нет, благодарите!

D-Bus-активация потенциально позволяет сэкономить, но если мы её вводим, то придётся засовывать привязывать инит к D-Bus, а потом кто-то подумает, что если есть D-Bus-активация, то почему бы и не сделать socket-активацию, и мы засунули в инит функции inetd, потом запуск при подключении устройств с udev и прочее и прочее...

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

//Я как-то давно придумал init в suckless-стиле, в котором init конфигурируется в момент компиляции, но я сам не люблю suckless-решения, поэтому ни предпринимал шагов к его созданию, ни рассказывал кому-то об этой идее.

и да, внесите сюда проповедника Поттеринга, пожалуйста!

$ sudo multicast intelfx

Здесь скучно и подобная тема уже была.

Годные идеи по сравнению с традиционной системой он имел

journald несмотря на бинарность хорош тем, что собирает весь выхлоп демона, неважно куда, он его выдаст (в syslog, в stdout/stderr), и сколько бы раз он не расфокраклся. Поддержка cgroup вообще помогает в случае расфоркавшихся демонов, так как форки не могут сбажать из cgroup, и при остановке демона будут убиты.

logind — полный аналог тухлого ConsoleKit, но он обеспечивает автоматический запуск systemd --user, с помощью которого пользователь может автоматически запускать демоны. Но он мог бы это обеспечивать и без прибития гвоздями. systemd бы просто подписывался на сигнал запуска сессии.

Использование autofs — сомнительной полезности фича, но может сэкономить при загрузке (почему бы просто не монтировать ненужные для загрузки ФС в фоне?), а вот то, что стандартный mount(1) — медленное говно, и systemd обрабатывает /etc/fstab гораздо быстрее — факт.

hostanamed, localed etc. может кому-то и нужны, но зачем они в systemd совсем не понятно.

На самом деле недостатки системы инициализации на шелл-скриптах следуют из недостатков шелла.

спасибо за ссылку, почитаю

кстати, молодой человек... Иван, да?
судя по вашему профилю в некой печальной соцсети, вы достаточно юный... не хотите ли заняться чем-то полезным в мире FSF? А то гляди, точно агентом Поттеринга станете.

Спасибо еще раз.

Т.е. или велосипедить свою систему сообщений или привязываться к готовым но низкоуровневым? Это помимо откровенных свистоперделок.

потом запуск при подключении устройств с udev

Каким боком тут система инициализации? Сделали бы отдельный демон.

D-Bus-активация (возможно я что-то перепутал, и она называется не так) позволяет запустить одновременно демон-сервер и демон-клиент, если они связаны через D-Bus. Без поддержки D-Bus это сделать просто невозможно. Вопрос лишь в том, стоит ли это того. Так что никакая система сообщений тут не поможет.

Управление самим инитом через D-Bus не так уж и нужно. systemd тоже вполне себе управляется через обычный сокет. Но может быть это и полезно ради какой-то унификации (всё через D-Bus).

В зависимости от того, кого считать агентом Поттеринга, может быть так, что уже стал. По крайней мере, мой код в systemd есть. И не только в systemd, так что уже занимаюсь.

Ну, systemd же udev в себя поглотил. Какие-то там device-юниты там у него ещё.

Которым походу и является udevd

Что должна уметь современная система инициализации?

выполнять один скрипт. все.

позволяет запустить одновременно демон-сервер и демон-клиент

возможно я что-то перепутал, и она называется не так

Да, перепутал. Это прекрасно работало и без systemd, работает и сейчас и надеюсь будет работать впредь.

современная это как?

Прелесть sysvinit в том, что скрипты инициализации модно писать на чем угодно. Можно даже написать свою подсистему с аналогом поттеринговых юнитов.

Это с NIH-синдромом и велосипедизмом.

это конечно хорошо, но по моему достаточно было найти замену bash subshell, с возможностью возврата статуса и не порождая отдельный процесс «не выходя за рамки bash» ...

Только не надо гнать что systemd перманентно нинужно

Современная система инициализации должна уметь всё от инициализации до встроенного крузиса.

Предлагаю плеер, «без музыки ж тоска»!

должна делать вид, что она - systemd

ко всему тому что здесь уже написали — не забудте добавить пункт:

-- должна ументь выключать компьютер (там, чтобы всё как положено — с генерированием shutdown-ramfs)

Вызывать шлюх и лечить похмелье, конечно же.

всё! и ещё немножко жить...

Вам сюда: http://www.skarnet.org/software/s6/why.html

uselessd.

Демон-клиент постучится к серверу, а тот ещё не успел запуститься, и отвалится.

wtf? Сколько можно? Обмусолили же уже несколько раз

Пора уже тех кто создает очередной тред «что должна уметь современная система инициализации» принудительно проверять на дислексию

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

системдэ же включает в себя вещи формально в систему инита не входят, но участвуют (с).

Что за bloatware? Учитесь у мастеров! http://tools.suckless.org/sinit

There are 3 signals that sinit will act on.
SIGUSR1: powers off the machine.
SIGINT: reboots the machine (or alternatively via ctrl-alt-del).
SIGCHLD: reap children