From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24456 invoked from network); 1 Sep 2020 19:24:34 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 1 Sep 2020 19:24:34 -0000 Received: (qmail 27043 invoked by uid 89); 1 Sep 2020 19:24:58 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 27036 invoked from network); 1 Sep 2020 19:24:58 -0000 X-Virus-Scanned: Debian amavisd-new at disroot.org Subject: Re: possible s6-rc redesign DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1598988270; bh=mOOVchj+e5c/v9woK1OpKwf6zUuycnjufVcL7sPApT8=; h=Subject:To:References:From:Date:In-Reply-To; b=D+MTAx53s37bZb7iUbelOOvRRwYzzhTAk3X5FUCIRPczD092rmVynFeEhMdypTpeD cjxGhU+FV0vygqpeeT3QNyTSy7NuafpGcfXmMiu1t4cdfh6WbTS91qGf4Aon5D8rie yVMZe3QBsifH508BwE46VXmYiGlLzsMwj8OiCJjDBQO44dHeESyjaEIuanfgM5zCQI 9fyJsM1QoO96+ngunmq39rPiSryves/GrGtG2zge3TbJgX2BvjZsinYUgo4/D0JBQa Th5L0oqz2bARSZzq/WMWtNR2bHW22gbwa+98lCAM79c0Tx12I7hR0mzIhbiF+t4TI0 TjEdPeDJDwXFg== To: supervision@list.skarnet.org References: <877dtgtu1z.fsf@ada> From: mobinmob Message-ID: Date: Tue, 1 Sep 2020 22:24:27 +0300 Mime-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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.