Systemd: Harbinger of the Linux apocalypse

[nedo]

It might not be the end of the world, but the design of systemd and the attitudes of its developers have been counterproductive.

Now that Red Hat has released RHEL 7 with systemd in place of the erstwhile SysVinit, it appears that the end of the world is indeed approaching. A schism and war of egos is unfolding within the Linux community right now, and it is drawing blood on both sides. Ultimately, no matter who "wins," Linux looks to lose this one.

The idea behind systemd was to replace the aged Init functionality and provide a sleek, common system initialization framework that could be standardized across multiple Linux distributions. systemd promised to speed up system boot times, better handle race conditions, and in general, improve upon an item that wasn't exactly broken, but wasn't as efficient as it could be.

[ First look: Docker 1.0 is ready for prime time | How-to: Get started with Docker | For the latest practical data center info and news, check out InfoWorld's Data Center newsletter. ]

As an example, you might be able to produce software that could compile and run on numerous Linux distributions, but if it had to start at boot time, you could be required to write several different Init-style boot scripts, one for each supported distribution. Clearly this is inelegant and could use improvement.

Also, there was the problem that traditional Init is slow and bulky, based on shell scripts and somewhat random text configuration files. This is a problem on systems that need to boot as fast as possible, like embedded Linux systems, but is much less of a problem on big iron that takes longer to count RAM in POST than it does to boot to a log-in prompt. However, it's hard to argue that providing accelerated boot times for Linux across the board is not a good thing.

These are all laudable goals, and systemd wasn't the first project aimed at achieving them. It is, however, the first such project to gain mainstream acceptance. This is in no small part due to the fact that the main developers of systemd are employed by Red Hat, which is still the juggernaut of Linux distributions.

Red Hat exerted its considerable force on the Linux world. Thus, we saw systemd take over Fedora, essentially become a requirement to run the GNOME desktop, then become an inextricable part of a significant number of other distributions (notably not the "old guard" distributions such as Gentoo). Now you'd be hard-pressed to find a distribution that doesn't have systemd in the latest release (Debian doesn't really use systemd, but still requires systemd-shim and CGManager).

While systemd has succeeded in its original goals, it's not stopping there. systemd is becoming the Svchost of Linux -- which I don't think most Linux folks want. You see, systemd is growing, like wildfire, well outside the bounds of enhancing the Linux boot experience. systemd wants to control most, if not all, of the fundamental functional aspects of a Linux system -- from authentication to mounting shares to network configuration to syslog to cron. It wants to do so as essentially a monolithic entity that obscures what's happening behind the scenes.

No matter which side of the argument you're on, this monolithic approach is in violation of the rules of Unix, specifically the rule stating it's best to have small tools that do one job perfectly rather than one large tool that is mediocre at performing many jobs. Prior to this, all the functions subsumed by systemd were accomplished by assembling small tools in such a way that they performed the desired function. These same tools could be used within a variety of other scripts to perform myriad tasks -- there was no singular way to do anything, which allowed for extreme freedom to address and fix problems. It also allowed for poor implementations of some functions, simply because they were poorly assembled. You can't have both, after all.

That's not the end of the story. There's more happening with systemd than many might realize. First, systemd is rather inelegantly designed. While there are many defensible aspects of systemd, other aspects boggle the mind. Not the least of these was that, as of a few months ago, trying to debug the kernel from the boot line would cause the system to crash. This was because of systemd's voracious logging and the fact that systemd responds to the "debug" flag on the kernel boot line -- a flag meant for the kernel, not anything else. That, straight up, is a bug.

However, the systemd developers didn't see it that way and actively fought with those experiencing the problem. Add the fact that one of the systemd developers was banned by Linus Torvalds for poor attitude and bad design and another was responsible for causing significant issues with Linux audio support, but , and you have a bad situation on your hands.

There's no shortage of egos in the open source development world. There's no shortage of new ideas and veteran developers and administrators pooh-poohing something new simply because it's new. But there are also 45 years of history behind Unix and extremely good reasons it's still flourishing. Tools designed like systemd do not fit the Linux mold, to their own detriment. Systemd's design has more in common with Windows than with Unix -- down to the binary logging.

My take is that systemd is a good idea poorly implemented, developed by people with enormous egos who firmly believe they can do no wrong. As it stands now, both systemd and the developers responsible for it need to change. In the open source world, change is a constant and sometimes violent process, and upheavals around issues such as systemd aren't necessarily bad. That said, these battles cannot be drawn out forever without causing irreparable harm -- and any element as integral to the stability and functionality of Linux as systemd has even less time than most.

Articol preluat de aici