Re: Be prepared for the fall of systemd

From: Daniel Fitzpatrick <doubleagent03_at_gmail.com>
Date: Fri, 5 Aug 2022 16:28:20 -0500

Trying this again since my first response wasn't archived. I'm not familiar
with mailing lists.

---
I'll echo what Tanuj said to some degree. If you want to sniff systemd's
level of adoption, I view these three things as critical, in decreasing
order of importance.
1. An advertising page.
2. Better guides, written by someone who knows wtf they're doing (like
Ludovic Courtès or Steve Klabnik), in close communication with Laurent
Bercot. Ideally, there should be two separate guides:
- System integrator guide
- End-user guide
3. Good test coverage, ideally with a CI to help maintainers review PRs.
You can further reduce noise and improve quality by gating contributors
with a Contributor Agreement (CA).
On Thu, Aug 4, 2022, 5:33 AM Laurent Bercot <ska-supervision_at_skarnet.org>
wrote:
>
> >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
> 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
> 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
> 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
>
>
Received on Fri Aug 05 2022 - 23:28:20 CEST

This archive was generated by hypermail 2.4.0 : Fri Aug 05 2022 - 23:29:05 CEST