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