[TUHS] Version 256 of systemd boasts '42% less Unix philosophy' The Register

[Alexis]

Grant Taylor via TUHS <tuhs at tuhs.org> writes:

> I'm anti-systemd *cough*Master Control Program*cough* and it's
> associated suite of utilities for many reasons.  But I've come 
> to
> accept that systemd is not just an init system.  It's role of a
> service life cycle manager is a superset of what an init system 
> does.
> It's a relatively new world (at least comparatively).

Indeed: it doesn't just do init, but also _service supervision_ 
(making sure that a service that _should_ be up, _is_ up) and 
_service management_ (enabling, disabling, starting, stopping, 
dependencies, etc.). Hence why phrases like "the init wars" are 
such a misnomer.

As described in the potted history outlined in the "known problems 
with System 5 rc" article i linked to upthread, Sys V rc's issues 
with service supervision and service management have been known 
for decades:

> In 1999, Luke Mewburn worked on replacing the /etc/rc system in 
> NetBSD. netbsd.tech.userlevel mailing list discussions from the 
> time show several criticisms of the System 5 rc and System 5 
> init systems, and encouragement not to repeat their mistakes in 
> the BSD world. The resultant rc.d system was roughly 
> contemporary with Daniel Robbins producing OpenRC, another 
> System 5 rc replacement that replaced the (Bourne/Bourne Again) 
> shell with a different script interpreter, nowadays named 
> /sbin/openrc, that provided a whole lot of standard service 
> management functionality as pre-supplied functions. The NetBSD 
> rc.d system likewise reduced rc.d scripts to a few variable 
> assignments and function calls (in about two thirds of cases). 

The initial release of OpenRC - still Gentoo's 'native' system for 
service management - was in April 2007; the initial release of 
systemd was in March 2010. But although both OpenRC and systemd 
address various pain points of Sys V rc on Linux, systemd has 
_also_ had the backing of an 800-pound gorilla in the Linux world 
- Red Hat - which has _implicitly_ forced its adoption over 
alternatives by distros that don't have the same level of 
resources behind them.

Here's an excerpt from something i wrote on the Gentoo forum back 
in April:

> There's been so much anger and vitriol expressed about 
> systemd. Has that significantly slowed the systemd juggernaut? 
> Not really. Not least because, as in the case of D-Bus, and as 
> in the case of Wayland, it addresses very real issues for 
> significant numbers of people.
>
> For example: unlike on, say, OpenBSD, which has developed a 
> pretty clean shell-script-based service management system, with 
> a 'standard library' in the form of rc.subr(8), the situation on 
> Linux was a mess. Many of the (usually volunteers) who maintain 
> packages for Linux don't want to have to learn the complexities 
> of shell scripting and the subtle issues that can arise, or 
> develop and maintain workarounds for race conditions, and so 
> on. systemd comes along and says: "Hey, with systemd, you'll be 
> able to write service definitions declaratively; you won't need 
> to wrangle shell scripts." That's a pretty attractive 
> proposition to a number of package maintainers, and in the 
> absence of systemd alternatives explicitly providing such an 
> interface - not just saying "oh that could be done on our 
> alternative" - those maintainers are going to be inclined 
> towards systemd, regardless of what design and implementation 
> issues are involved in systemd's approach.
>
> So in wanting to try to ensure that myself and others have 
> choices and alternatives available, i feel that ranting against 
> the incoming tide, like a tech King Cnut, is typically far less 
> effective than actually putting in the work to develop and 
> support those choices and alternatives. 


Alexis.