On Thu, 28 Apr 2022 at 19:39, Dave Ihnat <dihnat@xxxxxxxxxx> wrote:
On 28 Apr at 17:27, Tom Horsley <horsley1953@xxxxxxxxx> 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 mostlysupported, but Debian packages are not required to provide sysvinitstart scripts. Support for init systems other than systemd is significantlyimproved in Bullseye. runit is also packaged, but has not received thesame level of testing and support as the others, and is not currentlysupported as PID 1. As of Bullseye, a collection of sysvinit start scriptsthat have been removed from their original packages is provided in theorphan-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
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
