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 24289 invoked from network); 4 Aug 2022 10:33:52 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 4 Aug 2022 10:33:52 -0000 Received: (qmail 20725 invoked by uid 89); 4 Aug 2022 10:34:16 -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 20718 invoked from network); 4 Aug 2022 10:34:16 -0000 From: "Laurent Bercot" To: "Tanuj Bagaria" , "Steve Litt" Subject: Re: Be prepared for the fall of systemd Cc: dng@lists.dyne.org, supervision@list.skarnet.org Date: Thu, 04 Aug 2022 10:33:49 +0000 Message-Id: In-Reply-To: References: <4234078aeca178d4b1b5136a9463617d97cef66b.camel@troubleshooters.com> <75OjPiNdg7k-TrGOB10JwBnln7qJjJRtcsOdg1Dm_gk72TwWJ2Te1njPOEgXz-khoRDvkvqjOfB2kUNj5_iAXtoHivgeGVZwoUzvQod4vIo=@so.dang.cool> <7ee45cee99f3f84093ca674ac5caaf1e6a8b8421.camel@troubleshooters.com> Reply-To: "Laurent Bercot" User-Agent: eM_Client/9.0.1708.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable >What do we as a community need to do >to get S6 into a "corporate friendly" state? > >What can I do to help? "Corporate-friendly" is not really the problem here. The problem is more "distro-friendly". Distributions like integrated systems. Integrated systems make their lives easier, because they reduce the work of gluing software pieces together (which is what distros do). Additionally, they like stuff like systemd or openrc because they come with predefined boot scripts that, more or less, work out of the box. There are two missing pieces in the s6 ecosystem before it can be embraced by distributions: 1. A service manager. That's what's also missing from runit. Process supervisors are good, but they're not service managers. You can read why here[1]. In case you missed it, here is the call for sponsors I wrote last year, explaining the need for a service manager for s6: [2]. It has been answered, and I'm now working on it. It's going very slowly, because I have a lot of (easier, more immediately solvable) stuff to do on the side, and the s6-rc v1 project is an order of magnitude more complex than what I've ever attempted before, so it's a bit scary and needs me to learn new work habits. But I'm on it. 2. A high-level, user-friendly interface, which I call "s6-frontend". Distros, and most users, like the file-based configuration of systemd, and like the one-stop-shop aspect of systemctl. s6 is lacking this, because it's made of several pieces (s6, s6-linux-init, s6-rc, ...) and more automation-friendly than human-friendly (directory-based config instead of file-based). I plan to write this as well, but it can only be done once s6-rc v1 is released. Once these pieces are done, integration into distributions will be *much* easier, and when a couple distros have adopted it, the rest will, slowly but surely, follow suit. Getting in is the hard part, and I believe in getting in by actually addressing needs and doing good technical work more than by complaining about other systems - yes, current systems are terrible, but they have the merit of existing, so if I think I can do better, I'd rather stfu and do better. >Here are some ideas: >- easier access to the VCS (git, pijul, etc) The git repositories are public: [3] They even have mirrors on github. All the URLs are linked in the documentation. I don't see how much=20 easier I can make it. Note that the fact that it's not as easy to submit MRs or patches as it is with tools like gitlab or github is intentional. I don't want to be dealing with an influx of context-free MRs. Instead, if people want to change something, I'd like *design discussions* to happen on the ML, between human beings, and when we've reached an agreement, I can either implement the change or accept a patch that I then trust will be correctly written. It may sound dictatorial, but I've learned that authoritarian maintainership is essential to keeping both a project's vision and its code readability. >- Issue tracking system The supervision ML has been working well so far. When bigger parts of the project (s6-rc v1 and s6-frontend) are done, there may be a higher volume of issues, if only because of a higher volume of users, so a real BTS may become an asset more than a hindrance at some point. We'll cross that bridge when we get to it. >- CI/CD build chain (being careful not to make it too painful to use) Would that really be useful? The current development model is sound, I think: the latest numbered release is stable, the latest git head is development. The s6 ecosystem can be built with a basic configure/make/make install invocation, is it really an obstacle to adoption? I understand the need for CI/CD where huge projects are concerned, people don't have the time or resources to build these. I don't think the s6 ecosystem qualifies as a huge project. It won't even be "huge" by any reasonable metric when everything is done. It needs to be buildable on a potato-powered system! >- "idiot proof" website >- quick start / getting started guide >- easier access (better?) Documentation I file these three under the same entry, which is: the need for community tutorials. And I agree: the s6 documentation is more of a reference manual, it's good for people who already know how it all works but has a very steep learning curve, and beginner-to-intermediate tutorials are severely lacking. If the community could find the time to write these, it would be a huge help. Several people, myself=20 included, have been asking for them for years. (For obvious reasons, I can't be the one writing them.) Turns out it's easier to point out a need than to fulfill it. It's the exact same thing as the s6 man pages. People can whine and=20 bitch and moan for ages saying that some work needs to be done, but when asked whether they'll do it, suddenly the room is deathly silent. For the man pages, one person eventually stepped up and did the work[4] and I'm forever grateful to them; I have no doubt that the same will happen with tutorials at some point, but when? Who knows. [1]: https://skarnet.org/software/s6-rc/why.html [2]: https://skarnet.com/projects/service-manager.html [3]: https://git.skarnet.org/cgi-bin/cgit.cgi/ [4]: https://github.com/flexibeast/s6-man-pages -- Laurent