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. ;) > https://lmgtfy.com/?q=s6-log&iie=1 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 runsvdir/chpst/sv. 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. cheers, Jan ¹) 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-* Having fdholderd 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.