Please mention Shepherd (and other init systems) in the discussion about the GR proposals.
Svante Signell
svante.signell at gmail.com
Mon Dec 2 10:32:28 GMT 2019
Hello,
Can somebody already involved in the discussion about init system GR on debian-
vote (Ian, Adam?) add comments on alternate init systems, other than systemd and
sysvint. The focus is far too oriented towards sysvinit and not other
alternatives are mentioned, like OpenRC, initng, runit, monit, s6, daemontools,
and especially Shepherd, see https://en.wikipedia.org/wiki/Init
Below is a quote from one mail on init systems on debian-vote:
https://lists.debian.org/debian-vote/2019/12/msg00032.html
Subject: My analysis of the proposals
Uoti Urpala:
> In short: there is little to no worthwhile work being done on any
> alternatives to systemd. What is happening is some people trying to
> keep sysvinit working to about the level it did in 2014, while doing
> very little fundamental development to the system that would fix its
> widely recognized flaws. Such work will not help innovation, will not
> produce a plausible alternative to systemd, and is not worth
> supporting
Some of Shepherd's selling points, see
https://en.wikipedia.org/wiki/GNU_Guix#GNU_Shepherd_Init_system
GNU Shepherd Init system
Guix System uses the GNU Daemon Shepherd as its init system, which is developed
in tandem with Guix and is written in Guile as well. It was previously known as
"dmd", which stood for "Daemon managing Daemons" or "Daemons-managing Daemon",
but changed names to avoid collision with the Digital Mars D compiler.[34]
Shepherd supplies user-space functionality asynchronously as services, which
under Shepherd are generic functions and object data types that are exported for
use by the Shepherd to extend the base operating system in some defined way. In
contrast to systemd, a userspace shepherd process runs as that user. Core to the
Shepherd model of user space initialisation is the concept of the extension, a
form of composability where services are designed to be layered onto other
services, augmenting them with more elaborate or specialised behaviours as
desired.[35] This expresses the instantiation-based dependency relationships
found in many modern init systems,[36] making the system modular, but also
allows services to interact variadically with other services in arbitrary ways.
Shepherd also provides so-called virtual services which allow dynamic dispatch
over a class of related service objects, such as all those which instantiate a
mail transfer agent (MTA) for the system.[37] A system governed via the Shepherd
daemon can represent its user space as a directed acyclic graph, with the
"system-service" − responsible for early phases of boot and init − as its root,
and all subsequently initialised services as extensions to system-service's
functionality, either directly or transitively over other services.[35][38]
Being both written and configured in Guile Scheme, GNU Shepherd is intended to
be highly programmable by the system administrator, but it can also be used to
manage per-user profiles of unprivileged daemons and services.[39] Its services
and configuration are stored uniformly as object-oriented Scheme code, and while
a core set of services are provided with the basic Guix System Distribution,[40]
arbitrary new services can be flexibly declared, and through Guile's object
system, GOOPS, existing services can be redefined at the user's discretion by
asking the Shepherd to dynamically rewrite services in specified ways on
instantiation.[41][42]
GNU Shepherd was originally designed to work with GNU Hurd, and was later
adopted by Guix System.[43]
****************************************
I'm planning to package Shepherd for Debian but will not be able to make a
proposal until voting is due.
Thank you in advance!
More information about the Debian-init-diversity
mailing list