3 ms·
"Systemd is far more than an init system: it is becoming a secondary operating system kernel, providing a log server, a device manager, a container manager, a l
by irishcoffee 10y ago
"Systemd is far more than an init system: it is becoming a secondary operating system kernel, providing a log server, a device manager, a container manager, a login manager, a DHCP client, a DNS resolver, and an NTP client. These services are largely interdependent and provide non-standard interfaces for other applications to use. This makes any one component of systemd hard to replace, which will prevent more secure alternatives from gaining adoption in the future." [1]
"There will be better alternatives in the future that are more secure than what we have now. But adopting them will only be possible if systemd has not destroyed the modularity and standards-compliance that make innovation possible" [1]
[1] https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_...
- mgbmtl 10y agoIn other words, it's a service management layer for Linux. Before it, init scripts were mostly a bunch of duct tape (start a daemon and hope it doesn't crash). Some could argue it was more flexible, some could argue that it was a mess. In any case, this is off-topic. The article was an interesting example of how upstreaming unit file for systemd means more collaboration between distributions, less wasted work.
- emeraldd 10y agoWhat the parent quoted does not describe "a service management layer for Linux", it describes something that is trying to become all things to all people. Which is exactly what irks a large portion of the linux/unix community (myself included). What does DNS or DHCP have to do with managing "services"?
- lobster_johnson 10y agoSurely those are services in a very classical sense: Processes that provide a service that other apps need, and which need to go up, down or be reconfigured dynamically as a response to other changes in the system (such as networking). So far the way to do that has been pretty ad-hoc, with no formal definition of who has the responsibility for controlling the lifecycle of each component. What systemd brings to the table is a way to formalize those relationships and centralize a lot of common logic related to dependency handling and process control.
- emeraldd 10y agoIf that were all it brought to the table, it would be make for a great addition. It's all the other stuff in that's been rolled into systemd that I have issue with.