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

[Sujit K M]

George,

Some thing simple, as you are pointing out that there are other people
who are moderators in
the list. I find it very disgusting to the sort of tone that is being
used in these mails. Below Quote,
If you are moderating the list then why are such posts coming through,
Although language skills
might be poor but more so of a case of why the person is find it
necessary to question people.

"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."
^^^^^^^^^^^^^^^^^^^^^^^^


On Sat, Sep 19, 2015 at 9:42 AM, George Rosamond
<george at ceetonetechnology.com> wrote:
> 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.

What is a 'kooky' license.

>
> On that note, please don't attempt to mediate this mailing list.  There
> are way more moderator eyes watching this discussion than you could

I found it objectionable. I donot find it necessary to depend on
another moderator
to get a view. On this specific reason given below.

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

Don't find it necessary to let some ask others to look at the source  of a
paid service. That is what I found the Member way doing. Quote below

">>>(not an init system, I
>>> know, but close enough for this discussion, I think)"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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

You can build on the strength of proprietary solutions. Build on companies
investing on Open source. But in a manner better suited for people to
understand.
I mean, lay man who cannot invest in solutions provided by these companies.
Misrepresentation seems to be the way out for many of these guru's in
 several of the posts that are being poste