Having worked a lot with the different BSD operating systems I am very familiar with the BSD init system and as such I have always considered it far superior to the old sysVinit from Linux.
When the fighting over systemd broke out on the Debian mailing list I was very quick in agreeing with the people who were against Debian implementing systemd as their default init system because the systemd developers went against the Unix philosophy in their design approach.
But after having been faced with a box that had gotten its init system completely messed up, I thought I would try to replace sysVinit with systemd and see how it would handle the mess - just for testing. To my surprise systemd actually managed to get the box booted up and I didn't even have to do any initial troubleshooting.
I cannot remember what the exact problems where or how serious the box was messed up, I just remember that it was bad, but in any case it made me do some research and I ended up liking systemd as a new init system. This was about the time when the Debian developers then decided to make systemd the new default init system.
In the time that has followed I have changed my mind completely. I don't like systemd and I have decided to write this little post about it.
The developers of systemd had some good ideas and systemd does have some merit and it does solve some of the problems sysVinit used to cause, but it is no longer just an init system!
Systemd started out as an alternative to sysVinit, but it is now slowly swallowing up everything else too. It has become a multi purpose tool.
It is argued that systemd is developed into small independent binaries that each are tailor made for a very specific task and as such it follows the Unix philosophy, however that's just not true. Systemd has become a huge suit of tools that all intertwine. They are not independent and it is impossible to switch out one part with another different one, and switching stuff out with other stuff is the very core of the Open Source software community.
If I don't like how a particular piece of software provides a specific service I can remove that piece of software and install another piece of software that provides the same service, but in a different way.
That's why we have so many different applications to choose from in the Open Source community. Each thriving on its own, having a set of developers and followers who like how that particular software works, but others who like another particular software that does the same job but implemented differently.
Multi purpose tools are always bad. If you take a kitchen appliance as an example, a machine that is a blender, a mixer, a food processor, and a bunch of other stuff at the same time, what happens when one part of the machine breaks? Yes, the entire suite of tools stops working.
And this is the exact thing that the Unix philosophy is trying to prevent and which has caused all Unix like systems to thrive for some many years.
Suddenly systemd isn't happy about just being a new init system, it wants to be everything! It also wants to run a NTP service, a DNS service, cron, DHCP, and a lot of other services as well.
If you wan't to develop another NTP server, by all means develop another NTP server, but don't make it a part of the bloody multi purpose tool you're putting together that really should just be an init system!
OpenBSD has already developed a very well working and secure NTP server called OpenNDTD that works on GNU/Linux as well. It's small, clean and very secure and there is no need for it to be a part of any kind of init system!
There's no reason for systemd to fiddle with DNS either. DNS can be handled in so many different ways and we have never had any need for what systemd is trying to do. Yet, the developers of systemd are not happy with just being an init system, so they have added "systemd-resolved" to the suite.
This list of problems "systemd-resolved" is causing is just the tip of the iceberg Sad news today: systemd-resolved to be deployed in Ubuntu 16.10
Some people like how systemd tries to boot stuff in parallel, but having a single startup sequence that's the same every single time a system boots is really a very important issue for an administrator. Sure you can disable certain things by using an "after" directive to systemd, but that's the wrong way to do things. Disabling features isn't the way to do it, it's the other way around, you enable features when you need them, so it shouldn't exist in the first place.
With systemd the boot order is nondeterministic and you won't know what's going to happen the next time a machine boots. This is very bad in servers and embedded devices. How fast a system boots is not important, what's important is that it boots flawlessly every single time.
I do not know what's motivating the systemd developers, but something strange seems to be going on. It's like they don't care about reinventing the wheel over and over again, actually it seems like that's exactly what they want to do! They are re-implementing every possible Linux daemon that exists as a systemd "module" and they are then very adamant about having the rest of the world use the product they release. This behavior is reason enough for caution.
It also turns out that many of the problems they originally addressed regarding init systems were already solved by both OpenRC and the BSD init system.
Personally I am very disappointed with the Debian project regarding systemd. Debian has been my favorite Linux distribution for so many years, but the developers were to fast in implementing systemd as the default init system. The decision divided the community completely and had a huge effect on a very big part of the Open Source community in general.
Debian used to be famous for being very cautious about implementing new software and they should have waited much longer, but not only that, they shouldn't have implemented systemd in the first place when it caused such a huge split in the community. That was enough reason to at least work towards a solution enabling people to choose what init system to use. This is not like the Debian we know.
However, not everything is bad. The resulting split made some former Debian developers fork Debian into a new Linux distribution called Devuan which, even though its current stable version has "only" been released as beta, is a rock solid "Debian" without systemd and without systemd dependencies in packages.
Lots of other great Linux distrobutions now exist without systemd. One such distribution - another favorite of mine - is Alpine Linux which is a really great security oriented Linux distribution based on OpenRC, musl libc and busybox.
Systemd has become one of the best examples of software that Sucks! It has way too many problems in design and implementation and if history has taught us anything it is that projects following the path that systemd has taken eventually end up causing more damage than good. It really resembles the path that Microsoft took with Windows.
But maybe that's the whole point? The fact is that the main developers of systemd are employed by Red Hat, Inc., an American multinational software company providing Open Source software products to enterprise business.
Red Hat creates, maintains, and contributes to many free software projects. It has acquired several proprietary software product codebases through corporate mergers and acquisitions and has released such software under open source licenses. As of March 2016, Red Hat is the second largest corporate contributor to Linux after Intel. -- Wikipedia
Yes, Red Hat contributes back to the Linux community, but maybe a new agenda has emerged? First systemd took over the Fedora distribution, then Lennart Poettering asked the Gnome desktop project to make Gnome dependent upon systemd which they did, and now the systemd project is slowly replacing all major Linux daemons.
As some people has stated, systemd is becoming the Svchost of Linux. Systemd is growing well outside the bounds of enhancing the Linux boot experience. Systemd wants to control all of the fundamental functional aspects of a Linux system from authentication, mounting file system shares, networking,logging, cron, DNS to NTP. It wants to do so as essentially a monolithic entity, a suite of intertwined tools, that obscures what's happening behind the scenes.
This is very bad for Linux!
If you have any comments or corrections feel free to email them to me.