>As a relatively new convert to supervision software, my reasons for
>preferring runit over s6 are, in order of priority:
Hi Jan,
Thank you a lot for this feedback. This is very useful UX return.
Let me address the points one by one.
>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, but it's doubtful as long as
the people in charge are prejudiced against the "lots of small binaries
in /bin" approach. :(
>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. I just
can't get it. Launching a browser and reading a web page is something
that
we all do, every day, even the least computer-savvy ones among us, and
for
the life of me I can't fathom how this is *not* a friendly user
interface.
HTML even has the advantages of hyperlinks, so you can jump around in
the
documentation as needed, which you can't do with man pages!
Do you work offline? don't you have access to a web browser? do you like
reading stuff in a terminal *better*? (Text-based web browsers still
exist, if you do.)
It really stumps me. I did learn "man" too, 25 years ago, before the
Web existed. It was nice when man pages were all we had. But a couple of
years later, we had something that seems unarguably better to me, and
I see exactly zero reason to go back, apart from the force of habit of
typing "man".
Nevertheless, if people like man pages, they should have man pages, so
it's been a few years that I have appealed to the community for this.
I'm not going to learn nroff, ever, but we have a relatively large user
community, so they could probably contribute man pages, right? We've had
a few people who seemed interested, some of them even started thinking
about it *really hard*. And one of them even wrote a tool to convert
text into nroff, à la markdown (but simpler). But when it was about
doing
the actual work of writing the man pages (even if all the material is
already here, in the HTML doc)? You guessed it: crickets.
So, yeah, I want s6 to be accessible, but I figure that if people
really wanted man pages, they'd write man pages ¯\_(ツ)_/¯ Or maybe I was
wrong all along and the spirit of Open Source really is "If the one
person
doing the work doesn't do exactly what I want, then I'm just gonna sit
on
my ass and blame them".
If I'm sounding a bit jaded, it's because I am.
>3) s6 executables are somehow worse named than runit's. This may be
> highly subjective, but I can recall and recognize the runit commands
> far easier than the s6 ones. Possibly it's the "s6-" prefix getting
> in the way of my brain pattern matching on visual appearance of glyph
> sequences.
> This point is exacerbated by #2 and the number of s6 executables.
> Compare chpst with s6-envdir s6-envuidgid s6-fghack s6-setsid
> s6-setuidgid s6-applyuidgid s6-softlimit. Yes, I know about the
> historical reasons, but still.
This is very interesting. I thought that having a s6- prefix was a
*good*
thing, because I valued clarity above everything, and especially above
terseness. I understand the advantages of having commands named "sv" and
"chpst", but I believed, in my naïveté, that it wasn't a good idea for a
specialized package to tread on a large namespace; and to me the s6-
prefix would help users recognize exactly the domain of the command
they're using, and then they could abstract it away and focus on the
real command name.
Now you're saying that the s6- prefix *impedes* your pattern recognition
and detracts you from easily mapping the command name to its
functionality;
that having it is worse UI than not having it. I had not heard this
before, but it quite makes sense.
The number of executables is a choice; I like to have more, smaller,
executables than less, bigger ones. One function, one tool. It makes
code easier to write; this is not really for historical reasons, it's a
design choice. Personally, it's easier for me to remember several
process state change command names than all the options to chpst.
whenever I use chpst, I always need to check the doc; when I use
something like softlimit or setuidgid, I may need to check the doc for
specific options, but I always remember which command I want and its
general syntax. So, I suppose it comes down to individual preference
there.
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
My plan is for the future s6-frontend package to include such a
one-stop-shop command that controls various aspects of an s6
installation,
but if this command can help with s6 adoption, I can work on it much
earlier than the rest of the s6-frontend functionality.
Or, if you have other ideas that could help with easier assimilation of
the s6 commands, I'm very open to suggestions.
>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. 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? 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)
- 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 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.
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.
--
Laurent
Received on Sat Nov 30 2019 - 10:15:27 UTC