On 2013-10-27 17:10, Tyler Christiansen wrote:
On Oct 27, 2013, at 9:49 AM, Jason Lixfeld jason@lixfeld.ca wrote:
One thing you will discover (if you haven't already) is that Adam et. al develop Observium based on their own requirements or that of their (large-ish?) sponsors, not those of their general user base (but I don't know how much say us paying users have since the pro version has been rolled out; I've never asked).
Whether they're interested in supporting feature requests of their general user base or not isn't really what I'm getting at. I didn't say "help, I'm completely clueless." I offered helpful feedback. I identified an issue with the code. I showed how it could be improved by examining the OIDs from the RFCs, and I proved that it could be improved through a series of tests and by writing a patch for my own installation. In return, I was told to "fuck off" and removed from the list.
No you didn't, you made a bunch of incorrect assumptions and then proceeded to screech about them repeatedly. We've already been through all of this, you just seem to want to be right about something, anything.
We're quite well aware of what the MIBs contain and which parts are useful. You're not offering anything helpful beyond a lot of moaning and finger pointing, you're wasting everyone's time.
If they aren't interested in my patch or in performance issues being identified--fine. There's not really a reason to tell someone who offered feedback to "fuck off" and then remove them from a mailing list.
You've been told before that you're wrong, but you're still harping on about it, trying a different avenue to find people who'll make you feel clever. You're not, you're wrong.
I'm quite certain that all you've done is stopped the poller walking if[In|Out][Octets|UPkts|NUPkts] and have declared yourself victorious, of course completely ignorant to the fact that you've broken polling for anyone who's devices don't return 64-bit values for certain types of ports.
There are performance improvements that can be made to the ports poller, we know where they are and how to do them, we just haven't gotten around to fixing them yet.
They don't have a need for efficient polling of Juniper devices do it's very unlikely that it will ever make it into the code.
I am actually curious if it's a Juniper-only issue. Does anyone have anything with around 300 or 400 ports on a _single_ device that they are polling over a respectable distance? If so, what are your poll times like?
I've rarely monitored devices with less than 400 ports.
You've proved in a number of emails that you're only interested in ranting and being right, without actually bothering to look at the code at all. In your first email you didn't even seem to know that we use bulkwalk! In later emails you don't seem to have worked out how we do 32/64 bit decision, despite having claimed to have read and optimised the code.
I think you're an unhelpful timewasting bullshitter, and I'd much prefer if you went back to Cacti and stopped wasting our time.
It's the way it is around here. The observium team isn't trying to design a product for everyone. They are designing a product for themselves and those who are willing to use it as-is are welcome to do so.
Again, that's fine, but the response was a bit…excessive, particularly considering I am only trying to point out ways that the product can be improved. I actually like Observium.
Observium doesn't like you. Shoo.
adam.