Re: s6 usability

From: Jan Braun <>
Date: Sun, 22 Dec 2019 06:53:24 +0100

Laurent Bercot schrob:
> No, you're falling for the pretext - because this is only the current
> pretext they're using. Debian *does not provide* a POSIX-compliant cd
> binary, so their claims at POSIX compliance are just lies.

Including execline's (non-compliant) cd would preclude them from
becoming more POSIX-compliant if somebody actually bothers to provide a
POSIX-compliant cd in the future.

> The current version of execline includes POSIX-compliant cd and wait
> binaries, and the next one will also include a POSIX-compliant umask
> binary. Then we shall see what new excuse they find not to put execline
> binaries in the default PATH.

Oh, hey, that somebody is you. Awesome! So shipping that execline will
actually increase POSIX compliance in Debian. :)

So let's wait and see what happens.

I haven't had any reason to suspect any Debian Developers are/were
acting insincerely in dealing with Debian issues. Bad at communication,
annoyingly stubborn, overly pedantic, plain misguided: yes, but afaict
always honest¹.

I'm sorry you feel differently. :(

> Adélie Linux *actually* aims for full POSIX compliance and passes more
> VSX-PCTS2003 tests than any other Linux distribution. It includes all
> execline binaries in /bin. No VSX tests are failed because of that.

I guess that just means that
    find . -type d -exec cd {} \; -exec foo {} \;
(or similar for umask) is not part of the tests. ;)


Ewww, no, just no.
That's far too slow, and not deterministic.

> $ doc s6-log
> and you'd have your favorite browser auto-launched on the local s6-log.html
> page.

Yes. The lack of that is exactly my issue with the s6 docs.

> *That* would be software with some real added value, and maybe it would
> start the much-needed transition away from antiquated nroff pages.
> ... and since nobody else is ever going to write it, maybe I should. :(

Maybe. I don't see /much/ benefit in having hyperlinks and colors for
manpage-like docs.

However, I very much see the danger that people will start writing crap
instead of manpages-in-html once you tell them that "this is going to be
rendered by a browser".

One reason why GNU info docs are virtually unusable to me is because
they're a twisty little maze of tiny nodes hyperlinking each other, and
I found it impossible to concisely read stuff once from beginning to end
like I'd do with a new manpage.

And that's just hyperlinks. Some people will undoubtedly start doing
unprofessional things with images and Javascript and loading stuff from
the network, and then usability is completely out the window.

Man pages are not about nroff, but about having a standard template on
how to document things. But nroff serves as a filter that prevents
people from throwing random things into the man database. ;)

I think writing manpage-style docs in a simple markup language and then
compiling to nroff/html/pdf/... is the better aproach.
And then your "doc" command is just a slight variation on
"$BROWSER /usr/share/doc/html/$1", if you want it.

> I am currently experimenting with such a thing. The *exact* runit
> interfaces are difficult to provide, [...]
> The goal isn't to mimic runit, the
> goal is to help runit users transition to s6.

Well, to me, the litmus test would be whether my
 runsvdir -P /etc/service '................'
and various ./run scripts that use chpst and sv up/down/start/stop
result in a working supervision setup with the s6 versions of

The lack of config file for the logger is annoying. But since runit uses
it's own matching language, and s6-log uses posix extended regexps
(thanks!), the config file wouldn't be compatible anyway.

I shall be looking forward to the results of your experiments. :)

> I realize, from this conversation and others, that I need to write an
> additional documentation page, to be read even before the s6 overview,
> that explains what piece of the s6 ecosystem does what.

Yes, please. It's been confusing to have s6 (the supervision suite)
containing a bunch of s6-prefixed binaries, and then having a bunch of
other loosely related things also with s6- prefixes. Contributes greatly
to my "too many binaries to keep in memory" issue.

> > 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. :(
> That is only until you realize [...] I understand you may have been
> burned by crappy software before, but s6 is not like that.

Yes. I think and hope that I was careful in wording anything about "s6
complexity" as *impressions* that I got by reading the docs &co, not as
things I believe actually apply, if you can spot the difference.

When I look at runit, I see a system that's obviously simple (yay).
When I look at s6, there are so many parts that I *cannot tell* whether
each part is reasonably simple and independent of most² others (good),
or whether it's one big interdependent mess (bad).

As I'm learning more about s6, and by seeing your attitude about
relevant issues, I'm getting more confident that it's the former. But
technically I still can't be sure yet, and I'm trying to point out the
uphill battle s6 has to fight on the PR front in my head. ;) Of course,
better docs may help, see above.

> It brings its own scripting language along *in order to be simpler,
> less buggy, more restricted and less resource-consuming* than the scripting
> language that already exists on every Unix machine and that everyone uses.

Yes, I get that.

> [quote rearranged]
> So it's very unfair
> criticism to say "it brings its own scripting language along"

Except that it, in fact, actually does so. :P

For well-meaning reasons, and you may be right about the security
benefits over shell.
But I am *extremely* unlikely to bother learning execline.

Hence, in my case, there's no security benefits, and, on my computer,
execline is just unneeded dead code lying around. Not nearly XML in pid
1, but still a step away from true minimalism.

Actually, it's not lying around at the moment. But that means I can't
use !processor directives for s6-log. Which I would need if I were to
actually use s6. And they'd all be "!/etc/jan/logmailr/mailer". So
there's no need for execline, or a shell, to get invoked. Just plain
execvp() would do.³

Can you see why that bothers the perfectionist in me?

> Thanks again for your UX returns. They are definitely useful.

Glad to hear that. And sorry if I offended with my systemd comparison or
generally come across too strong. I'm genuinely trying to give
constructive feedback. But I do have a habit of erring on the side of
too blunt phrasing.


Well, there is/was one particular systemd advocate stretching the bounds
of my ability to believe that they're actually *that* narrow-minded and
unable to see the other side. Still, I'd prefer to give the benefit of
the doubt.

That's another thing where I prefer multibinaries: s6-fdholder-*
    fdholder list
    fdholder retrieve
    fdholder store
would be far more Jan-compatible UI.
And having both s6-fdholder-daemon and s6-fdholderd in $PATH also serves
to confuse me. If one is an implementation detail of the other, I'd
prefer it be hidden away into /lib or something. Then I don't have to
start by figuring out which one I should use. Or, worse, only seeing the
wrong one and trying to make that work.

Note I'm not saying you should implement "?processor" that way.
There's some pros+cons to each of
 * Stuffing "processor" unchanged into the 1st (and 2nd) argument of exec[vl]p
 * splitting on whitespace and parcelling into exec[vl]p
 * passing the string on to system()
Pick what you think best. I'm unlikely to notice the difference, and if
I do, it's trivial to adapt. Since there seems to be no standard about
this kind of thing, I made a habit of assuming that anything shell
metacharacter related causes breakage.

Received on Sun Dec 22 2019 - 05:53:24 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC