Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 10 Dec 2024 09:23:13 -0000 (UTC), Muttley wrote:
>
>> But the core part should really just be limited to starting the
>> machine and getting enough things running for a user to log on (or
>> if its a black box to do its task).
>
> One thing lacking from sysvinit is, while it can start a service, it
> cannot ensure the service was started properly, and it cannot perform
> reliable service shutdown. So the job of service management was really
> only half-done.

sysvinit has no concept of 'service.'

"Service started properly" is a pointless historical property because
"service was running propery 1ms" ago doesn't mean "service is still
running properly now" (that's one of the classic TOCTOU races everybody
just loves to ignore).

It's unclear what "reliable service shutdown" is supposed to mean. It's
possible to stop a somehow monitored process (not service) reliably (or
sort-of reliably) by killing it if it didn't terminate on its own
within some amount of time after a SIGTERM was sent to it. This works
perfectly with a special-purpose tool for that and doesn't need any
giant wolpertingers implemented with hundredthousands of lines of
overcomplicated C code.

On Tue, 10 Dec 2024 20:55:05 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>On Tue, 10 Dec 2024 09:23:13 -0000 (UTC), Muttley wrote:
>
>> But the core part should really just be limited to starting the
>> machine and getting enough things running for a user to log on (or
>> if its a black box to do its task).
>
>One thing lacking from sysvinit is, while it can start a service, it
>cannot ensure the service was started properly, and it cannot perform
>reliable service shutdown. So the job of service management was really
>only half-done.

It doesn't need to , it can just spawn off a script or some other program
which does that which is entirely inline with the unix philosophy. Something
Poettering never understood.

On Wed, 11 Dec 2024 08:33:29 -0000 (UTC), Muttley wrote:

> On Tue, 10 Dec 2024 20:55:05 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>
>> One thing lacking from sysvinit is, while it can start a service, it
>> cannot ensure the service was started properly, and it cannot perform
>> reliable service shutdown. So the job of service management was really
>> only half-done.
>
> It doesn't need to , it can just spawn off a script or some other
> program which does that which is entirely inline with the unix
> philosophy.

Which is where the trouble starts.

> Something Poettering never understood.

Poettering understands that services don’t just to be started, they also
need to be managed and shut down cleanly.

On 2024-12-11, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 11 Dec 2024 08:33:29 -0000 (UTC), Muttley wrote:
>
>> On Tue, 10 Dec 2024 20:55:05 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>>
>>> One thing lacking from sysvinit is, while it can start a service, it
>>> cannot ensure the service was started properly, and it cannot perform
>>> reliable service shutdown. So the job of service management was really
>>> only half-done.
>>
>> It doesn't need to , it can just spawn off a script or some other
>> program which does that which is entirely inline with the unix
>> philosophy.
>
> Which is where the trouble starts.
>
>> Something Poettering never understood.
>
> Poettering understands that services don???t just to be started, they also
> need to be managed and shut down cleanly.

My God, how did we all manage running services before systemd came along?

Jim Jackson , dans le message <slrnvlk56u.2qa.jj@iridium.wf32df>, a
écrit :
> My God, how did we all manage running services before systemd came along?

Badly, with services that have crashed and nobody noticed for weeks.

Some teams have been working on better replacement for SysV init, but
without the industrial strength of Red Hat they could only stay niche.

Nicolas George <nicolas$george@salle-s.org> writes:

> Jim Jackson , dans le message <slrnvlk56u.2qa.jj@iridium.wf32df>, a
> écrit :
>> My God, how did we all manage running services before systemd came along?
>
> Badly, with services that have crashed and nobody noticed for weeks.
>
> Some teams have been working on better replacement for SysV init, but
> without the industrial strength of Red Hat they could only stay niche.

Jonathan de Boyne Pollard, creator of the Nosh system[a], has written an
article about "known problems with System 5 rc":

https://jdebp.uk/FGA/system-5-rc-problems.html

i've used runit and s6+66 on Void Linux, and on Gentoo am currently
using OpenRC+s6 (the latter for providing user services, which are are
still a work in progress under OpenRC[b]):

https://wiki.gentoo.org/wiki/User:Flexibeast/guides/OpenRC_user_services_via_s6

My own case is certainly niche, though s6 is extensively used for
containers, via the s6-overlay project, which currently has ~3.8k stars
on GitHub:

https://github.com/just-containers/s6-overlay

Alexis.

[a] https://jdebp.uk/Softwares/nosh/

[b] https://github.com/OpenRC/openrc/pull/723

On 11 Dec 2024 23:34:39 GMT, Nicolas George wrote:

> Some teams have been working on better replacement for SysV init, but
> without the industrial strength of Red Hat they could only stay niche.

I wonder what you think Red Hat’s business model could be in forcing
competitors to adopt technology they developed without paying for it.

On Wed, 11 Dec 2024 22:26:56 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>On Wed, 11 Dec 2024 08:33:29 -0000 (UTC), Muttley wrote:
>
>> On Tue, 10 Dec 2024 20:55:05 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>>
>>> One thing lacking from sysvinit is, while it can start a service, it
>>> cannot ensure the service was started properly, and it cannot perform
>>> reliable service shutdown. So the job of service management was really
>>> only half-done.
>>
>> It doesn't need to , it can just spawn off a script or some other
>> program which does that which is entirely inline with the unix
>> philosophy.
>
>Which is where the trouble starts.

The trouble is with any support scripts, not with init. I've written a
number of init scripts with a lot of surrounding logic. God knows how I'd
do that with systemd short of just getting it to call the exact same script
which rather defeats the purpose of having systemd.

>> Something Poettering never understood.
>
>Poettering understands that services don’t just to be started, they also
>need to be managed and shut down cleanly.

Poettering created the wrong solution to the wrong problem.

On Thu, 12 Dec 2024 08:27:39 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>On 11 Dec 2024 23:34:39 GMT, Nicolas George wrote:
>
>> Some teams have been working on better replacement for SysV init, but
>> without the industrial strength of Red Hat they could only stay niche.
>
>I wonder what you think Red Hat’s business model could be in forcing
>competitors to adopt technology they developed without paying for it.

Dead Rat was the darling of the business community for a long time - even more
so once IBM bought it. It was effectively a replacement for Solaris, HP-UX and
AIX. So the other distros thought they needed to follow suite in order to pick
up some of that market. Whether that worked or not I don't know, but its left
us with this legacy of systemd infesting just about every mainstream distro.

Alexis , dans le message <87bjxhnwpz.fsf@gmail.com>, a écrit :
> My own case is certainly niche, though s6 is extensively used for
> containers, via the s6-overlay project, which currently has ~3.8k stars
> on GitHub:

I am rather pleased to ear that s6 has some success, although I know all the
ill its author thinks of containers.

On Thu, 12 Dec 2024 09:38:58 -0000 (UTC), Muttley wrote:

> So the other distros thought they needed to
> follow suite in order to pick up some of that market.

Something you pulled out of your fevered imagination, no doubt.

On Thu, 12 Dec 2024 08:39:07 -0000 (UTC), Muttley wrote:

> On Wed, 11 Dec 2024 22:26:56 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>> On Wed, 11 Dec 2024 08:33:29 -0000 (UTC), Muttley wrote:
>>
>>> It doesn't need to , it can just spawn off a script or some other
>>> program which does that which is entirely inline with the unix
>>> philosophy.
>>
>> Which is where the trouble starts.
>
> The trouble is with any support scripts, not with init. I've written a
> number of init scripts with a lot of surrounding logic.

I’m sure you have. Which means you are familiar with the wholesale copying
and pasting of boilerplate from one script to the next. “What does this
bit do?” “Don’t bother thinking too hard, just stick it in, just in case.”

> God knows how I'd do that with systemd ...

Figure out what the directives do (they’re all documented), and which
settings will achieve the result you want. Most of the time, your service
file will be very simple and very short, since all the common cases are
already covered.

“Simple things should be simple, and complex things should be possible.”
-- Alan Kay

He was talking about GUI design, but the same applies to systemd. And to a
lot of other popular *nix software, while we’re at it.

>> Poettering understands that services don’t just to be started, they al
>> so need to be managed and shut down cleanly.
>
> Poettering created the wrong solution to the wrong problem.

Lots of sysadmins, and distro maintainers, and developers of service apps,
disagree.

Think of how simple it is to log error messages now: systemd automatically
captures stderr, and shows it in your service status and in the journal.

On Thu, 12 Dec 2024 22:31:50 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>On Thu, 12 Dec 2024 08:39:07 -0000 (UTC), Muttley wrote:
>> The trouble is with any support scripts, not with init. I've written a
>> number of init scripts with a lot of surrounding logic.
>
>I’m sure you have. Which means you are familiar with the wholesale copying
>and pasting of boilerplate from one script to the next. “What does this
>bit do?” “Don’t bother thinking too hard, just stick it in, just in
>case.”

Its a few lines of code and usually one just copies a simple rc file and
starts from there.

>> God knows how I'd do that with systemd ...
>
>Figure out what the directives do (they’re all documented), and which

Why TF would I want to have to leanr Yet Another Config Language when in
shell script I have a turing complete language that can do anything with the
system? You might as well say "Don't bother with that car, use this pushbike
instead."

>> Poettering created the wrong solution to the wrong problem.
>
>Lots of sysadmins, and distro maintainers, and developers of service apps,
>disagree.

Sheep exist even i open source. That other abortion poetrring wrote pulseaudio
was shoved into every distro until people realised that all it did was
remove the complexity of Alsa and add its own complexity in exchange. And
being built on alsa it simply added another layer and hence delay into the
sound system where you REALLY don't want delays.

>Think of how simple it is to log error messages now: systemd automatically
>captures stderr, and shows it in your service status and in the journal.

Oh wow, is there no end to its magical abilities!

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 12 Dec 2024 08:39:07 -0000 (UTC), Muttley wrote:
>> On Wed, 11 Dec 2024 22:26:56 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>> On Wed, 11 Dec 2024 08:33:29 -0000 (UTC), Muttley wrote:
>>>
>>>> It doesn't need to , it can just spawn off a script or some other
>>>> program which does that which is entirely inline with the unix
>>>> philosophy.
>>>
>>> Which is where the trouble starts.
>>
>> The trouble is with any support scripts, not with init. I've written a
>> number of init scripts with a lot of surrounding logic.
>
> I’m sure you have. Which means you are familiar with the wholesale copying
> and pasting of boilerplate from one script to the next. “What does this
> bit do?” “Don’t bother thinking too hard, just stick it in, just in
> case.”

Nobody but you can be familiar with what you are doing when being forced
to write code.

>> God knows how I'd do that with systemd ...
>
> Figure out what the directives do (they’re all documented), and which
> settings will achieve the result you want. Most of the time, your service
> file will be very simple and very short, since all the common cases are
> already covered.
>
> “Simple things should be simple, and complex things should be possible.”
> -- Alan Kay

According to an automated count (mostly perl -ne 'print $_, "\n" for
/\w+=/g') the current version of systemd supports about 320
directives and people still combine that with start scripts, be this
because their use case still isn't supported or because they didn't want
to be bothered with learning about all the details of this huge, rusted
barbed wire obstacle just for solving a simple problem.

The quote would thus more appropriate be:

Make simple things hideously complicated and complicated things at all
impossible.

-- Lennart Poettering about "How to create problems for other people for one's
own benefit."

> He was talking about GUI design, but the same applies to systemd. And to a
> lot of other popular *nix software, while we’re at it.
>
>>> Poettering understands that services don’t just to be started, they al
>>> so need to be managed and shut down cleanly.
>>
>> Poettering created the wrong solution to the wrong problem.
>
> Lots of sysadmins, and distro maintainers, and developers of service apps,
> disagree.

Due to human nature, lots of people will always disagree with anything.

On Fri, 13 Dec 2024 10:38:51 -0000 (UTC)
Muttley@DastardlyHQ.org wrote:

> That other abortion poetrring wrote pulseaudio was shoved into every
> distro until people realised that all it did was remove the
> complexity of Alsa and add its own complexity in exchange. And being
> built on alsa it simply added another layer and hence delay into the
> sound system where you REALLY don't want delays.

This bears repeating. Why *anybody* decided to trust the judgement of
the person who gave us the jankiest of all the incredibly janky *nix
audio subsystems is beyond comprehension.

On 2024-12-11, Nicolas George <nicolas$george@salle-s.org> wrote:
> Jim Jackson , dans le message <slrnvlk56u.2qa.jj@iridium.wf32df>, a
> ?crit?:
>> My God, how did we all manage running services before systemd came along?
>
> Badly, with services that have crashed and nobody noticed for weeks.

People keep saying that. But in my experience services were run as
efficiently as they seem to be run today. Perhaps the team I worked in
knew what it was doing :-)

>> The trouble is with any support scripts, not with init. I've written a
>> number of init scripts with a lot of surrounding logic.
>
> I???m sure you have. Which means you are familiar with the wholesale copying
> and pasting of boilerplate from one script to the next. ???What does this
> bit do???? ???Don???t bother thinking too hard, just stick it in, just in case.???

Ah describing bad programming practice. The same thing happens when
people just cut and paste anything without knowing what they are doing.

>
>> God knows how I'd do that with systemd ...
>
> Figure out what the directives do (they???re all documented), and which
> settings will achieve the result you want.

Nah, as you say above just cut and paste and not think about any diffiicult
bits you need to read up on :-)

> Most of the time, your service
> file will be very simple and very short, since all the common cases are
> already covered.
>
>>> Poettering understands that services don???t just to be started, they al
>>> so need to be managed and shut down cleanly.

Actually a service should know how to shutdown itself cleanly and should
document how that is achieved.

On Fri, 13 Dec 2024 20:07:58 -0000 (UTC), Jim Jackson wrote:

> On 2024-12-11, Nicolas George <nicolas$george@salle-s.org> wrote:
>>
>> Jim Jackson , dans le message <slrnvlk56u.2qa.jj@iridium.wf32df>, a
>> écrit :
>>>
>>> My God, how did we all manage running services before systemd came
>>> along?
>>
>> Badly, with services that have crashed and nobody noticed for weeks.
>
> People keep saying that. But in my experience services were run as
> efficiently as they seem to be run today. Perhaps the team I worked in
> knew what it was doing :-)

How many custom services were you running on a single machine, just out of
curiosity?

On Fri, 13 Dec 2024 07:42:07 -0800, John Ames wrote:

> This bears repeating. Why *anybody* decided to trust the judgement of
> the person who gave us the jankiest of all the incredibly janky *nix
> audio subsystems is beyond comprehension.

There was no reason why you had to. You could easily have created your own
distro without any of his code in it, if you wanted to. Or become an
aficionado of one of the existing distros that did exactly that.

Open Source is all about choice. If you can’t stand the thought of people
making different choices from you, you know what you can do.

In article <vinp86$avd9$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 3 Dec 2024 08:20:51 -0000 (UTC), Muttley wrote:
>
>> I'm wondering on Linux if it would be enough on Linux to spoof ttyname()
>> and isatty() using LD_PRELOAD. However it seems doing something similar
>> on a Mac is the usual over complicated Apple hot mess.
>
> macOS may be a licensee of the “Unix” trademark, but it does not work the
> way people expect when they think of the term “Unix”.

It probably does as of the version of the formal specification they met
to be allowed to use the trademark.

Other features that are customary but not entirely standardized
may be implemented differently if at all, possibly with different
side-effects or complications.

Pretty sure I've some time ago used the equivalent of LD_PRELOAD on
macOS to wrap some existing library function, with very little change
to the C code, but some change to compiler options, environment
variables required, etc. For instance, one might need compiler flags
-fPIC -dynamiclib

which might be different from other platforms. And the environment variable
for macOS instead of LD_PRELOAD (from the dyld man page) is
DYLD_INSERT_LIBRARIES
This is a colon separated list of additional dynamic libraries to
load before the ones specified in the program. If instead, your
goal is to substitute a library that would normally be loaded, use
DYLD_LIBRARY_PATH or DYLD_FRAMEWORK_PATH instead.

However I just tried this with some old preloadable modules (of
suitable architecture), and it no longer seems to work. Not sure what
else I have to do now. Maybe this changed/broke when most dynamic libraries
were replaced by a pre-linked cache files that would map in in their entirety
at reserved address(es). Faster, more secure, but maybe less flexible.
Haven't googled enough yet to find the answer, if any.

In article <vit3dg$1quau$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 5 Dec 2024 08:19:46 -0000 (UTC), Muttley wrote:
>
>> On Thu, 5 Dec 2024 02:11:04 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>>
>>>On Wed, 4 Dec 2024 08:34:30 -0000 (UTC), Muttley wrote:
>>>
>>>> Linux is far closer to the unix philosphy (ignoring systemd) ...
>>>
>>>Which “unix philosophy” would that be?
>>
>> The one where init does a single task instead of spreading itself
>> throughout the system ...
>
> What “single task” did init do?
>
> * Mount filesystems
> * Spawn syslog, cron
> * Spawn terminal login processes (getty)
> * Respawn terminated getty processes
> * Monitor other special stuff in inittab
> * Spawn random other services, without monitoring their state
> * Act as a general catch-all for orphaned processes when they terminate
>
> This was all before systemd came on the scene.

It spawned other processes, and where the idea of run levels existed,
selected what to spawn based on those.

It did not do tricky communication with processes, elaborately
manipulate their initial environment, and except for adopting orphans
and respawning processes, didn't do much at all to bother them during
their lifespan unless the run level was changed.

MacOS launchd is arguably even worse insofar as it also has things like
Mach namespaces to deal with.

In article <vj16j0$30r12$1@dont-email.me>,
Muttley@dastardlyhq.com writes:
> On Fri, 6 Dec 2024 20:00:54 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> gabbled:
>>On Fri, 6 Dec 2024 10:28:15 -0000 (UTC), Muttley wrote:
>>
>>> On Thu, 5 Dec 2024 20:45:36 -0000 (UTC)
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wibbled:
>>>
>>>> What “single task” did init do?
>>>
>>> Boot the system to usable state.
>>
>>What would you say systemd does that is not related to that?
>
> Networking, including DNS
> Graphics
> Logging
> systemd-boot
>
> Basically init should start the system, maintain some the running of
> some essential daemons and then leave well alone.
>

On Solaris 10 and later, svc.startd does most spawning and respawning
and such, and uses a "contract" mechanism to be able to keep track of
and if needed kill off otherwise daemonized processes (sshd needs a
compile time option so it only kills the listening sshd and not the
children handling processes - which need to explicitly break their
"contract", otherwise an admin restarting sshd over ssh will kick
themselves out; but for the vast majority of other code, the contract
mechanism does what one might hope with no modification needed to the
code of what it controls)).

But it still has init, although init does little more than start or
control svc.startd (but you could configure it to start something
outside of the control of svc.startd if you really wanted to).

What's the point of svc.startd there? It with the relevant service
configuration files can handle dependencies among services (processes
or other actions) to be started, starting in parallel any whose
dependencies are satisfied; with sufficient hardware threads, that can
provide faster startup. And it can use the aforementioned contract
mechanism to stay more in control, and will fix simple things by
restarting, albeit not if they keep faulting too rapidly. It interacts
with fault management (which also deals with hardware issues) to
provide a consolidated handing of both daemon and hardware issues, for
greater fault tolerance.

For Solaris systems isolated enough that they didn't need regular security
updates, I've seen uptimes in years, so they're probably doing something
right (that they mostly have ECC RAM helps a lot, too). @home, I seldom
get those uptimes, in part because I don't have UPS for everything. :-)

In article <vj1rp1$363i0$1@dont-email.me>,
Muttley@dastardlyhq.com writes:
> On Sat, 7 Dec 2024 15:00:50 -0000 (UTC)
> gazelle@shell.xmission.com (Kenny McCormack) gabbled:
>>In article <vj16j0$30r12$1@dont-email.me>, <Muttley@dastardlyhq.com> wrote:
>>....
>>>>What would you say systemd does that is not related to that?
>>>
>>>Networking, including DNS
>>>Graphics
>>>Logging
>>>systemd-boot
>>>
>>>Basically init should start the system, maintain some the running of
>>>some essential daemons and then leave well alone.
>>
>>I agree with you. But it underscores a major difference between two very
>>different ways of thinking about computing, which can be described as
>>"Unix-think" vs. "Windows-think".
>>
>>systemd represents nothing so much as the bringing of "Windows-think" to Unix.
>>
>>If one embraces "Windows-think", then systemd makes complete sense.
>
> Yes, I've heard that said before and it does ring true. I guess we should be
> thankful that systemd still uses text based config but I wouldn't be surprised
> if some Windows like binary registry isn't somewhere on the horizon. Of course
> Poettering has worked for MS for a long time so one can see where all his bad
> ideas come from.j

AIX ("AIX Isn't uniX") has something like a registry, as I recall.

Even on Solaris, although the configuration files may still mostly be text,
there's a tendency toward commands that do the actual configuring. In a way,
that's safer since they can offer sanity checks before changes actually take
effect.

On Fri, 13 Dec 2024 07:42:07 -0800
John Ames <commodorejohn@gmail.com> gabbled:
>On Fri, 13 Dec 2024 10:38:51 -0000 (UTC)
>Muttley@DastardlyHQ.org wrote:
>
>> That other abortion poetrring wrote pulseaudio was shoved into every
>> distro until people realised that all it did was remove the
>> complexity of Alsa and add its own complexity in exchange. And being
>> built on alsa it simply added another layer and hence delay into the
>> sound system where you REALLY don't want delays.
>
>This bears repeating. Why *anybody* decided to trust the judgement of
>the person who gave us the jankiest of all the incredibly janky *nix
>audio subsystems is beyond comprehension.

Agreed. On a side note, its a shame the original authors of X didn't decide
to do sound too or at least provide an API that others could build extensions
to use because by the time X - or at least X11 - was adopted unix had moved on
from cabinet sized servers to desktop workstations where sound mattered. It
seems odd to me that graphics and sound are still totally seperate on unix
but perhaps my formative years on 8 bit home micros where graphics and sound
came bundled skew my opinion.

On Sat, 14 Dec 2024 08:48:00 GMT
rlhamil@smart.net (Richard L. Hamilton) gabbled:
>However I just tried this with some old preloadable modules (of
>suitable architecture), and it no longer seems to work. Not sure what
>else I have to do now. Maybe this changed/broke when most dynamic libraries
>were replaced by a pre-linked cache files that would map in in their entirety
>at reserved address(es). Faster, more secure, but maybe less flexible.
>Haven't googled enough yet to find the answer, if any.

Probably something to do with security. Apple have really nailed MacOS down
in recent releases. I looked at how to do it for recent versions and just
decided I couldn't be bothered. Seemed to require putting macros in code and
I just thought nah.