supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Steve Litt <slitt@troubleshooters.com>
To: supervision@list.skarnet.org
Subject: Re: s6 usability
Date: Tue, 3 Dec 2019 17:10:20 -0500	[thread overview]
Message-ID: <20191203171020.2a4e9a92@mydesk.domain.cxm> (raw)
In-Reply-To: <337de051-b2b4-4f69-78e7-3f737f40384f@sholland.org>

On Mon, 2 Dec 2019 17:17:50 -0600
Samuel Holland <samuel@sholland.org> 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


  reply	other threads:[~2019-12-03 22:10 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               ` s6 usability Samuel Holland
2019-12-03 22:10                 ` Steve Litt [this message]
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=20191203171020.2a4e9a92@mydesk.domain.cxm \
    --to=slitt@troubleshooters.com \
    --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).