* Binary log files (WHYYYYY; OTOH you could argue that the only proper place to do logging is to a remote database.)
* Monolithic nature - everything gets shoved in to the daemon, making it harder and more unusual to do things without it.
* Servers - systemd seems to be focused on a desktop lifecycle, where users interactively log in, have settings and log out. It is less clear how secure or well this inter-operates with services running as 'users' for privilege separation. I think this may have recently gotten better.
It stores everything in binary logs, however your old system didn't store it at all. You had a daemon (syslog, rsyslog, etc) that wrote them as plain text. If you start those daemons, you at exactly the same spot as before. Just with an additional copy in a binary log. Which btw, journalctl can do some magical things, and you should take some time to play with it.
systemd is not monolithic, or at the very least its a distributed monolith. The vast majority of services happen in their own userspace process.
Systemd excels with servers, since it standardizes how their execution gets defined. It takes only an added line to spawn them in their own namespaces, set cgroup restrictions, prevent network access, etc. Before hand, doing these things was very hard, so no one did them.
Systemd is a Jenga tower. Yes, there are lots of little pieces, and yes, removing a few won't hurt anything, but it's still fragile, and rather inconsistent. "Parts" like the journal, are a separate executable, but are not managed like other services. It uses a poorly documented ipc interface to talk to the various parts, and the configuration files are a nasty tangle of symlinks and control files stretching across the filesystem. It's just not a very well engineered piece of software.
But honestly, even an extra 30s booting a server is nothing, I don't give a shit about boot times on my servers.. I care about what order my services are started in- my servers should be 100% reproducable otherwise you could have bugs that never get found except in 1% of cases.
And since it's turtles all the way down 1% of one system can be a lot of problems in a 2,000,000 server architecture.
So "Fast boot" in the way systemd achieves it is not beneficial for me.
It was not.
http://0pointer.de/blog/projects/the-biggest-myths.html
Myth: systemd is about speed.
The first points that it details regarding the thesis of systemd is that it is a good init system, and a good init system is fast, and that SysV init is not fast.
The first time it begins talking about things a service management system should be interested in is about half-way through with "Keeping Track of Processes".
It spends roughly the rest of the document on important service management things, but to dismiss the idea that "systemd is about speed" is a myth is too much.
systemd IS about speed of booting -- during the development there were flame graphs showing how doing all this in parallel you could make the system boot really really fast. A lot of time was spent making the boot process with systemd minimal, or speedy.
Personally I'd prefer a less speedy service management system that didn't open listening sockets for my daemons so that it could deal with starting services out-of-order... to make the boot occur in a more parallel fashion... to make the boot faster.
EL6 and its derivatives was upstart, debian and its derivatives was upstart. The vast majority of linux systems were upstart for a long period of time. Other systems did not switch to upstart, because it introduced headache.
Switching init systems requires quite a bit of work. The fact that they all switched to systemd shows that beyond political pressure, they needed a better system.
We exercise our power to decide in cases of overlapping jurisdiction (6.1.2) by asserting that the default init system for Linux architectures in jessie should be
D systemd
U upstart
O openrc
V sysvinit (no change)
F requires further discussion
[...]
Therefore, the resolution reads:
We exercise our power to decide in cases of overlapping jurisdiction
(6.1.2) by asserting that the default init system for Linux
architectures in jessie should be systemd.At no point was it necessary for systemd to actually be better than upstart at being an init system. It just had to be bigger by the time it got to Debian.