The world of Linux is in a perpetual flame-war, the latest longstanding controversy is the topic of system service management. We needed a modern system service manager and systemd set a bar that nothing else could meet. Now with systemd being the default, many people are up in arms about it claiming that systemd impedes on open source software and freedom of choice. Is there something more sinister going on with systemd, or is this flame-war just smoke and mirrors?
What is a system service? It’s a pretty broad, but easily answered question. System services, often called daemons in the Linux and UNIX communities, are simply programs that run in the background that either provide functionality to other programs, like audio or networking capabilities, or they might monitor security events and provide alerts. Either way, as the name suggests, they provide services to the other programs running on the system.
So, how can something so fundamental and essential be so controversial? Just because there’s choice. You don’t see flame wars surrounding the system service management on Windows or OS X simply because there is no choice. But on Linux, there’s always a choice.
Part of the problem is that the system service managers also initialize the system, and there are many ways of going about doing that. The SysV init style has been around since, well, the System V days (System V was released in 1983).This set the trend for the way that POSIX compliant systems would be initialized. The SysV init style remained the de facto for almost three decades, with a few exceptions. Many IT professionals and software engineers did not want to abandon the SysV init because it had served them well for so many years, and it was a very simple process to understand. So, the introduction of anything that could replace it was met with strong resistance.
The problem with SysV init, though, was that it was built on concepts from many years before. It lacked the ability to natively handle many things, such as the detection of removable storage media, properly detecting hardware and allowing firmware to load, and it oversimplified the possible states of a computer to single-user mode, single-user with networking, multi-user mode, multi-user graphical mode, reboot, and halt. This only provided the customization of two modes, the multi-user mode, and multi-user graphical mode. This gross oversimplification severely limited the manageability of the system from an administrative point of view. This wasn’t a problem for personal computers, but it definitely limited the administrative potential of servers in production environments.
In an attempt to bring more features to the Linux initialization process, Canonical released Ubuntu 6.10 (Edgy Eft) in 2006 with Upstart. Upstart was designed with backward compatibility from the start. It could run daemons without any modification to the startup scripts. Because of this, many Linux distributions moved toward Upstart, but not all of them. In fact, the Debian based Devuan was developed in spite of Debian moving to systemd. Devuan uses SysV init, but offers many other choices.
In 2010, Red Hat engineers Lennart Poettering and Key Sievers had started developing systemd. The following spring Fedora 15 was released with systemd, the first ever systemd powered distribution. Over the course of the next three years, the majority of distributions switched to systemd for two major reasons, the inherent benefits of an updated system initialization system, and also not wanting to be left behind.
But, if systemd is considered better by all these distributions, enterprise and hobbyist alike, why is there so much controversy? Why was there so much resistance to something that is nearly unanimously agreed upon as better? The answer is choice.
systemd offers many, many improvements over SysV init and Upstart, but it also provides other components that developers can leverage for less work and tighter system integration. What’s wrong with that? Well, as developers write all this software that depends on systemd and/or any of its many other services (such as journald, udevd, consoled, logind, or networkd), that software then becomes less compatible with systems that are not running systemd. Furthermore, as the number of services provided by the systemd project continues to grow, systemd becomes more dependent on them itself. As a result, systemd is becoming a platform on its own and its ubiquity is inadvertently discouraging the development of software that is portable and compatible with non-systemd systems. I’m sure it’s now easy to see why some people would be so resistant to systemd.
But, is systemd really that bad? Of course not. It’s open source and people have the choice to use it or not. While users and developers might benefit from a more diverse system initialization landscape, it is not the fault of systemd that major distributions have made the switch, unless you consider the numerous benefits it provides.
As mentioned, there has been much resistance to systemd, but we have many alternatives. You can still use sysvinit, Upstart, or others like OpenRC, sinit, runit, shepherd, and s6 (provided your distribution supports them). There are still many distributions that work hard to maintain non systemd distributions. As mentioned before, there’s Devuan, but also Gentoo, Slackware, Dragora, and PCLinuxOS, and many UNIX operating systems such as FreeBSD, OpenBSD, and DragonflyBSD. The bottom line is that there is still choice, which is a large part of what open source is about.
EmoticonEmoticon