From: mobinmob <mobinmob@disroot.org>
To: supervision@list.skarnet.org
Subject: Re: possible s6-rc redesign
Date: Tue, 1 Sep 2020 22:24:27 +0300 [thread overview]
Message-ID: <acff2ad8-dbfb-2be7-f30c-6c66c8e33b95@disroot.org> (raw)
In-Reply-To: <ema7149ac8-833d-4cdc-9ee4-a8cfc087052a@elzian>
Thank you for taking the time to present the options and the technical
arguments for each of them. I cannot offer a comment on the best way
to proceed on technical grounds, but I can offer my two cents as someone
who tries to bring an s6-rc based solution (66) to a distribution.
1. There is one **huge** disadvantage for the second option. It is not a
technical one, so it may carry little weight on your final decision.
There already different implementations of init systems based on s6/s6-rc,
some of them successfully used on distributions. They will almost certainly
have to be abandoned or rewritten to function with the redesigned suite.
The first option will allow these implementations to augment what they
offer
with minimal or no disruption for their users and developers.
2. Which distributions or groups of distributions will find the redesign
appealing,
so that they will adopt it ?
IMHO distributions that use systemd are not likely to change in the
foreseeable
future, so that leaves the distributions that use something else. Some
of them
already have s6-based solutions (official or not), so adopting the
redesigned
will be akin to adding another init for them. Distributions that use
neither
s6/s6-rc nor systemd will be a likely target but they have to be
persuaded to
use a -almost certainly- more complex solution than what they have and that
is an uphill battle.
3. Yes, the compiled db of services or the many files in the servicedir can
discourage people to use s6-rc. But ANY new format will face similar
criticism and some of the problems can be alleviated with the proper
frontend. I use 66. Ι never touch servicedirs - it uses ini-based "frontend
service files"- and I have dabbled with the compiled once, indirectly.
4. On the issue of mechanisms vs policy I fully agree that people want
a turnkey solution. However I do not think that is something that should
be done in a cetralised manner. There already at least 3 different working
sets of services created for s6-rc (artix, slew, 66) and someone can
inspect,
use and modify them to fit their needs or policies.
next prev parent reply other threads:[~2020-09-01 19:24 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-30 8:30 [request for review] Port of s6 documentation to mdoc(7) Alexis
2020-08-30 9:10 ` eric vidal
2020-08-31 6:56 ` Alexis
2020-08-30 10:01 ` Laurent Bercot
2020-08-31 7:01 ` Alexis
2020-08-31 11:04 ` Laurent Bercot
2020-08-31 14:29 ` Guillermo
2020-09-01 10:00 ` possible s6-rc redesign (was: [request for review] Port of s6 documentation to mdoc(7)) Laurent Bercot
2020-09-01 19:24 ` mobinmob [this message]
2020-09-01 22:16 ` possible s6-rc redesign Dudemanguy
2020-09-01 22:20 ` Laurent Bercot
2020-09-02 9:41 ` mobinmob
2020-09-02 12:14 ` Laurent Bercot
2020-09-01 23:14 ` possible s6-rc redesign (was: [request for review] Port of s6 documentation to mdoc(7)) Steve Litt
2020-08-31 16:08 ` [request for review] Port of s6 documentation to mdoc(7) J. Lewis Muir
2020-08-31 17:45 ` Jason Lenz
2020-08-31 19:14 ` J. Lewis Muir
2020-08-31 20:51 ` Laurent Bercot
2020-09-01 6:38 ` Casper Ti. Vector
2020-09-01 9:03 ` Alexis
2020-09-01 9:20 ` Casper Ti. Vector
2020-09-01 10:02 ` Alexis
2020-09-01 10:15 ` Casper Ti. Vector
2020-09-01 20:13 ` Steve Litt
2020-09-02 0:50 ` Alexis
[not found] ` <20200901063801.GA2158@caspervector>
2020-09-01 10:11 ` Laurent Bercot
2020-09-01 11:28 ` Casper Ti. Vector
2020-09-01 11:55 ` Alexis
2020-08-31 19:36 ` Laurent Bercot
2020-08-31 19:58 ` J. Lewis Muir
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=acff2ad8-dbfb-2be7-f30c-6c66c8e33b95@disroot.org \
--to=mobinmob@disroot.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).