4 ms·
The summary is when you fork internationally you don't really need to follow trademark law in practice although it'll generate a lot of heat and forkers will en
by VLM 12y ago
The summary is when you fork internationally you don't really need to follow trademark law in practice although it'll generate a lot of heat and forkers will end up having to follow the law sooner or later so the lesson from the article is forkers are better off in the long run following trademark law from the start of their fork...
The fundamental argument that generated the fork was the community permanently diverged between simple and complicated and the primary maintainer decided to ally with the simple team, probably from a strong historical "eat your own dogfood" culture. Maybe rephrased some people have to ping 10K boxes per minute and other people have to check 1000 services or files or aspects on 10 boxes and its not REALLY possible for the same codebase to serve both groups equally well in actual real world practice.
Yo, heres some patches to make your screwdriver(tm) more hammer-ish to help professional nail installers work somewhat more effectively. What are you crazy the wood screw installation professionals such as myself will not tolerate that, patch denied. OK we'll fork and BTW we're taking the name with us so on the other side of the planet, people will be installing nails using our hammer shaped fork of Screwdriver(tm) what could possibly go wrong? Oh no you won't, at least with my trademarked name. (consults with lawyers inserted here) Um, yeah I guess you're right we're gonna rename our hammer shaped screwdriver the Hammer(tm). And years later the worlds carpenters happily use Screwdriver(tm) and Hammer(tm) and sometimes both at the same jobsite without knowing the somewhat contentious history of those different tools.
The two user communities have little if any overlap. This near total lack of overlap lets the two communities live together in peace and plugins generally interoperate etc etc. More like relations between the Word and Excel communities than like Android vs iPhone communities. Aside from that exciting little trademark spat a long time ago relations have always appeared pretty calm and cool.
I admin'd a large nagios system a bit more than a decade ago that basically pinged the heck out of a large number of customers using configs generated by polling our own network devices automatically (read only access, auto generated configs, etc). It depended on the system being simple stable reliable and fast, it was always speed limited in deployment. I needed Oracle support like I needed a hole in head, so new complicated slow unstable features held negative appeal for that implementation. So I stuck with nagios, although I can totally understand a user with a completely different use case needing icinga. I wonder if that system is still running at ex-employer? Probably. It was pretty bulletproof software.
- scottlamb 12y ago> Maybe rephrased some people have to ping 10K boxes per minute and other people have to check 1000 services or files or aspects on 10 boxes and its not REALLY possible for the same codebase to serve both groups equally well in actual real world practice. Really? Why? The first thing seems quite easy all around. Configuration-wise one would expect it to be simple. Computation-wise, pinging 10K boxes per minute means sending <200 packets per second (and receiving at most the same number). Maybe 3X that or so to get multiple samples. That's nothing for a modern machine. The second one obviously requires some more complexity but I don't know why the extensible configuration and plugin system it'd require would have to interfere with simply pinging a bunch of machines. Computation-wise, again sending <200 requests per second should be trivial unless they're spectacularly heavy-weight. The Nagios plugin protocol does seem to be somewhat heavy-weight, though. Looks like it still fork()+exec()s on every probe? https://nagios-plugins.org/doc/guidelines.html https://nagios-plugins.org/doc/guidelines.html That seems like a much greater problem in terms of computation than the actual probes themselves, particularly if probes are written in a scripting language with non-trivial startup overhead. Doesn't look like Icinga is any different? What significant architectural differences exist between the two?
- teh_klev 12y agoNagios has an embedded Perl interpreter[0] so it's possible to avoid fork()/exec() if performance is critical. There are some caveats about how to use and code for it though [1]. [0]: http://nagios.sourceforge.net/docs/nagioscore/3/en/embeddedperl.html http://nagios.sourceforge.net/docs/nagioscore/3/en/embeddedp... [1]: http://nagios.sourceforge.net/docs/nagioscore/3/en/epnplugins.html http://nagios.sourceforge.net/docs/nagioscore/3/en/epnplugin...
- devonkim 12y agoThe downsides and caveats are very similar to writing mod_perl based web apps last I saw those docs. The downsides shouldn't be a problem for most Nagios plugins though since they shouldn't require state hopefully.
- xorcist 12y ago