LWN.net Logo

Distributions

Debian debates systemd

By Jake Edge
July 27, 2011

Wherever systemd goes, arguments about it seem to follow. The latest episode involves Debian "discussing" the pros and cons of the init replacement, with many of the same arguments we have seen elsewhere on both sides. But there is a difference for Debian because, unlike most distributions, it supports both Linux and FreeBSD kernels and may start supporting Hurd in 7.0 ("Wheezy"). That makes switching to systemd more difficult for Debian—if it is even desirable—but it also brings up an interesting question for the distribution: should the needs of the smaller sub-distributions (GNU/kFreeBSD, GNU/Hurd) hold back progress on Debian GNU/Linux?

Perhaps unaware of the firestorm he was about to set off, Juliusz Chroboczek posted some observations about systemd to the debian-devel mailing list. In it, he offered his opinion on the good and the bad with respect to systemd and tried to make it clear that he wasn't trying to push the decision in any particular direction, just recording his observations. Overall, it is a fairly even-handed look at systemd that notes multiple advantages and disadvantages.

Of course, systemd advocates will argue that some of the disadvantages cited are wrong as Debian systemd maintainer Tollef Fog Heen did, but overall there weren't many big complaints about the posting itself—except from systemd developer Lennart Poettering. His response was forwarded to the list by Chroboczek and was characteristically combative, which to some completely justified one of the original posting's complaints: "Systemd's author is annoying".

Undoubtedly Poettering is tired of defending systemd against what he sees as "amazingly badly informed" criticisms. Given that the overall tone of Chroboczek's post was fairly positive, though, it's a little surprising to see the animosity with which Poettering responds. One of the main problems that some in the Debian community (including Chroboczek) have identified with systemd is its "Linux-only" attitude. Poettering addresses that, like he has many times before, but includes a long list of non-POSIX features that systemd uses, concluding: "There's a reason why systemd is more powerful than other init systems: we don't limit ourselves to POSIX, we actually want to give the user/administrator the power that Linux can offer you."

But that power also limits the environments where systemd can run, of course. In addition, the systemd developers have made it clear that they are not interested in taking patches to make it portable to non-Linux systems. In fact, Poettering calls it "practically impossible. about every line of it is non-portable code" in an IRC conversation summary posted to the thread by Matthias Klumpp. All of that makes it difficult for the Debian FreeBSD port, as well as the Hurd effort (and would presumably hinder a humorously suggested Plan 9 version of Debian too).

The Linux versions of Debian (including the various architectures and embedded Linux versions) are by far the most popular, so there is a question of how much minority Debians should be able to hold back progress. As Uoti Urpala puts it:

I think the important question is whether portability to other kernels is or should be a "project's goal", and how much else you're willing to lose for the sake of that goal. I know I would personally be a lot happier with a Debian that supports systemd functionality than with a Debian that can run on a BSD kernel.

Wouter Verhelst, on the other hand, is adamant that GNU/kFreeBSD is going to continue as part of Debian, and that systemd is not welcome if it will make it harder for that variation to operate:

Whatever its features, if we have to jump through a large heap of hoops to get it to work at all, or to make life for maintainers of daemon packages not a complete nightmare, it's not likely to become the default in Debian any time soon.

As might be guessed, Urpala was not convinced that supporting FreeBSD was enough of a reason to stop the eventual adoption of systemd:

But the attitude that it's OK for kFreeBSD to set limits on Linux development (or that developers working on Linux must handle the BSD porting/compatibility to be "permitted" to adopt a new technology) smells of trying to hold the project hostage, and I doubt it can have positive effects for the project overall.

In addition, he and others believe that moving away from the traditional System V shell-script-based init would be a net benefit for package maintainers: "I think the life of many maintainers of daemon packages is a 'complete nightmare' now with sysvinit, compared to what it would be with systemd." Because systemd can use existing init scripts, there is no need for a mass translation of packages to support systemd. However, an eventual switch to use systemd by default would undoubtedly cause various Debian packages to drop their init scripts in favor of systemd unit files that are far simpler, but wouldn't be usable directly by the System V init system that is currently the default. All is not lost however, as Russell Coker describes:

If a daemon supports socket activation then there would need to be separate work done to write a systemd unit and a sysvinit script.

If a daemon doesn't support socket activation then IMHO the ideal situation would be to have a program that takes a systemd unit file as input and creates a sysvinit script. That would reduce the amount of effort and reduce the amount of low quality sysvinit scripts that are out there (and I've written my share of such bad scripts).

Another possibility would be for Debian to directly support both System V and another init (i.e. systemd or Upstart) but many think that idea is a non-starter. Maintainers would have to support both styles of initialization (or ignore the benefits of the newer systems) as Russ Allberry noted:

Unless you're willing to write init scripts and cripple systemd by making it use init scripts, it's a huge pain, since you have to maintain two parallel init setups for every package requiring something to run at boot, one of which will probably never be tested by the maintainer.

The same issue applies with upstart, of course. Both systems support old-style init scripts, but one of the huge motivations for switching init systems is to *stop using* old-style init scripts, since they support a tiny fraction of the capabilities of systemd or upstart and are massively annoying and tricky to maintain in a bug-free fashion.

There is a potential support problem for upstream projects, however, as Gergely Nagy points out: "[...] even if systemd can be made portable enough for Debian's needs, or Debian can find a way to work around systemds unportability, upstreams who need to support other systems will still have yet another extra burden to carry." Of course, whether Debian switches to systemd, Upstart, or stays put, the problem for upstreams doesn't really change. None of the init systems is likely to disappear anytime soon, so either upstreams or distributions will have to support all of them in one way or another. As is often the case, Debian project leader Stefano Zacchiroli finds some middle ground:

But what I find surprising in this discussion (with notable exception, luckily) is the feeling that portability is boolean: it is not. It is rather a trade-off among the work that needs to be done / code that needs to be maintained and the distro-wide technical choices that we make. In that respect, the fact that systemd upstream might decide not to integrate upstream our [changes] is sad, but it's not the end of the world: it won't be the first nor the last upstream not willing to integrate some of our changes.

Zacchiroli's post—worth reading in full—manages to express support for most of the positions taken in the thread, while also pointing out a clear path forward for any change to the init system for Debian. While there hasn't been a large contingent pushing Upstart in the thread, it is clearly on the radar as a possibility. Any change is likely to be a ways off in any case, so a long thread arguing the merits of systemd is premature. Whenever such a decision is made, though, the general sense from those participating in the thread is that the decision will be made on technical grounds separate from the issue of how to support non-Linux versions of Debian. That problem will be solved too, but there is no reason to hold back progress on Linux for other kernels (or vice versa).

Comments (86 posted)

Brief items

Distribution quote of the week

As you can clearly see, you can see nothing. Yes, nothing! As of 18:55:52 UTC+2 the NEW queue, which at some times was well over 500, sometimes even 600 packages is now empty. Completely empty.

To the best of my (and Ganneff's knowledge) the last time the NEW queue was empty was at least five years ago.

Interesting enough, that triggered an yet undiscovered bug in dak, which refused to scan an empty directory...

-- Alexander Reichle-Schmehl

Comments (none posted)

Release for CentOS-6.0 LiveCD i386 and x86_64

The CentOS 6.0 live DVD is available. "The CentOS-6.0 LiveCD is meant to be a Linux environment suited to be run directly from either CD media or USB storage devices. It does not need any persistent storage on a machine, which also makes it a suitable recovery environment."

Full Story (comments: 1)

Fedora 15 for IBM System z 64bit official release

The Fedora IBM System z (s390x) Secondary Arch team has announced the Fedora 15 for IBM System z 64bit official release.

Full Story (comments: none)

IPFire 2.9 Core Update 50 released

IPFire is a server distribution intended for use as a firewall. IPFire 2.9 Core Update 50 has been released. "Since 44 months and 50 core updates, IPFire is working better than on the first day. The developers keep working on little updates that improve the base system and addons, but also bring major updates on the way. That is why the system runs very great on recent hardware and keeps up with new technology. A very special attention is paid to safety-critical problems. Many security issues of third party packages have been patched, tested and delivered only within a couple of hours."

Full Story (comments: none)

Mandriva 2011 RC2

The second release candidate for Mandriva 2011 has been released. "In this release candidate we fixed more than 300 bugs and added or changed about 700 packages."

Comments (none posted)

openSUSE 12.1 milestone 3

The openSUSE project has released the third milestone for openSUSE 12.1. "Just a few days ago the third of six milestones on the road to openSUSE 12.1 has been made available for testing before it goes to final release November 11th, 2011. (Yes, 11-11-11!)"

Comments (none posted)

Red Hat Enterprise Linux 5.7 Now Available

Red Hat has announced the release of Red Hat Enterprise Linux 5.7. "Today's update adds features that enhance the flexibility, security, and stability of Red Hat Enterprise Linux 5 environments, and includes a number of features incorporated from Red Hat Enterprise Linux 6. Application interface consistency is maintained between Red Hat Enterprise Linux 5.7 and prior updates, allowing systems to be updated easily without application re-certification." More information can be found in the release notes and the technical notes.

Comments (none posted)

Ubuntu 10.04.3 (Lucid Lynx) LTS released!

The Ubuntu team has announced the release of Ubuntu 10.04.3 LTS. "This release includes updated server, desktop, alternate installation CDs and DVDs for the i386 and amd64 architectures." Kubuntu 10.04.3 is also available.

Full Story (comments: none)

Distribution News

Debian GNU/Linux

Debian 7 'Wheezy' to introduce multiarch support

The introduction of "multiarch support" is now a release goal for the coming Debian release 7 "Wheezy" (targeted for a 2013 release). "Multiarch is a radical rethinking of the filesystem hierarchy with respect to library and header paths, to make programs and libraries of different hardware architectures easily installable in parallel on the very same system."

Full Story (comments: 18)

openSUSE

openSUSE Conference travel sponsorship program

The openSUSE conference team has announced the travel sponsorship program to financially support community members to attend the conference (September 11-14 in Nuremberg, Germany). The application deadline is August 5.

Full Story (comments: none)

Newsletters and articles of interest

Distribution newsletters

Comments (none posted)

Fedora 16 to have Grub2, GNOME 3.2 and KDE 4.7 (The H)

The H takes a look at some of the features planned for Fedora 16. "The feature list contains 40 items, including GNOME 3.2 and KDE Plasma Workspaces 4.7. The developers are planning to switch to using Grub2 for the boot loader. Having switched to systemd, as an alternative to sysvinit and upstart, in Fedora 15, the project plans to replace further sysv init scripts with systemd units in version 16. Furthermore, Fedora is to offer everything that's required for Xen virtualisation, as version 3.0 of the Linux kernel, which is now expected to be released on Friday, will include all the necessary components."

Comments (none posted)

Ten reasons for giving Slackware Linux a go (ZDNet)

Jack Wallen presents his top 10 reasons to use Slackware. "1. Stability Even for an operating system known for its stability, you'll be hard-pressed to find a more reliable Linux distribution than Slackware. It's been around for 20 years and has long enjoyed a reputation for being solid. In my time using it - and I have installed the most recent version as well as having used versions throughout my time with Linux - I can honestly say its reputation is entirely justified. Whether on a server or a desktop, it is remarkably stable."

Comments (4 posted)

Page editor: Rebecca Sobol
Next page: Development>>

Copyright © 2011, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds