Re: [Nagios-devel] New Nagios implementation proposal
Posted: Fri Jan 08, 2010 1:05 pm
Hi,
I was working in the socket return some times ago, but it is not so
fun as I remember when I was hacking Nagios in the past. Seeing this,
I think I will finish this patch, that is a personal challenge, but I
will not make another patch like the rest of the process management of
the queue for modules, sorry (I work at home after work, so it must be
at least a little fun for me).
I still go on with Shinken, making it a real project and all that go
with it like it's own git, site, mailing list, etc. If people want to
test it or just know about it, they can go at
http://shinken-monitoring.org/ and subscribe to the mailing list at
https://lists.sourceforge.net/lists/lis ... nken-devel.
I won't make more noise about this project in this mailing list unless
a mix is possible with this two projects. If some want to take ideas
from Shinken for Nagios, go for it, it was it's primer role after all.
Jean
On Fri, Dec 18, 2009 at 2:36 PM, Brad O'Hara wrote:
> It's been very interesting following this, but I vote that you work
> together on version 4.
>
> Brad
>
> Andreas Ericsson wrote:
>> On 12/18/2009 12:42 PM, nap wrote:
>>
>>> On Fri, Dec 18, 2009 at 10:49 AM, Andreas Ericsson =A0wrote:
>>>
>>>>> I'm not saying C/C++ is garbage. I just say we must use them only whe=
n
>>>>> need. A scheduler is not a problem to be solved why such low level
>>>>> language. Maybe I am wrong about thinking scheduling is a high level
>>>>> problem. I just need someone to prove it's a low level problem and I
>>>>> will agree with keeping of C code.
>>>>>
>>>>>
>>>> Again, the language is unimportant. It's not hard to write a scheduler
>>>> in whatever language you want, since it's basically just a matter of
>>>> checking what time it is and comparing numbers.
>>>>
>>> Yes, that why I think we must use the easier language for it.
>>>
>>>
>>
>> "Easier" for who? If you really want the perfect language to rewrite
>> Nagios for distributed checking and scheduling you should use Erlang.
>> It was built exactly for that purpose, yet you didn't choose it. Why?
>>
>>
>>>>> Do you watch the code I propose? Can you truly say that you can have
>>>>> such a modularity, performances and distributed usage with C and do
>>>>> not ask another 10years of development?
>>>>>
>>>> Yes. It's perfectly possible to write object-oriented code in C too,
>>>> without the performance penalties that come with an interpreted
>>>> language. Just look at the linux kernel's device driver API and you'll
>>>> see how it's done.
>>>>
>>> "Yes we can" (oups, I forgot the TM) do object-oriented code in C, but
>>> I will be harder than doing it than to use a natural language for it.
>>> The perf penalties are not important here : the major performance
>>> needs are in the checks, not in the core. That why we have the choice
>>> for the development.
>>>
>>>
>>
>> Again, language is only important when it comes to "who can do what in
>> the language used?".
>>
>>
>>>>> (In fact I think it is
>>>>> possible in less that 10 years, but far more than 3). The others like
>>>>> Zenoss are still in the good way. Nagios cannot stay behind.
>>>>>
>>>>>
>>>> That's fairly bullshit imo. With C you can load any other language int=
o
>>>> the core. With Python you're stuck with Python.
>>>>
>>> In fact you can load C (and so whatever you want) :
>>>
>>> import ctypes
>>> libc =3D ctypes.cdll.LoadLibrary("libc.so.6")
>>> libc.printf("Hello %s", 'World')
>>> Hello World
>>>
>>> It also work on windows dll (but in the Windows platform, it is not mag=
ical).
>>>
>>>
>>
>> That's good to know. That means it's possible to write super-fast
>> snippets in C and put that in a Nagios library that the Python
>> thing loads.
>>
>>
>>>>>> and you want more
>>>>>> control over all memory and all data structures, nor do you want to =
bind a
>>>>>> program to running under an interpreter.
>>>>>>
>>>>> Yes you do not manage memory, but you control your data structure hop=
efully.
>>>>>
>>>>> For the interpreter problem : how do you install Nagios into Windows?
>>>>>
>>>> You can'
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
I was working in the socket return some times ago, but it is not so
fun as I remember when I was hacking Nagios in the past. Seeing this,
I think I will finish this patch, that is a personal challenge, but I
will not make another patch like the rest of the process management of
the queue for modules, sorry (I work at home after work, so it must be
at least a little fun for me).
I still go on with Shinken, making it a real project and all that go
with it like it's own git, site, mailing list, etc. If people want to
test it or just know about it, they can go at
http://shinken-monitoring.org/ and subscribe to the mailing list at
https://lists.sourceforge.net/lists/lis ... nken-devel.
I won't make more noise about this project in this mailing list unless
a mix is possible with this two projects. If some want to take ideas
from Shinken for Nagios, go for it, it was it's primer role after all.
Jean
On Fri, Dec 18, 2009 at 2:36 PM, Brad O'Hara wrote:
> It's been very interesting following this, but I vote that you work
> together on version 4.
>
> Brad
>
> Andreas Ericsson wrote:
>> On 12/18/2009 12:42 PM, nap wrote:
>>
>>> On Fri, Dec 18, 2009 at 10:49 AM, Andreas Ericsson =A0wrote:
>>>
>>>>> I'm not saying C/C++ is garbage. I just say we must use them only whe=
n
>>>>> need. A scheduler is not a problem to be solved why such low level
>>>>> language. Maybe I am wrong about thinking scheduling is a high level
>>>>> problem. I just need someone to prove it's a low level problem and I
>>>>> will agree with keeping of C code.
>>>>>
>>>>>
>>>> Again, the language is unimportant. It's not hard to write a scheduler
>>>> in whatever language you want, since it's basically just a matter of
>>>> checking what time it is and comparing numbers.
>>>>
>>> Yes, that why I think we must use the easier language for it.
>>>
>>>
>>
>> "Easier" for who? If you really want the perfect language to rewrite
>> Nagios for distributed checking and scheduling you should use Erlang.
>> It was built exactly for that purpose, yet you didn't choose it. Why?
>>
>>
>>>>> Do you watch the code I propose? Can you truly say that you can have
>>>>> such a modularity, performances and distributed usage with C and do
>>>>> not ask another 10years of development?
>>>>>
>>>> Yes. It's perfectly possible to write object-oriented code in C too,
>>>> without the performance penalties that come with an interpreted
>>>> language. Just look at the linux kernel's device driver API and you'll
>>>> see how it's done.
>>>>
>>> "Yes we can" (oups, I forgot the TM) do object-oriented code in C, but
>>> I will be harder than doing it than to use a natural language for it.
>>> The perf penalties are not important here : the major performance
>>> needs are in the checks, not in the core. That why we have the choice
>>> for the development.
>>>
>>>
>>
>> Again, language is only important when it comes to "who can do what in
>> the language used?".
>>
>>
>>>>> (In fact I think it is
>>>>> possible in less that 10 years, but far more than 3). The others like
>>>>> Zenoss are still in the good way. Nagios cannot stay behind.
>>>>>
>>>>>
>>>> That's fairly bullshit imo. With C you can load any other language int=
o
>>>> the core. With Python you're stuck with Python.
>>>>
>>> In fact you can load C (and so whatever you want) :
>>>
>>> import ctypes
>>> libc =3D ctypes.cdll.LoadLibrary("libc.so.6")
>>> libc.printf("Hello %s", 'World')
>>> Hello World
>>>
>>> It also work on windows dll (but in the Windows platform, it is not mag=
ical).
>>>
>>>
>>
>> That's good to know. That means it's possible to write super-fast
>> snippets in C and put that in a Nagios library that the Python
>> thing loads.
>>
>>
>>>>>> and you want more
>>>>>> control over all memory and all data structures, nor do you want to =
bind a
>>>>>> program to running under an interpreter.
>>>>>>
>>>>> Yes you do not manage memory, but you control your data structure hop=
efully.
>>>>>
>>>>> For the interpreter problem : how do you install Nagios into Windows?
>>>>>
>>>> You can'
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]