Contributors' Study Guide

There is no royal road to science, and only those who do not dread the fatiguing climb of its steep paths have a chance of gaining its luminous summits.

• Carl Marx

The InitWare Suite of Middleware is concerned with a very important subject: that of the management of services. Every app and server on a modern Unix-like operating system stands in some way atop this foundation. Yet it remains a subject obscure and ill-understood in much of the GNU/Linux community.

This is a study guide intended for those who would contribute to InitWare, but nevertheless it should serve well enough as a course of study for anyone interested in the history of service management on Unix-like systems, problems of the subject, and elements of the philosophies which give direction to InitWare's development. It is assumed that you have some basic familiarity with how Unix-like systems work and what a daemon is.

It is important to understand why we might want our systems to realise certain concepts, principles, and design choices.

1. Read Eric S. Raymond's Basics of the Unix Philosophy.
2. Read the Anti-Foreword, Preface, and Chapter I of the UNIX Hater's Handbook, then Apendix C, Richard P Gabriel's "The Rise of Worse is Better". You might ask yourself whether you think UNIX itself really lived up to the UNIX philosophy.
3. Read at least a little of Alan Kay's Early History of Smalltalk to help disabuse yourself of any Java or C++-inspired misunderstandings of what he meant object-oriented programming to mean.
4. Read M. P. Weiher's What Alan Kay Got Wrong About Objects.

These cover three different philosophies of software - the Unix Philosophy, the MIT or Lisp approach, and the Californian School of Object-Oriented Programming (plus Weiher's light revision of it). Each differs in the emphasis given to particular factors, but all are principled and systematic. Architecture will arise in software of anything other than the most trivial - all these philosophies argue that forethought should go into architecture.

1. Read the INIT(8) manual page from UNIX V7.
2. Look at the /etc/rc file from UNIX V7. When UNIX V7 was released in the 70s, this was all that needed doing to bring up a system. init simply ran /etc/rc to initialise the system before it proceeds to run getty instances to allow console login. When daemons started to appear, the clean system became messier:
3. Look at the /etc/rc file from an old version of FreeBSD. BSD init still basically works the same as the UNIX V7 init from which it descends - but note the distinction between init and rc.

1. Read Luke Mewburn's The Design and Implementation of the NetBSD rc.d system, which describes the system sometimes called rcNG.
2. Read Richard Gooch's Linux Boot Scripts with particular focus on how he describes the operation of System V-style rc.
3. Read closely the original USENIX paper on Solaris' SMF.
4. Read the Ubuntu Wiki article ReplacementInit, the founding document of Upstart, and particularly consider whether event-based semantics are really the solution to the problems posed.
5. Read Lennart Poettering's Rethinking PID 1, which introduced systemd for the first time and argues against the event-based approach.
6. Read Jonathan de Boyne Pollard's Readiness protocol problems with Unix daemons.

These all address the limitations of traditional Unix service management (as in BSD and System V init and rc) and each discusses some approaches to improving on it. Note the diversity of solutions to these problems.

InitWare began as a fork of systemd. The core elements of systemd are three: Units, Jobs, and Transactions. A thorough understanding of this system, its power, flexibility, and limitations alike, is crucial.

1. Read vezzy-fnord's Structural and semantic deficiencies in the systemd architecture.
2. Read bl33bl0p's Notes on how systemd's Job engine is structured.
3. Read bl33pbl0p's systemd - Job propagation through dependencies.
4. Read bl33pbl0p's Some rebuttals and additions to vezzy-fnord's "Structural and semantic deficiencies[...]".
5. Read vezzy-fnord's systemd, 10 years later: a historical and technical retrospective

Some of these are raised in the articles above. This is the point at which InitWare sets off.

• First, consider the Holy Trinity:
  • Consider .device units for example, and how they are very different to other units. A dependency generally causes the dependent to be automatically started before the depender, but devices cannot be 'started'. A start job on a .device unit simply waits to see if the device will appear or not.
  • If systemd is to have a sort of universal object model of system resources, shouldn't one be able to extend that object model to accommodate other resources?
• Remind yourself of the philosophy of software you read earlier.
  • Read D. J. Bernstein's Why is qmail secure?
  • Browse the LangSec.org homepage.
  • Study systemd CVEs 2020-13776, 2017-100082, and 2016-7795. A langsec approach would have prevented them all.