Too true. Systemd offered the pot of gold as long as you handed it the keys to the kingdom.
Runit still requires work, but less work if a package for scripts exists. The most arbitrary need is the Stage scripts, which generally can utilize a general script setup, or translated init shell scripts.
I've worked with Runit enough to see that many distributions wanted ready-to-use, not more hackfests to redo run script are run script.
The problem is, Runit solved every problem with system management and service supervision before systemd, but because few were willing to create scripts, it fell off the radar. Runit is a very complete init+supervision suite in all respects and regards, but it needed scripts.
And believe me, after you debug a script about 10 times and sshd still refuses to stay in the up state and available, it makes you want to rip hair out.
Sent from my Windows Phone
________________________________
From: post-sysv<mailto:boycottsystemd_at_openmailbox.org>
Sent: 6/16/2015 1:35 PM
To: supervision_at_list.skarnet.org<mailto:supervision_at_list.skarnet.org>
Subject: Re: comparison
Implying that the distributions would have transitioned from System
V-style to daemontools-style mechanisms?
Strongly doubt it.
For all the noise and controversy that's been happening over PID1, I
always got the impression that most distros back in the day simply
didn't care. They happily piled on hack after hack to their messy
sysvinit setups in the form of dependency header parsers (as
standardized by LSB and done through insserv(8), asynchronous executors
(startpar), generic tools like start-stop-daemon(8) to get around the
fact that they never wrote a common initscript library, symlinking
/bin/sh to dash to improve startup speeds, etc.
There were alternatives like initng (which Ubuntu for some reason
skipped over and settled on Upstart instead with its awkward event
model), depinit, minit, eINIT, daemontools derivatives and others for
quite a while, but mainstream distros by and large never expressed much
interest in them. Instead, they drowned themselves in quick fixes until
the boot process unsurprisingly became difficult to maintain.
Soon systemd arrives with its promise of being a unified userspace
toolkit that systems developers can supposedly just plug in and
integrate without hassle to get X, Y and Z advantages. No more writing
initscripts, no more setting policy because systemd will do as much as
it can for you. A lazy package maintainer's dream, ostensibly.
Everyone hops on the bandwagon and there you are. Now we get to hear
about how systemd solves so many long-standing problems with the
distributions, but I can't shake the feeling that many of them were
self-inflicted through indifference and/or incompetence.
On 06/16/2015 04:09 PM, James Powell wrote:
> And supervision-scripts has been that generic profile that can be used in 99% of situations. Sadly, Avery, I wish we could have had your work about 8 years ago. The UNIX world might have been a vastly different place.
Received on Tue Jun 16 2015 - 20:53:41 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:19 UTC