systemd has one purpose: to be about system and service management. It will replace everything that deals with services: starting them (whether based on traditi

systemd has one purpose: to be about system and service management. It will replace everything that deals with services: starting them (whether based on traditional init, scheduling, socket activation, or from a desktop user session), logging the stdout/stderr in a consistent and well-defined location, and about giving you flexible tools to manage, debug, and inspect system services. Besides that, yes, it does have a few things (hostnamed, timedated), which are mostly about some POSIX infrastructure that wasn't there already: notification when the system hostname or timedate changes (yes, it happens quite often on desktop systems, due to NTP, user setting, and VPN). They're just utilities they needed along the way, and systemd can be built without them. If the system or service fails to start, instead of hunting around in /var/log/, syslog, dmesg, etc. for anything that looks relevant, you simply use the journal which aggregates most everything. It's already a very good breakthrough. I've debugged countless bad Debian service scripts (which usually comes down to bash's terrible whitespace and quote management), and inserted echo statements into my Arch Linux to debug why it wouldn't boot when I upgraded, hacking out clear statements here and there designed to make the boot pretty. Shell scripts aren't a good solution for robust system and service management.