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 16237 invoked from network); 2 Sep 2020 09:41:22 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 2 Sep 2020 09:41:22 -0000 Received: (qmail 6415 invoked by uid 89); 2 Sep 2020 09:41:44 -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 6408 invoked from network); 2 Sep 2020 09:41:44 -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=1599039672; bh=pHt2sWAkCx0ZaDRllow07EcD+GHgqpb/3wVjBljAZOI=; h=Subject:To:References:From:Date:In-Reply-To; b=a+JrZ7iexRvFMdpk/Ib+/jzsPNekiJWbzspx3iglUtjxjkJ0qw3JmthxZzpo3CZoN ElKUSOxWirXpY4GM4OBXc4PNwBhv4dbTI0CUP8Yz6cNICuITalbQ6YqhDs1eyDb5IZ D5lwpNmQErKJanePipHIXg77xzest7EhcwtikXCU/R5g+v4wn1SrQALkPLI9s7F8Wo HaIey9KKKkxMBH8T3My+sOxoIBAS0OyNnFM8f3IY1rWn94tF6aol6OoAZjZdNUO2uK ik+cCyt2HDiBZQZ4DLr6LX0Ro4CWkYoia1CgS83pu3LdaTDDkCPCe8tOcx99jmj1W9 937nnDFR/m7gQ== To: supervision@list.skarnet.org References: <877dtgtu1z.fsf@ada> From: mobinmob Message-ID: <3f51fff7-7e1c-3718-4b58-2f464cac4eb4@disroot.org> Date: Wed, 2 Sep 2020 12:41:05 +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 On 2/9/20 1:20 π.μ., Laurent Bercot wrote: >> 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. > >  You may have missed the part where I'm saying that the current version > of s6-rc will still be supported for a *long time*. I would also try, > obviously, to make the conversion to the new format as painless as > possible; ideally (but I don't know yet whether it's an attainable goal), > the source directories would have the exact same format as long as only > static services are defined - so tools using s6-rc-0.x would still work > with basically no changes. > If long term support is guaranteed and a smooth transition path is provided then any concern I have suddenly dissipates :p >> 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, > >  And they definitely won't, if nothing challenges systemd. But > providing the same level of functionality as systemd (as far as the > init system is concerned, I'm not talking about all the tendrils it sends > into various parts of running a Linux machine) with a better design, that > is not completely alien to what those distros are used to, is the only > way to - someday - have a chance at challenging systemd. > There are two issues here... 1. In order to provide the -sane- functionality of systemd, a system needs to use linux-only interfaces. I am absolutely not saying that cgroups, namespaces etc should be tightly integrated to a service manager/init system. Most of the work can be done on dedicated programs but they are needed if the goal is feature-parity... 2. Distributions that use systemd are slowly depending more and more on these tendrils (great analogy btw :P). I do not think they will make the effort to get rid of them or provide alternate mechanisms to facilitate inclusion of a different init system no matter how much better, cleaner and well- designed it is. And s6-rc is all three of them IMHO. The only way to create pressure is a successful set of distributions that use other solutions... >  I agree with that - except that the compiled db is actually a very > small hurdle, that goes away once you explain that OpenRC and systemd > also use a compiled db except that it's hidden and everything is done > dynamically, and s6-rc only makes it cleaner and more upfront. Well said :) >  Yes, the solution is a user-friendly interface, but that's not > relevant to what I'm talking about. What I'm saying is that > distributions, > including ones that currently use s6/s6-rc under 66 or any other > interface, *will* need dynamic events integration to the service manager > at some point, and the question is, how to add the functionality to > s6-rc. I think Option 2 is *more* likely to get adopted by > distributions overall. Distros that have already drunk the s6-rc > kool-aid will be fine with either option 1 or option 2 (see above); > normie distros will very probably be repulsed by option 1. > Yes, dynamic events integration is absolutely needed, no argument there. If that can be done with minimal disruption on the user/integrator side I have no problems with either option. > >> 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. > >  Yes, people can pick and choose what they want, and as it is now, things > are working for power users. >  That is still niche though, and in order to reach more people, a wide > array of distributions is the way to go. >  I'm very happy that distributions such as Obarun and Artix have done > the effort of actually porting services to a new format, be it 66 > or raw s6-rc; but it is not something that can be expected from most > distributions, especially the big ones, which I *will* be aiming for at > some point. I don't like the idea of a software author providing policy, > any more than you do, but it is what worked for systemd and OpenRC, and > in case you haven't noticed, I'm trying to be very pragmatic here, and > to make the necessary sacrifices of principles in order to gain wider > adoption. > > -- >  Laurent > I am not saying that policy should not be provided at all. I am saying that they are  advantages if it is provided outside of the main project and downstreams tailor it to their specs. Voidlinux runit configuration is influenced by ignite and artix runit is influenced by voidlinux. Both voidlinux and artix have pretty different policies expressed in the relevant scripts. They also share a lot of scripts. Building 66 frontend service files for voidlinux (unofficially) I have checked obarun 66 frontends, artix s6-rc services and voidlinux runit scripts. but the minimal policies I strive to implement are those of voidlinux. My point is... runit has found adoption in the post-systemd era despite having obvious issues. It was not a comprehensive upstream policy that helped it. I think it is a better model for adoption that that of openRC or systemd.