On Tue, 17 Dec 2024 19:48:51 +0000, Richard Kettlewell wrote:

> Whether systemd was the best possible design, or just the best option
> available, is another question, and perhaps more opinion-based.

There were, and are, other open-source choices available. Nobody is
holding a gun to anybody’s head.

Richard Kettlewell <invalid@invalid.invalid> writes:
> Jim Jackson <jj@franjam.org.uk> writes:
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Mon, 16 Dec 2024 07:55:19 -0800, John Ames wrote:
>>>> The fact that people are free to make stupid choices does not mean
>>>> that other people aren't allowed to call out stupidity where they
>>>> see it.
>>>
>>> Notice that all the complaints seem to go in one direction, not the
>>> other? We only see systemd-haters complaining about those using it,
>>> you don???t see systemd users complaining about those who don???t?
>>
>> No. But I think some of us get a bit pissed at some people making out
>> that previous inits were (almost) unworkable - which is palpably false.
>
> ‘Unworkable’ may be an exaggeration, but the practical issues and
> functionality gaps were real; even if you didn’t personally experience
> them, other people did. I think there were at least ten different
> attempts to come up with something better in the free software world
> alone. Meanwhile the commercial Unixes largely got their act together
> long before Linux did.

Practical issue and functionality gaps and generally, a load of useless
mess, were real in the rc systems mainstream Linux distributions had
conventionally layered atop of sysvinit. These could have been addressed
in a variety of ways but basically, nobody _working for RedHat_ ever
tried until systemd. Then, RedHat drove the pretty much universal switch
to it, just as it had already driven the switch to sysvinit and to glibc
2 (known as libc6 in Linuxland) before.

> Whether systemd was the best possible design, or just the best option
> available,

or possibly neither of both. It was the RedHat option available and
that's what caused its universal adoption (combined with an extremely
aggressive and extremely unpleasant propaganda campaign by systemd
fanbois --- but without RedHat, these wouldn't have accomplished
anything).

BTW, on of the first things I learnt about systemd after I had to
support it was that it still uses pid files.

In article <vjsnsr$1t88k$2@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Tue, 17 Dec 2024 19:48:51 +0000, Richard Kettlewell wrote:
>
>> Whether systemd was the best possible design, or just the best option
>> available, is another question, and perhaps more opinion-based.
>
>There were, and are, other open-source choices available. Nobody is
>holding a gun to anybodys head.

As you well know, in a way, they are. In many circles, you can't get any
support unless you are running the "approved" stuff, which means running
systemd. Also, there are apps that depend on systemd, so if you want to
run GreatNewApp_2.0, you need to adopt systemd.

--
The only thing Trump's made great again is Saturday Night Live.

On 2024-12-17, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 16 Dec 2024 23:03:46 -0000 (UTC), Jim Jackson wrote:
>
>> Ok I've done specific network monitoring stuff from scratch - back in
>> the day, when SNMP was a new thing. But it was easier to control than
>> other stuff because I (and a couple of others) wrote it - we knew it -
>> so what's difficult? We even transitioned it from pre-SYS-V init to
>> SYS-V init, and I remember no difficulties.
>
> Anything with this <https://www.phoronix.com/news/Facebook-systemd-2018>
> level of complexity?

Of course not - what a silly question. And the interesting thing was
that their set up is SO complicated systemd is only a part of their
solutions, which is sort of obvious. I'd have been more interested in a
comparison of previous set up v. current with systemd.

Their process for non-stop upgrades was a fairly standard one of old
service handing over to new and having to notify and co-operate with
systemd because systemd handles new connections. Previously I suspect
their processes handled incoming connections directly and there would
have been process-process link to do the hand over. Which one works out
easier to program and manage I'm not sure. But given they'd gone for a
solution Centos which had systemd init they had to adapt to it.

Anyway it was interesting thanks for the pointer.

Jim Jackson <jj@franjam.org.uk> writes:
>
>
>Their process for non-stop upgrades was a fairly standard one of old
>service handing over to new and having to notify and co-operate with
>systemd because systemd handles new connections. Previously I suspect
>their processes handled incoming connections directly and there would
>have been process-process link to do the hand over. Which one works out
>easier to program and manage I'm not sure. But given they'd gone for a
>solution Centos which had systemd init they had to adapt to it.

Modern non-stop systems route new connections at a higher level (e.g. netscaler)
for both load balancing and resiliancy. systemd is not (thankfully)
involved in that at all.

On 2024-12-18, Scott Lurndal <scott@slp53.sl.home> wrote:
> Jim Jackson <jj@franjam.org.uk> writes:
>>
>>
>>Their process for non-stop upgrades was a fairly standard one of old
>>service handing over to new and having to notify and co-operate with
>>systemd because systemd handles new connections. Previously I suspect
>>their processes handled incoming connections directly and there would
>>have been process-process link to do the hand over. Which one works out
>>easier to program and manage I'm not sure. But given they'd gone for a
>>solution Centos which had systemd init they had to adapt to it.
>
> Modern non-stop systems route new connections at a higher level (e.g. netscaler)
> for both load balancing and resiliancy. systemd is not (thankfully)
> involved in that at all.

Indeed, and for over 20 years. But, the talk did describe the adaptations
needed for running a non-stop service on top of systemd on a single box.