С одной стороны - зоопарк из кучи инициализационных скриптов давно пора ликвидировать, меняющийся их функционал от дистрибутива к дистрибутиву в купе с дружественностью отдельных проектов к отдельным дистрибутивам же, как и попытки некоторых проектов включить в себя код обслуживающий процессы делает практически невозможным создание системы удовлетворяющей требованиям - простоты, скорости, функциональности и гибкости.
Если ни одна из существующих систем не подходит, логично предположить появление еще одной - рассчитанной на удовлетворение исходным критериям. Однако, стоит задуматься, насколько подобное решение будет эффективным, понятно, что для разработчиков Apache написать скрипт для новой системы труда не составит, а даже если они этого не сделают, это сделают разработчики самой системы инициализации, но существует ПО которое уже давно никто не разрабатывает, соответственно кому-то придется создавать новые пакеты со старым софтом для новой системы, более того кто-то должен добавлять поддержку новой системы в новые проекты, учитывая, что администрации некоторых из них не удосуживаются выложить даже архивы с исходниками релизов отписываясь ссылкой на git-репозитарии, возникает вопрос кто этим будет заниматься, в контексте жирных корпоративных клиентов - это будет сам redhat, частично комьюнити. Но в полном объеме никто этого не сделает, кроме конечного админа (если он не забьет), разумеется будут оставленны всевозможные способы выполнения задачи в режиме совместимости с другими системами - для ленивых админов/пользователей и как результат вместо первоначального зоопарка мы получим зоопарк с еще одним питомцем.Очевидно надо ввести уровень абстракции что-то вроде HAL и не hald от которого некоторые дистрибутивы успели отказаться, а что-то другое, что позволит изголяться над системой как угодно на радость красноглазикам, писать сценарии загрузки для корпоративных клиентов и тд, В линуксе уже есть рабочие аналоги подобных решений, в частности sysfs; удобная, функциональная и легковесная,.. Если уж речь идет об управлении процессами, то заниматься этим должен некоторый процесс, соответственно демон, dbus сомнительная кандидатура, хотя бы потому, что на пару с hald был отвергнут.
И смотреть тут надо на так нелюбимую некоторыми винду и ее системами управления процессами, устройствами и событиями. Короче говоря в нынешнем виде этот systemd костыль не меньший чем скрипты,
|
