From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2773 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jan Braun Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: s6 usability Date: Sun, 22 Dec 2019 06:53:24 +0100 Message-ID: <20191222055324.4iakf3sny5xz2utj@klumpi.ignorelist.com> References: <20191125214342.y7lx5mixrljr6s27@gromit.local> <20191127203307.ohaameqfgncm52h5@gromit.local> <20191129140901.klifpegc74iv4zul@klumpi.ignorelist.com> <20191221092639.p5iid3y3csmni4iw@klumpi.ignorelist.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bsej2lcdceim6opw" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="196130"; mail-complaints-to="usenet@blaine.gmane.org" Cc: "supervision@list.skarnet.org" To: Laurent Bercot Original-X-From: supervision-return-2362-gcsg-supervision=m.gmane.org@list.skarnet.org Sun Dec 22 06:53:30 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iiuBF-000ouf-ML for gcsg-supervision@m.gmane.org; Sun, 22 Dec 2019 06:53:29 +0100 Original-Received: (qmail 25944 invoked by uid 89); 22 Dec 2019 05:53:52 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 25935 invoked from network); 22 Dec 2019 05:53:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1576994004; bh=MQhfXfQDdMLbZHSIzaHoXoAcWZ5PuJpLAeDs8d1LJ14=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References:In-Reply-To; b=VGWp2inuJmdqkcE3fCPIRgAn3OnUKqlgM4SlxdQJjL1MM5+BUqlaatRs7HNGsfk6B 1kcTUhM81AjxMtn2i3N9gaaHM+moQIwW4+3631iTg8thWHBcwWwwQjsG+PMZPa5PXV k8ptuJFB9pjPY7ptagCCkV4LDD5Ynt12eo4WKbWc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Mail-Followup-To: Laurent Bercot , "supervision@list.skarnet.org" X-GPG-Fingerprint: 1736 D50F 170B 70A6 9223 BC15 295E 703E 6D1D 2FCF X-GPG-Encryption-Welcome: always Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:ZVUanZ4pz1vOAkN+G6MUrxTlpXUYsQWEjqu37Q33qQKgmuL7a8W rgIWcGKZcHmS16Oeb8I2FWTulOtR6TfAUncopsB3RP/llM4MF24Fk2KpuBIJ/amuhI0QWqJ seSnDUq2weCEGeDhGr5klcHXtEyLV6Kup+C6CiCXQIXAHSPfmo2wIZ+QF48h3oavuW0QUPs QFTYeAIjGgkPV2IqJB4yg== X-UI-Out-Filterresults: notjunk:1;V03:K0:1II0+9iZliQ=:jUTvkNs7R0qoqR6SrFQKlJ dJ603I5YNQOQyThTBzKOxsyPo8q+8ZJPhSWeVAmc0lZFioSf0PKERDuHvg8JPCtE6vixzA77o GTR8I/mLUBTRI04wxN8mkBal9dy20o1p/d3kSX2r06W09x2KjAzzmUnLrGvUTjDoCpXBFfNGU f+dlygsF6kmvi3WCvOYKOKbyacSU292gkS9z74IL+9BeVbRpqVHmRibdnewIIZCDT0rybutmc eU995vpE9+5eG/2KTie2PwWjKx48fGnTXIL9iZaxeWgTqgy2o7AFenLQI7lmKrQDfW+pf6Xl2 qweJ9XMw2Ce0VvplWDWCa4idYkGRUDkWFjgEZYYRgMqkhrRJBDpQoyK+6/+f1HuNPpvxi9AUy SmCtBAs8ul8VF7zx/jof08UcWMDaE5+FQJGaMnff8zOsWITK14bH2dpWfHa6mJbGPyLAWXRZu jLnG2hjVNWVQ2QohRyb36icIx3a+Kcp+IE1Wxt+Q/PjvCnvPMEvUf37DkJRRFpiliJkvKtjxI VHc9GTtnd7K2EBXOUwazguzCvNeJQveW/bHWR6dVVbaAbaYaU+HWPEfX2hPPdc1vKhH/rdMp6 N5Ku/yAscWsfAXK1LkOxS3bju+MVB57HqQ+cdZH9Vy7nxwj/i4rZvO49X8ehatjE9Eo8wcpyR ATG5iuVFDM9Yzz48cmp+gEIKvZuMHXPhGr3qRq0Y7YHU5LHSvjXHvQNXezt5rbF7O/+7e+bWI PanpYHQZX84l2zg0v1M/xjqUPkhb4H7lhGiHa2Wcc8hDCifhRFEmJGX+rzYpWGvhsc3OnKP4 Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2773 Archived-At: --bsej2lcdceim6opw Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=B9. I'm sorry you feel differently. :( > Ad=E9lie 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=3Ds6-log&iie=3D1 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.ht= ml > 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. >=20 > ... 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. :( >=20 > 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=B2 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 scripti= ng > 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.=B3 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 =B9) 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. =B2) 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. =B3) 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[v= l]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. --bsej2lcdceim6opw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEFzbVDxcLcKaSI7wVKV5wPm0dL88FAl3/BM4ACgkQKV5wPm0d L8+beg//fXzVoX0e75yyJr8pqh+vcc/tm3Q0/Xe5fJ1j+P0Xh+FyfSc4o0jh4epS M9fpGfYY8bWVBeGuKuHUhhdpW1NxjdgQJbnaR4ptSmLsYg3Tsk2IVUz2PS4Vq9S1 Lkr4uYNgQodN1voIpoB3EQbtWoge1b5p+ucoE1DbTBRgfN66uTzj5k4HH1T4gRe2 8mCU5Yp6ocV3C/nc8SHeKvwsDUf3h/gd0SShvEYBoHa5M/0Ec08q1fZaWp7r/MBq mxkDlqLs+72pZ8GR5RT21/LtzXsYUdNZPVENSyvH3shUwvyFAyMZZZdENZ2zmCfv yisbGpi7zqklfzSTn5cQu5kAaRygLY6xtQ9lOCSpWKLdrvDZvphVAxuwjMv7/8CA EFQjen8WwLKU5g9SEPOsoyfsTunEbK59DpgLmdNysEnHfwqDOhW5KafJeWuGeyWK h7L6weAdPw05cTrQVbvigkHX1kZUkRjDGH9FAfduGTaDn4rNPzP+AYo9dFNAW4E+ GEszOx+tunMUa0cYzweQPP50S2K/VGGHLHmf9DL7HITae6d4O9T08QJ1rhHaqOJJ xH4Z2/scuq0HyNivvrW42gDwx2WnodEMYDGNFd9JirZ1fQ4SWoNojV4IyHzRqzI8 F90dRjyFk0xuzyR0tA/dWjTOWNHbqY08JHtDiPm7ezvNgiU+j6c= =haya -----END PGP SIGNATURE----- --bsej2lcdceim6opw--