История изменений
Исправление mxfm, (текущая версия) :
Они просто просто следуют за головными дистрами типа RHEL/Debian/Arch и никакой другой причины в выборе systemd там нет. Это пустой разговор.
Выбор в Debian прекрасно обоснован - там было длительное обсуждение. Если вы не согласны с выбором, то это ваши проблемы. С арчем это делалось решением разработчиков могу привести саммари:
-
it is hotplug capable: systemd assumes that all resources may appear and dissapear at any time. If you plug in your external harddrive after systemd has booted, it will be fsck’ed and mounted correctly. This is unlike initscripts which relies on all disks being enumerated and ready when it starts fsck, and then it relies on fsck of all disks being finished before it starts mounting any of them. Hotplug is important, not only because it is convenient to be able to insert/remove hardware while the system is running, but also because that’s how the linux kernel does boot: every device appears to be «hotplugged» as the kernel becomes aware of it, so with a very fast boot we can no longer assume that all devices are ready and waiting for us when we need them (even if they were plugged in when the computer started). In reality this is often not a problem, but if you ever had your rootfs on an external USB harddrive you might have experienced problems (and as things become faster and faster more problems like this will crop up).
-
we can know the state of the system: systemd keeps track of all daemons, and all processes that are started, and who owns what, and when something fails, etc. Also, using the (awesome) journal all syslog() entries and writes to stdout/stderr by all processes are captured by systemd. These are stored with enough meta-data so that you can very easily retrieve say «all entries from a certain service/binary/pid» or «all entries written by the kernel regarding a given device», etc. In addition to logging this information, and showing it to you, systemd will allow you to specify (easily) what to do in a wide range of possible error-scenarios: «a service shuts down normally/with an error/ on a signa» or «a service has not sent its watchdog signal in the designated time» or «a service has shutdown with an error 10 times in the last half hour». The recent addition of hardware watchdog support also allows you to say «restart the machine if systemd itself is not responding».
В арче, кстати есть пару человек, которые пилят в AUR поддержку openRC, она у них как-то работает. Результат для других - ноль целых ноль десятых.
Исходная версия mxfm, :
Они просто просто следуют за головными дистрами типа RHEL/Debian/Arch и никакой другой причины в выборе systemd там нет. Это пустой разговор.
Выбор в Debian прекрасно обоснован - там было длительное обсуждение. Если вы не согласны с выбором, то это ваши проблемы. С арчем это делалось решением разработчиков могу привести саммари:
-
it is hotplug capable: systemd assumes that all resources may appear and dissapear at any time. If you plug in your external harddrive after systemd has booted, it will be fsck’ed and mounted correctly. This is unlike initscripts which relies on all disks being enumerated and ready when it starts fsck, and then it relies on fsck of all disks being finished before it starts mounting any of them. Hotplug is important, not only because it is convenient to be able to insert/remove hardware while the system is running, but also because that’s how the linux kernel does boot: every device appears to be «hotplugged» as the kernel becomes aware of it, so with a very fast boot we can no longer assume that all devices are ready and waiting for us when we need them (even if they were plugged in when the computer started). In reality this is often not a problem, but if you ever had your rootfs on an external USB harddrive you might have experienced problems (and as things become faster and faster more problems like this will crop up).
-
we can know the state of the system: systemd keeps track of all daemons, and all processes that are started, and who owns what, and when something fails, etc. Also, using the (awesome) journal all syslog() entries and writes to stdout/stderr by all processes are captured by systemd. These are stored with enough meta-data so that you can very easily retrieve say «all entries from a certain service/binary/pid» or «all entries written by the kernel regarding a given device», etc. In addition to logging this information, and showing it to you, systemd will allow you to specify (easily) what to do in a wide range of possible error-scenarios: «a service shuts down normally/with an error/ on a signa» or «a service has not sent its watchdog signal in the designated time» or «a service has shutdown with an error 10 times in the last half hour». The recent addition of hardware watchdog support also allows you to say «restart the machine if systemd itself is not responding».