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.
