Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

From: Jeff <sysinit_at_yandex.com>
Date: Mon, 02 Dec 2019 13:07:55 +0100

30.11.2019, 19:58, "Laurent Bercot" <ska-supervision_at_skarnet.org>:
>> the solution here could be a simple symlink to the original s6 tool without
>> the prefix if you prefer (maybe even located in an other dir than /bin).
>
> That would be a decision for users, not software authors - else it would
> defeat the point of not invading the namespace. Daemontools is still
> around with names such as "svc".

sure, that was just an idea for Jan, he could just create a dir somewhere,
populate it with symlinks he prefers to the original s6 tools and put this dir
in front of the PATH when running s6 since it seems the utilities do not bother
under what name they run.
 
>> using a single combined tool is more efficient since it avoids wasteful
>> further exec chaining steps, though.
>
> Sure, but if we're talking about UI, optimization at this level is a
> very
> moot point. A human choosing between "chpst" and "s6-applyuidgid" will
> *not* notice the extra millisecond taken by an execve() step. The
> primary focus should be usability.

i prefer short names like "chpst" (change process state ?) with multiple
command line options from a usability perspective. but the usage of single
tools with descriptive names is of course easier to read (not to write) and
hence understand when they occur in a script, that's true.

> I am reluctant to make the ABI details public because I want the freedom
> to change them. If people start relying on internals, their stuff may
> break when updating, which would be bad.
> There are *some* details that I could document as official and stable,
> but I'd need to go through all of it and decide with precision what can
> be guaranteed and what cannot - and that's extra work, so it will have
> to wait.

ok. i was more about insights into the design of the whole s6-rc toolset.
are the up/down scripts run by a dedicated service from within the supervision
tree? what exactly is the task of the "s6-rc-oneshot-run" and
"s6-rc-fdholder-filler" internal programs ? how is the startup organized,
how are "longruns" and "oneshots" intertwined ?

having to read the sources to get this information is somewhat inconvenient.
:-(
Received on Mon Dec 02 2019 - 12:07:55 UTC