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.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10890 invoked from network); 1 Sep 2020 22:20:52 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 1 Sep 2020 22:20:52 -0000 Received: (qmail 30011 invoked by uid 89); 1 Sep 2020 22:21:18 -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 30004 invoked from network); 1 Sep 2020 22:21:17 -0000 From: "Laurent Bercot" To: supervision@list.skarnet.org Subject: Re: possible s6-rc redesign Date: Tue, 01 Sep 2020 22:20:51 +0000 Message-Id: In-Reply-To: References: <877dtgtu1z.fsf@ada> Reply-To: "Laurent Bercot" User-Agent: eM_Client/8.0.3385.0 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrudefkedgtdejucetufdoteggodftvfcurfhrohhfihhlvgemucfpfgfogfftkfevteeunffgpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhhrfgggtgfgsehtqhertddtreejnecuhfhrohhmpedfnfgruhhrvghnthcuuegvrhgtohhtfdcuoehskhgrqdhsuhhpvghrvhhishhiohhnsehskhgrrhhnvghtrdhorhhgqeenucggtffrrghtthgvrhhnpedvgfevffeuleegvdektdffteegvdeiieefkeetgfeuheffheelheejhfevueeijeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht >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 certainl= y >have to be abandoned or rewritten to function with the redesigned suite. >The first option will allow these implementations to augment what they off= er >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=20 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. >2. Which distributions or groups of distributions will find the redesign a= ppealing, so that they will adopt it ? >IMHO distributions that use systemd are not likely to change in the forese= eable 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=20 sends into various parts of running a Linux machine) with a better design,=20 that is not completely alien to what those distros are used to, is the only way to - someday - have a chance at challenging systemd. > so that leaves the distributions that use something else. Some of them >already have s6-based solutions (official or not), so adopting the redesig= ned >will be akin to adding another init for them. No, absolutely not. The idea is to have something similar to s6-rc, but with more functionality integrated in it. It would not be a different init by any stretch of the imagination. >3. Yes, the compiled db of services or the many files in the servicedir ca= n >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. =CE=99 never touch servicedirs - it uses ini-based "fr= ontend >service files"- and I have dabbled with the compiled once, indirectly. 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. 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=20 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. >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 inspe= ct, >use and modify them to fit their needs or policies. Yes, people can pick and choose what they want, and as it is now,=20 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