Переход Ubuntu на Systemd

[Hephaestus]

KDM так же, как и другие сервисы, может быть автоматически перезапущен, если сконфигурирован должным образом.

Ну, если kdm можно, тогда, полагаю, и иксы упавшие поднять можно.

А мне непонятно, почему вместо того чтобы воспользоваться традиционным средством получения документации в UNIX: man-страницами - вы начали со статей, сообщений на форумах и так далее, и, не разобравшись в предмете, пытаетесь спорить о нём. В том же man systemd есть секции Description и Concepts и ссылки на другие man-страницы - начните с них.

Я начал с документа, который переведён на русский. Имею право. Кроме того, этот документ написан самим автором продукта. Была надежда найти там какие-то детали, описанные простым человеческим языком, в противовес сухому техническому языку man-страниц.
Это достаточное основание, чтобы проявить интерес к статье?

Сообщения с форума я приводил с единственной целью: показать, сколь неоднозначное отношение к systemd со стороны сообщества. Нет единогласного приятия, равно как и нет единогласного отторжения. Мнения разделились.
Это означает ровно одно: продукт сомнительного качества, он не хорош и не плох - ни то, ни сё.
Заметьте, кстати, что голоса в техническом совете Debian относительно systemd разделились поровну.
На мой взгляд - это вполне себе иллюстрация к тезису о неоднозначном отношении.

А победил systemd только потому, что один из членов совета использовал право дополнительного голоса. Будь этот человек против systemd - и всё было бы иначе. То есть победа systemd есть не результат технических преимуществ, а всего лишь результат действия административных рычагов.

И спорю я не о systemd как таковом, а о его нужности в том виде, в каком он сейчас.
man-страницы можно посмотреть, но вообще-то мне для этого нужны основания. Потому что я уже потратил время на чтение 98-страничной портянки от автора. Если man написан им же, не думаю, что будет сильно лучше.

То есть я сейчас вынужден знакомиться с продуктом, с документацией, которые лично мне нафиг не сдались.
Но приходится это делать, потому что эта штука не сегодня-завтра свалится мне на голову, а чего от неё ждать и зачем она вообще нужна - совершенно непонятно. Более того, читая документацию, я невольно выискиваю там причины, по которым эта фиговина могла бы быть мне полезной. Я опять же вынужден это делать, потому что сами по себе эти причины никак не обнаруживаются. А без них приговор будет однозначным и безжалостным.
В итоге я вынужден перелопатить кучу инфы по какой-то неведомой приблуде, совершенно мне ненужной.
И меня же ещё упрекают в необъективности и недобросовестном изучении документации? Это типа я ещё и виноват? Да глаза б мои не глядели на эту хреновину.


Впрочем, я не исключаю вариант перехода на другой дистр.

[alv]

А победил systemd только потому, что один из членов совета использовал право дополнительного голоса.

systemd победил только потому, что соучастие в развитии upstart потребовало бы от дебианистов или подписания cla-соглашения, или поддержки собственного форка
первое для них неприемлемо по идеологическим причинам, второе - накладно
это обеспечило два голоса против upstart - реальных, а не председательских
так что ещё раз должен повторить: обсуждать технические достоинства или недостатки systemd бессмысленно
это вопрос политический и идеологический
почему всё время и возникает вновь и вновь
не будь политической стороны - да и хрен бы с ним, с этим systemd'ом: окажется хорош - пользовались бы, окажется дерьмом - упокоился бы в той же братской могиле, что и devfs с HAL'ом

[serzh-z]

упокоился бы в той же братской могиле, что и devfs с HAL'ом

Я что-то пропустил?.. Когда это они умерли?

Идеи, изначально лежавшие в основе devfs, продолжают существовать в udev, пусть и в изменённом виде. HAL перекочевал туда же и в udisks. И вообще это всё, в конце концов, влилось в systemd.

[Hephaestus]

systemd победил только потому, что соучастие в развитии upstart потребовало бы от дебианистов или подписания cla-соглашения, или поддержки собственного форка

Пардон.
Я вот об этом (см. выделение жирным)

На этот раз голосование прошло с перевесом Systemd, что позволяет считать Systemd победителем. За systemd проголосовали Bdale Garbee, который как глава совета обладает правом дополнительного голоса, Don Armstrong, Keith Packard и Russ Allbery. В пользу upstart свой голос отдал Colin Watson. Steve Langasek на первое место поставил продолжение дальнейшего обсуждения, на второе Upstart, на третье systemd. Ian Jackson на первое место поставил продолжение дальнейшего обсуждения, на второе - sysvinit. При этом все три последних участника - высказались в пользу upstart против systemd. Andreas Barth выступил в пользу upstart и на втором месте - дальнейшее обсуждение. Таким образом, перевес сводится только к решающему голосу председателя, являющегося сторонником systemd. Бидейл Гарби применил дополнительный голос и объявил о победе в голосовании systemd.

http://www.opennet.ru/opennews/art.shtml?num=39047

Допускаю, что может иметь место неверный перевод (как уже бывало не раз), но не думаю, что новость переврали настолько, что от первоначального смысла ничего не осталось.

[ArkanJR]

Вот и в состав Ubuntu включили systemd. Возможно, когда-нибудь, он будет и в составе МСВС (всё-таки ВНИИНС сотрудничает с Red Hat; правда вниинсовцам придётся убедить в необходимости systemd чинов в Министерстве Обороны РФ).

[serzh-z]

Сейчас довелось заводить CentOS, в котором нет systemd, и я понял, что уже ощущаю себя некомфортно из-за того, что нужно тратить время на изучение деталей запуска и конфигурирования сервисов другого дистрибутива. Это к слову про пользу унификации.

[Rootlexx]

KDM так же, как и другие сервисы, может быть автоматически перезапущен, если сконфигурирован должным образом.

Ну, если kdm можно, тогда, полагаю, и иксы упавшие поднять можно.

Можно, конечно, если они будут запускаться как сервис systemd и управляться им.

А мне непонятно, почему вместо того чтобы воспользоваться традиционным средством получения документации в UNIX: man-страницами - вы начали со статей, сообщений на форумах и так далее, и, не разобравшись в предмете, пытаетесь спорить о нём. В том же man systemd есть секции Description и Concepts и ссылки на другие man-страницы - начните с них.

Я начал с документа, который переведён на русский. Имею право. Кроме того, этот документ написан самим автором продукта. Была надежда найти там какие-то детали, описанные простым человеческим языком, в противовес сухому техническому языку man-страниц.
Это достаточное основание, чтобы проявить интерес к статье?

Если вашей целью было получить обзорное представление о systemd, написанное "простым человеческим языком", то, действительно, статья является разумным выбором. Но странно ожидать от обзорной статьи полного и подробного описания всех особенностей и возможностей systemd. Статьи не заменяют документацию, поэтому то, что вы написали:

Да вот неизвестно, подойдет или нет.
Статья Леннарта не затрагивает подобные случаи, стало быть, всегда есть вариант "Вам этого не обещали".

- неверно. Для получения надёжной информации следует пользоваться референсной документацией, а не статьями.

Сообщения с форума я приводил с единственной целью: показать, сколь неоднозначное отношение к systemd со стороны сообщества. Нет единогласного приятия, равно как и нет единогласного отторжения. Мнения разделились.
Это означает ровно одно: продукт сомнительного качества, он не хорош и не плох - ни то, ни сё.

Это верно лишь в предположении, что все мнения являются обоснованными, а не основанными на слухах, эмоциях, теориях заговора или личности Леннарта.

Заметьте, кстати, что голоса в техническом совете Debian относительно systemd разделились поровну.
На мой взгляд - это вполне себе иллюстрация к тезису о неоднозначном отношении.

Вы неправы. Голосование "за Upstart" не означает голосование "против systemd". Практически все, выступавшие за Upstart, ставили systemd на второе место, и наоборот. Так что вопрос был не в том, что хорошо, а что плохо, а в том, какая из двух приведённых систем лучше.
sysvinit, замечу, практически все ставили на последнее место.

А победил systemd только потому, что один из членов совета использовал право дополнительного голоса. Будь этот человек против systemd - и всё было бы иначе. То есть победа systemd есть не результат технических преимуществ, а всего лишь результат действия административных рычагов.

Победа над Upstart.

То есть я сейчас вынужден знакомиться с продуктом, с документацией, которые лично мне нафиг не сдались.
Но приходится это делать, потому что эта штука не сегодня-завтра свалится мне на голову, а чего от неё ждать и зачем она вообще нужна - совершенно непонятно.

По схожим причинам и я начал изучать кандидатов на пост системы инициализации по умолчанию.

Более того, читая документацию, я невольно выискиваю там причины, по которым эта фиговина могла бы быть мне полезной. Я опять же вынужден это делать, потому что сами по себе эти причины никак не обнаруживаются. А без них приговор будет однозначным и безжалостным.

А вот здесь мы с вами расходимся.
(Сейчас будет разрыв шаблона.)
Меня лично вполне устраивает sysvinit, я лично вполне свободно ориентируюсь в shell-скриптах, и для меня лично systemd не принесёт каких-нибудь критически важных преимуществ. Просто потому, что я лично большей частью функциональности systemd (пока) не пользуюсь. (Хотя некоторое повышение удобства приветствую.)
Но в то же время я понимаю причины, почему systemd пользуется популярностью, понимаю причины перехода на него Debian, и при условии небольших затрат миграции не испытываю по этому поводу отрицательных эмоций. Более того, я не считаю, что вопреки мнению значительного количества разработчиков Debian должен оставаться на sysvinit лишь потому, что меня лично он полностью устраивает.
В Debian есть процедура принятия решений, которая позволяет в итоге направить проект туда, куда хочет большинство его разработчиков. Поэтому всё обстоит довольно просто: будет много недовольных - будет GR, не будет - значит, всех принятое решение устраивает. Несогласные могут принять это решение или сменить дистрибутив.

[alv]

может иметь место неверный перевод

да нет, всё правильно, я про причины (ещё во время второго тура)
Паккард привёл вышеуказанный голос - и тем склонил против upstart двоих, можно найти кого именно, но лень
во втором туре и пункты были другие, и расклад

[alv]

Идеи, изначально лежавшие в основе devfs, продолжают существовать в udev

идеи как раз прямо противоположные, насколько я понимаю: файловая система в кернел-лэнде и сервис в юзерлэнде
если, конечно, не считать главной идеей сделайте мне п...олучше
между прочим, во Free devfs работает без особых изменений вот уже скоро 12 лет - и вреда ни малейшего
потому как а) не спешили прикручивать, и б) не торопились скальпелем отрезать по самые... уши

Вот и в состав Ubuntu включили systemd

тут в Джуйке было высказано предположение, что в Ubuntu systemd допилят до юзабельного состояния, и тогда им можно будет пользоваться

Это к слову про пользу унификации.

Про это хорошо сказал лет 20 назад Джим Сеймур, правда, по другому поводу: у моей магнитолы и стиральной машины разные ручки управления, и меня это почему-то не напрягает
(по памяти, в сети этого номера нет)

[drBatty]

и я понял, что уже ощущаю себя некомфортно из-за того, что нужно тратить время на изучение деталей запуска и конфигурирования сервисов другого дистрибутива.

я уже привык к этому.

[drBatty]

Шутить изволите?

если-бы…

Xorg пишет в собственный текстовый файл журнала.
Журнал выводится на экран в текстовом формате, а в каком виде это всё лежит на диске, в данном случае не важно.

1. это радует
2. нет, важно, ибо часто не подымающиеся иксы оканчиваются ПОЛНЫМ зависанием.

Нет, это ответ на ваши попытки чрезмерно обобщить область применения systemd, взвалив на него то, для чего он не предназначен.

ИМХО инит обязан запускать Xorg, разве нет?

Интересно, как моё "причина данной проблемы не известна" у вас превратилось в "АДМИНИСТРАТОР НЕ СМОЖЕТ ВЫЯСНИТЬ ПРИЧИНУ ПРОБЛЕМЫ!!!". Вы журналистом, случайно, не работали

Бох миловал, не работал журнализдом (:
А превращение не моё, да, оно конечно было-бы демагогией, согласен. Если-бы я это придумал. Но я просто наблюдаю пока. В продакшен ваш systemd даже сама RH не пихает. Может и не будет пихать, кто её знает?

[serzh-z]

идеи как раз прямо противоположные, насколько я понимаю: файловая система в кернел-лэнде и сервис в юзерлэнде

Идея - сделать содержимое /dev динамическим.

Про это хорошо сказал лет 20 назад Джим Сеймур, правда, по другому поводу: у моей магнитолы и стиральной машины разные ручки управления, и меня это почему-то не напрягает

Джим явно был техзадротом. При применении Linux в промышленности, день изучения "нового" дистрибутива - это минус к экономике компании.

[alv]

идеи как раз прямо противоположные, насколько я понимаю: файловая система в кернел-лэнде и сервис в юзерлэнде

Идея - сделать содержимое /dev динамическим.

В devfs это сделали. И это работало хорошо. В Solaris'е и FreeBSD, и в DragonFly сейчас не хуже.
Так почему же это было так хреново в Linux'е?
Может, потому что чукча-хирург рано за скальпель схватился?

Про это хорошо сказал лет 20 назад Джим Сеймур, правда, по другому поводу: у моей магнитолы и стиральной машины разные ручки управления, и меня это почему-то не напрягает

Джим явно был техзадротом. При применении Linux в промышленности, день изучения "нового" дистрибутива - это минус к экономике компании.

Джим ни в коем случае не техзадрот, а прожжённый тех-журналюга
И имел ввиду другое: просто попробуйте представить, что было бы, если бы телевизор и холодильник имели бы одинаковые средства управления?
Так и с дистрибутивами.
Не говоря уж о том, что одинаковые линуксы - это просто скучно.
Одна одинаковая ОС у нас уже есть.
И как бы Линукс не стандартизировали - конкуренции с ней он не выдержит никогда.
В частности, потому, что пока всё устаканится с systemd'ом, придумают supersystemd
и всё начнётся сначала

PS кстати, а кто заставляет Вас в промышленности для той же задачи применять другой дистрибутив?
Не паршивость ли организации процесса?

[Hephaestus]

Но в то же время я понимаю причины, почему systemd пользуется популярностью, понимаю причины перехода на него Debian, и при условии небольших затрат миграции

Во-первых, насчет затрат миграции - это ещё вопрос.
А во-вторых, я уже говорил: Всё это очень здорово, но только при условии, что systemd со временем не станет хуже. А у него есть все шансы стать хуже, может быть даже хуже, чем сейчас sysvinit. Просто в силу своей монструозности и стремления объять необъятное. Пока ещё это не критично. Но критическая масса наберётся очень быстро.

Более того, я не считаю, что вопреки мнению значительного количества разработчиков Debian должен оставаться на sysvinit лишь потому, что меня лично он полностью устраивает.

Дело не в том, что sysvinit устраивает лично Вас, меня или ещё кого-то.
Дело в том, что sysvinit - проверенная рабочая лошадка, все слабые места её давно известны и никаких сюрпризов от неё ждать не приходится - работает исправно много лет.
С чего вдруг потребовалось её заменить, да ещё на такую вещь как systemd, которая ещё неизвестно, как будет работать - это явно лежит за пределами технических вопросов - тут alv прав.
Это очень странное решение, с учётом принципа KISS, который, вроде никто не отменял.

Да, я знаю, что многие принципы unix нарушаются сплошь и рядом, но принимать решение, заведомо не соответствующее основным принципам - это уж слишком.

Про HAL я уже говорил, со временем он стал давать сбои по непонятным причинам.
Вы ещё вспомните мои слова: systemd ждет та же участь. Бинарный формат логов вкупе с сишным кодом (который нельзя поправить без дополнительных телодвижений), а также стремление рулить всем и вся - вот эти факторы сделают своё дело. Монстр рухнет под собственной тяжестью.
Для полного комплекта там только большой красной (зеленой) кнопки не хватает.

[serzh-z]

Не говоря уж о том, что одинаковые линуксы - это просто скучно.

Это скучно только если это хобби.

И как бы Линукс не стандартизировали - конкуренции с ней он не выдержит никогда.

Эту мегаОС уже сложно назвать "просто Linux", слишком уж там много Java поверх. Да и стандарты Linux на неё всё ещё влияют.

Не паршивость ли организации процесса?

Возможно, но это не моя забота и не должно ею быть. Разделение труда - это отличный двигатель прогресса.

А supersystemd, уверен, будет всё так же использовать идеи systemd/upstart/openrc/sysv/bsd, Танненберга и Ритчи. Обожаю фразу Шаттлворта про возможность встать на плечи прежних гениальных парней...

[alv]

Не говоря уж о том, что одинаковые линуксы - это просто скучно.

Это скучно только если это хобби.

Вы полагаете, что работа и должна быть скучна?
А оттягиваться надо во внеслужебное время?

И как бы Линукс не стандартизировали - конкуренции с ней он не выдержит никогда.

Эту мегаОС уже сложно назвать "просто Linux", слишком уж там много Java поверх. Да и стандарты Linux на неё всё ещё влияют.

До сих пор все стандарты Linux были а) плохи и б) создавались только для того, чтобы нарушаться.
Этот постигнет та же судьба.

Не паршивость ли организации процесса?

Возможно, но это не моя забота и не должно ею быть. Разделение труда - это отличный двигатель прогресса.

Тоже характерный подход. И разделение труда тут ни при чём.

А supersystemd, уверен, будет всё так же использовать идеи systemd/upstart/openrc/sysv/bsd, Танненберга и Ритчи. Обожаю фразу Шаттлворта про возможность встать на плечи прежних гениальных парней...

Сказал её Ньютон. А процитировал Торвальдс, а вовсе не Шаттлворт.

[Red Gremlin]

И имел ввиду другое: просто попробуйте представить, что было бы, если бы телевизор и холодильник имели бы одинаковые средства управления?

Был бы 2014 год.
Телевизор
Холодильник

[Red Gremlin]

Это очень странное решение, с учётом принципа KISS, который, вроде никто не отменял.

Постоянно замечаю, что очень и очень многие воспринимают принцип KISS не в его оригинальном значении, а в значении, похожем на бритву Оккама — "делать надо проще, а проще — значит вместо создания новых сущностей пользоваться существующими, если это возможно". Но оригинальный KISS к такой трактовке не имеет никакого отношения. В рамках управления сервисами systemd куда больший KISS, чем sysvinit.

Бинарный формат логов

И что? В системе и кроме логов есть кучи бинарных баз данных, чьё содержимое порой куда как интересней логов. И ничего, не вижу орд хулителей с воплями "а как же мы посмотрим в случае чего????".

вкупе с сишным кодом (который нельзя поправить без дополнительных телодвижений)

Можно подумать, ты код баша или демона можешь поправить без дополнительных телодвижений. Особенно в типовом варианте, когда просто стартуется внешний демон. Для примера возьмём старый добрый smartd

Код:

#!/bin/sh # chkconfig: 2345 40 40 # description: Self Monitoring and Reporting Technology (SMART) Daemon # processname: smartd ### BEGIN INIT INFO # Provides: smartd # Required-Start: $syslog # X-UnitedLinux-Should-Start: $sendmail # Should-Start: $sendmail # Required-Stop: $syslog # Default-Start: 2 3 5 # Default-Stop: # Short-Description: Monitors disk and tape health via S.M.A.R.T. # Description: Start S.M.A.R.T. disk and tape monitor. ### END INIT INFO # Source function library . /etc/rc.d/init.d/functions # Source configuration file [ -r /etc/sysconfig/smartd ] && . /etc/sysconfig/smartd RETVAL=0 prog=smartd case "$1" in start) gprintf "Starting %s: " "$prog" daemon /usr/sbin/smartd $SMARTD_OPTIONS RETVAL=$? echo [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog ;; stop) gprintf "Shutting down %s: " "$prog" killproc $prog RETVAL=$? echo [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog ;; reload) gprintf "Reloading %s daemon configuration: " "$prog" killproc $prog -HUP RETVAL=$? echo ;; report) gprintf "Checking SMART devices now: " killproc $prog -USR1 RETVAL=$? echo ;; restart) $0 stop $0 start ;; status) status $prog ;; *) gprintf "Usage: %s {start|stop|reload|report|restart|status}\n" "$0" RETVAL=1 ;; esac exit $RETVAL

Код: Выделить всё

[Unit]
Description=Self Monitoring and Reporting Technology (SMART) Daemon
After=syslog.target

[Service]
EnvironmentFile=/etc/sysconfig/smartd
ExecStart=/usr/sbin/smartd -n $smartd_opts

[Install]
WantedBy=multi-user.target

В каком варианте используется больше сишного кода советую подумать на досуге.

[landgraf]

И имел ввиду другое: просто попробуйте представить, что было бы, если бы телевизор и холодильник имели бы одинаковые средства управления?

Был бы 2014 год.
Телевизор
Холодильник

Только хотел высказаться про тыкательные интерфейсы,
а еще добавить сюда интерфейс дроидофона и Tesla S -> все плюс-минус одинаковое

[Rootlexx]

нет, важно, ибо часто не подымающиеся иксы оканчиваются ПОЛНЫМ зависанием.

Тогда это баг. Полного зависания от программы в пространстве пользователя быть не должно. И если такое зависание случилось, тут уже формат хранения журнала не имеет значения, ибо система не работает. При загрузке же в rescue.target (аналог single), опять же, никакой разницы нет.
Бинарный формат журнала может стать проблемой лишь в случае, если вы хотите прочитать журнал в другой системе, в которой нет journalctl. Согласен, что это снижает гибкость; тем не менее, для выбора такого формата были свои причины.

ИМХО инит обязан запускать Xorg, разве нет?

Если "запускать" понимать транзитивно, как вы предлагаете, то "обязан". Но я не согласен с таким определением.
Кстати, мне удалось настроить KDM на использование предварительно запущенного X-сервера, так что конфигурация, когда X-сервер и KDM запускаются по отдельности системой инициализации, вполне реализуема.

В продакшен ваш systemd даже сама RH не пихает. Может и не будет пихать, кто её знает?

Ну, судя по [1], [2], [3]... - вряд ли.

[Rootlexx]

Во-первых, насчет затрат миграции - это ещё вопрос.

Уже довольно давно можно просто установить systemd в Debian рядом с sysvinit и выбирать при загрузке передачей параметра ядру init=/bin/systemd (по умолчанию остаётся sysvinit, который продолжает работать как ни в чём не бывало). У меня всё просто заработало, без вмешательств с моей стороны. Можете сами попробовать.

А во-вторых, я уже говорил: Всё это очень здорово, но только при условии, что systemd со временем не станет хуже. А у него есть все шансы стать хуже, может быть даже хуже, чем сейчас sysvinit. Просто в силу своей монструозности и стремления объять необъятное. Пока ещё это не критично. Но критическая масса наберётся очень быстро.

Вот как станет, тогда и поговорим. Про ядро такое уже много лет как кричат, а оно, собака, всё работает и работает и под собственной тяжестью рушиться не собирается.

Дело в том, что sysvinit - проверенная рабочая лошадка, все слабые места её давно известны и никаких сюрпризов от неё ждать не приходится - работает исправно много лет.
С чего вдруг потребовалось её заменить, да ещё на такую вещь как systemd, которая ещё неизвестно, как будет работать

Если использовать единственный критерий "работает исправно много лет", то ни одно новое решение на замену существующего никогда не появится, ибо у него срок существования невелик по определению. Нужно подходить к вопросу комплексно, и проверенность временем - лишь один из критериев.

Да, я знаю, что многие принципы unix нарушаются сплошь и рядом, но принимать решение, заведомо не соответствующее основным принципам - это уж слишком.

Насчёт этого я уже высказывался, но повторюсь:

• Я считаю, что принципы UNIX полностью распространяются лишь на пользовательские программы, которые имеет смысл комбинировать, а не на системные.
• Я не считаю, что некие принципы являются этакой священной коровой, в догматическую угоду которым следует хоронить любые не соответствующие им решения, даже если они лучше существующих и решают реальные проблемы.
• Тем не менее, systemd во многом соответствует этим принципам: несвязанная функциональность разнесена по отдельным исполняемым модулям; для контроля используются разные утилиты (systemctl, journalctl, timedatectl и так далее), выводящие в текстовом формате; systemd делает одну вещь: управляет сервисами .

Последнее, конечно, несколько провокационно, но иначе и быть не могло: классические принципы UNIX сформулированы настолько размыто, что каждый понимает их по-своему. Например, пользователи Slackware наверняка скажут, что dpkg нарушает принципы UNIX, ибо не только устанавливает, но и удаляет пакеты, а значит, делает больше одной вещи. С другой стороны, можно сказать, что dpkg делает одну вещь: управляет пакетами, а принципы UNIX заключаются в том, что в нём нет текстового редактора. Но даже если бы был, можно было бы сказать, что dpkg занимается обработкой данных, и опять признать его соответствующим принципам UNIX.
Такие нечёткие определения опираются на здравый смысл (common sense), который, тем не менее, у каждого свой, отчего возникает большой простор для споров и демагогии. Поэтому использовать их в качестве аргумента в дискуссии бессмысленно.

[Bizdelnick]

И что? В системе и кроме логов есть кучи бинарных баз данных, чьё содержимое порой куда как интересней логов. И ничего, не вижу орд хулителей с воплями "а как же мы посмотрим в случае чего????".

"В случае чего" надо смотреть не что-то, а логи. А без случая логи не особо интересны, в отличие от остального.

[Hephaestus]

Постоянно замечаю, что очень и очень многие воспринимают принцип KISS не в его оригинальном значении, а в значении, похожем на бритву Оккама — "делать надо проще, а проще — значит вместо создания новых сущностей пользоваться существующими, если это возможно".

А что такое? Keep It Simple Stupid - "сохрани это простым, тупица". Я это понимаю как "не усложняй" или "делай проще, не плоди лишних сущностей" и бритва Оккама тут как нельзя более кстати.
Между прочим, в русскоязычной вики статьи про KISS и бритву Оккама имеют взаимные перекрестные ссылки.

И что? В системе и кроме логов есть кучи бинарных баз данных, чьё содержимое порой куда как интересней логов.

В отличие от баз данных, логи предназначены для чтения человеком. Значит, эта информация должна быть в текстовом формате. Самый простой вариант - когда информация хранится в текстовом формате изначально. Любой другой вариант предполагает дополнительную операцию: преобразование бинарного формата в текстовый, то есть как минимум не проще, чем вариант с текстом.

А вообще, назрел вопрос. Не холивару ради, а понимания для.
Вот скажем есть сервисы, имеющие текстовые логи. Случается авария, система рушится. Грузимся с Live-диска, подмонтируем файловую систему рухнувшей ОС, смотрим логи, анализируем ситуацию, принимаем решение.
В случае текстового формата нет никаких проблем - текстовый файл лога и любой текстовый редактор, или даже cat+grep. В случае бинарного формата systemd... Как посмотреть? Даже будь на Live-диске systemd, он умеет открывать логи из другой системы? Я не знаю. А вы знаете? А если на live-диске нету systemd? Всё, приплыли?
А вот текстовый формат можно прочитать всегда, подойдет хоть cat, хоть редактор (практически любой), хоть grep.

Можно подумать, ты код баша или демона можешь поправить без дополнительных телодвижений.

А в чем проблема? shell-скрипты я открывал и исправлял, это обычный текст. Исправлять не так часто требовалось, всего пару раз, но исправлял же. В systemd сервис-файлы кода не содержат, только настройки. Стало быть, код где-то в другом месте. В модулях. А их уже так просто не исправишь.

[Hephaestus]

Уже довольно давно можно просто установить systemd в Debian рядом с sysvinit

Это ещё не вся миграция. Леннарт в статье пишет, что не всякий скрипт можно превратить в сервис-файл. И не все программы готовы для работы с systemd. Не зря же он просит поддержки у дистров и разработчиков.

Вот как станет, тогда и поговорим.

Непременно поговорим.

Про ядро такое уже много лет как кричат, а оно, собака, всё работает и работает и под собственной тяжестью рушиться не собирается.

Вот ядро-то как раз подвергается изменениям: выпиливают поддержку старых железок и архитектур.
Так что там худо-бедно, но за балансом следят. Кроме того, в ядро никогда не пытались запихнуть всё сразу. В отличие от.

Если использовать единственный критерий "работает исправно много лет", то ни одно новое решение на замену существующего никогда не появится

И правильно. Новое решение нужно тогда, когда старое перестаёт работать.
Это Windows можно выпускать раз в год, дабы продавать побольше да подороже.

Я считаю, что принципы UNIX полностью распространяются лишь на пользовательские программы, которые имеет смысл комбинировать, а не на системные.

А системные чем хуже?

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

Принципы для того и нужны, чтобы им следовать. И выработаны они, исходя из практических соображений. То есть для них имеются основания. В этом отличие принципов от догмы и всяких священных коров. На конкретный набор принципов можно и наплевать, но тогда будут использованы другие принципы.
В результате в одной системе будет винегрет из разных принципов.
Например в пакетном дистре Debian можно понаставить программ с помощью make install.
Ведь пакетный менеджер - это не священная корова, правда? Стало быть, можно? Можно. Но не нужно.
И это не догма, а именно принцип, основанный на практических соображениях.

Тем не менее, systemd во многом соответствует этим принципам: несвязанная функциональность разнесена по отдельным исполняемым модулям; для контроля используются разные утилиты (systemctl, journalctl, timedatectl и так далее), выводящие в текстовом формате

Ой, только не говорите мне, что "разные утилиты (systemctl, journalctl, timedatectl и так далее)" - это проще, чем cat+grep. Не поверю, что шуруповёрт с набором насадок проще обычной отвертки. Хотя бы потому, что пользование шуруповёртом требует изучения инструкции. А вот инструкцию к обычной отвертке я никогда не видел.

systemd делает одну вещь: управляет сервисами

"Управляет сервисами" - это целый комплекс задач.
Эдак можно и про Windows сказать, что она соответствует unix-принципам: Windows делает одну вещь: управляет ЭВМ.

[serzh-z]

Сказал её Ньютон. А процитировал Торвальдс, а вовсе не Шаттлворт.

Дословно: "Свободное ПО позволяет любому умному парню в мире встать на плечи предыдущих умных парней и сплясать свой маленький танец инновации." - я ещё помню интервью с Шаттлвортом в LXF.

[den_beckett]

В рамках управления сервисами systemd куда больший KISS, чем sysvinit.

Ну да, в sisvinit генератора QR-кодов и http-сервера нету - какой же это KISS?

тем не менее, для выбора такого формата были свои причины.

Огласите весь список, пожалуйста!

[*]Я считаю, что принципы UNIX полностью распространяются лишь на пользовательские программы, которые имеет смысл комбинировать, а не на системные.

А воть coreutils - пользовательские или системные?

[*]Тем не менее, systemd во многом соответствует этим принципам: несвязанная функциональность разнесена по отдельным исполняемым модулям

Как мне установить systemd без journal? Что, нельзя? И в каком месте он тогда "отдельный"?

Последнее, конечно, несколько провокационно

Это толсто даже для вас.

но иначе и быть не могло: классические принципы UNIX сформулированы настолько размыто, что каждый понимает их по-своему.

Что размытого в "не усложняй", "используй вывод одной утилиты на входе другой", "храни вывод в текстовом формате"?
ИМХО, они ничуть не более размыты, чем "не убий", "не укради", что не мешает, впрочем, всяким иезуитам толковать их ну очень отлично от первоначального значения, вложенного аффтаром.

[drBatty]

Например, пользователи Slackware наверняка скажут, что dpkg нарушает принципы UNIX, ибо не только устанавливает, но и удаляет пакеты, а значит, делает больше одной вещи.

скорее проблема dpkg(как и systemd) не в том, что он ещё и удаляет, а в другом: кроме своей основной задачи, скажем "поставить dolphin", dpkg ставит ещё и всё KDE, и мало того — удаляет какой-то другой DE, который конфликтует с данной версией KDE.

Только не нужно сейчас вдаваться в детали, я говорю о принципе, задача "поставить dolphin" -- это одна задача, а "сменить DE" — совсем другая. И если "поставить dolphin" невозможно сделать с текущим DE, то dpkg так и должен написать "невозможно".

Вот у systemd та же проблема: он пытается быть умнее администратора. Это путь в никуда, хотя в теории это "удобно". На практике это must die.

Ладно, я не буду встревать в вашу содержательную дискуссию, вам и без меня хорошо. У меня пока недостаточно фактов.

[drBatty]

Даже будь на Live-диске systemd, он умеет открывать логи из другой системы?

нет, и это фича, а не баг. Лог зашифрован, причём не просто своим уникальным ключом, а ещё и неким начальным состоянием, т.е. распутать его можно только имея ВЕСЬ, а не обрывок. Посмотреть администратору лог своей системы очень просто. Посмотреть злоумышленнику — невозможно. QR code как раз и нужен для того, что-бы отличить локального администратора(который может его сфоткать) от врага.

Как я понял Леннарта -- это так работает. Поправьте, в чём я не прав.

[Hephaestus]

нет, и это фича, а не баг. Лог зашифрован, причём не просто своим уникальным ключом, а ещё и неким начальным состоянием, т.е. распутать его можно только имея ВЕСЬ, а не обрывок.

То есть для возможности посмотреть лог нужно, чтобы всё работало?
Мда... Большая часть логов нужна именно тогда, когда что-то не работает. А когда оно не работает, то нормальная загрузка системы вообще и самого systemd, в частности, не гарантирована. И тогда что?

Вообще-то для таких случаев есть LivdCD/LiveDVD/LiveUsb.
В схеме с systemd возможность восстановительных работ не предусмотрена?
В печку.

Посмотреть администратору лог своей системы очень просто.

Да уж. Особенно в случае аварии с Live-диском в руках.

[drBatty]

То есть для возможности посмотреть лог нужно, чтобы всё работало?

ну прямо об этом Леннарт конечно не говорит, это я додумал на основе его описания. Что лично меня не обрадовало. А его соратники в рунете только орут и топают ножками, и осыпают меня проклятьями. Наверное я прав…

По словам Леннартов это всё сделано для безопасности, т.е. сервер пишет лог в удалённый сервер в зашифрованном виде. Лично мне тут непонятно, зачем вообще ключи для расшифрования хранить на ЭТОМ сервере? Ведь есть асимметричное шифрование, и ЭТОТ сервер вполне может шифровать свой лог чужим ключом. Задача подмены удалённого лога легко решается append only хранилищем. А Леннарт со своим братом пытаются придумать какую-то ☣, что-бы защитить лог от подчисток прямо на ЭТОМ сервере. ИМХО это возможно лишь через http://en.wikipedia.org/wiki/Security_through_obscurity (рус: http://ru.wikipedia.org/wiki/%D0%91%D0%B5%...%81%D1%82%D1%8C ). За тем и нужны разные костыли вроде QR code, для заворачивания тайных непонятных(для САМОГО локального админа) ключей, что-бы он их переносил НЕ ПОНИМАЯ, что он собственно делает.

Возможно это оправданно для систем, рядом с которыми дрессированная обезьяна, которая может сфоткать QR, и сбросить его на соседнюю систему.