On Thu, 28 Apr 2022 at 19:39, Dave Ihnat <dihnat@dminet.com> wrote:

On 28 Apr at 17:27, Tom Horsley <horsley1953@gmail.com> wrote:
> But systemd-timedated tries to supplant them all :-). This is where
> my "computer fungus" description comes from. Every systemd release
> seems to take over something else that worked fine without systemd
> engulfing it.
[...]
And everything that we wanted to avoid is resurfacing with systemd. It's
become a glop of totally unrelated features and services, difficult
to diagnose and maintain, and prone to unwanted and unforseen
interactions. Tug this strand, and the spiderweb shivers.

In my experience, init.d scripts suffered from lack of the sort of filtering

we get with the kernel. The world is very different today. If you had a

problem with some init script it was faster to fix it yourself than to deal

with the vendor's technical support by email or get a response from

a usenet group for your flamor of UNIX.

Linux now has a wide range of use cases, from data centers run by

internet "giants" to schools and individuals trying to make the best of

tight budgets. We have many distributions and spins because they

meet the needs of groups large enough to warrant the effort. Debian

still provides init, but it is up to packagers to choose whether to provide

init scripts. Quoting from Init - Debian Wiki

Since jessie, only systemd is fully supported; sysvinit is mostly
supported, but Debian packages are not required to provide sysvinit
start scripts. Support for init systems other than systemd is significantly
improved in Bullseye. runit is also packaged, but has not received the
same level of testing and support as the others, and is not currently
supported as PID 1. As of Bullseye, a collection of sysvinit start scripts
that have been removed from their original packages is provided in the
orphan-sysvinit-scripts package.

It remains to be seen if there is significant adoption of init scripts and how often

packagers provide sysvinit scripts.

George N. White III