Re: [Nagios-devel] New Nagios implementation proposal
Posted: Fri Dec 18, 2009 2:32 pm
On Fri, Dec 18, 2009 at 2:03 PM, 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 when
>>>> 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?
For the Erlang :
https://www.ohloh.net/languages/compare ... 3Dpython&=
l2=3Derlang&l3=3D-1&l4=3D-1&measure=3Dcommits&percent=3Dtrue
I think the Erlang can be more than useful for the distributed part
but for all others parts (like for modules and database exprot) the
lack of modules (and coders) can be a real problem.
>
>>>
>>>> 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 into
>>> 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 magi=
cal).
>>
>
> 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.
Yes. Some games are made like this : Higer part (logic and co) are in
higher language (Python, LUA, etc) and lower part are in C/C++ (opengl
and picture manipulation).
>
>>>
>>>>> and you want more
>>>>> control over all memory and all data structures, nor do you want to b=
ind a
>>>>> program to running under an interpreter.
>>>> Yes you do not manage memory, but you control your data structure hope=
fully.
>>>>
>>>> For the interpreter problem : how do you install Nagios into Windows?
>>>
>>> You can't just now, but that's mostly because it relies on filesystem
>>> pipes which windows doesn't support, and the fact that windows performs
>>> so utterly horrible with multiple processes.
>>>
>>>> Yes, an interpreter dependency can be a problem (2 installs instead of
>>>> one, even if Python is installed by default in nearly all Linux
>>>> distributions...), but if it allows us to do not have to manage low
>>>> level problem, have a huge portability, =A0I think use an open source
>>>> interpreter is not such a problem.
>>>>
>>>
>>> What low level problems are you talking about? Managing memory? That's
>>> not really hard in a well-written
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
> 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 when
>>>> 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?
For the Erlang :
https://www.ohloh.net/languages/compare ... 3Dpython&=
l2=3Derlang&l3=3D-1&l4=3D-1&measure=3Dcommits&percent=3Dtrue
I think the Erlang can be more than useful for the distributed part
but for all others parts (like for modules and database exprot) the
lack of modules (and coders) can be a real problem.
>
>>>
>>>> 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 into
>>> 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 magi=
cal).
>>
>
> 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.
Yes. Some games are made like this : Higer part (logic and co) are in
higher language (Python, LUA, etc) and lower part are in C/C++ (opengl
and picture manipulation).
>
>>>
>>>>> and you want more
>>>>> control over all memory and all data structures, nor do you want to b=
ind a
>>>>> program to running under an interpreter.
>>>> Yes you do not manage memory, but you control your data structure hope=
fully.
>>>>
>>>> For the interpreter problem : how do you install Nagios into Windows?
>>>
>>> You can't just now, but that's mostly because it relies on filesystem
>>> pipes which windows doesn't support, and the fact that windows performs
>>> so utterly horrible with multiple processes.
>>>
>>>> Yes, an interpreter dependency can be a problem (2 installs instead of
>>>> one, even if Python is installed by default in nearly all Linux
>>>> distributions...), but if it allows us to do not have to manage low
>>>> level problem, have a huge portability, =A0I think use an open source
>>>> interpreter is not such a problem.
>>>>
>>>
>>> What low level problems are you talking about? Managing memory? That's
>>> not really hard in a well-written
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]