From: Wesley Parish <wobblygong@gmail.com>
To: tuhs@tuhs.org
Subject: [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register
Date: Sun, 16 Jun 2024 18:43:40 +1200 [thread overview]
Message-ID: <edb958c5-6d6d-42e3-9087-a79d56c822fa@gmail.com> (raw)
In-Reply-To: <87msnl4ew0.fsf@gmail.com>
On 16/06/24 17:48, Alexis wrote:
> Grant Taylor via TUHS <tuhs@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
next prev parent reply other threads:[~2024-06-16 6:43 UTC|newest]
Thread overview: 174+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-13 14:56 [TUHS] Version 256 of systemd boasts '42% less Unix philosophy' • " Charles H Sauer (he/him)
2024-06-13 15:33 ` [TUHS] " Dan Cross
2024-06-13 15:35 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy
2024-06-13 15:41 ` Alan D. Salewski
2024-06-13 15:55 ` Steve Nickolas
2024-06-13 15:39 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Clem Cole
2024-06-13 16:47 ` Arrigo Triulzi via TUHS
2024-06-13 18:39 ` segaloco via TUHS
2024-06-13 18:45 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Mychaela Falconia
2024-06-14 8:59 ` Ralph Corderoy
2024-06-13 18:54 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Dan Cross
2024-06-12 19:29 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' " Greg A. Woods
2024-06-13 20:03 ` Dan Cross
2024-06-13 17:07 ` Greg A. Woods
2024-06-14 14:17 ` Grant Taylor via TUHS
2024-06-16 5:48 ` Alexis
2024-06-15 8:48 ` Greg A. Woods
2024-06-16 19:44 ` Clem Cole
2024-06-17 0:10 ` Peter Yardley
2024-06-17 0:29 ` Clem Cole
2024-06-17 1:01 ` Alexis
2024-06-17 1:21 ` Warner Losh
2024-06-17 1:25 ` Larry McVoy
2024-06-17 1:32 ` Warner Losh
2024-06-17 19:21 ` Stuff Received
2024-06-17 19:28 ` Larry McVoy
2024-06-17 22:34 ` Steve Nickolas
2024-06-16 7:57 ` Greg A. Woods
2024-06-17 23:44 ` Warner Losh
2024-06-18 0:06 ` Larry McVoy
2024-06-18 22:44 ` Greg A. Woods
2024-06-19 2:33 ` David Arnold
2024-06-18 1:52 ` Steve Nickolas
2024-06-18 4:52 ` segaloco via TUHS
2024-06-18 22:50 ` Greg A. Woods
2024-06-18 23:03 ` Warner Losh
2024-06-18 23:27 ` ron minnich
2024-06-19 1:38 ` Greg 'groggy' Lehey
2024-06-19 1:42 ` Warner Losh
2024-06-19 23:28 ` Greg A. Woods
2024-06-20 5:01 ` Scot Jenkins via TUHS
2024-06-20 5:09 ` Luther Johnson
2024-06-20 5:18 ` Luther Johnson
2024-06-20 18:34 ` Greg A. Woods
2024-06-20 18:41 ` Adam Thornton
2024-06-20 19:59 ` Warner Losh
2024-06-20 20:12 ` ron minnich
2024-06-20 20:22 ` Adam Thornton
2024-06-20 20:29 ` ron minnich
2024-06-21 15:46 ` Chet Ramey via TUHS
2024-06-21 16:06 ` Henry Bent
2024-06-21 16:24 ` Chet Ramey via TUHS
2024-06-21 16:40 ` Henry Bent
2024-06-21 16:52 ` Warner Losh
2024-06-21 17:25 ` Chet Ramey via TUHS
2024-06-21 17:31 ` Phil Budne
2024-06-21 17:55 ` Chet Ramey via TUHS
2024-06-20 20:19 ` Clem Cole
2024-06-20 20:34 ` Luther Johnson
2024-06-20 21:00 ` ron minnich
2024-06-20 21:53 ` David Arnold
2024-06-20 22:00 ` ron minnich
2024-06-20 22:11 ` Larry McVoy
2024-06-20 22:35 ` Luther Johnson
2024-06-21 13:57 ` Stuff Received
2024-06-20 19:57 ` [TUHS] Version 256.1: Now slightly less likely to delete /home Jim Capp
2024-06-20 8:05 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' The Register Steve Nickolas
2024-06-19 2:38 ` David Arnold
2024-06-19 22:52 ` Greg A. Woods
2024-06-19 0:08 ` Luther Johnson
2024-06-19 0:46 ` Nevin Liber
2024-06-19 1:00 ` segaloco via TUHS
2024-06-19 3:07 ` Luther Johnson
2024-06-19 3:14 ` Luther Johnson
2024-06-19 3:36 ` Luther Johnson
2024-06-19 6:50 ` arnold
2024-06-19 11:28 ` sjenkin
2024-06-19 9:00 ` Ralph Corderoy
2024-06-19 13:28 ` Larry McVoy
2024-06-19 14:44 ` Warner Losh
2024-06-19 14:53 ` Larry McVoy
2024-06-19 15:08 ` Warner Losh
2024-06-19 15:11 ` G. Branden Robinson
2024-06-19 15:16 ` ron minnich
2024-06-19 15:59 ` Theodore Ts'o
2024-06-19 22:48 ` Kevin Bowling
2024-06-20 5:14 ` David Arnold
2024-06-20 5:32 ` George Michaelson
2024-06-20 6:37 ` Alexis
2024-06-20 7:07 ` David Arnold
2024-06-20 21:07 ` [TUHS] Building programs (Re: " Bakul Shah via TUHS
2024-06-20 23:35 ` [TUHS] " Alexis
2024-06-21 0:05 ` Warner Losh
2024-06-21 0:34 ` Alexis
2024-06-21 0:54 ` Greg A. Woods
2024-06-21 1:06 ` G. Branden Robinson
2024-06-21 1:32 ` Alexis
2024-06-21 1:43 ` Warner Losh
2024-06-21 16:07 ` Chet Ramey via TUHS
2024-06-21 0:35 ` Bakul Shah via TUHS
2024-06-21 1:15 ` Alexis
2024-06-21 1:43 ` segaloco via TUHS
2024-06-21 13:58 ` Alan D. Salewski
2024-06-21 0:35 ` Larry McVoy
2024-06-21 0:49 ` Alexis
2024-06-21 1:22 ` Greg A. Woods
2024-06-21 1:44 ` Kevin Bowling
2024-06-21 15:57 ` Chet Ramey via TUHS
2024-06-22 0:04 ` Alexis
2024-06-22 17:53 ` Chet Ramey via TUHS
2024-06-22 18:15 ` Luther Johnson
2024-06-22 21:16 ` David Arnold
2024-06-23 0:29 ` segaloco via TUHS
2024-06-23 18:50 ` Theodore Ts'o
2024-06-23 18:56 ` Chet Ramey via TUHS
2024-06-23 20:15 ` Stuff Received
2024-06-24 14:03 ` Theodore Ts'o
2024-06-24 14:33 ` Dan Cross
2024-06-24 15:17 ` Warner Losh
2024-06-24 15:23 ` Chet Ramey via TUHS
2024-06-21 15:41 ` [TUHS] " Chet Ramey via TUHS
2024-06-21 15:38 ` Chet Ramey via TUHS
2024-06-20 20:14 ` Alexander Schreiber
2024-06-16 6:43 ` Wesley Parish [this message]
2024-06-16 21:56 ` David Arnold
2024-06-16 23:34 ` Luther Johnson
2024-06-16 23:46 ` Larry McVoy
2024-06-17 21:40 ` Steffen Nurpmeso
2024-06-17 0:54 ` Åke Nordin
2024-06-18 5:55 ` Alexis
2024-06-18 6:39 ` Michael Kjörling
2024-06-13 19:37 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Alan D. Salewski
2024-06-13 20:05 ` Clem Cole
2024-06-13 20:31 ` Bakul Shah via TUHS
2024-06-13 20:06 ` A. P. Garcia
2024-06-13 20:26 ` Jim Capp
2024-06-13 21:35 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy
2024-06-14 0:27 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Alexis
2024-06-14 0:59 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' ??? " Larry McVoy
2024-06-14 1:11 ` Luther Johnson
2024-06-14 1:42 ` Alexis
2024-06-14 4:22 ` ron minnich
2024-06-14 6:54 ` Angel M Alganza
2024-06-14 7:04 ` Dave Horsfall
2024-06-14 7:33 ` arnold
2024-06-14 7:34 ` Andy Kosela
2024-06-14 7:44 ` Dave Horsfall
2024-06-14 11:31 ` Vincenzo Nicosia
2024-06-13 20:26 ` [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' • " Dave Horsfall
2024-06-14 11:32 ` Michael Kjörling
2024-06-14 12:21 ` A. P. Garcia
2024-06-18 12:02 ` Arrigo Triulzi via TUHS
2024-06-23 0:13 ` Dave Horsfall
2024-06-23 1:47 ` Alexis
2024-06-23 19:00 ` Theodore Ts'o
2024-06-23 20:04 ` Alexander Schreiber
2024-06-24 13:50 ` Theodore Ts'o
2024-06-24 14:21 ` Dan Cross
2024-06-26 7:39 ` Kevin Bowling
2024-06-24 15:03 ` Steffen Nurpmeso
2024-06-17 0:48 [TUHS] Re: Version 256 of systemd boasts '42% less Unix philosophy' " Noel Chiappa
2024-06-17 1:02 ` Clem Cole
2024-06-17 1:05 ` Larry McVoy
2024-06-17 3:56 ` ron minnich
2024-06-17 3:57 ` ron minnich
2024-06-17 5:41 ` Bakul Shah via TUHS
2024-06-17 5:51 ` Bakul Shah via TUHS
2024-06-17 15:56 ` Clem Cole
2024-06-17 16:00 ` Clem Cole
2024-06-17 16:59 ` Charles H Sauer (he/him)
2024-06-17 16:43 ` Larry McVoy
2024-06-17 22:49 ` Steffen Nurpmeso
2024-06-20 16:45 Lyndon Nerenberg (VE7TFX/VE6BBM)
2024-06-20 18:32 ` Kevin Bowling
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=edb958c5-6d6d-42e3-9087-a79d56c822fa@gmail.com \
--to=wobblygong@gmail.com \
--cc=tuhs@tuhs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).