and sorry for taking so long to reply.

Laurent Bercot schrob:
> > 1) Debian ships with a working and maintained runit-init package. It
> >    provides pid 1 and hooks into /etc/rcS.d/* to integrate with other
> >    Debian packages. s6-linux-init and s6-rc are not packaged in Debian.
> I hear you. Unfortunately, I have no control over what Debian does.
> Debian isn't even able to ship a not-broken execline package, so I'm at
> a loss on what to do with them. I'm working on a version of execline that
> they *might* accept to package correctly,

If you're referring to
then, well, you are fighting against POSIX. There's little choice for
Debian in the matter. Taking a hardline stance on such "legal" issues is
part of their identity as a distro.

> but it's doubtful as long as
> the people in charge are prejudiced against the "lots of small binaries
> in /bin" approach. :(

I don't think that's the real issue. POSIX saying "the cd/umask/wait
shell builtin must also be exec()able" is. Or execline's desire for
binaries with those names and different behaviour, depending on your

> > 2) runit has manpages. s6 has HTML. :(
> This is far from the first time I hear this, so it would be foolish to
> ignore it, but I *really* have a hard time understanding how in 2019 it's
> so difficult for people to launch a browser to read a web page.

It's not difficult launching the browser, it's difficult getting to the
correct webpage. Compare
| $ elinks /usr/share/doc/s6/s6-log.html
with a hypothetical
| $ man s6-log
and count keystrokes. (And then look up the K key in vim. ;)
The main advantage of manpages is that they are in a well-known place
and therefore instantly found. The displaying itself makes hardly a
difference. Especially since, thankfully, your html mimicks the man page
conventions wrt sections and so on.

Something like djb's /doc (thanks, Jonathan!) would scratch my itch too,
but as long as that's not in widespread use, I prefer man over html.

(I also have several rants about html/browsers/JS available on request,
but that's rather tangential to the issue of *finding* documentation.)

> [... 3) ...]
> The number of executables is a choice; I like to have more, smaller,
> executables than less, bigger ones. [...]
> So, I suppose it comes down to individual preference there.

I agree, it's probably personal UI taste. To me, a good metric is the
"fanout" of possible options:
When I want to call something runit-related, I got
    * chpst: change process state
        **  -u: user
        **  -n: nofiles
    - sv: manipulate a service
        ** up
        ** down
        ** term
    - runsv<tab>    supervision implemention
        ** runsv     one service
        ** runsvdir  a dir of services

    - sv-<tab> my custom scripts
        ** sv-errors  show the readproctitle logs

If any point in the tree, there's 7±2 children I can find by
tab-completing/glancing at a man page, then I can probably navigate the
whole thing pretty quickly.

On the other hand:
| $ ls /usr/bin/s6* | cut -d- -f 2 | uniq | wc -l
| 39
Even if there's still some related commands (e.g. 3x s6-sudo*), that
number is not coming down to a point where I can keep everything in
my head.

> Would a generic "s6" command, that takes alternative syntax and rewrites
> itself into "internal" commands, help? It could emulate runit syntax,
> among other things.
> s6 runsv ... -> s6-supervise ...
> s6 sv ... -> s6-svc ...
> s6 chpst ... -> various s6-prefixed process state change commands

Probably yes, but if you are doing that, then why don't you look at
argv[0] and provide the runit interface proper? :D
(Or provide runsv/sv/chpst/.. as individual binaries, since you prefer

But outside of supervision, I notice that you are reimplementing a
lot of small programs. As long as they're mostly command-line compatible
with their inspiration, I think such a "s6" executable would enable a
nicer UI for s6-{linux,portable}-utils and the s6 djb reimplementations:

Have your binaries in /usr/lib/s6/ (or wherever), and named without the
"s6-" prefix. Have a "s6" binary multiplexing to these on its first
argument. That way, a user can choose any of:

| $ s6 cat foo
| $ PATH="/usr/lib/s6/:$PATH"
| $ cat foo
| # ln -sf /usr/lib/s6/cat /bin/cat
| $ cat foo

(And possibly a s6-cat compatibility symlink somewhere.)
This is similar to busybox (except for the reverse goal :) and allows
individual customization, while keeping /bin/ uncluttered by default.

And with all those reimplementations out of the way, maybe the remaining
binaries are few enough that I can actually remember them. Of course, if
you then want to rename s6-supervise to runsv, and s6-svscan to
runsvdir, that might even work. ;)

> > 4) s6 seems more complex (hello execline!), and I don't (yet?) see any
> >    benefit/feature I'd appreciate except minimizing wakeups.
> This, on the other hand, is a misconception that really needs to
> disappear. Understanding execline is *not needed* to run s6.

Needing to *understand* execline wasn't my misconception, nor worry. But
when I'm told that a runit-lookalike depends on bringing its own
scripting language along, then that sounds more like systemd and less
like djb to me. :(

> s6 depends
> on execline in two places (there were more, but I scrapped them because
> nobody used the commands that were involved):
> - at build-time, in s6-ftrig-listen
> - at run-time, in s6-log, for processor invocation
> Would entirely removing s6's dependency on execline help clear that
> misunderstanding and help with s6 adoption?

When you explain it like that, it sounds far more reasonable.

> This could be made possible
> by:
> - duplicating el_semicolon() functionality in s6-ftrig-listen.c
> (it's not elegant, but clearing the dep may be worth it)

I can't judge that.

> - adding an alternative '?' processor directive to s6-log, that spawns
> the processor using /bin/sh instead of execlineb. (The '!' directive
> would still be there; processor invocations using '!' would just fail
> if execline is not installed.)

I'd appreciate this regardless of the internal dependency. I know you
want to popularize execline, but "you must use it if you want to use my
other tools" is not a helpful form of advocacy.

> I don't like this, but if "execline" is a scarecrow that keeps people
> away from s6 for no other reason than perception, it's a possibility.
> Savvy users will still install execline for use in run scripts.

That's perfectly fine. Small modular building blocks you can use,
disregard, or replace as you see fit are Unixy.

> s6-rc, however, absolutely cannot do without execline, since it uses
> autogenerated execline scripts. But s6-rc is a different beast, that
> requires a lot more involvement than s6 anyway, and that isn't needed
> at all if we're just talking about runit-like functionality.

Yes. But since you are mentioning it, that was another of my "s6 seems
more complex" issues. runit goes from "start the supervisor manually" to
"be pid 1" with very little effort. See runit(8).
Or https://www.unix.com/man-page/debian/8/runit/ I guess. ;-P

s6-linux-init and s6-rc seem extremely complicated in comparison. And
it's not clear to me how much of that complexity is optional, and what
it might buy me. Maybe a better high-level overview document might help

cheers, and sorry for the wall of text,

P.S: I stumbled over this execline oddity:
| dollarat     -0 -d a                      # separates by \0
| forbacktickx -0 -d a var {gen...} loop... # splits on a
IMHO, both should be an error, but at least treat them the same.

Attachment: signature.asc
Description: PGP signature

Reply via email to