A while back the Debian dev crew had a BIG, and some say heated, debate over the inclusion of systemd into the Debian distro. Systemd was included and a chuck of the dev crew left Debian and began their own systemd-free distro called Devuan - Debian without systemd.
The story is on "The A Register". The interesting part isn't the article, it is the comments in the comment section, which was heavily trolled by the anti-systemd crowd, who seem to enjoy spitting into the wind and then claiming it's raining.
My opinion:
When I first began using RH 5.0 Linux on May 1st, 1998, it was controlled by a text file, /etc/inittab, i.e., the "initialization table". A table of tupals. It was easy to modify and use, but it was only one of a myriad of configuration text files, one or more for each package the user installed. Each package developer had his own approach to how his package should interact with the rest of the the distro, and they were not always compatible. After several attempts sysinitv became the standard focal point for booting and operating the system and its run levels, and priorities were given to a process during boot by using a two digit number in front of the name of the config file. During boot the files in a particular run level sub-directory were sorted numerically and then executed in sequence. But, there was also /etc/mod.d files that controlled the modules (lsmod, modprobe, etc).
Systemd was designed to bring order to this willy-nilly kludge that developed over the years. Having taken control of PID1 it is slowing gaining control over all of the other configuration processes. It can't happen over night, but it will happen. In the future distros using systemd will have three basic layers: kernel, systemd and the desktop (or cli). Developers making packages for the desktop will have to conform to systemd requirements. KMail, for example, uses as a database backend Akonadi, but Akonadi uses its own config system and controls, not systemd. (akonadicontrol or akonadiconfigure). In the future, if development goes as I suspect it will, users will control Akonadi with systemd-ui from systemsettings5. The sooner those changes happen for the plasma desktop and ALL packages installed on it the better. A thrown-together package by a Qt novice won't cut it for systemd inclusion.
The story is on "The A Register". The interesting part isn't the article, it is the comments in the comment section, which was heavily trolled by the anti-systemd crowd, who seem to enjoy spitting into the wind and then claiming it's raining.
My opinion:
When I first began using RH 5.0 Linux on May 1st, 1998, it was controlled by a text file, /etc/inittab, i.e., the "initialization table". A table of tupals. It was easy to modify and use, but it was only one of a myriad of configuration text files, one or more for each package the user installed. Each package developer had his own approach to how his package should interact with the rest of the the distro, and they were not always compatible. After several attempts sysinitv became the standard focal point for booting and operating the system and its run levels, and priorities were given to a process during boot by using a two digit number in front of the name of the config file. During boot the files in a particular run level sub-directory were sorted numerically and then executed in sequence. But, there was also /etc/mod.d files that controlled the modules (lsmod, modprobe, etc).
Systemd was designed to bring order to this willy-nilly kludge that developed over the years. Having taken control of PID1 it is slowing gaining control over all of the other configuration processes. It can't happen over night, but it will happen. In the future distros using systemd will have three basic layers: kernel, systemd and the desktop (or cli). Developers making packages for the desktop will have to conform to systemd requirements. KMail, for example, uses as a database backend Akonadi, but Akonadi uses its own config system and controls, not systemd. (akonadicontrol or akonadiconfigure). In the future, if development goes as I suspect it will, users will control Akonadi with systemd-ui from systemsettings5. The sooner those changes happen for the plasma desktop and ALL packages installed on it the better. A thrown-together package by a Qt novice won't cut it for systemd inclusion.