Нет. Хватит уже плодить init'ы.

А почему?
То что я предложил - это же практически systemD, но намного более простое. Тут можно и одновременную загрузку прикрутить, и отложенную и понять её проще.

Но зачем?

Даже первая часть в полном объёме не нужна. Нужен лишь последовательный запуск демонов. Всё. Никаких параметров, никаких ini, никаких обращений...

А теперь выброси ненужнод на свалку истории и получишь bsd-init или sysv, если добавишь runlevel (которые, впрочем, тоже не нужны).

autorun.bash

autoexec.bat, ага

Это для совместимости с ini systemD же. Параметры это runlavel. Точно убрать?

Даже первая часть в полном объёме не нужна. Нужен лишь последовательный запуск демонов. Всё. Никаких параметров, никаких ini, никаких обращений...

BSD-Init.

Без парсера конфиг придётся править только вручную.

ненужно

Параметры init передаёт при вызове скрипта. Это могут быть не только уровни загрузки, а всё что ты в нём напишешь.

Зачем что-то парсить? Глянь просто, как это сделано в OpenBSD and be enlightened. ;)

Ну сама идея - максимально простой init который совместим с systemD. Всё равно зависимости и прочее должно где-то храниться. Если не SystemD формат, то свой собственный, непопулярный.

Соль ненужнод не в конфигах, а в том, что это комбайн-чёрная-дыра. Функции самого init — там доли промилле.

Круто же! Преимущества SystemD и не очень сложно.

и понять её проще.

то есть нелюбовь к systemd из-за неосиляторства?

Вот-вот. А сама идея его конфигов мне кажется хорошей.

кажется

Именно, что кажется. ;) KISS

http://www.slideshare.net/iXsystems/jordan-hubbard-free-bsd-the-next-10-years

слайды 32-33

Странно что ЛОР их не обсуждает.

Но как иначе можно автоматически настраивать приоритет загрузки?
Тут всё будет работать автоматически с учётом зависимостей. При этом запуск из простого скрипта. Уровень загрузки (если он и правда нужен) можно будет добавить очень легко просто вставив в скрипт обработку вызванного параметра.

Я не знаю как BSD init смогло бы заменить systemD, а такая штука выполняет большинство его функций и остаётся простой.

bash

Эту гадость выпиливать надо, а не наоборот.

Почитав лор можно легко и непринужденно прийти к выводу, что главная запчасть линукса это система инициализации. Остальные оси десятилетями смотрели сквозь пальцы на эту архиважную хрень и довольствовались тем, что она что-то запускает или наоборот, убивает. И только когда Леннарт, вдохновившись примерно килограммом травы и макосевским launchd, запилил свой велосипед, линуксоиды прозрели. Брошен ненужный прикладной софт, замшелые DE, никчемные драйвера... Каждый линуксоид обязан выразить свое мнение о systemd, а самые храбрые школьники сразу начинают пилить свою, принципиально новую, систему инициализации.

bash

Закопать.

Too many things need to know explicitly about dependencies (when can I start? What has to start before me?)

Запустить пол-десятка сервисов и две тулзы из портов уже неподьёмная задача? ;) Для этого нужен умный комбайн, который через libastral сам зависимости раставит? Если нет, то один скрипт вида

#!/bin/sh
run_a
run_b
run_c

Run=b
IfAlreadyRunning=a
ButNotPriorRunnig=c

А как в openBSD сделаны зависимости загрузки и где они пишутся? Просто руками?

• /etc/rc
• /etc/rc.conf
• /etc/rc.d/

Сейчас всё хорошо, но вот я ставлю новый пакет который зависит от других.

bsd-init или sysv

Сжечь в одной печи с GNU.

Разный подход, разная идиология. В том же Open ничего автоматом в конфиг не пишется и не стартуется. Админ должен сам добавить, что ему надо.

Например для пакетов:

$ grep pkg_scripts /etc/rc.conf.local
pkg_scripts="dovecot apache"

Если мне надо будет добавить mysql, я уж как-нибудь в трёх соснах разберусь и добавлю его в начало.

В линухах другой подход. Ставим и запусакем всё! И бъём шишки об зависимости. ;)

Так ты не мне это пиши, там автор слайдов указан.

А я просто в сторонке постою-посмотрю как BSD получит свою дозу холиваров.

Ну вот ;(
Система без зависимостей это на самом деле уж слишком. Я и хотел их прикрутить. Мне кажется что описание их в каждом файле это более сложно чем ini и такой парсер.

Вопрос только, зачем они нужны? Что у нас в активе? Диски, сеть, разные сервисы. Что ещё? Первое-второе и так разруливается на системном уровне. Последнее — последним и запускается. Простая и ясная система. Думаю, рассортировать dovecot, apache, mysql админ, не упавший на голову, и так сможет.

Contra: нет зависимостей

Pro: нет зависимостей — меньше деталей, которые могут сломаться

Проблема же.

Только админ и сможет..

Как будешь проверять состояние демона?

Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d.

по старинке же: ps aux|grep $daemon|grep -v grep и так далее

Да узнай же о pgrep, о великий grep -v grep!

Такое было бы нужно?

Такое было ещё до systemd.

Stuffed_toy> Ну сама идея - максимально простой init который совместим с systemD.

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

Stuffed_toy> Преимущества SystemD и не очень сложно.

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

Управлением сервисами занимается rc-система. И уже есть такая на основе зависимостей - OpenRC. Причём появилась она задолго до systemd. А ещё есть upstart (который также появился ещё до того, как Поцеринг начал думать об инитах), но это монстр по подобию systemd, которого терпят только потому, что у разработчика нет наркоманских замашек долбеня Поцеринга.

Спасибо. Не знал про эту штуку.

Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d.

I write SystemD as «SystemD» because the letter «D» means «Dickhead» - not a daemon.

Эм. Базовая поставка системд состоит из внезапно: инита с парсером конфиг и зависимостями, журнального демона, удева и... фак, все. Больше ничего.
http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/

И что из этого лишнее? Журнал? Ну таки куда-то надо ловить совсем ранние сообщения. Раньше на них тупо забивали.

Удев? Эм, удев по факту везде есть.

В общем, почитай. То, что ты собрался навелосипедить будет по итогу сложнее этой штуки.

http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/

kir2yar> Эм. Базовая поставка системд состоит из внезапно: инита с парсером конфиг и зависимостями, журнального демона, удева и... фак, все. Больше ничего.

Только в этот инит с «парсером конфига и зависимостей» что-то слишком дофига напихали.

kir2yar> И что из этого лишнее? Журнал?

Супервизор сервисов как минимум лишний. Он обязан сидеть вне инита.

И где таки он должен сидеть? Так, что бы он мог отличить процесс cgi-скрипта одного апача от cgi-скрипта другого.

И почему не в ините? Достаточно разумный подход. Кто запустил сервис, тот и отвечает за него.

Конечно, портянка на баше, которая ищет по всей ФС пид-файлы и теряет неявных потомков сервиса - идеальный супервизор сервисов. )

/o

А systemd API кто реализовывать будет? Скрипт на баше?