RE: Is runit not being maintained?
You have to look at how stability, sanity, sensibility, and even simplicity as how to
determine if maintenance is needed. Often projects can be stable for years without
the need for additional work, or even just require minimal patches.
While perp is a way forward, it still requires a bsdinit or sysvinit substructure to work,
but it is a sound solution regardless, and deserves as much credit for it's offerings.
However, the ongoing problem is, how do we avoid the systemd hostile takeover
and promote sane software solutions for GNU/Linux without sacrificing existing
projects that do work and are known stable over a fad of software that promotes
feature creep, kernel lock outs, and forced deprecation of other projects.
We avoid it by offering sound solutions that avoid deprecation, lockouts, feature creep,
and hostile takeover of the system resources. GNU/Linux needs solutions, not fadware
that was designed more around whim and coding to code for the sake of coding,
solutions that are sound, sane, and simplified.
GNU/Linux needs a modernized init solution, but it needs an init solution that is an
init solution, but ONLY an init solution and service supervisor. Systemd is not the
answer. Solutions like Runit, OpenRC, s6, and even bsdinit+perp are solutions with
real answers to questions.
> Date: Wed, 23 Jul 2014 08:58:07 -0700
> From: wcm_at_b0llix.net
> To: supervision_at_list.skarnet.org
> CC: joe9mail_at_gmail.com
> Subject: Re: Is runit not being maintained?
>
> On Tue, 22 Jul 2014 16:57:56 -0500
> Joe M <joe9mail_at_gmail.com> wrote:
> >
> > I read that dragora moved from runit to perp as runit was not being
> > maintained.
> >
> > Just wanted to check if runit is not being actively maintained and if
> > perp is a better option going forward.
>
> Of course perp is a better option going forward. And I get to say that
> because I wrote it :>
>
> As for considering "actively maintained" as a metric for software
> quality, what does this really mean? Is a project that makes a flurry
> of releases, always in constant flux, changing specifications, creeping
> featurism, really in some way better than a similar project that is
> stable, mature, proven, working well, and not in need of constant fixes?
>
> Wayne
Received on Wed Jul 23 2014 - 17:03:47 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:18 UTC