> Ничего. Если оно действительно реально и "бесплатно" (т.е. решение не плодит худшие проблемы).Не понимаю аргумента с худшими проблемами. Юнит написанный для systemd отработает нормально, так же как init-скрипт написанный для sysvinit. Ошибки - проблемы переходного периода.
>Ничего. Вот только зачем тут systemd? - В дебиан и стандартным sysvinit обходятся.
> Ну да... Там уже телепатический модуль вкрутили? Нет, уважаемый - зависимости прописываются абсолютно так же, как и прежде. Например, как в Debian сейчас. Отличие разве в синтаксисе.
Я прочитал это и сделал вывод что таки телепатический модуль вкрутили:
"To speed up the entire boot and start more processes in parallel, systemd creates the listening sockets before actually starting the daemon, and then just passes the socket to it. All sockets for all daemons are created in one step in the init system, and then in a second step run all daemons at once. If a service needs another, and it is not fully started up, what will happen is that the connection is queued in the providing service and the client will potentially block on that single request. But only that one client will block and only on that one request. Also, dependencies between services no longer have to be configured to allow proper parallelized start-up: starting all sockets at once and a service needing another, it surely can connect to its socket."
То есть как я понял, стартуем все сервисы зараз, а они потом сами разберуться. Может чего недопонял, хз.
> 3) что плохого в d-bus активации, если это позволяет экономить ресурсы системы
> не запуская ненужные сервисы все и сразу?
> Это может быть полезным на десктопе. d-bus для оного и выдуман. Но везде это сувать зачем?
d-bus всего лишь небольшой демон. не самый быстрый, но один, если не единственный, из удобных способов одному процессу сказать чего-нибудь другому всем понятным способом. Причем тут роль, которую выполняет компьютер? не знаю, чем может помешать d-bus, даже на сервере.
> Работал у вас сервис, работал. Вы однажды отредактировали его конфиг и попортили (очипяткой, к примеру), а перезапустить сервис забыли. Пришла необходимость сделать ребут - сервер запустился. А об ошибке вы узнаете не тогда, когда сервер стартует - а тогда, когда сервис on-demand запустится. Вам такое интересно?
Хорошая привычка проверять конфиги после внесения изменений. Большинство серьёзных программ это умеет делать априори.
> Простой пример. Не экономьте на спичках... На сервере нет ненужных сервисов.
Вы приводите пример, что не надо забывать о других ролях системы, кроме десктопа. С другой стороны, я могу сказать тоже самое. Вас никто не принуждает использовать on-demand и dbus, просто такая возможность есть.
>> 4) что плохого в использовании cgroups
>Например, linux-only.
соглашусь. но с технической точки зрения - решение в яблочко. делает то, что нужно самым простым способом из возможных. Я не знаю возможностей других ОС в этой области, поэтому не могу сказать, насколько сильно завязано на linux.
> Это вам автор пообещал. А мы скажем мягше - пытается не ломать. Не всегда получается...
Ну дык, работа над ошибками, как и ошибки, будут всегда..
> Ну-ну. Багтрекеры дистрибутивов посмотрите...
не ковырялся. Сужу по своему опыту. reboot, shutdown работают, мне большего не надо.
> Слизанный синтаксис. Там, где по-уму нужен нормальный скриптовый язык - пихают порнографию с ConditionPathExists и прочим недо-тьюринговым брахлом.
У декларативного синтаксиса есть плюс - он лучше поддаётся разбору компом и вообще автоматизации. Довольно важная фишка. Хотя конечно в корне вопрос спорный, согласен. У меня мало опыта в написании init-скриптов, чтобы я мог говорить однозначно. С другой стороны, это немногим отличается от if [ -d "path" ] ))
> Это, в основном, известный всем-кому-оно-надо скриптовый язык и абсолютно стандартные утилиты. Мейнтейнерам и администраторам нет никакой необходимости лезть в 100500 ман-страниц, чтобы вспомнить значение тучи опций, включая ТуКоторуюПоттерингПрикрутилВчераВамНаРадость.
Я думаю сложность преувеличена. Типичный юнит для systemd это несколько строк говорящего самого за себя текста. А там, где нужна сложная логика - без манов не обойтись в любом случае, как в случае с systemd, так и в случае с sysvinit.
> Для этого разработчику всегда было достаточно написать man-страницу для сервиса, указать его ключи и т.п.
Тем не менее многие включают в дистрибутив init-скрипты, особенно если процесс загрузки сервиса неочевиден и имеет ньюансы.
>> 8) что плохого в снапшотах, с возможностью перейти в один режим с
>> сохранением текущего состояния и затем вернуться на исходные?
> Зачем? Попробуйте привести хороший пример.
Затем же, зачем нужен telinit, просто этот способ более продвинутый. Я не владею серверами, и не сталкивался с такими use-case'ами. Могу предположить только одно - если звезды падают, значит это кому-нибудь нужно? То, что люди тратили время и силы на ненужный функционал, тем более в open source - сомнительно.
>> 9) что плохого в архитектуре systemd, если она расширяема на манер плагинов
>А что хорошего? sysvinit расширяется любым языком, и?
если так рассуждать, то systemd аналогично расширяется любым языком ))
>> Я не спец конечно, но что-то из этого можно исполнить в sysvinit?
> cgroups может? Вроде, больше ничего и нет особо интересного.
я и пытался выяснить. с cgroups знаком только по наслышке, знаю что такое и для чего может использоваться, не больше. ну а особо интересное в системе инициализации трудно найти в принципе )
