[TUHS] Version 256 of systemd boasts '42% less Unix philosophy' The Register
Wesley Parish
wobblygong at gmail.com
Sun Jun 16 16:43:40 AEST 2024
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
More information about the TUHS
mailing list