Systemd is often demonized and the basis of many arguments against bloat. While I do prefer a minimalist system and often look for functional alternatives to heavier software that follow the GNU Philosophy. I would like to take a moment to open a dialog about Systemd.

What is Systemd?

Systemd is a software suite that provides a collection of system components for the GNU/Linux operating system. The primary purpose of Systemd is to script and organize boot functions for GNU/Linux using a system and service manager, which is an init system. An init is a initialization program, which is the first process started during booting of the computer system, the Init process is directly started by the kernel, in this case, the Linux kernel. And will continue running until the computer is shut down. Systemd used this init system to bootstrap user space and manage user processes. It also provides replacements for various daemons and utilities, including device management, login management, network connection management, and event logging. Systemd is often criticized with arguments that Systemd suffers from function creep and being bloated. Systemd also has faced criticism over other software adding dependencies on Systemd, such as the GNOME desktop, which can cause a compatibility issue with other GNU/Linux and Unix like systems. But regardless of these issues, as of right now, the majority of GNU/Linux distributions have adopted Systemd as their primary init system, having replaced other systems such as SystemV and BSD init systems.

The Good and The Bad

To start Systemd does follow the GNU Philosophy in its current form. However it does not abide by the Unix Philosophy. Systemd has heavily diverged from the Unix Philosophy by feature creeping itself into being a near full operating system, minus the user space. But this is just a meme, and many would take this opportunity to start a rant about why Systemd is bad without looking at why it was adopted by many major GNU/Linux distributions in the first place. For many years GNU/Linux was content with other Init Systems. But these became outdated when add on service managers came along like the chkconfig commands. Which by design intended to make service management easier for systems and the users, but has the side effect of causing more system clutter and resource use. This gave developers more freedom to add interesting features and interactions in these new service managers. So developers do what developers do and began to test and play around with key Linux subsystems. This however did become an issue for many because if the user did not like a particular bit of software there were alternatives, but essential subsystems are also essential to the kernel and all manner of of other scripts and dependencies, to which the user could not change. Causing the user to then be stuck with whatever change took place. But these changes were needed at the time due to the following complications caused by previous init systems being outdated...

The init process has a very limited role. init does little more than starting according to the configuration read from a file, which in turn will run scripts to do the real work of the init process. This process will happen sequentially, one script starting after the other, making the whole process slow as each script has to wait for the previous one to finish. The init process at the time did not have access to the PID or the processes it has started. It only reads PIDs and associates them with actual processes in a complicated way which caused issues for system administrators trying to modify the environment under which a certain process would start. The init processes left out functionality common to every service but instead had each process implement itself, forcing these services to daemon themselves, which is an elaborate and long process. And the current init processes also left certain functionality to external programs which the init process knew nothing about the services started by those external programs.

All of this left a huge open market for another init system to come in and correct these issue. Hence Systemd being made and adopted by many major GNU/Linux distributions. And made the the standard to many users dismay. However in spite of their arguments against Systemd, I would like to make a point that I do not believe the argument should be is Systemd bad but is this type of Init option good? And for the most part, Yes. It corrected many issues facing modern systems and replaced arguably outdated and underdeveloped alternatives. But only if the Developers like Lennart Pottering listen to users and only make the changes necessary to keep software like Systemd relevant in the current age of Linux and make a choice to keep potentially unneeded or harmful features out of the Linux Subspace and Init System.

The Alternatives

Now the intention of this document is to talk about why Systemd is not the cancerous meme many make it out to be, it may have the opposite effect, which is completely fair and fine. If you are concerned about Systemd do not worry as there are plenty of alternatives, some like the ones mentioned above like SysVinit or BSD Init. But if you are looking for well developed Systemd free GNU/Linux operating systems. I would have you check out No Systemd which lists some wonderful alternatives to operating systems with Systemd as well as using Distrowatch to search for other Systemd free alternatives.

Form Your Own Opinion

While I did write this to allow me to have my own dialog on Systemd and why I believe its not the disaster many make it out to be I would want to give you some resources to read more on the other arguments for and against Systemd.

  • I hope this helped inform you more on the What Systemd is and why it was both adopted into modern Linux systems. But also the cries against the usage of Systemd.