It is so noted in Wikipedia:
systemd is a replacement for the Linux init daemon (either System V or BSD-style). It is intended to provide a better framework for expressing services' dependencies, allow more work to be done in parallel (concurrently) at system startup, and to reduce shell overhead.
Thus far, there seems to be a division in adoption. My Distro, Fuduntu, a fork of Fedora 14, does not employ systemd. I tried to reach +Andrew Wyatt for comment who was not available, but was lucky to find on a Saturday +Shawn W Dunn one of the Fuduntu analysts who gave this comment regarding systemd:
Systemd, whether by design, or circumstan[Edit-- Last minute, +Andrew Wyatt, Fuduntu founder, came through with this comment:
ce, is largely becoming non-option al. Inclusion of core technologi es such as dbus and udev are reducing choice for linux users and developers , rather than expanding them--which is the very antithesis of the idea of Free/Open Source software.
ConsoleKit + UDev + Syslog + DBus + Polkit + Sysinit + this + that. RedHat Enterprise Systemd is the best product we've ever been force fed. We are facing being forced to integrate it at Fuduntu because it's replacing so many core tools now that it's impossible to continue the project without it.
Those "idiots" that don't like binary logs aren't "idiots", some of us actually have some idea of what we are talking about, but what do I know..]
This Wikipedia list shows some that have gone head-long into adoption:
- Uses parallelization, a lot of it
- That means that some daemons are started simultaneously, which means boot time should be faster.
- Has a convenient API
- systemd supports DBus and sockets, so you can easily control it and talk to it from your own code
- The unit syntax is way simpler
- For most cases, all you need to do is start a daemon on boot and kill it on shutdown. Old bash-based init systems need a large piece of boilerplate code to do that, but systemd doesn't. A common unit syntax is also easier to work with for developers, because you only need to support one init system, and not tons of <something> init derivatives, OpenRC and whatnot.
- Integrated logging
- As an init binary, systemd knows more about other processes than, e.g. syslog, so it can log data in a more convenient way. For example, you can get logs for a specific process, unit or target. You can also add additional information to the log if your code uses systemd's library.
- Everything in one package
- Currently, systemd has a lot of features in a single package. QR codes for log verification, a built-in HTTP server, json serialization, you name it. This means a lot of dependencies that are not actually needed. Lennart promised to split those out into separate packages later, but no one knows when 'later' is going to come.
- Not POSIX compliant
- systemd uses things that are exclusive to Linux, so it can't be used on *BSD systems. This makes *BSD people unhappy. If you use Linux, you can probably ignore this.
- It is forced aggressively
- As much as I like it (and yes, I like it), seeing GNOME enforce systemd as a strict dependency is just wrong. Also, see the previous point.
- I'm not sure if his personality is a valid point, but he seems to take a 'I'm right and fuck y'all' stance in some cases, and I don't really like it. Also it's quite common for his code to be really buggy (see early systemd/pulseaudio), but it's not really imporant any more now that a quite large team is working on systemd.
Marching to the beat of a different drum.
As a perhaps relevant side-note, systemd is (imho) the new pulseaudio: it breaks things that were working (which is bad) to bring new features we couldn't get at with the old system (the intentions are good). It is not particularly easy to use, it is easy to get wrong and it is hard to debug when things go wrong. We've experienced all sorts of wonderful things during its short tenure inc triggering kernel panics.
Anecdote time: We use systemd in Plasma Active images (for various reasons I won't get into here). Recently we ran into an inexplicable set of crashes. Turned out one of our systemd service files had an empty line at the end of it, and systemd does not put up with that. It just simply skipped over this offending file and a critical service was not being started. There was nothing in the logs to note this was happening, or any hints in the documentation. We found the "solution" out the hard way, and I'm still baffled that a blank line should even matter.
Even more fun is how tightly welded specific versions of systemd are to specific versions of the kernel .. which on devices can be "fun" as kernel versions that are supported for a given SoC are often (sadly) limited.
The foundational ideas behind systemd, borrowed from another OS, are sound ... but the implementation is simply not there yet and I sense it is overreaching too early in the game in places (e.g. also taking on logging infrastructure).
I suspect it needs a "Colin Guthrie" type figure; Colin imho rescued pulseaudio, moving it out of the 7th level of hell into a slightly chillier level of hell .. pulseaudio is still a cranky bitch at times, but it works tolerably relative to prior incarnations since Colin began working to make it so.
So on the one hand, I'm rooting for systemd. On the other, I wish it would stop sucking .. and I really wish it had a different set of developers working on it.