Composing system services in GuixSD
or how we came to wonder what a "system service" really is
What's a "system service"? How do we model that in GuixSD?
In most people’s mind, system services are a bunch of daemons that simply need to be started at boot time, or whenever they are actually needed. Possibly services form a dependency graph, and possibly they are actions other than spawning a daemon, such as mounting a file system.
As always, the devil is in the detail, and reality is that “system services” on a modern GNU/Linux system—with udev, dbus, polkit, along with more traditional Unix services—include lots of different “activities”, with lots of interactions among them. That naive picture of a graph of services no longer works.
This talk is going to tell the story of system services in GuixSD. GuixSD started from the naive visions of a “dependency graph of actions” to evolve into a generic model of service composition. I will describe what makes GuixSD’s service composition model unique, and how it helps users and sysadmins reason about the whole system.