Linux and the Systemd Conflict

Going on for about two years now, we’ve been witnessing the Linux developement team and community being divided over the presense of the systemd process management suite in place of init in most distributions. The source of negative reception toward systemd stems mainly from the notions that it goes against the traditional Unix philosophy that each program and daemon should remain separate and maintain one primary purpose, whereas systemd is a group of daemons that effect numerous operations of a system, and that it also creates a large amount of unnecessary complexity in process management. This and other reasons have lead members of the GNU/Linux following into a large debate over how to ‘correctly’ go about system management, and has lead some to believe that the Unix-like community is loosing its way.

At a glance, I’ve seen this as yet another fervent and pointless criticism over what is happening in developement, much like how the integration of PulseAudio initially received among users. However on further observation I realized that it is a rewrite of basically everything we knew about system management, and that the arguments have some meaning to them beyond mere nitpicking.

Systemd was started by German Programmer Lennart Poettering, in an effort to create something that could excel in efficiency over init in terms of concurrent processing and reducing the overhead during operation. Upon the project gaining a reputation, it was adopted by several distros before taking the spotlight with numerous others, such as Ubuntu, openSUSE, Arch and more recently Debian, which has lead to some to propose to fork it.

Reading up on the details of systemd’s basic functionality, I couldn’t immediately find anything wrong with it, not including that it goes against Unix in working as a large mechanism of programs with mixed purposes. It allows for simpler managing of startup processes, stoping and starting services using systemctl, and works as a modular and dynamic tool for troubleshooting, filtering and using service types and targets. This is an example of the front-end aspect that serves well for me and makes it hard to understand why some users seem to hate it, but for those more closely versed in the operations behind this, it makes for a large and far too complex mess of managing processes. Jouranld writes system information to binary files instead of plain text files, and requires journalctl to query the logs. As a result, the logs are usually at risk of being corrupted. Compatibility between kernel versions is very limited due to its strong base from the Linux API, and is therefore prone to being unusable on some systems. Dbus and udev have become required dependencies for systemd, as well as udev merging with systemd, making many packages that dependant on udev to also depend on systemd.

On top of these issues, there seems to be a lack of responsibility in the developement structure of systemd, considering that many of these functionality problems have been mentioned to the developers on multiple occasions, and the response was less than useful and almost sarcastic and uncaring, some of these from Poettering himself. For the most part, Poettering’s time during the conversation of systemd’s technical issues was spent complaining about the social atmosphere in the Linux Kernel developement team, and mostly leaving these problems up to other developers. It is almost a no-brainer that whoever starts a project and cannot take initiative for it is not a suitable project leader, especially when it is a vital operation to the process management system of one of the world’s most widely used Operating Systems in servers and personal computing. This is unacceptable.

Now setting these aside, the developer incompitence does not make the software itself unusable or unreliable; it does not change the fact that systemd is good at doing what it does and operating how it should. This also does not change the fact that it possesses some issues that cannot be left unresolved and neglected. Systemd is an imperfect piece of compiled source code, very much like everything else we use on a computer: They’re imperfect, they do not satisfy everyone else’s needs and wants, and they’re often handled by stubborn developers who work at their own pace. This does not imply that it fails in every requirement for a system to work, it has worked as needed for me and those I know. And for those whom it has not worked for, or has not served a particular purpose, nobody is forcing you to use systemd, init is very much still available for use.

Verdict, TL;DR

At the end of it all, I continue to find myself mostly indifferent about the situation: About which side of this debate has the upper hand or the most reasonable point made, or who screamed the loudest and made whatever difference. I am of the opinion that Systemd is the victim of a very bad developement structure and possesses some features that have made it an infamous piece of software in the eyes of many GNU/Linux users, but the management suite itself is usable, decent and convenient enough for me to leave it on my current Arch system. I think that once the developement structure of systemd is cleaned up, the program itself is cleaned up and it becomes less of a dependancy for other utilities, most users will have a less harsh view of it, and we can all get back to enjoying our favorite Operating system with less debating and more planning for the future.

Linux and the Systemd Conflict

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s