From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2771 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Laurent Bercot" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: s6 usability Date: Sat, 21 Dec 2019 23:46:34 +0000 Message-ID: References: <20191125214342.y7lx5mixrljr6s27@gromit.local> <20191127203307.ohaameqfgncm52h5@gromit.local> <20191129140901.klifpegc74iv4zul@klumpi.ignorelist.com> <20191221092639.p5iid3y3csmni4iw@klumpi.ignorelist.com> Reply-To: "Laurent Bercot" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB4B17F3EF-8931-4377-AB95-4D38044901EC" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="147223"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: eM_Client/7.2.36908.0 To: "supervision@list.skarnet.org" Original-X-From: supervision-return-2360-gcsg-supervision=m.gmane.org@list.skarnet.org Sun Dec 22 00:46:41 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 1iioSH-000c8s-1E for gcsg-supervision@m.gmane.org; Sun, 22 Dec 2019 00:46:41 +0100 Original-Received: (qmail 21537 invoked by uid 89); 21 Dec 2019 23:47:04 -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 21530 invoked from network); 21 Dec 2019 23:47:04 -0000 In-Reply-To: <20191221092639.p5iid3y3csmni4iw@klumpi.ignorelist.com> X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrvdduiedgudduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecupfgfoffgtffkveetuefngfdpqfgfvfenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkjghfrhgfgggtsegrtderredtreejnecuhfhrohhmpedfnfgruhhrvghnthcuuegvrhgtohhtfdcuoehskhgrqdhsuhhpvghrvhhishhiohhnsehskhgrrhhnvghtrdhorhhgqeenucffohhmrghinheplhhmghhtfhihrdgtohhmpdhunhhigidrtghomhdpuggvsghirghnrdhorhhgnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhhtnecuvehluhhsthgvrhfuihiivgeptd Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2771 Archived-At: --------=_MB4B17F3EF-8931-4377-AB95-4D38044901EC Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable >If you're referring to >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D906250#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=C3=A9lie 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=3Ds6-log&iie=3D1 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=20 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=20 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=20 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=20 simpler, less buggy, more restricted and less resource-consuming* than the=20 scripting language that already exists on every Unix machine and that everyone=20 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=20 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 --------=_MB4B17F3EF-8931-4377-AB95-4D38044901EC--