Let's start off by looking at what an init system is, how they used to work and what systemd does different before we go into more systemd-specific details.
### 3
system processes that are started include for example FS mounts, network settings, powertop...
system services are long-running processes such as daemons, e.g. SSH, database or web servers, session managers, udev ...
orphans: Process whose parent has finished somehow, gets adopted by init system
-> when a process terminates its parent must call wait() to get its exit() code, if there is no init system adopting orphans the process would become a zombie
### 4
Before systemd there were simple init systems that just did the tasks listed on the previous slide.
Init scripts -> increased greatly in complexity over time, look at incomprehensible skeleton for Debian service init scripts
Runlevels -> things such as single-user mode, full multiuser mode, reboot, halt
Init will run all the scripts, but it will not do much more than print information on success/failure of started scripts
Init scripts run strictly sequential
Init is unaware of inter-service dependencies, expressed through prefixing scripts with numbers etc.
Init will not watch processes after system is booted -> crashing daemons will not automatically restart
### 5
### 6
How systemd came to be
Considering the lack of process monitoring, problematic things about init scripts -> legacy init systems have drawbacks
Apple had already built launchd, a more featured init system that monitored running processes, could automatically restart them and allowed for certain advanced features -> however it is awful to use and wrap your head around
Lennart Poettering of Pulseaudio fame and Kay Sievers decided to implement a new init system to address these problems, while taking certain clues from Apple's design
Systemd criticism comes from many directions and usually focuses on a few points
feature-creep: systemd is absorbing a lot of different services
### 16
explain diagram a bit
### 17
opaque: as a result, systemd has a lot more internal complexity that people can't easily wrap your mind around. However I argue that unless you're using something like suckless' sinit with your own scripts, you probably have no idea what your init does today anyways
unstable: this was definitely true even in the first stable release, with the binary log format getting corrupted for example. I haven't personally experienced any trouble with it recently though.
Another thing is that services start depending on systemd when they shouldn't, a problem for the BSD world (who cares (hey christoph!))
### 18
Despite criticism, systemd was adopted rapidly by large portions of the Linux
Initially in RedHat, because Poettering and co work there and it was clear from the beginning that it would be there
ArchLinux (which I'm using) and a few others followed suit quite quickly
Eventually, the big Debian init system discussion - after a lot of flaming - led to Debian adopting it as well, which had a ripple effect for related distros such as Ubuntu which abandoned upstart for it.