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

[Wesley Parish]

On 16/06/24 17:48, Alexis wrote:
> 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.

Might also be worth pointing out that Red Hat's an IBM *nix daemon, and 
IBM's mainframe business is built in no small part on service managers 
in the OS management layer. I expect their "Phone Home" ability was 
part-and-parcel of the IBM mainframe service contracts. If systemd 
phones home without an explicit (ie, sign-on-the-dotted-line type) 
contract between me and Red Hat, I'll raise a stink about - but so far 
it hasn't. (I'm running Fedora.)

Wesley Parish