Re: s6 usability

[Oliver Schad]

On Mon, 23 Dec 2019 10:15:11 +
Jonathan de Boyne Pollard 
wrote:

> Oliver Schad:
> 
> > A booting tools should be in /bin - full stop!
> >  
> 
> That is historically untrue.  The real world has not actually worked
> in the way that some people think.

Sorry, this is a historical explanation of some things - is this a
history course here?

That is *not* what you would expect today. Scripts
for system initialization (a special case) should find all tools
in /bin, because it's in always in the path (always today).

To put tools for a lot of scripts somewhere(!) would mean, that all
scripts have a method to find these tools or would mean to add more
directories to PATH.

Because the maintainer of these scripts are completely distributed
(it's not one small team, which writes boot/start scripts), it's crazy
to do something else than put everything in /bin.

If you would say, that this is not true, then we can discuss where we
should place cp, mv, ls - maybe in /usr/lib/gnu/? Really?

Important scripting tools should always be in /bin or /usr/bin - /bin
for boot, /usr/bin for later stages is ok.

Best Regards
Oli

-- 
Automatic-Server AG •
Oliver Schad
Geschäftsführer
Turnerstrasse 2
9000 St. Gallen | Schweiz

www.automatic-server.com | oliver.sc...@automatic-server.com
Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47


pgpU0oY0kJ2ci.pgp
Description: OpenPGP digital signature

Re: s6 usability

[Laurent Bercot]

However - what is the concrete suggestion from the Debian guys what
Laurent should do?


 The Debian people are happy with putting execline binaries in a 
separate

directory that is not in the default PATH. They don't see a problem with
that. And the thing is, nobody will notice a problem either - except
people who try calling useful execline binaries (such as redirfd) 
outside

of execline scripts, *which is a use case I officially want to support*.

 I'll try releasing the execline version with a POSIX-compliant umask
before the end of the year. Then we'll see where Debian really stands.

--
 Laurent

Re: s6 usability

[Laurent Bercot]

You can sling all the insults you want, but the fact is


... the fact is, I have explained this multiple times on this very list,
I am tired of seeing the same fallacy come up again and again, and I am
tired of repeating myself.



fine with me, as long as the distro cooperates. But if the distro fails
to carry out the intent of  your software, there are worse things than
putting it all in one directory or tree, prepathing their location, and
running it that way.


1. There aren't any worse things than software breaking. Do I need to
explain again why software breaks when you do that?

2. Why aren't you suggesting the same thing to the ImageMagick authors?
or to the util-linux authors? Those are also dumping a lot of stuff into
/bin or /usr/bin, including a program abusively named "import" - for
which I was willing to concede, in the name of historical priority.
It's a real question. Why should I accept subpar treatment that nobody
else would consider?

--
Laurent

Re: s6 usability

[Steve Litt]

On Sun, 22 Dec 2019 23:20:03 +
"Laurent Bercot"  wrote:

> >That being said, is having your stuff on the executable path such an
> >advantage?  
> 
> I don't know, why does Unix like to have its binaries in /bin? Why
> does PATH exist? What is the nature of an executable? You have two
> hours.
> 
> 
> >December 2019 featured book: Rapid Learning for the 21st Century  
> 
>   Ah, so that's your secret. Rapid learning and rapid forgetting.

You can sling all the insults you want, but the fact is, putting all
your stuff for a single software group into one tree, outside of the
path, and accessing it with a prepath script that perhaps does a cd and
sets other environment variables that you'll need makes a tidy little
package, with no name conflicts. You can "uninstall" it with a simple
tree delete.

Depending on dependencies and architecture and the way your software's
written, you might be able to copy it to another computer with cp -Rp
or rsync -va. It's very easy to examine.

The UNIX way, with /usr/bin and /usr/local/bin and the rest, is just
fine with me, as long as the distro cooperates. But if the distro fails
to carry out the intent of  your software, there are worse things than
putting it all in one directory or tree, prepathing their location, and
running it that way.

SteveT

Steve Litt 
December 2019 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

Re: s6 usability

[Oliver Schad]

On Sun, 22 Dec 2019 23:20:03 +
"Laurent Bercot"  wrote:

> I don't know, why does Unix like to have its binaries in /bin? Why
> does PATH exist? What is the nature of an executable? You have two
> hours.

Sorry, this discussion is crazy: Laurent provides a basic booting tools
with his toolchain. A booting tools should be in /bin - full stop!

However - what is the concrete suggestion from the Debian guys what
Laurent should do?

On top, it makes sense to start a community integration program to
fullfill distro requirements. So that would include public test and
build infrastructure and pre-packaging stuff.

I can support that with free hosting for building and testing, i.e. I
can provide a public gitlab with build and test pipelines.

Best Regards
Oli

-- 
Automatic-Server AG •
Oliver Schad
Geschäftsführer
Turnerstrasse 2
9000 St. Gallen | Schweiz

www.automatic-server.com | oliver.sc...@automatic-server.com
Tel: +41 71 511 31 11 | Mobile: +41 76 330 03 47


pgprAyE0rdVxz.pgp
Description: OpenPGP digital signature

Re: s6 usability

[Dewayne Geraghty]

On the question of PATH for BSD land (FreeBSD, TrueOS, HardenedBSD et 
al), binaries installed from packages (ports) live under /usr/local, 
with the exception of /var and /tmp.  The wars were fought and 
/usr/local can easily be mounted read-only.


Of the 1446 packages I have installed (no desktop stuff),
the breakdown is

# ls /usr/local/bin/ | wc -l
2857
# ls /usr/local/sbin/ | wc -l
 349
# find /usr/local/bin/ -type d -depth 1
/usr/local/bin/db5; # No directories under /usr/local/sbin
# ls /usr/local/libexec|wc -l
  72

The placement of files, is more a "distribution" decision that I'm sure 
is already settled.


On the documentation front, Laurent's work is very good, but I did find 
the examples from the gentoo docset for s6 & s6-rc, a life saver for 
someone with no prior process or service management background.  (I'd 
only used monit previously, and still do to reload application configs 
and some other system state change events over s6 tools).

Re: s6 usability

[Laurent Bercot]

That being said, is having your stuff on the executable path such an
advantage?


I don't know, why does Unix like to have its binaries in /bin? Why does
PATH exist? What is the nature of an executable? You have two hours.



December 2019 featured book: Rapid Learning for the 21st Century


 Ah, so that's your secret. Rapid learning and rapid forgetting.

--
 Laurent

Re: s6 usability

[Steve Litt]

On Sat, 21 Dec 2019 23:46:34 +
"Laurent Bercot"  wrote:

> 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.
> 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.

My finding in the past is that Debian will do harm to any software just
so they can comply with their arcane rules. One such rule caused them
to change the prepend key-sequence in VimOutliner from the incredibly
quick and easy double comma (,,) to the wrist-twisting, error prone,
slow, and keyboard dependent double backslash (\\), even though
VimOutliner's manifesto listed authoring speed as the top priority.

That being said, is having your stuff on the executable path such an
advantage? A lot of times I put all the executables for a system in a
directory off the path, and then create a shellscript like this:


#!/bin/sh
export PATH=/path/to/s6:$PATH
$@


Or this:


#!/bin/execlineb -s1
importas OLDPATH PATH
export PATH "/path/to/s6:$OLDPATH"
$1 $@


Symlink the shellscript from a directory on the path, and whatever is
in $@ is as good as being on the path. By doing this I avoid any
program name conflicts, I can easily delete my whole program or copy it
to another computer. And of course slashpackage is another way.

I'm not saying this is perfect.  I'm just saying it could be as simple
a opening a tarball in an arbitrary directory and typing make; make
install. That's basically how we distributed VimOutliner for a long
time. Earlier in this thread somebody suggested a method of Debian
packaging that was both breathtaking in its convolution and
preventing of other software from being installed at the same time. With
Debian's propensity to break things doing them their way, perhaps it's
time to consider the possibility of doing an end run around the Debian
Developers.

SteveT

Steve Litt 
December 2019 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

Re: s6 usability

[Colin Booth]

On Sun, Dec 22, 2019 at 02:05:14AM +0100, Jan Braun wrote:
> > It doesn't help that neither Adam nor Jakub read the documentation for
> > the execline equivalents for cd, umask, or wait.
> 
> Why would you say that? They effectively only claim that execline's
> cd/umask/wait binaries don't conform to the POSIX specification for
> cd/umask/wait. And I think that's uncontroversally true.
> 
> > That or they don't know what 'execs into' means.
> 
> POSIX requires:
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_06
> | However, all of the standard utilities, including the regular built-ins
> | in the table, [...]  shall be implemented in a manner so that they can be
> | accessed via the exec family of functions as defined in the System
> | Interfaces volume of POSIX.1-2008 and can be invoked directly by those
> | standard utilities that require it (env, find, nice, nohup, time,
> | xargs).
> 
> i.e, if you call
> execvp("cd", "cd", /* any other args, */ NULL);
> , POSIX says you MUST get the behaviour documented at
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html
> . And if /bin/cd is execline's cd, then you don't.
>
Fair enough. Pedantic as it was I had mostly taken issue with the
statement that:
  Regular "cd" changes the directory for the calling process (thus it
  even can't possibly be a separate process), this "cd" takes two
  arguments and runs a _child_ with the changed directory.
Which is a false statement unless you consider a program execve'd into
another to be "running a child".
> 
> There's also the imho sensible rationale of e.g.
> | find . -type d -exec cd {} \; -exec foo {} \;
> | (which invokes "foo" on accessible directories)
> for that requirement, even if these are admittedly rare cases.
>
Not sure if this is a legitimate counter but:
find . -type d -exec cd "{}" pwd \;
does what is expected with execline's binary. In fact, I'm not sure if
your hypothetical is valid since I believe each exec is given its own
execution context and cd is not allowed to modify the callers
environment. Of course, I don't think there are any true stand-alone cd
utilities that we can test this with. If you know of one please tell me.

Similarly:
$ nohup /command/cd / pwd ; cat nohup.out
nohup: ignoring input and appending output to 'nohup.out'
/

On third thought, you're specifically talking about the case where you
fail to give a follow-on program to cd. As of v2.5.3.0, the configure
script in execline has grown the --enable-pedantic-posix option which,
when given, will generate a cd that knows how to handle the NULL case.
> 
> > [placing binaries]
> > Have you ever considered slashpackage ;)
> > 
> > In all seriousness though this, with the exception of dropping the s6-
> > prefix (and the prefix-appender binary I guess), is what slashpackage
> > does. /bin stays uncluttered, commands end up in a PATH-able place, and
> > if you want to surprise any systemic shell scripts you have you can
> > symlink in replacements to the default PATH. 
> 
> Yes, I'm aware of that. Unfortunately, I'm not aware of a unix distro
> usable for my general needs implementing /package as their packaging
> scheme.
> Nix/NixOS does something similar, and is on the short list of distros
> I'll consider if Debian goes ahead with the systemd madness.
> 
> And FWIW, if I were to create my own distro/OS, I'd do away with $PATH
> entirely and have people union-mount stuff into /bin .
> 
And yet NixOS is also primarily a systemd based distro, unless we have
different definitions of "systemd madness."
> 
> 
> > > 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.
> > >
> > As per the docs for forbacktickx:
> > -0 : accept null characters from gen's output, using them as delimiters.
> > If this option and a -d option are used simultaneously, the rightmost
> > one wins.
> 
> Yes, and as per the docs for dollarat:
> -0 : use the null character as separator. Any -d argument will be
> ignored.
> 
> They're both working as advertised. But they have *different* rules for
> resolving the case where both -0 and -d are given.
> I think that's a lack of UI consistency, and would consider it a bug in
> my software.
> (And, as I said, I think the best response to getting both -0 and -d
> would be erroring out, but that's just an aside.)
> 
Fair enough. For some reason I was thinking you were talking about a
documentation error, not a functional inconsistency. I was assuming that
this leaked in when forbacktickx became a wrapper but that isn't the
case, the inconsistency exists as far back as the 2.0.0.0 rewrite.

-- 
Colin Booth

Re: s6 usability

[Jan Braun]

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=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 , 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 

Re: s6 usability

[Jan Braun]

Colin Booth schrob:
> > If you're referring to
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250#37
> > 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.
> >
> It doesn't help that neither Adam nor Jakub read the documentation for
> the execline equivalents for cd, umask, or wait.

Why would you say that? They effectively only claim that execline's
cd/umask/wait binaries don't conform to the POSIX specification for
cd/umask/wait. And I think that's uncontroversally true.

> That or they don't know what 'execs into' means.

POSIX requires:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap01.html#tag_17_06
| However, all of the standard utilities, including the regular built-ins
| in the table, [...]  shall be implemented in a manner so that they can be
| accessed via the exec family of functions as defined in the System
| Interfaces volume of POSIX.1-2008 and can be invoked directly by those
| standard utilities that require it (env, find, nice, nohup, time,
| xargs).

i.e, if you call
execvp("cd", "cd", /* any other args, */ NULL);
, POSIX says you MUST get the behaviour documented at
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/cd.html
. And if /bin/cd is execline's cd, then you don't.

There's also the imho sensible rationale of e.g.
| find . -type d -exec cd {} \; -exec foo {} \;
| (which invokes "foo" on accessible directories)
for that requirement, even if these are admittedly rare cases.

See Message-ID: 
here on the list, from Jonathan de Boyne Pollard for more details.


> Within the context of a shell the builtin will always* take precedence.

True, but not the controversial issue.



> [placing binaries]
> Have you ever considered slashpackage ;)
> 
> In all seriousness though this, with the exception of dropping the s6-
> prefix (and the prefix-appender binary I guess), is what slashpackage
> does. /bin stays uncluttered, commands end up in a PATH-able place, and
> if you want to surprise any systemic shell scripts you have you can
> symlink in replacements to the default PATH. 

Yes, I'm aware of that. Unfortunately, I'm not aware of a unix distro
usable for my general needs implementing /package as their packaging
scheme.
Nix/NixOS does something similar, and is on the short list of distros
I'll consider if Debian goes ahead with the systemd madness.

And FWIW, if I were to create my own distro/OS, I'd do away with $PATH
entirely and have people union-mount stuff into /bin .



> > 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.
> >
> As per the docs for forbacktickx:
> -0 : accept null characters from gen's output, using them as delimiters.
> If this option and a -d option are used simultaneously, the rightmost
> one wins.

Yes, and as per the docs for dollarat:
-0 : use the null character as separator. Any -d argument will be
ignored.

They're both working as advertised. But they have *different* rules for
resolving the case where both -0 and -d are given.
I think that's a lack of UI consistency, and would consider it a bug in
my software.
(And, as I said, I think the best response to getting both -0 and -d
would be erroring out, but that's just an aside.)


cheers,
Jan


signature.asc
Description: PGP signature

Re: s6 usability

[Colin Booth]

On Sat, Dec 21, 2019 at 10:26:39AM +0100, Jan Braun 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,
> 
> If you're referring to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250#37
> 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.
>
It doesn't help that neither Adam nor Jakub read the documentation for
the execline equivalents for cd, umask, or wait. That or they don't know
what 'execs into' means.
> 
> > 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
> viewpoint.
> 
Within the context of a shell the builtin will always* take precedence. 

*I'm sure there's a way to break your shell so that it doesn't but I
don't know what it is and anyway it would be an impressively stupid
thing to do.
> 
> > [... 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
> ...
> - runsvsupervision implemention
> ** runsv one service
> ** runsvdir  a dir of services
> 
> - sv- 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.
> 
I think the real problem here is not that there are too many things
prefixed s6- but that there isn't a super clear delineation between
user-facing commands (s6-svc, s6-svscanctl, s6-svstat, s6-svok, s6-sudo,
s6-tai64nlocal), the portions that belong directly to the supervisor
(s6-svscan, s6-supervise, s6-ftrigrd), and the parts that are only used
occasionally or are meant to be called from inside of scripts (most
everything else). FWIW, runit is actually worse in terms of separating
out what goes where from a documentation standpoint, however there are
only nine programs shipped with runit so it matters less.
> 
> 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.
> 
Have you ever considered slashpackage ;)

In all seriousness though this, with the exception of dropping the s6-
prefix (and the prefix-appender binary I guess), is what slashpackage
does. /bin stays uncluttered, commands end up in a PATH-able place, and
if you want to surprise any systemic shell scripts you have you can
symlink in replacements to the default PATH. 
> 
> > 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
> 

Re: s6 usability

[Guillermo]

El sáb., 21 dic. 2019 a las 6:26, Jan Braun escribió:
>
> > > 1) Debian ships with a working and maintained runit-init package.
> [...]
> > I hear you. Unfortunately, I have no control over what Debian does.
> [...]
> If you're referring to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250#37
> 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.

Trying to accomodate Debian is probably a waste of time at the moment,
until the results of the ongoing General Resolution vote are known
next weekend.

> It's not difficult launching the browser, it's difficult getting to the
> correct webpage. Compare
> | $ elinks /usr/share/doc/s6/s6-log.html

'elinks /usr/share/doc/s6/index.html' and then navigate? :)

> > Would a generic "s6" command, that takes alternative syntax and rewrites
> > itself into "internal" commands, help?
> [...]
> Probably yes, but if you are doing that, then why don't you look at
> argv[0] and provide the runit interface proper? :D

That would create a 'multple personality binary'.

> (Or provide runsv/sv/chpst/.. as individual binaries, since you prefer
> those.)

That could prevent installing both s6 and runit, depending on
packaging, Same as s6 and daemontools[-encore] if the s6- prefix in
program names was dropped.

> > > 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. :(
> [...]
> 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.

If there is no misconception about the need to understand execline,
then I find this criticism quite odd. It's like complaining that a GUI
application 'imposes' e.g. Qt, or that Xorg 'imposes' X11 video and
input drivers. As long as it is a dependency (i.e. an implementation
detail from the POV of a user), if fail to see the problem. I would
understand if it was e.g. a big and intrusive dependency, or a
dependency that prevented you from installing other packages, but
execline isn't that, so I don't see how this compares to systemd.

> 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.

s6 + s6-rc vs runit is not a good comparison. One alternative provides
a service manager, the other one doesn't. Not equivalent feature sets.
s6  + s6-linux-init vs runit would be a better comparison
feature-wise. But, if one takes 1) into account, this is kind of
abstract, because Debian currently packages neither s6-linux-init nor
s6-rc.

G.

Re: s6 usability

[Jan Braun]

Steve Litt schrob:
> > From a Linux distribution perspective, there's also the question of
> > if s6 can be made a drop-in replacement for daemontools, [...]
> 
> In my opinion, 99% of all people currently using daemontools are highly
> technically proficient and could easily either rename commands or
> prepath to a directory containing prefixless symlinked synonyms. IMHO
> if the distro does it, they'll find a way to screw it up. And even if
> the distro does it right, it will screw that 1 in a million people
> (like me) who occasionally use daemontools and s6 on the same box,
> switching between them regularly.

I find these claims to be rather unplausible, given my Debian
experience.

The Debian way would be creating a package "s6-daemontools" containing
just the symlinks from foo to s6-foo and declaring the following package
relationships:
Depends: s6
Conflicts: daemontools
Provides: daemontools
That is, when s6-daemontools is installed:
s6 must also be installed,
daemontools must not be installed,
but daemontools is treated as installed for dependency purposes.

Then, you can choose to install s6 and daemontools together, getting
the default naming for each.

And I can install s6-daemontools and get tai64n/tai64nlocal binaries
that produce correct timestamps despite my kernel clock being set to
UTC. (That is, the ones from s6.)

And every dependency on "daemontools" will be fulfilled, by exactly one
of either djb's daemontools, or s6 plus the symlinks in s6-daemontools.

See espeak-ng-espeak for a real package like that. This is hardly rocket
science, and has been done for *decades* by now.


Maybe non-Debian(-derived) distros are in the business of doing stupid
sh*t, but then you should either switch to a sane distro or be building
your own system. It's certainly no reason to refuse to consider the "s6
as daemontools" concept. Or to insist that people must setup the
symlinks themselves.


Onwards:
Comparing the debian daemontools package with s6 gives:

| $ dpkg -L daemontools  | grep /usr/bin/ | sed -E 's_/usr/bin/_/usr/bin/s6-_' 
| xargs ls -1
| ls: cannot access '/usr/bin/s6-multilog': No such file or directory
| ls: cannot access '/usr/bin/s6-pgrphack': No such file or directory
| ls: cannot access '/usr/bin/s6-readproctitle': No such file or directory
| ls: cannot access '/usr/bin/s6-svscanboot': No such file or directory
| /usr/bin/s6-envdir
| /usr/bin/s6-envuidgid
| /usr/bin/s6-fghack
| /usr/bin/s6-setlock
| /usr/bin/s6-setuidgid
| /usr/bin/s6-softlimit
| /usr/bin/s6-supervise
| /usr/bin/s6-svc
| /usr/bin/s6-svok
| /usr/bin/s6-svscan
| /usr/bin/s6-svstat
| /usr/bin/s6-tai64n
| /usr/bin/s6-tai64nlocal
| $ 

As Laurent said in the other mail:
> s6-setsid can be symlinked as pgrphack [...]
> s6-log can be symlinked as multilog.

That leaves only readproctitle and svscanboot.
The latter is just clearing env, setting $PATH and executing
svscan /service 2>&1 | readproctitle service errors: .
with 400 dots, according to the manpage.

But I don't think there's an equivalent of readproctitle in s6.

Plus, there remains the issue of non-compatible supervise directories.
I don't think the above packaging scheme is valid if it would mean
services (with their existing supervise dirs) fail to work because the
supervise(8) implementation got switched from djb to s6 or vice versa.

But in my quick testing they actually could re-use each other's
supervise dir without tripping over the other implementation's
artifacts.¹

Laurent, is that something that should work/you are willing to support?

In that case, readproctitle would be the only remaining obstacle.

regards,
Jan

¹ They would not recognize each other's locking, however.


signature.asc
Description: PGP signature

Re: s6 usability

[Jan Braun]

Hey,
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
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906250#37
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
viewpoint.



> > 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
...
- runsvsupervision implemention
** runsv one service
** runsvdir  a dir of services

- sv- 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
those.)


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, 

Re: s6 usability

[Laurent Bercot]

From a Linux distribution perspective, there's also the question of if s6 can be
made a drop-in replacement for daemontools, since it does follow djb's naming
scheme. In gentoo, there are various packages that depend on
virtual/daemontools; for example, the nullmailer test suite uses ipcserver. From
a quick comparison of the documentation, it looks like s6 only adds options, and
remains compatible with the daemontools options.


Yes, and that was on purpose, but it's only true with the "official" API
and not with the internals. For instance, the supervise/status file
isn't compatible.



So would it be valid/acceptable for a distribution to create unprefixed symlinks
to the s6-* binaries? It looks like this would mostly only work for the subset
of the binaries that implement daemontools functionality; some others
(s6-setsid, s6-sudo) would have naming conflicts if they were not prefixed.


s6-setsid can be symlinked as pgrphack: same functionality, different
name. The same way that s6-log can be symlinked as multilog.



Then, with the symlinks, s6 could "provide" virtual/daemontools. Maybe this
would also help discoverability (the issue at hand). Maybe the inconsistency
would cause more harm than good, and the symlinks should be "for compatibility
only".


s6 can provide at least surface compatibility with daemontools, yes. 
With

the symlinks, it can still be a drop-in replacement (unless there are
interface changes I haven't thought about).

daemontools replacement is easy. The real subject is compatibility with
runit, which is possible but not quite drop-in.

--
Laurent

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Casper Ti. Vector]

On Sun, Dec 01, 2019 at 09:47:52PM -0500, Steve Litt wrote:
> 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.

Or can we consider the Plan 9 style [1], which searches all relative
paths (in the broad sense, i.e. all which do not begin with `/', `./' or
`../') from $PATH, so we can install chainloaders into /bin/s6 and then
use `s6/cd' to run `/bin/s6/cd' in execline?

[1] 

I fully understand that this convention is not followed in most Unix
shells (except for rc(1) which is from Plan 9, and perhaps some others),
but execline is not a shell, and we can additionally symlink /bin/s6/*
into /bin for backward compatibility.

-- 
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C

Re: s6 usability

[Steve Litt]

On Mon, 2 Dec 2019 17:17:50 -0600
Samuel Holland  wrote:

> On 12/2/19 3:32 PM, Laurent Bercot wrote:
> >> 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.  
> > 
> > Yes, there are a good number of people, me included, who prefer that
> > naming scheme. However, Jan's UX return is valid, and if I want to
> > make s6 adoption as easy as possible, it needs to be taken into
> > account too.  
> 
> From a Linux distribution perspective, there's also the question of
> if s6 can be made a drop-in replacement for daemontools, since it
> does follow djb's naming scheme. In gentoo, there are various
> packages that depend on virtual/daemontools; for example, the
> nullmailer test suite uses ipcserver. From a quick comparison of the
> documentation, it looks like s6 only adds options, and remains
> compatible with the daemontools options.
> 
> So would it be valid/acceptable for a distribution to create
> unprefixed symlinks to the s6-* binaries? It looks like this would
> mostly only work for the subset of the binaries that implement
> daemontools functionality; some others (s6-setsid, s6-sudo) would
> have naming conflicts if they were not prefixed.
> 
> Then, with the symlinks, s6 could "provide" virtual/daemontools.
> Maybe this would also help discoverability (the issue at hand). Maybe
> the inconsistency would cause more harm than good, and the symlinks
> should be "for compatibility only".
> 
> Thoughts?

In my opinion, 99% of all people currently using daemontools are highly
technically proficient and could easily either rename commands or
prepath to a directory containing prefixless symlinked synonyms. IMHO
if the distro does it, they'll find a way to screw it up. And even if
the distro does it right, it will screw that 1 in a million people
(like me) who occasionally use daemontools and s6 on the same box,
switching between them regularly.

Personally, I'd leave well enough alone.

SteveT

Steve Litt 
December 2019 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21

Re: s6 usability

[Samuel Holland]

On 12/2/19 3:32 PM, Laurent Bercot wrote:
>> 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.
> 
> Yes, there are a good number of people, me included, who prefer that
> naming scheme. However, Jan's UX return is valid, and if I want to make
> s6 adoption as easy as possible, it needs to be taken into account too.

>From a Linux distribution perspective, there's also the question of if s6 can 
>be
made a drop-in replacement for daemontools, since it does follow djb's naming
scheme. In gentoo, there are various packages that depend on
virtual/daemontools; for example, the nullmailer test suite uses ipcserver. From
a quick comparison of the documentation, it looks like s6 only adds options, and
remains compatible with the daemontools options.

So would it be valid/acceptable for a distribution to create unprefixed symlinks
to the s6-* binaries? It looks like this would mostly only work for the subset
of the binaries that implement daemontools functionality; some others
(s6-setsid, s6-sudo) would have naming conflicts if they were not prefixed.

Then, with the symlinks, s6 could "provide" virtual/daemontools. Maybe this
would also help discoverability (the issue at hand). Maybe the inconsistency
would cause more harm than good, and the symlinks should be "for compatibility
only".

Thoughts?

Samuel

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Laurent Bercot]

sure, that was just an idea for Jan, he could just create a dir somewhere,
populate it with symlinks he prefers to the original s6 tools and put this dir
in front of the PATH when running s6 since it seems the utilities do not bother 
under what name they run.


Right, but I've heard enough people complain about s6's UI that a 
one-stop

wrapper command sounds like a good idea anyway.



ok. i was more about insights into the design of the whole s6-rc toolset.
are the up/down scripts run by a dedicated service from within the supervision
tree? what exactly is the task of the "s6-rc-oneshot-run" and
"s6-rc-fdholder-filler" internal programs ? how is the startup organized,
how are "longruns" and "oneshots" intertwined ?

having to read the sources to get this information is somewhat inconvenient.


 This is exactly what I was saying: I'm not documenting those details
because I don't want to be bound by them. The s6-rc-fdholder-filler API
changed right before 0.2.0.0; making this necessary change would have 
been

a lot more difficult if people had relied on details of the interface.

 If you're doing something that requires knowledge of the internal 
programs,

you're definitely good enough to read the code. :P

--
 Laurent

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Laurent Bercot]

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.


s6 binaries aren't a problem for Debian; but apparently, execline
binaries are. They're doing exactly that: they're storing execline
binaries under /usr/lib/execline - except they're not putting that
directory in the default PATH, they're only adding it to PATH when
execlineb is invoked. Which breaks some s6 commands in older s6 
versions,

and breaks s6-rc commands (any version), because those assume that
execline binaries can be found in their PATH, and don't call execlineb.

It's completely acceptable to me to put binaries in a separate 
directory.

But said separate directory *needs* to be in the default PATH. If it is
not, it means that those binaries are considered second-class citizens,
and that is *not* acceptable - and even more importantly, it breaks
things.



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.


Yes, there are a good number of people, me included, who prefer that
naming scheme. However, Jan's UX return is valid, and if I want to make
s6 adoption as easy as possible, it needs to be taken into account too.



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.


I think it's already the case, but I'll make a pass on the documentation
to make it abundantly clear.



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.


 1. execline is used *internally* by s6-rc, in autogenerated scripts. 
The

user doesn't have to know anything about it.

 2. source oneshot up/down scripts are parsed by execlineb, so this is a
place where users interact with it. However, the interaction can be made
pretty minimal if the up/down script just calls a shell script stored
somewhere else (typically /etc/init.d), which is common, and generally
good, practice.
 For instance, the "source/network-interfaces/up" script could simply
contain:

 /etc/init.d/network start

and that's it. Technically, this is an execline script, made of two 
words,
but nobody needs to know that; and the complex logic of the script can 
be

implemented in the /etc/init.d/network program, which can be written in
any language. Even in a compiled language, if you're a masochist.

Advanced users can write more complex logic in the
source/network-interfaces/up script itself, using execline binaries for
control flow, etc. But it's by no means essential. For all intents and
purposes, that script is just a small command line that execs into 
another

script, hosted wherever you want, written in whatever language you want.
So I'd say the necessary interaction between s6-rc users and execline is
really tiny.



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.


Well, for one, the execline documentation is bad (it was my first real
attempt at writing software documentation, and it shows), so revamping 
it

would probably help a lot. And second, there *are* execline tutorials
online, you just haven't looked.

--
Laurent

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Jeff]

30.11.2019, 19:58, "Laurent Bercot" :
>> the solution here could be a simple symlink to the original s6 tool without
>> the prefix if you prefer (maybe even located in an other dir than /bin).
>
> That would be a decision for users, not software authors - else it would
> defeat the point of not invading the namespace. Daemontools is still
> around with names such as "svc".

sure, that was just an idea for Jan, he could just create a dir somewhere,
populate it with symlinks he prefers to the original s6 tools and put this dir
in front of the PATH when running s6 since it seems the utilities do not bother
under what name they run.
 
>> using a single combined tool is more efficient since it avoids wasteful
>> further exec chaining steps, though.
>
> Sure, but if we're talking about UI, optimization at this level is a
> very
> moot point. A human choosing between "chpst" and "s6-applyuidgid" will
> *not* notice the extra millisecond taken by an execve() step. The
> primary focus should be usability.

i prefer short names like "chpst" (change process state ?) with multiple
command line options from a usability perspective. but the usage of single
tools with descriptive names is of course easier to read (not to write) and
hence understand when they occur in a script, that's true.

> I am reluctant to make the ABI details public because I want the freedom
> to change them. If people start relying on internals, their stuff may
> break when updating, which would be bad.
> There are *some* details that I could document as official and stable,
> but I'd need to go through all of it and decide with precision what can
> be guaranteed and what cannot - and that's extra work, so it will have
> to wait.

ok. i was more about insights into the design of the whole s6-rc toolset.
are the up/down scripts run by a dedicated service from within the supervision
tree? what exactly is the task of the "s6-rc-oneshot-run" and
"s6-rc-fdholder-filler" internal programs ? how is the startup organized,
how are "longruns" and "oneshots" intertwined ?

having to read the sources to get this information is somewhat inconvenient.
:-(

Re: s6 usability

[fungal-net]

As a test for portability for the 66 software, other than its display
case based on arch - called obarun - a couple of devs recently tried it
in a few distributions that have the s6 in their repository.

Funtoo was the first target
https://forum.obarun.org/viewtopic.php?id=956 and this was done by a dev
who used plasma on obarun and used plasma on funtoo.

Void has s6 and 66 is under testing but boot-66serv has to be installed
separately with a modification to match void's choice of placing
services in /usr/share instead of the original /usr/lib.  With 6-7
commands and it booted to a tty of choice.  I've been using it daily
since (I was shown the way) in musl flavor.  A delight and a more
responsive system (feels that way) than the OEM runit.  I wish I had one
of the 7-9 alternative void architectures to do further testing but all
I have is refurbished tired x64s.
https://forum.obarun.org/viewtopic.php?id=957

Then there was adelie and kiss (an alpha system with similarities to
gentoo but installs in little time)
https://forum.obarun.org/viewtopic.php?id=961
https://forum.obarun.org/viewtopic.php?id=959 with similar ease.

With debian there is the obstacle of s6 being intentionally broken by
dislocated skalibs but I am speculating there is more to it.  How often
has a broken package been available in the 4 level hierarchy of debian?
If it was on experimental I can understand, but there are two versions,
recent and previous s6 and libs, both broken, in sid,testing,stable.  I
may be paranoid but isn't this also preventing devuan and antiX (and its
MX derivative) from effectively trying s6 unless they uniquely rename
the packages confusing users?

I know that the scope of this list is in hacking experimental init and
service supervision software but what better way to test the work other
than displaying it in more popular distributions?
All one needs past s6 is boot-66serv
# git clone https://framagit.org/obarun/boot-66serv
# cd boot-66serv
# ./configure --bindir=/usr/bin --shebangdir=/usr/bin
--with-system-service=/usr/lib-{or share or whatever}/66/service
# make install

I think it would take an earth-shaking new development for someone to
pry me away from 66 for years to come, if I have that much left in me.

PS  I am writing this still shaking in anger from reading Jesse Smith's
Distrowatch review of Obarun, using an old image with a previous
installer, declining its initial prompt to update the installer and
theme, failing the installation and moving on to bluestar, a desktop
theme customizer of arch, and finding it wonderful.  This is after
listing Obarun for 1.5 years, declining to correct its information for
more than 7 months, and bad mouthing it, in the same article where its
headline lists Devuan as Debuan2.1.  Same guy reviewed Adelie (near its
beta life end) and failed to see s6 in it.

Has RH and its mother... IBM converted the open and free software world
into a head-butting ring?  No, there are others at fault for that as
well.  Arch for example is pushing facebook's compression algorithm into
its packaging by default.  I am now going to shut off this machine and
take my 30yo Bridgestone cycle with friction shifters out for a ride in
this fine sunny wintery day, because I am getting too disgusted from
doing any real work, hopefully no big truck will run in my way.  :)
Did you know there are now about 3 corporations responsible for about
90% of the bikes made?  A "free" choice among 1300 models.

Re: s6 usability

[Dewayne Geraghty]

Hi Steve,


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.


No the user doesn't need to write execline scripts. The following 
equally applies to s6-rc.


Refer to:https://skarnet.org/software/s6/overview.html
for:
"execline makes it natural to handle long command lines made of massive 
amounts of chain loading. This is by no means mandatory, though: a run 
script can be any executable file you want, provided that running it 
eventually results in a long-lived process with the same PID."



Regarding creating a s6 subdir of bin.  I have some 1325 applications 
(FreeBSD people call them ports), only 1 has a separate directory under bin.

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Steve Litt]

On Sat, 30 Nov 2019 10:15:27 +
"Laurent Bercot"  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

Re: s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Jeff]

30.11.2019, 11:15, "Laurent Bercot" :
> 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.

totally agreed, Laurent.

using a dedicated namespace prefix like "s6-" is a very good idea.
this avoids nameclashes (i. e. overwriting on installation) with similar
utilities of other supervision suites and frees Laurent from the task
of coming up with proper AND unique command names. consider
nameclashes of several "init" program for example.

the solution here could be a simple symlink to the original s6 tool without
the prefix if you prefer (maybe even located in an other dir than /bin).

> 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.

using a single combined tool is more efficient since it avoids wasteful further
exec chaining steps, though.

> 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.

Busy/ToyBox style ?

> 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.)

sounds not too bad, IMO. though i personally can live without it,
especially since the other suites also provide loggers (without any
execline deps of course), he can use dt encore's "multilog" utility.

> s6-rc, however, absolutely cannot do without execline, since it uses
> autogenerated execline scripts.

could you document the way s6-rc works (i. e. its architecture) somewhere ?
or are users requested to follow your C code to find out how it works
exactly ?

> 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.

indeed.

s6 usability (was: runit patches to fix compiler warnings on RHEL 7)

[Laurent Bercot]

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,