Probably everything you want to know is here on the "Debate Init System To Use" pages that the Debian project put together around making the decision of which initsystem to go with. Within that page is a separate link to each of the choices of initsystems.
For a primer on Systemd this page has pretty much everything one would need to know to get started with it, RHEL7: How to get started with Systemd.
Additional resources that I found helpful in getting a better understanding of the 2 primary choices I'd also read the Wikipedia pages on the respective technologies:
The Gentoo project also maintains a nice comparison of some of the key features across the various initsytems:
My take on your questions
Q#1: How does systemd compare to other init systems?
This is a very tough question to address in the space of an SE answer so I'd rather defer to the various sources that I've referenced above. I'll say this though. In reading through much of the articles about
systemd of the alternatives it's trying to address many aspects of what were deficient in previous tools used for starting up services on Linux systems. It has a very well thought out design and is attempting to provide it in a very modular way.
So IMO, I would say that it compares very favorably both in terms of the effort in its design, execution of that design, and the adoption of it by several larger Linux distros.
Q#2: What sets it apart -- what can it do that the other init systems cannot?
The are many things that
sytemd can do that other systems cannot. Probably 3 of its strongest features are:
- Resource Limiting
- Dealing with daemons that fork
On the logging front,
systemd has instituted a new logging system called the "Journal", the service is called
systemd-journald.service. This is its own topic, you can read more about it here in this article titled: Introducing the Journal. Here's an example of a user, "harald", logging in.
MESSAGE=User harald logged in
2 & 3. Resource limiting & daemons that fork
systemd uses a novel approach here of using
cgroups to both contain and resource limit any services that require forking or limiting of access to resources.
Systemd has a very clever solution to the problem of tracking daemons
that fork, which coincidentally happens to handle resource limiting at
the same time. Where Upstart uses ptrace to watch the forking, systemd
runs each daemon in a control group (requires Linux 2.6.24 or newer)
from which it can not escape with any amount of forking. This allows
easy resource limiting , both for forking and non-forking daemons,
since control groups were made for this sort of thing.
Source:Daemon Showdown: Upstart vs. Runit vs. Systemd vs. Circus vs. God
Q#3: Is there anything to lose in switching to it from another init system?
Probably the biggest caveat to switching to systemd over Upstart or sysV init is having to embrace a lot of new complexities. Systemd has a lot of moving parts and is extremely feature rich and with that added capabilities you'll likely be spending a fair amount of time gaining understandings around how it all works.
Q#4: How does administering systemd compare to the others?
As stated in my above answer to Q#3. I'l reiterate here again. Where sysV init was fairly trivial to learn how to manage and navigate in a few hours to days, Upstart will likely take you a week or more to get up to speed, while systemd will likely take you much longer, I'm anticipating taking several weeks to gain enough cursory knowledge about it, where I'll be able to both produce my own
.service files, to stopping/starting services with the same ease that I now enjoy with sysV init.