>What about using "slew.rc" and changing the installation path from
>`/etc/s6' to `/etc/slew'?
That's all fine with me, but it may have connotations in English
that you don't want to associate with a project aimed at stability
and friendliness :)
>To be honest, I find the idea not very appealing to me. I did not want
>to say about this before, but now I find it necessary before more
>energy
>is spent in goals that I consider less meaningful. Fortunately, only
>`s6-linux-init-maker' is affected by this issue as of now, and I will
>use it as an example.
>
>I think the direct downstream of init/rc systems is distributions, not
>end users which demand "usability" in the usual sense (actually, one of
>the many problems with systemd is that it attempts to bypass distros
>and directly provide "unified" features to end users). After s6/s6-rc
>becomes mainstream, `s6-linux-init-maker' will perhaps have, IMHO, an
>embarrassing role: most end users would begin with scripts provided by
>their distros, which might often be very different from those generated
>by `s6-linux-init-maker'.
Yes, but I don't see this as a problem. The target audience for
s6-frontend would precisely be *distributions*, not end users; the
goal is to factor the work of putting all the s6 pieces together and
make it easier for distributions to tailor those pieces to their own
policies. For instance, instead of having to provide s6-rc source
definition directories for services, they would provide a descriptive
file, similar to systemd unit files, that would then be automatically
processed and turned into a set of s6-rc definition directories. So
they can focus on the functionality they want to achieve in the
service without having to learn the nuts and bolts of the s6
mechanisms.
Bear in mind that - this is a simplified, but descriptive enough view
of the political landscape of the current Linux ecosystem - distribution
maintainers are *lazy*. They already know systemd, or openrc, or
sysvinit; they don't want to put in more effort. They don't want to have
to significantly modify their packaging scripts to accommodate a wildly
different format. They don't want to have to learn how things operate
under the hood. Ideally, they don't want to have to come up with
policy decisions themselves!
You may not find the idea of s6-frontend appealing, but distro
maintainers really do. I've had distro maintainers say to me verbatim
that the *main*, and in some cases *only*, obstacle to s6 adoption was
its interface and how different it is from what they already have; but
apart from that, they love the idea.
Remember that a few years ago I started a quest to learn what kind
of functionality people wanted in s6 in order for them to switch to
it? I expected technical answers, I expected weird systemd features;
I got literally none of those. What I did get, though, is requests
for a friendly UI and accessibility for "average" users (read: lazy
distro maintainers included). This is not the answer I wanted, but
it's the crystal clear answer I got; so it would be foolish of me to
ignore it. I don't like it any more than you do, and interface work
would definitely not be my first choice, but there it is.
However, I'm absolutely committed to keeping the individual s6
pieces independent and maintaining them separately, and the frontend
will always be optional. So, power users like you will always be able
to use s6-linux-init, s6 and s6-rc separately, with your own scripting
around them; slew.rc or similar initiatives will not be obsoleted.
I'm not turning s6 into a monolithic behemoth, don't worry. ;)
>And the difference is not only in the utilities used, but also in the
>functionalities offered: eg. conditional (re-)mounting of `/run'
>according to results of `mountpoint -q /run', loading/saving the clock,
>saving the "uncaught" logs. This is honestly not to show off the
>features provided by my project, but to show that attempts to encapsule
>factors in real-world use cases of an init/rc system into a code
>generator can be largely unproductive.
Well, obviously the frontend should offer knobs and settings to
allow customization of those aspects. And in the worst case, there
should be a "run this user-provided script as is" function, which
allows users to bypass the UI and provide snippets of code themselves.
>Instead, I think a better way is to provide a full "reference
>implementation" of what you have in mind, with the code generation
>knobs
>converted into comments (cf. the `devtmpfs' line in `rc.boot' in my
>project) or notes in the documentation.
These two approaches are not mutually exclusive. :)
> I do not consider package dependencies
>to be a big problem: distros (and those adventurous users) will
>naturally handle them when customising the init/rc system. No better
>way has been proposed to my knowledge: `s6-linux-init-maker' basically
>solves it by depending on skaware, and systemd "solves" it by using its
>own extremely bloated implementations.
That is precisely the discussion that I want to have. To a
distribution, dependencies are not a problem because they know what
they are packaging and they are responsible for their integration
choices. To a software author, however, dependencies are an issue -
because I can take responsibility for software I provide, but I
cannot take responsibility for external software; this is why
s6-linux-init depends on skaware, because I cannot depend on, say, a
coreutils implementation - but I'm well aware that distributions will
choose to depend on some coreutils instead, and they will be right;
so obviously distributions will probably not depend on the verbatim
output of s6-linux-init-maker, and that's okay.
systemd has the exact same approach to external dependencies: it
provides all the functionality itself so it doesn't depend on anything
else.
The difficult part is that writing an integrated init system is
riding the fine line between "software author" and "distro packager".
At one end of the spectrum, you have s6, which is pure mechanism,
self-reliant, but that needs to be paired with other programs to
get a complete turnkey init system; at the other end, you have
kitchen sinks like systemd that include everything they need by
reinventing the square wheel. To provide a reasonably lightweight
but immediately usable and distro-adoptable init system, there is
a golden mean to be found, and I think it's important to find it.
>Regarding networking, I consider netifrc to be, though bloated, a
>successful example. As I mentioned, the functionalities of netifrc can
>in principle be implemented using preprocessors in much cleaner ways,
>and I guess the complexity cost that comes with the flexibility would
>not be too big in this case.
But is it the software's job to determine the format of the
network configuration file, or is it purely the distribution's?
Is it an advantage for an init system to come with its own
network configuration format, or a drawback? Is it possible, and
worth it, to write hooks that call pre-existing network scripts,
or should the whole network interface config mess be torn down and
rebuilt from scratch? Those are the exact kind of questions we need
to ask ourselves.
>Of course, this means you probably cannot use C exclusively. If Unix
>used a small language with S-expressions that can be both compiled and
>interpreted, and with garbage collection enabled at
>compile/interpret-time but optional for compiled binaries, we would be
>perhaps free from those "flexible {whatever language} or efficient C"
>dilemmas. Unfortunately, no such language exists, at least to my
>knowledge.
Language is an implementation detail. I usually go for C because
it doesn't depend on anything and keeps things lightweight, so it's a
natural choice for low-level software, but obviously when doing
integration you need a lot of scripting. I will go with autogenerated
execline scripts, in the spirit of s6-rc; you chose to use the rc shell,
which is a small, acceptable dependency; all this is fine, and it's
really not worth spending time on.
--
Laurent
Received on Fri Mar 23 2018 - 10:51:57 UTC