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 wrote:
>>
>>>> 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?
>
>
>>>> 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 = 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 magical).
>>
>>
>
> 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 hopefully.
>>>>
>>>> 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, I 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 application with clear API's.
>>>
>> But so why is it so hard to create an object? Look at the service creation :
>>
>> I don't imagine how many lines we need to add for just add a new
>> property in service. And the modules recompilation too.
>>
>>
>
> Because it's not written optimally, ofcourse. A better design would
> have used macros to recognize, parse and obtain values of the core
> structures. That way you add new properties in tw
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]