Re: Be prepared for the fall of systemd

2022-08-04 Thread Jan Bramkamp
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

Re: Be prepared for the fall of systemd

2022-08-04 Thread Laurent Bercot
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 t

Re: [DNG] Be prepared for the fall of systemd

2022-08-04 Thread Laurent Bercot
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 imp

Re: Be prepared for the fall of systemd

2022-08-04 Thread Tanuj Bagaria
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 - quic

Re: [DNG] Be prepared for the fall of systemd

2022-08-04 Thread Steve Litt
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 c

Re: Be prepared for the fall of systemd

2022-08-04 Thread Steve Litt
On Wed, 2022-08-03 at 17:19 +, 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 dar