Steve Litt wrote on 26.07.2018 18:17:
> On Thu, 26 Jul 2018 13:17:21 +0200
> Irrwahn <irrwahn@???> wrote:
>> What's more, I'd
>> go even further and say I wouldn't mind at all if every daemon
>> package came with support for all init systems in current use
>> (rc-style sysv|openrc, runit, ... , systemd), as that would make
>> switching init systems in an already installed system much, much less
>> of a pain in the rear. Why would I care about a few dozen tiny
>> innocuous unused files on a system that per default install is
>> already cluttered with literally thousands of files I'm never going
>> to use in any way.
>
> I write my own daemons. There may come a time when I put a free
> software license on one of them and distribute it to the world. If I
> did so, I might (or might not) include the runit run script I use to
> run it. If I were feeling particularly nice that day, I might also
> supply an s6 run script, because s6 run scripts are almost 1 to 1
> translations from runit.
>
> But there's no way I'd ever take the time to supply facilities for
> startup in sysvinit, OpenRC, systemd or busybox. **Not my job!**

While writing I was thinking more about package maintainers, not
necessarily the author of a piece of software, though there will
always be some considerable overlap between those groups of people.

>> That'd be what I'd call "init freedom". It's very unlikely to happen
>> in the foreseeable future though, as it would require cooperative
>> effort of hundreds of individuals to include and maintain those init
>> support files in the respective packages.
>
> Now it sounds like you're talking about something else. It now sounds
> like you're talking about a group of init experts making startup
> facilities for programs using various inits. This is a good idea. A
> systemd unit file, or an s6 or runit run script offer excellent
> documentation for how to configure the application for just about any
> init system.

Again, as above, I was thinking more about distribution package
maintainers. Though it would obviously be of great help if patches
were submitted by "init experts", without giving much thought to
the question what traits would characterize such an "expert". By
"cooperative effort" I meant that the maintainers of _all_ the
daemon packages present in a distribution would have to provide
and/or maintain init facilities for all supported init systems,
as otherwise the whole endeavor would fail.

> <rant>
> sysvinit and OpenRC typically have init scripts tens or hundreds of
> lines, making init integration of an application seem like an arcane
> art. What are they thinking? IMHO these immense and unfathomable init
> scripts are what opened the door for systemd.
> </rant>

<re-rant>
I rarely write init scripts from scratch, and when I have to edit
one I count myself lucky if it's just some posix shell script that,
while admittedly not being exactly elegant, is in most parts
comprehensible to me without in-depth study of some init system
manual. Hence, I for one am content with the imperfect well-hung
sysv-rc init. I'd however never try to force that attitude onto
other people. (Not implying you did, mind you, just generally
speaking here.)
</re-rant>

Each to their own, I'd say. While I agree that a lot of rc-style
scripts look quite messy, at least these are plain shell scripts,
giving full control over as much minutiae of daemon behavior as
is conceivably possible, as the author is provided with virtually
unrestricted access to the complete toolbox of standard unix
utilities to pick from in order to accomplish his task.

On the other hand, concise configuration files as used by many
non-rc-style init systems have their own charm, but this gain in
elegance comes at the expense of handing over a lot of fine
grained control specifics to (a set of more or less integrated)
binaries that behave to at least some degree opaque to the casual
observer. This offloading of nitty-gritty specifics can come as
either a blessing or a curse, depending on the case at hand.

In the big picture, rc-style init systems constitute (almost)
one extreme of the spectrum, while systemd is the perfect example
for the other extreme, i.e. what happens when scope creep takes
the alleged simplification more than a few steps too far by
basically building a shadow OS, epitomized as a nightmarish
hairball of elements that each are individually inferior compared
to their "do one thing" unixish counterparts in the actual OS.

Somewhere among this vast spectrum between spaghetti script and
three-liners consumed by incomprehensible pseudo-modular binary
monsters there should be something suitable for virtually anybody.
And that is what makes me buy into the notion of init freedom as
a declared objective of Devuan.

As always this post is worth what you paid for it, YMMV, etc.

Regards,
Urban

--
Sapere aude!