p.s. кстати, «современные, стильные, молодёжные», повторяющие тут мантру про «портянки», неправы именно потому, что в силу неимения опыта не представляют разнообразия задач, которые могут возникнуть. набор опций в systemd и так уже большой и неоднозначный (не всегда можно чистой логикой догадаться, что именно делает опция; а это плохо). дальше так и будут продолжать добавлять опции и правила для вновь возникающих ситуаций. а в итоге юнит-файлы, может, и будут маленькими, но количество опций и их взаимосвязей, которые надо будет знать — огромным.собственно, лёня к тому и стремится: чтобы юнит-файлы *выглядели* просто, но искусство правильного их написания было чёрной магией, доступной только тем, кто потратит кучу времени на изучение опций и правил systemd. в отличие от «портянок» на sh, которые может и выглядят страшно, но чтобы в любой из них разобраться (и написать новое), достаточно знаний sh и coreutils. классическое «обэнтерпрайзивание», во всей красе. умные молодые и опытные старпёры это видят, и потому воспринимают systemd в штыки. ну, не только по этой причине, конечно — качество кода и документации, отсутствие вменяемой архитектуры… но главное — таки усложнение написания инит-сценариев при кажущемся упрощении. кстати, в upstart это было решено намного красивей. плюс — upstart не старался вобрать в себя кучу утилит. и даже — о, кощунство! — мог работать как обычный service manager, не будучи процессом с pid 1.
|