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:[email protected]> Sent: 6/16/2015 1:35 PM To: [email protected]<mailto:[email protected]> 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.
