>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.
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.
>I don't think that's the real issue.
Unfortunately, it is. Debian's claim at POSIX compliance is pure
hypocrisy, only used when it furthers other goals of theirs and
promptly forgotten when it's at odds with them.
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.
>It's not difficult launching the browser, it's difficult getting to the
>correct webpage. Compare
>| $ elinks /usr/share/doc/s6/s6-log.html
https://lmgtfy.com/?q=s6-log&iie=1
Of course, you can argue that not every machine is connected to the
Internet, which is true. But the overwhelming majority of times when
I've had to tinker with an unconnected machine, and had no access to
the Web whatsoever, it was for bootstrapping, or for tinkering with an
embedded target, and the unconnected machine did not have a functional
manpages database either.
A manpages indexer is actually more difficult to bootstrap than a
network connection + a text-based Web browser!
What I would say is that if the obstacle to HTML documentation is
that there are no shortcuts to locally installed HTML docs, whereas man
comes with an index for the local manpages database, then what we need
to do as a community is a local HTML doc indexer. Then you would be able
to type
$ doc s6-log
and you'd have your favorite browser auto-launched on the local
s6-log.html
page.
*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. :(
>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.)
One does not preclude the other. :P
I am currently experimenting with such a thing. The *exact* runit
interfaces are difficult to provide, because runit's conception is
slightly different from s6's and emulating precise runit behaviour
requires significant effort that I feel is not a good time investment.
(For instance, runsv and s6-supervise are not exactly similar, because
runsv also handles a logger whereas s6-supervise only handles one
service. svlogd reads a config file in a logdir, s6-log does not.)
I'd rather provide close interfaces that work in the common cases
but fail in the edge cases with an explanation why and a suggestion on
how to use the related s6 command. The goal isn't to mimic runit, the
goal is to help runit users transition to s6.
>But outside of supervision, I notice that you are reimplementing a
>lot of small programs.
Those are mostly legacy, from a time when I wanted to bootstrap a
machine with no GNU code (and no busybox either). They're out of scope
for s6 or the related utilities; prefixing them with s6- was probably
my worst naming mistake.
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. That page
would, among other things, mention s6-*-utils and explain how relevant
they are (i.e. not much).
>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 that s6 is a collection of utilities
doing a lot of stuff, and that the scripting language is used by a
few binaries in the collection, and not by the core supervision
programs.
Moreover, there would be a relatively easy way not to do that: anywhere
execline is used, use a shell instead. And spawn shell scripts instead
of simple command lines. And nobody would bat an eye.
But the reason why execline exists is to make it lighter, easier and
more secure to spawn command lines. It is to be *better* than the shell
in the s6 use cases. It's not to add Turing completeness to a parser in
pid 1 or whatever nonsense you can come up with. So it's very unfair
criticism to say "it brings its own scripting language along": I
understand
you may have been burned by crappy software before, but s6 is not like
that. 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.
>When you explain it like that, it sounds far more reasonable.
The new documentation page I'm thinking about should definitely explain
that, to nip any misconsceptions in the bud.
>I'd appreciate this regardless of the internal dependency. 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.
That is really not the goal. I don't want to popularize execline because
it's execline. I want it to be used in the exact places where it's
beneficial to use it over a shell. And a s6-log processor definition is
precisely such a place. I care about software design first and
popularity
second; if it weren't the case, I'd be writing commands that are easy
to type and that autoplay cute videos.
$ cute cat
$ cute puppy
$ cute blobfish
I guarantee you such a program would be more popular than s6.
>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
>it's not clear to me how much of that complexity is optional, and what
>it might buy me. Maybe a better high-level overview document might help
>there.
Yes. The document I'm thinking about would explain that.
Thanks again for your UX returns. They are definitely useful.
--
Laurent
Received on Sat Dec 21 2019 - 23:46:34 UTC