История изменений

Нет, ну я не проверял конечно, но на вменяемость как-то так надеюсь. :-)

Ну и вот. А винишь systemd. Единственная ситуация, когда оно действительно перезагрузит систему вопреки твоему желанию - в случае краша, или если ты в него кинешь SIGKILL. Но, ИМХО, это единственное что имеет смысл сделать, если подох init, не важно systemd это или нет.

Вообще-то значит. Есть общепринятые подходы, и их надо придерживаться. Даже если ты планируешь что-то менять, в нормальном мире оставляют обратную совместимость. Особенно, если это ничему не мешает.

Нет, не значит. Общепринятые подходы способны менятся, если новые из них чем-то лучше старых. К тому же, /etc/fstab не выкинули на мороз, хотя и могли. Так что systemd всё же придерживается старых подходов, хотя и не следуют им в точности. Примонтированный /usr скорее всего является необходимостью для того что бы следовать FHS. Например, в /usr лежат генераторы, которые конвертируют /etc/fstab в unit-файлы, а так же unit-файлы базовой поставки systemd, unit-файлы предоставляемые пакетами. Ключевая особенность - обновлениям системы разрешено удалять или менять эти файлы без боязни поломать то, что руками сконфигурировал администратор. В /etc же лежат именно модификации (Drop-in) этих файлов, либо полные их копии, если администратор решил, что так нужно - что обновления этих файлов в /usr должны быть полностью или частично проигнорированы.

В случае с предшественниками, пардон если не прав, всё было в кучу и скрипты лежали в /etc/init.d. Где им не место, потому что /etc - как раз для всего, что администратору допустимо ломать руками как вздумается, и что следовало бы игнорировать при обновлении.

Так что я бы не сказал, что это ничему не мешало, и что этот подход хуже предыдущего.

Зачем? Есть fstab. Изволь сделать всё, что там написано, а уже потом развлекайся.

Затем что теперь это - общепринятый подход :D

И хотя это стёб, но не без доли истины.

И да, что касается /usr, я уже написал выше. С другими точками монтирования проблем не возникает, насколько мне известно, и указывать что-то дополнительно не приходилось. Но ты можешь и сам придумать ситуацию, где монтирование всего разом - не [самый лучший] вариант. Или когда отвалившееся (Например - сетевое), нужно примонтировать обратно, когда появится такая возможность (Например - восстановится соединение). И пока оно не примонтировалось обратно, хорошо бы было что бы сервис, которому этот маунтпоинт нужен, был остановлен, а затем - перезапустился. Окей, это может быть не нужно, если всё что ты держишь - файлопомойка под диваном или десктоп, но это ни коим образом не значит, что это не нужно вообще никому.

Точно! Особенно screen. Ну и тому подобное. :-)

Ну толсто же! Если твоя сессия померла, но в ней остались процессы, то scope с этими процессами никуда не денется (Если в конфиге logind ты явно не указал, что такие scope нужно убивать). При этом ты в любом случае будешь знать, что «вот эти процессы остались от вот этой сессии» и получишь возможность их разом прибить, если захочешь.

В эту же кучу можно добавить корректно работающий переход из runlevel 2-3 в runlevel 1, когда у тебя гарантированно остантся из живых процессов остаётся только systemd и единственный шелл, потому как systemd ведёт учёт процессов и способен их пришлёпнуть, если попросишь.

Нет, ну я не проверял конечно, но на вменяемость как-то так надеюсь. :-)

Ну и вот. А винишь systemd. Единственная ситуация, когда оно действительно перезагрузит систему вопреки твоему желанию - в случае краша, или если ты в него кинешь SIGKILL. Но, ИМХО, это единственное что имеет смысл сделать, если подох init, не важно systemd это или нет.

Вообще-то значит. Есть общепринятые подходы, и их надо придерживаться. Даже если ты планируешь что-то менять, в нормальном мире оставляют обратную совместимость. Особенно, если это ничему не мешает.

Нет, не значит. Общепринятые подходы способны менятся, если новые из них чем-то лучше старых. К тому же, /etc/fstab не выкинули на мороз, хотя и могли. Так что systemd всё же придерживается старых подходов, хотя и не следуют им в точности. Примонтированный /usr скорее всего является необходимостью для того что бы следовать FHS. Например, в /usr лежат генераторы, которые конвертируют /etc/fstab в unit-файлы, а так же unit-файлы базовой поставки systemd, unit-файлы предоставляемые пакетами. Ключевая особенность - обновлениям системы разрешено удалять или менять эти файлы без боязни поломать то, что руками сконфигурировал администратор. В /etc же лежат именно модификации (Drop-in) этих файлов, либо полные их копии, если администратор решил, что так нужно - что обновления этих файлов в /usr должны быть полностью или частично проигнорированы.

В случае с предшественниками, пардон если не прав, всё было в кучу и скрипты лежали в /etc/init.d. Где им не место, потому что /etc - как раз для всего, что администратору допустимо ломать руками как вздумается, и что следовало бы игнорировать при обновлении.

Так что я бы не сказал, что это ничему не мешало, и что этот подход хуже предыдущего.

Зачем? Есть fstab. Изволь сделать всё, что там написано, а уже потом развлекайся.

Затем что теперь это - общепринятый подход :D

И хотя это стёб, но уже так и есть.

И да, что касается /usr, я уже написал выше. С другими точками монтирования проблем не возникает, насколько мне известно, и указывать что-то дополнительно не приходилось. Но ты можешь и сам придумать ситуацию, где монтирование всего разом - не [самый лучший] вариант. Или когда отвалившееся (Например - сетевое), нужно примонтировать обратно, когда появится такая возможность (Например - восстановится соединение). И пока оно не примонтировалось обратно, хорошо бы было что бы сервис, которому этот маунтпоинт нужен, был остановлен, а затем - перезапустился. Окей, это может быть не нужно, если всё что ты держишь - файлопомойка под диваном или десктоп, но это ни коим образом не значит, что это не нужно вообще никому.

Точно! Особенно screen. Ну и тому подобное. :-)

Ну толсто же! Если твоя сессия померла, но в ней остались процессы, то scope с этими процессами никуда не денется (Если в конфиге logind ты явно не указал, что такие scope нужно убивать). При этом ты в любом случае будешь знать, что «вот эти процессы остались от вот этой сессии» и получишь возможность их разом прибить, если захочешь.

В эту же кучу можно добавить корректно работающий переход из runlevel 2-3 в runlevel 1, когда у тебя гарантированно остантся из живых процессов остаётся только systemd и единственный шелл, потому как systemd ведёт учёт процессов и способен их пришлёпнуть, если попросишь.