Systemd, 10 years later: a historical and technical retrospective (2020)

downbad_1 pts0 comments

systemd, 10 years later: a historical and technical retrospective

Pleroma |<br>MBN

Related sites:<br>| login<br>| site updates<br>| site map

DnE Blog The dankest, edgiest blog etc etc.

&rsaquo; authors/

&rsaquo; creative/

&rsaquo; entertainment/

&rsaquo; humour/

&rsaquo; misc/

&rsaquo; news/

&rsaquo; philosophy and culture/

&rsaquo; science/

" technology/

&rsaquo; 2014/

&rsaquo; 2015/

&rsaquo; 2016/

" 2020/

" 05/

" 02/

" 0/

systemd, 10 years later: a historical and technical retrospective

by V.R.

I am not sure I am such a big fan of reimplementing NetworkManager…

– Lennart Poettering&rsquo;s famous last words, March 2011

10 years ago, systemd was announced and swiftly rose to become one of the most persistently controversial and polarizing pieces of software in recent history, and especially in the GNU/Linux world. The quality and nature of debate has not improved in the least from the major flame wars around 2012-2014, and systemd still remains poorly understood and understudied from both a technical and social level despite paradoxically having disproportionate levels of attention focused on it.

I am writing this essay both for my own solace, so I can finally lay it to rest, but also with the hopes that my analysis can provide some context to what has been a decade-long farce, and not, as in Benno Rice&rsquo;s now famous characterization, tragedy.

In the first chapter, on the basis of contemporary mailing list posts, I discuss efforts to modernize init, rc and service management that took place before systemd, and what were the prevailing motives at the time. I begin with a preface on the cultural cleavages between different classes of Linux users.

In the second chapter, I discuss the early history and design philosophy of systemd, and what factors drove its adoption.

The third chapter is a technical critique of systemd. It assumes prior familiarity with systemd and it is heavy on discussion of implementation details. I also include a few &ldquo;case studies&rdquo; based on bug reports to better illustrate some of the drier theory.

The fourth chapter discusses other historical parallels to systemd in FOSS development, wraps up some of the threads in the first and second chapters, and concludes with some conjectures about the future of low-level Linux userspace.

Contents

Init modernization efforts before systemd

1.1. The root of the Linux culture war

1.2. Before systemd: the disjointed goals of mid-2000s Linux vendors

systemd: the design philosophy and politics

2.1. The frustrated visionaries

2.2. The rise to power

2.3. Complacency and the loss of purpose

systemd: a technical critique

3.1. systemd defined concretely

3.2. Units

3.3. Jobs

3.4. Transactions and the Manager

3.5. Naming inconsistencies and abstraction failure in systemd

3.5.1. Dependency hell-based init

3.6. Case studies

3.6.1. Valid transaction with nonexistent unit

3.6.2. Transaction with conflicting job types

3.6.3. Dependency propagation overrides explicit restart policy

3.6.4. Bugs as features: destructive transactions, implicit .wants, and PartOf= intransitivity

3.7. Illusions of declarative configuration

What comes after?

4.1. Utopia Banished: HAL, DeviceKit and the other vision that wasn&rsquo;t

4.2. Closing thoughts

1. Init modernization efforts before systemd

1.1. The root of the Linux culture war

The complaints over Linux&rsquo;s fragmented nature as an anarchic bazaar of individual white-box components stitched together into distributions, and various perennial attempts at coming to a &ldquo;resolution&rdquo; of this innate issue – are nearly as old as the first distributions themselves.

Fred van Kempen, an early contributor to Linux&rsquo;s TCP/IP stack, is quoted in a June 1994 interview with the Linux Journal as saying:

Personally, I think the Linux community will have to get used to (a) paying some money for the software they use (for example, shareware and commercial applications), and (b) a somewhat more closed development environment of the system itself. Many, many people will disagree, and exactly this program is what is keeping Linux from a major breakthrough in The Real World.

The lively bazaar would need to make compromises with the Cathedral and with proprietary software, in this early pioneer&rsquo;s estimation.

A 1998 article entitled &ldquo;Linux and Decentralized Development&rdquo; by Christopher B. Browne, written in the storm<br>of critical reception following ESR&rsquo;s famous essay on the Cathedral and the Bazaar, opens with the observation that &ldquo;many people have complained over the last few years that there should be some sort of "central&rdquo; Linux organization."

Browne goes on to argue for the merits of decentralized development, but by the end does concede the usefulness of what he dubs a &ldquo;Linux Foundation,&rdquo; and goes on to describe and sources of funding for such an organization, which would indeed go on to become a reality shortly...

systemd linux rsaquo rsquo technical years

Related Articles