Archive for September 2012

Yet another systemd comment

At this point, the whole discussion has started to annoy me. I started so many replies to so many comments on reddit, posts on Arch’s forums and or mails on [arch-general] – and I aborted most of them. The stupidity of the whole discussion makes me sick. But in the end, you cannot change who you are, and I am a man of many angry words.

As with every discussion, there’s two extremes: Morons who praise systemd as if it would save the world, and retards that think systemd is the reason the world will end this year. Of course, all of them are wrong. If you belong to one of those groups: Fuck you! Everyone else: Keep reading.

Write programs that do one thing and do it well.

I won’t pretend to know the internal design of systemd. I also won’t argue that it actually does or does not follow that principle.

Let us instead remember that this UNIX principle was formulated decades ago. Back then and now, what was one of the biggest problem with computers? Bugs in your software. How do you avoid bugs? Divide your work into small tasks, only write the code for each task once, put it together as you need it. How? Use one tool, let it write its output to a file or the standard output, let the next tool read the output and process it. Does it sound like a good idea? Maybe, but here’s what’s wrong with it:

  • The only way of communication between tasks are strings. Every tool has to serialize its output, and the next tool has to parse it again. The communication is one-way only, parsing can be complex and error-prone.
  • cmd1 | cmd2 | cmd3 – an error occurs in cmd2, how do you handle that?
  • For performing a complex task, you need to create a shitload of processes and call a shitload of tools. Sounds efficient.
  • Syntax is checked on runtime.

I’m no expert, but to me it sounds like that could be improved. So, what’s changed in the last few decades? Shared libraries. Let me repeat that: shared fucking libraries. Here’s what you get:

  • Libraries contain code for common tasks that can be integrated into any program. Bug fixes in the library automatically affect all programs that use it.
  • Well-defined APIs, structured data, less data copying.
  • Proper error reporting.
  • No bugs from output and parsing errors.
  • Syntax is checked on compile time.

I’m not going to say more about this. Does systemd follow the classical UNIX principle? I don’t care. It’s the fucking 21st century. If we have better ways of doing things, let us please use them! Let us not follow a guideline that is decades old and mostly obsolete.

systemd is not easily hackable, Arch’s initscripts are more flexible

Let us have a look at the old initscripts. They boot up your system. They start your daemons. And they don’t do that very well. They don’t nearly cover all use cases. The code is complex. Extending them means changing the scripts and doing it again after the next update. There are bugs which are hard or even impossible to fix.

A lot has improved since Tom took over maintainership of the scripts. However, it has become clear that they can only be an intermediate solution: If we want them to remain simple, we will keep missing important features. If we keep extending them, they will become so complex that nobody understands them anymore.

Now, to the people that claim systemd is not hackable: Have you looked at /usr/lib/systemd/system? You can change, disable or extend almost every single detail of it. You can override almost all of its behaviour by placing files in /etc/systemd/system and it will be persistent to upgrades. All of that without changing a single line of C or shell code. If you want to, you can even mask all of its units and instead make it call a script very similar to our old rc.sysinit.

In short: systemd’s hackability and flexibility supercedes initscripts’ considerably.

systemd – why not?

I have only been running pure systemd on my machines for a few weeks. I like it. It has some rough edges, its support in Arch Linux is incomplete. There’s room for improvement. It will not save the world. It will not eat your children either.

A final message to the people who keep complaining

You can yell all you want, yet Arch Linux will slowly move towards systemd. Initscripts will probably keep working for a long time, but they will eventually disappear. It doesn’t help if you insult us for it. It doesn’t help if you state a thousand times that you leave Arch over “the systemd issue”. We don’t care. You can either embrace systemd and enjoy all its advantages, provide an alternative or use another distribution. We don’t care. We make Arch for ourselves, and for the ones that like it like we do. Whether we have a million users or one hundred users – we will keep making it the distro we like. Deal with it.