Learning to live with systemd

Off the Beat: Bruce Byfield's Blog

May 08, 2015 GMT
Bruce Byfield

My first experience with systemd could not have been worse. Suddenly, after upgrading KDE from Debian unstable, my monitor could not display at its highest resolution. Booting displayed errors because I was not using GNOME. Even worse, I had to search for how to turn off my computer, and even then could only do so from the root account. All this seemed a high price to pay for an init replacement, but I reserved judgment until I knew enough to develop an informed opinion.

Now I am glad that I kept my mouth shut. Having spent the last few days learning about systemd, I conclude that most of the objections to systemd were premature and that, although perhaps unnecessary, it is surprisingly well-structured and easy to learn.

Some of the objections to systemd should only embarrass those who made them. For example, one of the conspiracy theories that are endemic in free software held that that, because systemd was developed by a Red Hat team, Red Hat would use it to seize control of Linux. According to rumor, Red Hat would block rival technologies, forcing everyone to use GNOME and the .rpm package management system exclusively.

But quite aside from the fact that Red Hat has always been one of the more responsible corporate members of the free software movement, once you check the licensing, any plausibility in the rumor is deflated. Since systemd is released under the second version of the GNU General Public License, anyone can modify it as desired, making a power grab by Red Hat or anyone else impossible.

Similarly, basic logic defeats objections to systemd based on a dislike of its founder, Lennart Poettering. It is perfectly true that many feel that Poettering still has a lot to answer for because of PulseAudio, his previous project. It is true, too, that Poettering frequently shows the diplomacy of a fretful hornet, criticizing time-honored Unix programming principles and insisting on the superiority of his own alternatives.
 

However, Poettering's attitudes should have nothing to do with efforts to evaluate systemd. It is as wrong to condemn systemd because of Poettering's behavior as it would be to praise it because of the unacceptable and persistent abuse heaped on him.

Architectural arguments
 More valid reasons for rejecting systemd center on its design -- although many objections have more to do with how systemd was developed and implemented than its final form. For example, the feature creep in  systemd is undeniable; systemd is not only an init replacement, but a manager for virtually every aspect of a computer system. Whether such a manager is needed seems a valid question, and those who complain that systemd violates the Unix principle of having small programs that do one thing well are certainly correct on the surface.
 

Still, design is not an exact science, and while you may favor, as Linus Torvalds apparently does, plain text logs to binary ones like systemd's, to an extent, the technical debate comes down to personal preferences rather than any unvarying laws of programming.

At any rate, thanks to a thorough collection of symlinks, systemd as finally implemented provides the same collection of small, specialized applications as Linux always has. In the same way, systemd's binary logs can easily be piped to text files if you want to save them. If the files have changed, how users interact with the system remains much the same as ever.

If you want to, you can use a systemd system almost exactly as you would one without systemd. But if you choose to use systemd directly, you will find that it is not much different from the tweaks that a distribution has always provided to make all the pieces work as a single system. The difference is that, unlike the binaries it replaces, systemd's binaries are designed to work together. Moreover, far from limiting your ability to do system administration, systemd adds additional controls to help you to manage and observe.

In addition, systemd is structured in such a way that it is easy to learn. Its file-naming is extremely consistent, with utilities ending in "ctl" and related binary, configuration and logfiles having similar names. And while systemd's changes are extensive, it also includes dozens of man files, as well as an index to them to help bring you up to speed.

As a result, while systemd seemed chaotic during its development  because of poor communications and its sheer size, in its final form, systemd is surprisingly straightforward. While in theory I prefer the Unix principle of one small program, in practice, I find systemd surprisingly quick to learn and to use for gathering information for troubleshooting. Far from making a Linux system less accessible to users, systemd could actually make administration more accessible to average users. So perhaps systemd's architecture, while not strictly traditional, has its points as well.

Living and let live
I am still not convinced that systemd was necessary. If init was no longer sufficient, why not switch to Ubuntu's upstart as a replacement? Probably the reason was at least as political as technical -- which would give the lie to the belief that free software is a meritocracy.

No doubt, too, the development of systemd was mismanaged, with so little communicated that people were left to fill in the blanks by expressing their own fears and jumping to unfounded conclusions. A PR or a crisis manager might have prevented much of the energy wasted on predicting disasters, and prepared a more favorable reception for systemd.

I am still not enthusiastic about systemd. However, having explored it, I can find aspects to admire about how it was implemented and I can accept the rest. By contrast, much of the discussion of it during the last year was out of proportion to reality, and shows free software at its worst.

comments powered by Disqus

Issue 36: Getting Started with Linux – /Special Editions

Buy this issue as a PDF

Digital Issue: Price $15.99
(incl. VAT)

News