That's an understatement! And, as the old saying goes, the best time to plant a tree is 20 years ago. The second best time is today.
Thanks Avery! SteveT On Tue, 16 Jun 2015 13:09:32 -0700 James Powell <[email protected]> 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. > > Sent from my Windows Phone > ________________________________ > From: Avery Payne<mailto:[email protected]> > Sent: 6/16/2015 11:26 AM > To: [email protected]<mailto:[email protected]> > Subject: Re: comparison > > On 6/16/2015 5:22 AM, James Powell wrote: > > Very true, but something always seems to say something along the > > lines of "if we had done #2 years ago, we might have avoided a huge > > mess that now exists". > Agreed. > > The same applies to init systems. If there are ready to use feet > > wetting, taste testing scripts ready to go, the job of importing > > things just gets easier on the distribution. > Also agreed. Actually, there's some discussion on the mailing list > from a few months back about this. > > ________________________________ > > From: Steve Litt<mailto:[email protected]> > > Sent: 6/16/2015 4:45 AM > > To: > > [email protected]<mailto:[email protected]> > > Subject: Re: comparison > > > > On Tue, 16 Jun 2015 04:05:29 -0700 > > James Powell <[email protected]> wrote: > > > >> I agree Laurent. Though, even though complete init+supervision > >> systems like Runit exist, it's been nearly impossible to get a > >> foothold with any alternatives to sysvinit and systemd > >> effectively. I think one of the major setbacks has been the lack > >> of ready-to-use script sets, like those included with OpenRC, > >> various rehashes of sysvinit and bsdinit scripts, and systemd > >> units just aren't there ready to go. > The true problem is that each daemon needs its own special environment > variables, command flags, and other gobbledygook that is specific to > getting it up and running, and a master catalog of all settings > doesn't exist. Compounding that is the normal and inevitable need > for each supervision author to do their own thing, in their own way, > so tools get renamed, flags get mapped, return codes aren't > consistent. That's just the framework, we haven't talked about run > scripts yet. Who wants to write hundreds of scripts? Each > hand-cobbled script is an error-prone task, and that implies the > potential for hundreds of errors, bugs, strange behaviors, etc. > > This is the _entire_ reason for supervision-scripts. It was meant to > be a generic "one size fits most" solution to providing prefabricated > run scripts, easing or removing the burden for package maintainers, > system builders, etc. All of the renaming and flags and options and > environment settings and other things are abstracted away as variables > that are correctly set for whatever environment you have. With all of > that out of the way, it becomes much easier to actually write scripts > to launch things under multiple environments. A single master script > handles it all, reduces debugging, and can be easily swapped out to > support chainload launchers from s6 and nosh. > > The opposite end of this is Laurent's proposal to compile the scripts > so they are "built into existence". If I'm understanding / imagining > this correctly, this would take all of the settings and with a > makefile "bake" each script into existence with all of the steps and > settings needed. It would in effect provide the same thing I am > doing but it would make it static to the environment. There's nothing > wrong with the approach, and the end result is the same. > > The only difference between Laurent's approach and mine, is that > Laurent's would need to "re-bake" your scripts if your framework > changes; in my project, you simply run a single script and all of the > needed settings change on the fly. I'm not sure of the pros/cons to > either approach, as I would hazard a guess that any system switching > between frameworks may also require a reboot if a new init is desired. > > Here's the rub: in both cases, the settings for each > service/daemon/whatever are key to getting things running. Again, we > come back to the idea of a "master catalog of settings". If it > existed, then half of the problem would be resolved. There are lots > of examples out there, but, they're not all in one place. > > So I try to toil over supervision-scripts when I get time, and make > that catalog. Even if people don't like what I'm doing with the > master run script itself, that doesn't matter. *What matters is that > I've managed to capture the settings for the various daemons, along > with some annotations*. Because I took the time to support envdir, > and the settings for each daemon are stored in this format, those > settings can be extracted and used elsewhere. I'm slowly creating > that "master catalog" in a plaintext format that can be read and > processed easily. This is the real, hidden value of > supervision-scripts. > > By the way, I'm going to bite the bullet and switch off of MPL 2.0 > soon, probably by month-end.
