Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi List,
I think the concept does have value, however the core team is likely to be
looking at the maturity of the existing code ,as well as, the complexity of
integrating something like this into the core.
Threads do exist in C (pthread) However threading should NEVER be "Just 10
lines of code and All good." Synchronization, reliability, logging and
extra bookkeeping (just in case); will always take more effort in
multi-threaded apps, attention to the potential Critical code blocks,
mutexes/monitors, limited resources, thread racing and starvation are
difficult to debug. particularly when using code managed by a virtual
machine (like Java)
On the Language of choice, it is important to remember that C is a mature
and stable language that is low level. being a mature language it has less
bugs than some of the newer languages (like Dot Net). All new languages
take time to become stable and an application like Nagios ( in my opinion)
should never be ported to a language that gets upgrades ever three months. =
I
am not familiar with Python, or any of its administration needs. I have
seen in less mature language on major version changes functionality drooped
or modified forcing rework on existing code that was originally bug free.
Is it possible to maybe merge Shinken concept into Nagios as a compilation
option? or is that just to complex to merge? Is it posible to put together
some flow charts/outlines as to what it would take to merge this model into
the existing Nagios progect?
Tony (Author of NC_Net )
On Thu, Dec 10, 2009 at 4:33 AM, nap wrote:
> Yep, you are wright, it's nearer a fork than a patch. But before being
> a reimplementation proposal, Shinken was a proof of concept for pool
> processes and distributed architecture. I already ask core dev what
> they think about theses ideas. I ask them in offlist what they thought
> about theses ideas because at this time, I did not want Shinken to be
> seen as a Fork or something similar. It was just a proof of concept to
> prove my ideas was not too stupid, and a C implementation was
> possible.
>
> I knew that distributed architecture was hard to accept, but the
> process pool was not so hard, it's just a technical problem, not a
> user thing.
>
> Ethan just say nothing, Andreas think this is a too big change (the
> process pool). At this moment, I knew there was a problem : a process
> pool is something threatening in C. In others language? 10 lines and
> it's good. If something is so simple in Python, Java, Perl, etc and so
> hard in C, we can't evolve quickly.
>
> I know Ethan will not be happy with it, it break its code but it's
> still Nagios, just not the same code. I think he will vote 1 (or 4).
> But at least he can say it. I try to make a good job for Nagios, a
> great enhancement. I do it for all Nagios users, and for new ones
> (very big and very little (windows) ones).
>
> I think a good C coder can go into Python very easy. Nagios core dev
> are just awesome C coders. Language change is not a real problem.
> Change code is. It will take 6 months for reaching Nagios
> functionalities, and maybe 6 others months for testing in devel
> branch. But after we won't be afraid by Zenoss or Zabbix anymore.
> I think this difficult year is not a too hard price for keeping the
> number one position of open source monitoring. If core dev do not
> think like me, I won't oppose their decisions, they do a great job for
> 10 years, making Nagios a so good product. If so, I will launch
> Shinken as an independant product. Maybe I will just make an epic fail
> (can you truly follow a man putting an Obiwan Kenobi option in a
> survey?
) but at least I try to give to the open source world a> good monitoring product. At least the ideas I put in it will not be
> lost (I speak a lot about process poll, but it's not the only one I
> put into this code like new options for host/services).
>
> So I vote 3
>
>
> Jean
>
> PS
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]