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.
systemd components

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:
- Logging
- Resource Limiting
- Dealing with daemons that fork
1. logging
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.
_SERVICE=systemd-logind.service
MESSAGE=User harald logged in
MESSAGE_ID=422bc3d271414bc8bc9570f222f24a9
_EXE=/lib/systemd/systemd-logind
_COMM=systemd-logind
_CMDLINE=/lib/systemd/systemd-logind
_PID=4711
_UID=0
_GID=0
_SYSTEMD_CGROUP=/system/systemd-logind.service
_CGROUPS=cpu:/system/systemd-logind.service
PRIORITY=6
_BOOT_ID=422bc3d271414bc8bc95870f222f24a9
_MACHINE_ID=c686f3b205dd48e0b43ceb6eda479721
_HOSTNAME=waldi
LOGIN_USER=500
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.
excerpt
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.
References
systemd
doesn't now include a web server nor will it do so ever, nor is reading QR anywere in the roadmap. Please go check what it is all about, consider that as we speak all important distributions (except Ubuntu for now) use it as default (open source folks tend to be rabidly independent, no "pressure" will get them to do this if they don't believe it's the best alternative).systemd
. Makes me wonder when the hellPy3k
will become the default python interpreter in distros.