supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Samuel Holland <samuel@sholland.org>
To: Laurent Bercot <ska-supervision@skarnet.org>,
	"supervision@list.skarnet.org" <supervision@list.skarnet.org>
Subject: Re: s6 usability
Date: Mon, 2 Dec 2019 17:17:50 -0600	[thread overview]
Message-ID: <337de051-b2b4-4f69-78e7-3f737f40384f@sholland.org> (raw)
In-Reply-To: <em2e0268be-cdbf-4cef-9d66-6bfb0eb8ff38@elzian>

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


  reply	other threads:[~2019-12-02 23:17 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-25 21:43 runit patches to fix compiler warnings on RHEL 7 J. Lewis Muir
2019-11-27 20:33 ` J. Lewis Muir
2019-11-28  7:59   ` Ben Franksen
     [not found]   ` <ecdf4d8f-93f6-3f9f-b84c-351fa91c7f02@uni-bremen.de>
2019-11-28 19:04     ` Laurent Bercot
2019-11-28 20:39       ` Steve Litt
2019-11-28 22:17         ` runit or s6 (was: runit patches to fix compiler warnings on RHEL 7) Laurent Bercot
2019-11-29 14:09       ` runit patches to fix compiler warnings on RHEL 7 Jan Braun
2019-11-29 21:46         ` Dewayne Geraghty
2019-11-30  1:22           ` Colin Booth
2019-11-30  0:21         ` Colin Booth
2019-11-30  3:14           ` Steve Litt
2019-11-30 13:32           ` Jeff
2019-11-30 13:46             ` Jeff
2019-11-30 10:15         ` s6 usability (was: runit patches to fix compiler warnings on RHEL 7) Laurent Bercot
2019-11-30 14:32           ` Jeff
2019-11-30 18:58             ` Laurent Bercot
2019-12-02 12:07               ` Jeff
2019-12-02 22:20                 ` Laurent Bercot
2019-12-02  2:47           ` Steve Litt
2019-12-02  3:37             ` s6 usability Dewayne Geraghty
2019-12-02 10:24               ` fungal-net
2019-12-02 21:32             ` s6 usability (was: runit patches to fix compiler warnings on RHEL 7) Laurent Bercot
2019-12-02 23:17               ` Samuel Holland [this message]
2019-12-03 22:10                 ` s6 usability Steve Litt
2019-12-21 11:49                   ` Jan Braun
2019-12-04 12:15                 ` Jonathan de Boyne Pollard
2019-12-04 21:02                 ` Laurent Bercot
2019-12-04  1:30             ` s6 usability (was: runit patches to fix compiler warnings on RHEL 7) Casper Ti. Vector
2019-12-21  9:26           ` s6 usability Jan Braun
2019-12-21 18:36             ` Guillermo
2019-12-21 21:19             ` Colin Booth
2019-12-22  1:05               ` Jan Braun
2019-12-22  8:30                 ` Colin Booth
2019-12-21 23:46             ` Laurent Bercot
2019-12-22  5:53               ` Jan Braun
2019-12-22 20:33               ` Steve Litt
2019-12-22 23:20                 ` Laurent Bercot
2019-12-23  1:28                   ` Oliver Schad
2019-12-23  9:14                     ` Laurent Bercot
2019-12-23 10:15                     ` Jonathan de Boyne Pollard
2019-12-24  0:18                       ` Oliver Schad
2019-12-23  1:57                   ` Steve Litt
2019-12-23  9:00                     ` Laurent Bercot
2019-12-22 23:47                 ` Dewayne Geraghty
2019-12-04 11:36         ` runit patches to fix compiler warnings on RHEL 7 Jonathan de Boyne Pollard
2019-12-04 16:40           ` J. Lewis Muir
2019-12-04 20:48             ` Laurent Bercot
2019-12-04 21:32               ` J. Lewis Muir
2019-12-04 21:06             ` Steve Litt
2019-12-04 21:50               ` Laurent Bercot
     [not found]                 ` <20191205132736.7f501460@puter>
2019-12-08 19:10                   ` Laurent Bercot
2019-12-02 17:57       ` J. Lewis Muir
2019-12-02 21:06         ` J. Lewis Muir
2019-12-02 22:22           ` Laurent Bercot
2019-12-02 21:58         ` Laurent Bercot
2019-12-03 10:57           ` Benjamin Franksen
2019-12-04 10:43       ` Jonathan de Boyne Pollard
2019-12-02 17:13     ` J. Lewis Muir
2019-12-04 11:13       ` Jonathan de Boyne Pollard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=337de051-b2b4-4f69-78e7-3f737f40384f@sholland.org \
    --to=samuel@sholland.org \
    --cc=ska-supervision@skarnet.org \
    --cc=supervision@list.skarnet.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).