16 Jun
2024
16 Jun
'24
12:43 p.m.
On 16/06/24 17:48, Alexis wrote:
Grant Taylor via TUHS <tuhs(a)tuhs.org> writes:
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
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.