Interview: Lennart Poettering (systemd).

Lennart Poettering (born October 15, 1980) is a German computer free software programmer known for his work on PulseAudio, a sound server, systemd, a replacement for the System V init daemon, and Avahi, an implementation of the zeroconf protocol for network device discovery.

Could you briefly introduce yourself?

I am Lennart Poettering, I work for Red Hat, as part of the desktop group. I wrote most of Avahi and PulseAudio, among other stuff. Right now I am focusing on systemd which I created together with Kay Sievers from SUSE. Systemd is a new system and service manager for Linux which is currently being adopted as init system by most major distributions.

What will your talk be about, exactly?

Well, systemd! The exact contents of my talk depends on what the audience wants to hear. ;-)

Systemd touches a lot of things and since it manages the entire runtime behaviour of the Linux userspace there's enough stuff to talk about to fill many hours. At FOSDEM we can only cover a subset of it.

I guess I'll start my presentation with talking about the basic design ideas of systemd, and its feature set, comparing it with other options. Depending on the wishes of the audience we could focus on a few specific areas in more detail. For example, if the audience wants to hear about the Linux cgroup magic that is built into systemd we can focus on that. Or if folks are particularly keen on talking about systemd from an administrator's point of view then I'd happy to go into detail about that. And there is a lot more we could talk about. My hope is to make this a truly interactive talk where the audience takes an active role and we can have a good conversation.

What do you hope to accomplish by giving this talk? What do you expect?

My hope is to interest people in systemd, and explain what makes systemd great software (in my biased opinion at least ;-)), what the technical reasons for it are, and why most big distributions are adopting it. Besides this kind of systemd advocacy the biggest thing I hope to achieve is getting feedback from the community on systemd.

What where your reasons to start with systemd?

When Kay and I started to work on systemd we had for quite some time been interested in the init system situation. And we found that unfortunately the options back then were disappointing. Most distributions were still relying on sysvinit as init system whose basic design was only minimally different from what Unix offered decades ago, although the Linux kernel (and the platform beyond that) offered so many improvements since then. The amount of missed opportunities of the Linux init systems was massive. On the other hand we looked at the boot and service management tools that other operating systems offered, in particular Mac OS and Solaris. They were dramatically better at parallelizing boot up, or with their management interfaces.

On Linux, the only real alternative to sysvinit back then was Upstart, whose basic design in our opinion was all backwards and maximized the work necessary to boot instead of minimizing it (among other design problems we saw). Also, while it definitely was an improvement over sysvinit it was still missing most opportunities that Linux offered. These three factors together (i.e. missed opportunities, much nicer boot/service managers on competing OSes, and the misdesign of Upstart) led us eventually to create our own init system from scratch, implementing everything we always dreamt of in an init system, without the design problems we saw in existing solutions and taking maximum advantage of what the modern Linux kernel offers today. And given the very positive feedback we got so far we created something that is appealing to quite a number of people.

Which Linux-specific functionality does systemd use and what's the advantage of this over a solution that is portable to other operating systems?

There's quite a bit of Linux-specific functionality we rely on. The first that comes to mind is probably cgroups (short for "Control Groups") which is a Linux kernel feature that may be used to create hierarchical groups of processes, label them, and optionally apply resource limits or other rules to them. But there's a lot more. Systemd tightly integrates with the Linux-specific udev system for hot-plug events. And then, the disk read-ahead solution we include in systemd uses the Linux-specific fanotify() call. Or we support spawning processes in their own file system namespaces or with limited capability sets, both of which are Linux specific features. Or we support the Linux-specific automounter and other mount APIs such as polling mount changes via /proc/self/mountinfo which do not exist on other OSes. Internally we use a lot of newer API calls, such as timerfd() or signalfd() which are not available outside of Linux. These latter calls could be emulated on other OSes, but using them greatly simplifies our own code. And many of the other Linux features we use have no suitable counterparts on other Unixes at all.

Not having to care about portability has two big advantages: we can make maximum use of what the modern Linux kernel offers these days without headaches -- Linux is one of the most powerful kernels in existence, but many of its features have not been used by the previous solutions. And secondly, it greatly simplifies our code and makes it shorter: since we never need to abstract OS interfaces the amount of glue code is minimal, and hence what we gain is a smaller chance to create bugs, a smaller chance of confusing the reader of the code (hence better maintainability) and a smaller footprint.

Many of my previous projects (including PulseAudio and Avahi) have been written to be portable. Being relieved from the chains that the requirement for portability puts on you is quite liberating. While ensuring portability when working on high-level applications is not necessarily a difficult job it becomes increasingly more difficult if the stuff you work on is a system component (which systemd, PulseAudio and Avahi are).

In fact, the way I see things the Linux API has been taking the role of the POSIX API and Linux is the focal point of all Free Software development. Due to that I can only recommend developers to try to hack with only Linux in mind and experience the freedom and the opportunities this offers you. So, get yourself a copy of The Linux Programming Interface, ignore everything it says about POSIX compatibility and hack away your amazing Linux software. It's quite relieving!

What's the unique selling point of systemd?

There's not just one, there are really a lot.

Since I can't list them all here, I'll just mention a single really simple one. One that probably surprises many readers:

Systemd is the first Linux init system which allows you to properly kill a service.

Surprised by this statement? Rightly so, but it is true. Properly killing a daemon on Linux is really hard and without systemd actually almost impossible to do correctly. (No, a simple "killall httpd" is due to many reasons unsuitable to kill Apache) If you want to know why I say that and what systemd does differently here, then make sure to attend my talk and ask me about it!

How many developers are currently working on systemd?

<>Kay and I do most of the work, but we have an active community and got contributions from as many as 44 other developers (according to Ohloh from today) and many of these contributions have actually been substantial. So, depending how you count there are between 2 and 46 people working on systemd right now.

After creating Avahi, PulseAudio and systemd, what is the next big thing you want to work on?

With systemd we still have big plans, and it will take some time before we can say that it is reasonably finished and does everything we want it to do. One of the bigger things that we have been working on is extending systemd so that it is useful to replace/extend gnome-session and similar session managers. Session and system management are actually very similar problems and other operating systems have shown that is a good idea to handle both with the same code.

But to be honest I don't really like speaking too much about my grand plans for the definitely awesome future. While I do have plans like that, I prefer making them reality and delivering them instead of just talking about them and making big announcements.

Have you enjoyed previous FOSDEM editions?

Yes, this will be my fourth FOSDEM, but the first FOSDEM where I'll speak. FOSDEM is a fantastic conference and has a clearly unique atmosphere. I am really looking forward to it!

If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog: