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 <james4591_at_hotmail.com> 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:avery.p.payne_at_gmail.com>
> Sent: 6/16/2015 11:26 AM
> To: supervision_at_list.skarnet.org<mailto:supervision_at_list.skarnet.org>
> 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:slitt_at_troubleshooters.com>
> > Sent: 6/16/2015 4:45 AM
> > To:
> > supervision_at_list.skarnet.org<mailto:supervision_at_list.skarnet.org>
> > Subject: Re: comparison
> >
> > On Tue, 16 Jun 2015 04:05:29 -0700
> > James Powell <james4591_at_hotmail.com> 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.
Received on Tue Jun 16 2015 - 20:50:28 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:19 UTC