[talk] In Contrast to BSD init, A history of modern init systems (1992-2015)

[George Rosamond]

Sujit K M:
> On Thu, Sep 17, 2015 at 12:54 AM, Malcolm Matalka <mmatalka at gmail.com> wrote:
>> Raul Cuza <raulcuza at gmail.com> writes:
>>
>>> In light of the recent discussion on *BSD and init system, I thought
>>> this history of modern init systems a interesting contrast:
>>> http://blog.darknedgy.net/technology/2015/09/05/0/
>>>
>>> By definition of "modern", the BSD style init is the "classical" that
>>> these systems are not. Maybe I don't understand the problems these
>>> alternatives are trying to solve sufficiently. If you can shed some
>>> light on it, I'd love to hear it.
>>
>> I have not had a problem that these new systems solve either.  I
>> actually prefer daemontools out of all of these (not an init system, I
>> know, but close enough for this discussion, I think), because it's very
>> simple.  In the case of a server, I'm not sure why one would want
>> something more than something like daemontools.  I can see an argument
>> for something more sophisticated for a desktop environment but I'm not
>> sure what that would really look like.  I'm pretty biased in my opinion
>> here though, so YMMV.
> 
> Please stop promoting proprietary solutions to the list.

If you're referring to daemontools, 'proprietary' is not an exactly
accurate description, and it does exist in both FreeBSD (and therefore
DFly) and pkgsrc ports, regardless of a layer of people's feelings about
the licensing. Personally, 'kooky' might be more useful as a description
of the past djb licenses.

On that note, please don't attempt to mediate this mailing list.  There
are way more moderator eyes watching this discussion than you could
imagine.  Even if someone had noted a strength of some other explicitly
proprietary solution as useful for their tasks at-hand, without doing
some marketing spiel, it would still be an acceptable post.

We can't be blind to the strengths of proprietary solutions. Lots of
open source solutions wouldn't exist without appreciating strengths of
closed solutions.

g