supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
* Be prepared for the fall of systemd
@ 2022-08-01  7:21 Steve Litt
  2022-08-03 17:19 ` J.R. Hill
  0 siblings, 1 reply; 9+ messages in thread
From: Steve Litt @ 2022-08-01  7:21 UTC (permalink / raw)
  To: dng; +Cc: supervision

Hi all,

As I said in a previous message, I see sentiment very slowly turning against
systemd. If systemd keeps losing popularity, I have no doubt the corporate
carpetbaggers will try to force an even worse atrocity on us, so we need to be ready
this time and not have the argument centered on a false choice.

I see two init systems ready to take the baton and run with it:

* Runit
* S6

Runit is the simplest init system other than /bin/bash or an rc script. It's
maintained by the Void Linux project, so hit hard at the FUDdists who claim runit is
unmaintained.

S6 is advancing full speed to a complete solution, implementing all the best
features of systemd, but these features are voluntary and separable. If you want top
quality, choice and performance, and are willing to accept a little more complexity
(but sane complexity), S6 plus its service manager is the way to go. In my opinion,
S6 plus its service manager offers more than OpenRC, and IMHO it's easier to
configure/manage.

If and when systemd falls, we need to be ready, so we can get the right init system,
instead yet another corporate sponsored Rube Goldberg Machine.

SteveT

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Be prepared for the fall of systemd
  2022-08-01  7:21 Be prepared for the fall of systemd Steve Litt
@ 2022-08-03 17:19 ` J.R. Hill
  2022-08-04  8:21   ` Steve Litt
       [not found]   ` <CAK2MWOvJfx6kB8wiLL4OfgFx25et=_-2OZCsS4VPLYpuBfngyQ@mail.gmail.com>
  0 siblings, 2 replies; 9+ messages in thread
From: J.R. Hill @ 2022-08-03 17:19 UTC (permalink / raw)
  To: Steve Litt; +Cc: dng, supervision

There are a few things that need to be in place for a smooth transition.

For general trust in the project...

1. the init system itself should be maintained by more than a single human.
2. the maintainers should be willing to respond to a large audience. (If a project is used widely across distributions and is critical to operation and security, it'll attract attention from armies of newbies and large cloud corporations alike.) This means there needs to be an ability to move slow (maintain backwards compatibility) and also to move fast (in security situations)
3. the project should be available from some trusted platform with versioning and source history.

For ease of transition...

4. many init scripts need to exist, or they need to be trivial to write.

I'll give some thoughts on runit:

I'll start by saying that I've used Void linux for a few years now, and I love using runit. It's simple, it works, and it's understandable. That's the opposite of my experience with systemd. I'm not passionately against systemd (or the developers, or RedHat, or even IBM), and I think systemd is technically impressive and ambitious. But also I don't really want to use it or anything like it.

> It's maintained by the Void Linux project...

Unfortunately I don't think this is true. It's used by Void, but we're packaging it by building from the source tarball like anyone else.

https://github.com/void-linux/void-packages/blob/master/srcpkgs/runit/template#L12

They do, in effect, drive the maintenance or creation of runit scripts. In the event that we wanted to move many distros to runit, there are many examples of runit scripts to either copy or use (#4). Also it might go without saying, but the scripts themselves are trivial to write anyway.

If I consider runit for my other points above, it doesn't look so hot.

I don't see evidence that runit is maintained by more than a single person (#1), and given that the mailing list archive seems to be down... (And using the "wayback machine" archives it looks like it's been down for more than a year) it doesn't give me a lot of confidence that the maintainer is ready to respond to large audiences (#2). Also, the source is distributed as a single snapshot tarball on a personal website. There's no shasum, no GPG signature, no revision history, etc, which also doesn't give me a ton of confidence (#3). I don't care about seeing a lot of development activity or even recent activity, runit is simple. But especially for security reasons it's important to know the history of a project, like exactly which version has vulnerable code introduced and which version has a fix.

Now, I really really like runit, but I don't think it's ready right now. For runit to be a broadly-attractive alternative, it needs a few small things: to move to some source control system (git/mercurial/etc) where more than one person has access, and the maintainers have to be reasonably responsive. Without that, I think FUD around runit is probably justified. (Of course, we can always take the tarball and shove it in github/gitlab/etc, that wouldn't be the end of the world)

I don't know enough about S6 (using it, or the project) to comment on it.

-- J.R. Hill

------- Original Message -------
On Monday, August 1st, 2022 at 07:21, Steve Litt <slitt@troubleshooters.com> wrote:


> Hi all,
>
> As I said in a previous message, I see sentiment very slowly turning against
> systemd. If systemd keeps losing popularity, I have no doubt the corporate
> carpetbaggers will try to force an even worse atrocity on us, so we need to be ready
> this time and not have the argument centered on a false choice.
>
> I see two init systems ready to take the baton and run with it:
>
> * Runit
> * S6
>
> Runit is the simplest init system other than /bin/bash or an rc script. It's
> maintained by the Void Linux project, so hit hard at the FUDdists who claim runit is
> unmaintained.
>
> S6 is advancing full speed to a complete solution, implementing all the best
> features of systemd, but these features are voluntary and separable. If you want top
> quality, choice and performance, and are willing to accept a little more complexity
> (but sane complexity), S6 plus its service manager is the way to go. In my opinion,
> S6 plus its service manager offers more than OpenRC, and IMHO it's easier to
> configure/manage.
>
> If and when systemd falls, we need to be ready, so we can get the right init system,
> instead yet another corporate sponsored Rube Goldberg Machine.
>
> SteveT

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Be prepared for the fall of systemd
  2022-08-03 17:19 ` J.R. Hill
@ 2022-08-04  8:21   ` Steve Litt
  2022-08-04  9:09     ` Tanuj Bagaria
       [not found]   ` <CAK2MWOvJfx6kB8wiLL4OfgFx25et=_-2OZCsS4VPLYpuBfngyQ@mail.gmail.com>
  1 sibling, 1 reply; 9+ messages in thread
From: Steve Litt @ 2022-08-04  8:21 UTC (permalink / raw)
  To: dng, supervision

On Wed, 2022-08-03 at 17:19 +0000, J.R. Hill wrote:
> There are a few things that need to be in place for a smooth transition.
> 
> For general trust in the project...
> 
> 1. the init system itself should be maintained by more than a single human.

This hasn't been the case with runit. It's so darn simple people *do* trust it, even
though it was written by one guy and he stepped away.

> 2. the maintainers should be willing to respond to a large audience. (If a project
> is used widely across distributions and is critical to operation and security,
> it'll attract attention from armies of newbies and large cloud corporations
> alike.) This means there needs to be an ability to move slow (maintain backwards
> compatibility) and also to move fast (in security situations)

True. All I can say is runit does one thing and does it well, appears to have no
known security flaws, has a small attack surface, so there's little call for
updates.

> 3. the project should be available from some trusted platform with versioning and
> source history.
> 
> For ease of transition...
> 
> 4. many init scripts need to exist, or they need to be trivial to write.

The originator of runit gives many example scripts, AND they are trivial to write.
See http://smarden.org/runit/runscripts.html .


> 
> I'll give some thoughts on runit:
> 
> I'll start by saying that I've used Void linux for a few years now, and I love
> using runit. It's simple, it works, and it's understandable. That's the opposite
> of my experience with systemd. I'm not passionately against systemd (or the
> developers, or RedHat, or even IBM), and I think systemd is technically impressive
> and ambitious. But also I don't really want to use it or anything like it.
> 
> > It's maintained by the Void Linux project...
> 
> Unfortunately I don't think this is true. It's used by Void, but we're packaging
> it by building from the source tarball like anyone else.

I guess what I meant was https://github.com/void-linux/runit . That's the source
code, maintained by the Void Linux project, and it's up to individual distros to
package it for their distro.

SteveT

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [DNG] Be prepared for the fall of systemd
       [not found]   ` <CAK2MWOvJfx6kB8wiLL4OfgFx25et=_-2OZCsS4VPLYpuBfngyQ@mail.gmail.com>
@ 2022-08-04  8:55     ` Steve Litt
  2022-08-04  9:29       ` Laurent Bercot
  0 siblings, 1 reply; 9+ messages in thread
From: Steve Litt @ 2022-08-04  8:55 UTC (permalink / raw)
  To: dng, supervision

On Wed, 2022-08-03 at 15:36 -0700, Bruce Perens wrote:
> I came to the conclusion a while back that systemd was symptomatic of the
> fact that we had gone as far as the fundamental assumptions of the Unix API
> could take us. 

I find it symptomatic of the fact that a guy wrote some Rube Goldberg code and a
corporation decided it would be a great idea to spend millions getting the Rube
Goldberg code into many major distros. As far as us running our of road with the
Unix API, systemd solves no problem and offers no improvement that couldn't have
been solved or improved in a dozen different ways, almost all of which would have
been more modular and less prone to vendor lock in.

[snip]

> There is room for replacement of systemd and continuation of Linux and BSD.

Exactly! And if Redhat/IBM ever stops spending millions per year to keep systemd
from collapsing under its own weight, that room becomes a necessity.

> But we should be looking forward to something else as the next OS paradigm.

In the preceding sentence, I'd change the "But" to "Also".


SteveT

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Be prepared for the fall of systemd
  2022-08-04  8:21   ` Steve Litt
@ 2022-08-04  9:09     ` Tanuj Bagaria
  2022-08-04 10:33       ` Laurent Bercot
  2022-08-04 10:59       ` Jan Bramkamp
  0 siblings, 2 replies; 9+ messages in thread
From: Tanuj Bagaria @ 2022-08-04  9:09 UTC (permalink / raw)
  To: Steve Litt; +Cc: dng, supervision

[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]

What do we as a community need to do
 to get S6 into a "corporate friendly" state?

What can I do to help?


Here are some ideas:
- easier access to the VCS (git, pijul, etc)
- Issue tracking system
- CI/CD build chain (being careful not to make it too painful to use)
- "idiot proof" website
- quick start / getting started guide
- easier access (better?) Documentation

On Thu, 4 Aug 2022, 09:21 Steve Litt, <slitt@troubleshooters.com> wrote:

> On Wed, 2022-08-03 at 17:19 +0000, J.R. Hill wrote:
> > There are a few things that need to be in place for a smooth transition.
> >
> > For general trust in the project...
> >
> > 1. the init system itself should be maintained by more than a single
> human.
>
> This hasn't been the case with runit. It's so darn simple people *do*
> trust it, even
> though it was written by one guy and he stepped away.
>
> > 2. the maintainers should be willing to respond to a large audience. (If
> a project
> > is used widely across distributions and is critical to operation and
> security,
> > it'll attract attention from armies of newbies and large cloud
> corporations
> > alike.) This means there needs to be an ability to move slow (maintain
> backwards
> > compatibility) and also to move fast (in security situations)
>
> True. All I can say is runit does one thing and does it well, appears to
> have no
> known security flaws, has a small attack surface, so there's little call
> for
> updates.
>
> > 3. the project should be available from some trusted platform with
> versioning and
> > source history.
> >
> > For ease of transition...
> >
> > 4. many init scripts need to exist, or they need to be trivial to write.
>
> The originator of runit gives many example scripts, AND they are trivial
> to write.
> See http://smarden.org/runit/runscripts.html .
>
>
> >
> > I'll give some thoughts on runit:
> >
> > I'll start by saying that I've used Void linux for a few years now, and
> I love
> > using runit. It's simple, it works, and it's understandable. That's the
> opposite
> > of my experience with systemd. I'm not passionately against systemd (or
> the
> > developers, or RedHat, or even IBM), and I think systemd is technically
> impressive
> > and ambitious. But also I don't really want to use it or anything like
> it.
> >
> > > It's maintained by the Void Linux project...
> >
> > Unfortunately I don't think this is true. It's used by Void, but we're
> packaging
> > it by building from the source tarball like anyone else.
>
> I guess what I meant was https://github.com/void-linux/runit . That's the
> source
> code, maintained by the Void Linux project, and it's up to individual
> distros to
> package it for their distro.
>
> SteveT
>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [DNG] Be prepared for the fall of systemd
  2022-08-04  8:55     ` [DNG] " Steve Litt
@ 2022-08-04  9:29       ` Laurent Bercot
  0 siblings, 0 replies; 9+ messages in thread
From: Laurent Bercot @ 2022-08-04  9:29 UTC (permalink / raw)
  To: supervision


>I find it symptomatic of the fact that a guy wrote some Rube Goldberg code and a
>corporation decided it would be a great idea to spend millions getting the Rube
>Goldberg code into many major distros. As far as us running our of road with the
>Unix API, systemd solves no problem and offers no improvement that couldn't have
>been solved or improved in a dozen different ways, almost all of which would have
>been more modular and less prone to vendor lock in.

  We know all of this.
  Please keep these posts out of the supervision ML. It's not that we
don't like systemd-bashing, it's that it takes a lot of space and makes
a lot of noise, and I'd like the supervision ML to be laser-focused on
solving technical issues with supervision systems, not be yet another
place where we complain about systemd day in day out. Thanks.

--
  Laurent


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Be prepared for the fall of systemd
  2022-08-04  9:09     ` Tanuj Bagaria
@ 2022-08-04 10:33       ` Laurent Bercot
  2022-08-05 21:28         ` Daniel Fitzpatrick
  2022-08-04 10:59       ` Jan Bramkamp
  1 sibling, 1 reply; 9+ messages in thread
From: Laurent Bercot @ 2022-08-04 10:33 UTC (permalink / raw)
  To: Tanuj Bagaria, Steve Litt; +Cc: dng, supervision


>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


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Be prepared for the fall of systemd
  2022-08-04  9:09     ` Tanuj Bagaria
  2022-08-04 10:33       ` Laurent Bercot
@ 2022-08-04 10:59       ` Jan Bramkamp
  1 sibling, 0 replies; 9+ messages in thread
From: Jan Bramkamp @ 2022-08-04 10:59 UTC (permalink / raw)
  To: supervision

On 04.08.22 11:09, Tanuj Bagaria wrote:
> What do we as a community need to do
>   to get S6 into a "corporate friendly" state?
>
> What can I do to help?
>
>
> Here are some ideas:
> - easier access to the VCS (git, pijul, etc)

I would not (yet) consider pijul common and stable enough to count 
toward that goal. I would recommend we accept that git is the 
established default VCS for *nix software development for the 
foreseeable future.

Each skaware software project has:

   * Its own git repository at 
https://git.skarnet.org/cgi-bin/cgit.cgi/$project (with plaintext 
read-only access at git://git.skarnet.org/$project as well)

   * A GitHub mirror are at https://github.com/skarnet/$project.

A list of the existing projects is hosted at https://skarnet.org/software/.

> - Issue tracking system
The the per project mirror GitHub issue trackers aren't disabled and 
used occasionally, but their use is discouraged [1] (at least for 
support). Unless someone has a better idea I would recommend using them 
at least for bug tracking. Here the biggest problem I expect is a drain 
on Laurent Bercot's time and the biggest help would be for someone to 
moderate and classify the reports to save preserve developer time. A 
useful moderator would have to know their technical limitations (when to 
bump an issue to a developer for further analysis), engage with human 
users so the project feels "alive" for lack of a better word, help 
reporters improve their issues to they point they become actionable, tag 
and assign the issues correctly. Such a post  would require dedication 
and perseverance in the face or repetitive, thankless work. It would 
neither require a deep understanding of the implementation nor are most 
developers a good fit it. It requires its own skillset.
> - CI/CD build chain (being careful not to make it too painful to use)
Running post-commit s6 and s6-rc regression tests (that don't exist to 
the best of my knowledge) on several platforms would be enough for cover 
most of it.
> - "idiot proof" website

The website is idiot proof in the sense that idiots bounce of it without 
wasting anyone's time, but their own. It also provides a reference/man 
page style documentation with a few pages explaining one concepts that 
could be collected to be easier to discover.

> - quick start / getting started guide
> - easier access (better?) Documentation

That's exactly what missing in my opinion: an introduction/tutorial 
style documentation to bring down the *very* steep learning curve. It 
should further explain how the concepts fit together back-referencing 
how they've already been applied in the tutorials.

Enough mechanisms are in place in s6 and s6-rc implement most (sane) 
policies. The big missing quality of life feature is a safe frontend 
making dynamic reconfiguration easier. This feature is work in progress 
[2] and development can probably be accelerated a great deal by throwing 
enough money at Laurent Bercot enabling him to dedicate more of his time 
to completing it [3].

[1]: https://github.com/skarnet/s6/issues/31#issuecomment-1079312762

[2]: https://skarnet.org/software/s6-frontend

[3]: https://skarnet.com/projects/service-manager.html


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Be prepared for the fall of systemd
  2022-08-04 10:33       ` Laurent Bercot
@ 2022-08-05 21:28         ` Daniel Fitzpatrick
  0 siblings, 0 replies; 9+ messages in thread
From: Daniel Fitzpatrick @ 2022-08-05 21:28 UTC (permalink / raw)
  To: Laurent Bercot; +Cc: supervision

[-- Attachment #1: Type: text/plain, Size: 6490 bytes --]

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@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
>
>

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2022-08-05 21:28 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-01  7:21 Be prepared for the fall of systemd Steve Litt
2022-08-03 17:19 ` J.R. Hill
2022-08-04  8:21   ` Steve Litt
2022-08-04  9:09     ` Tanuj Bagaria
2022-08-04 10:33       ` Laurent Bercot
2022-08-05 21:28         ` Daniel Fitzpatrick
2022-08-04 10:59       ` Jan Bramkamp
     [not found]   ` <CAK2MWOvJfx6kB8wiLL4OfgFx25et=_-2OZCsS4VPLYpuBfngyQ@mail.gmail.com>
2022-08-04  8:55     ` [DNG] " Steve Litt
2022-08-04  9:29       ` Laurent Bercot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).