Actually a better way to say it: sysvinit was not perfect, but it worked with careful monitoring. Using the bsdinit approach, sysvinit could be humanized in terms of readability.
When you add in things like djbdts, perp, Runit, or s6 you give flexibility to sysvinit, and assist an imperfect solution and create a more perfect solution. Runit to me when reading it, feels like a bsd-like approach to init, but with proper handling of services built-in rather than added onto by an external program. Stage-1 reminds me of the rc.S of Slackware in the sense it loads all the core system then passes it off to Stage-2. Stage-2 then simultaneously starts all the service trees. Now that might not be entirely correct in terms and application, but it says that Runit is a more perfect and human-like solution to the problems of init and it requires no extras from the system. You can drop it in or out without needless rebuilding of other packages. Plus if needed Runit can be made to work with older sysv style scripts with care. That's what I meant by Runit being not a replacement but a successor to sysvinit. Sent from my Windows Phone ________________________________ From: Charlie Brady<mailto:[email protected]> Sent: 7/29/2014 3:37 PM To: James Powell<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]> Subject: Re: runit-for-lfs at GoogleCode On Tue, 29 Jul 2014, James Powell wrote: > A replacement is something to replace a faulty or broken part. Sysvinit, > in our any many others' opinions, was not broken. Seriously? Start something, often something crucial to the running of the system, and just *hope* that it runs forever? Wow!
