On Sat, 30 Nov 2019 10:15:27 +0000 "Laurent Bercot" <ska-supervis...@skarnet.org> wrote:
> 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. :( Would it be acceptable to you and them to put the binaries in /bin/s6 and then very early in the boot add /bin/s6 to the path? This isn't a lot different from what djb did with /command, except it's not off the root, which everyone seems to hate. [snip] > >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. As a guy who has both daemontools and s6 installed on the same box, I thank you from the bottom of my heart for: 1) Prepending s6- to each command so they don't clash with djb's 2) Except for the s6-, naming them the same as djb's so I have less to remember. [snip] > > >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. I don't think it's necessary to remove the dependency unless ordinary users would be altering the code of s6-ftrig-listen or s6-log. A simple change change I think would do it is to change the documentation to imply that, for the *user*, execlineb is a way to get just a little extra whatever. Currently, when I read it, I thought I'd be missing a lot by using /bin/sh. > > 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. Does the *user* need to code execline scripts, or is it just something the program does? If the former, then make a point that one doesn't need to use execline for s6-rc to be a very powerful startup system. If anybody would make an execline tutorial, that would help a lot. For a guy like me who only does procedural programming (C, C++, Pascal, Perl, Python, Ruby, Lua, etc), execline is difficult to understand. SteveT Steve Litt November 2019 featured book: Manager's Guide to Technical Troubleshooting Second edition http://www.troubleshooters.com/mgr