On Thu, Mar 22, 2018 at 05:10:58PM +0000, Laurent Bercot wrote:
> would it be possible for you to change the name of the project?
What about using "slew.rc" and changing the installation path from
`/etc/s6' to `/etc/slew'? The change is not exactly trivial but already
much smaller than the `/etc/s6-init' / `/etc/s6-rc' merge I did before
releasing this project, and can be done in a few hours (the project itself
is not complex; the complexity on my part comes from the several machines
where it is delpoyed and has to be migrated :().
(Hint for the etymology: note how "6" is pronounced in Chinese ;)
> - I now recommend using socklog[1] to implement syslogd.
I see.
> It will likely be called s6-frontend. It will be written in C, and
> provide a user-friendly interface for setting up a complete init
> system, as well as a one-stop-shop "s6" command; the goal is to
> improve usability and simplicity for users who are not longtime
> members of the process supervision gang.
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'.
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.
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. Let distros (and some
adventurous users), i.e. those who understand their requirements for
init/rc systems better, decide how to customise their systems: after
all, text editors are the ultimate code generators for plain text files.
If it is agreed that the Unix philosophy is essentially about minimising
the total complexity of a system, I guess people would consider this to
be the more Unix-ish way.
> However, if decisions about "where to put stuff" are easy enough
> to take, decisions about "what init scripts should I provide, what
> external software should I assume is present on the system" are
> definitely not.
> But there is a large gray area here: what is "reusable policy" (RP)
> and what is "distribution-specific" (DS)?
First of all, I would like to note that the files in my project are not
to be used exactly as is; instead, they are intended as "reasonable
approximations" considering a majority of use cases. I currently use
Alpine and Void on my servers and desktops, and I deviate from the
published version of my project, more or less, on each and every
machine, and their versions differ from each other. I consider this
phenomenon normal and healthy.
Considering the adoption of systemd, I think most longrun definitions
are reusable, at least in an approximate sense; oneshots can be more
volatile, but most are still reusable with a reasonable amount of
distro-specific customisation. 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.
> If it involves choosing between several external software packages
> that provide equivalent functionality, is it okay to hardcode a
> dependency, or should we provide flexibility (with a complexity cost)?
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.
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.
--
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Received on Fri Mar 23 2018 - 04:00:22 UTC