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

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> p.s. кстати, «современные, стильные, молодёжные», повторяющие тут мантру про > «портянки», неправы именно потому, что в силу неимения опыта не представляют > разнообразия задач, которые могут возникнуть. набор опций в systemd и так > уже большой и неоднозначный (не всегда можно чистой логикой догадаться, что > именно делает опция; а это плохо). дальше так и будут продолжать > добавлять опции и правила для вновь возникающих ситуаций. а в итоге > юнит-файлы, может, и будут маленькими, но количество опций и их взаимосвязей, > которые надо будет знать — огромным. > собственно, лёня к тому и стремится: чтобы юнит-файлы *выглядели* просто, но искусство > правильного их написания было чёрной магией, доступной только тем, кто потратит > кучу времени на изучение опций и правил systemd. в отличие от > «портянок» на sh, которые может и выглядят страшно, но чтобы в > любой из них разобраться (и написать новое), достаточно знаний sh и > coreutils. классическое «обэнтерпрайзивание», во всей красе. > умные молодые и опытные старпёры это видят, и потому воспринимают systemd в > штыки. ну, не только по этой причине, конечно — качество кода > и документации, отсутствие вменяемой архитектуры… но главное — таки усложнение > написания инит-сценариев при кажущемся упрощении. > кстати, в upstart это было решено намного красивей. плюс — upstart не > старался вобрать в себя кучу утилит. и даже — о, кощунство! > — мог работать как обычный service manager, не будучи процессом с > pid 1.
	Введите код, изображенный на картинке: