New Nagios implementation proposal

[Brad O'Hara]

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<ae at op5.se>  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 two places. In the
> structure and once in the struct describing how to parse the value,
> where you also set rules for valid input. Using macros makes it
> extremely simple to make a little data go a long way.
>
>   
>>>> Yes you can do all of theses things in C, patch the process pool and
>>>> reaping, but is it the best way of doing it? We must look far more
>>>> than we do for the moment.
>>>> A last question (the seventh :) ) : Is the language I propose the
>>>> problem, or changing habits for developers?
>>>>
>>>>         
>>> The language you're proposing is a problem because the current
>>> developers do not speak it. If you want to go ahead with Python, you'll
>>> be on your own (to start with) and it won't be Nagios. Sorry.
>>>       
>> Yep. I begin to think it is not possible.
>>
>> I still persist to think we can do much more with higher language in
>> few months than in years of low level coding. So let's try something :
>> I work on my own for some times, let's say 6 months (the same time it
>> took me to get the current code proposal). I will stay in the Nagios
>> way (same conf, etc). At the end of theses 6 months, let's take a
>> objective picture of the 2 implementations (with all theirs modules)
>> and what they propose to the users. Each one can take all ideas of the
>> other (after all the major part in open source software are ideas, not
>> codes). At this moment, if I prove that a Nagios code change can be
>> good for the project, we will look for the best way of merging if it
>> is still possible. If not, I will stay aside from Nagios and I will
>> say sorry for all the noise during this few days. We can see this
>> proposal as a "temporary Fork".
>>
>>     
>
> You're free to fork if you like (although what you've done is  a
> re-implementation). What you're winning is a chance to have
> it all your way, language and all. What you're losing is the
> userbase Nagios has. I'm not saying people won't switch to using
> Shinken instead, but I think the majority will stay with Nagios
> simply because it's wellknown.
>
>   
>> During this time, please look at Python. I was raised with
>> emacs/gcc/malloc/gdb/bit masks and printf and I thought that all
>> others languages were just garbage. I knew I was wrong when I give a
>> try to Python. It just allow you to concentrate in how fix your real
>> problem (algorithm or architecture), and not in the preparation for
>> solving the problem (manage memory, fixed data structure, etc). The
>> way from C to Python is not so hard. You can still C-style code in
>> Python (just less (, ) or ;  ) and then try new type of code. You can
>> still call C code with the ctypes module.
>>     
>
> I've already started looking into it. I tend to dislike languages that
> force an indentation down your throat though, but perhaps I'll just
> have to get used to it.
>
>   
>> Are you agree for a next mailing list meeting in 6 months? All others
>> core dev too? (I still hope for my Christmas gift :) )
>>
>>     
>
> Why in 6 months? Work with me now and we can make Nagios 4 happen with
> process pools and distributed checking builtin instead. Isn't that the
> major gripe right now?
>
>   
>>> Why not look into how we can implement the more important parts of
>>> your design in C instead? It shouldn't really be hard, but I need
>>> to get time from my boss to help out on that.
>>>       
>> Yes we can take some ideas for putting them into the code. But it is
>> not a long term solution. If I'm wrong, we will only lose 6 month and
>> gain a good competition :)
>>
>>     
>
> Well, creating a new monitoring tool without a userbase or a developer
> base isn't really a long term solution either. The best program in the
> world is utterly useless if nobody uses it.
>
>   

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev