Need help

[Alan DeKok]

Valts Mazurs wrote:
> I already had a suspicion that I would get reply to my previous email
> really fast.

  That's what happens when you troll on a list.

> Alan DeKok wrote:
>>   If you're going to bash the server and direct people to your own
>> product, I suggest you unsubscribe.
> 
> This is not the case.

   Simple contradiction doesn't establish your point, or make mine not true.

> I have been user of FreeRADIUS for very long
> time, and I (and company I worked for then) decided that it will be
> much easier and comfortable to make small RADIUS server which would not
> be designed for general use. It's main purpose is to provide easy and
> stable backend for writing modules in Python. I tried to do the same
> with FreeRADIUS some time ago. There were fixes to rlm_python but it
> still has never worked as expected (at least on all my systems).

  Hmm..  You're saying it's easier to write & support a complete RADIUS
server than to fix rlm_python.  Right.

> I am not going to redirect any FreeRADIUS user to my product.

  So when you said people should use bsdradius, you were doing what,
exactly?

> The very
> most of FreeRADIUS users don't want to develop their own modules in
> Python.
> Oh, and I am so unlucky to be the maintainer of another RADIUS project.
> Seems like this is very serious reason for bashing me.

  Ah, yes.  I'm being rude for asking you to follow common politeness.

> In case of all known radius servers they become slow when there's
> serious business logic implemented in the backend.

  You've successfully optimized the backends by writing a BSD-licensed
server?

  i.e. This response indicates that your web site claims about the need
for a fast, small server are B.S.

> And what if
> authorization requests had higher priority than the accounting ones?

  You can do this with FreeRADIUS.  Read the config files, and the
documentation for the "nice" command.

> And what if accounting response could be sent even before processing
> the request? It is a major speedup. It is optimization in design, not
> in several parts of code.

  It optimizes away robust accounting.  That's a non-starter for anyone
who's basing a business on correct accounting.

  FreeRADIUS won't be implementing this "feature"  It can destroy a
business.

> In VoIP world 50 requests per second is nothing BIG. Users begin
> and terminate their sessions very often. The main reason is bad
> link quality which results in many unsuccessful call attempts.

  Is that near the 1000's/s limit I said?  Nope.  Then why the B.S.
claims about the need for a fast & efficient server?

>>   "reduce code size" - Nonsense.
> 
> I think that code size matters, a lot. It is much easier to hold in
> your head all the stuff if it takes less space. The same is with
> screen.

  Try using something called "structured programming".  It helps.

> Just, please, Alan, don't take it so personally that there are other
> RADIUS servers in the world.

  It's easier to dismiss my points by labelling me as taking it
"personally".  It's harder to dismiss my points by arguing the facts.

> P.S.
> You should take a look at openradius.org I really like the idea when
> RADIUS server communicates with modules through pipes.

  Really?  Wow... it's only been listed as another open source RADIUS
server on freeradius.org for what, 3-4 years now?

  And the author of OpenRADIUS hasn't trolled in this list, either.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog