Re: Benchmarked tcpserver dlopen() -> qmail_smtpd() VS tcpserver --> fork() --> exec qmail-smtpd

On 5 April 2017 at 17:42, Kai Peter <[email protected]> wrote:
> On 2017-04-04 23:20, Charles Cazabon wrote:
>>
>>
>> That's fine; inventing and solving weird problems can be fun.  It's
>> basically
>> intellecutal masturbation at that point.
>>
> The m* word has an evil touch at least in german ... perhaps in other
> languages not.
>

I have learned to chill and not take offence. Different countries,
different cultures. In my country there are worse things happening.
Nothing is sacred in this world, Koran, Bible, Gita, qmail, postifx,
or my favourite programming language. Nothing matters more than
knowledge. It is just that over the years I have got tired of
modifying generic code like tcpserver. exec is one way of achieving
the common code in tcpserver and leave out non-generic things to
external code. This external code could be a shell script, could be a
compiled binary and also a shared library. After all in all
probability if you do ldd on your executable you will find few shared
libraries already linked duing the linking stage by the ld. Yes the
original tcpserver doesn't have any external library linked to it. But
then it has also become a source of frustration, especially "NO TLS
?". Seriously? No IPV6, I can still manage.

> Initially I wouldn't jump in here, because I wasn't able to give an answer
> to Manvendra's core question. But as nobody did it ... points to the nature
> of lists.
>
> I think I know enough about *qmail that I can safely point out: I know
> nothing about *qmail! Means I cannot and I will not compare me with the
> developers of netqmail and/or patch authors. And my eQmail wouldn't exist at
> all if there would be a continuous, coordinated, less conservative
> development of netqmail. Fortunately nobody have to wait for this. eQmail
> was published because it was looking to me that the community has a need
> for. Some more thoughs:

We are in the same boat. In 1999 the company I worked for - the
largest private ISP in India, went bust along with the dot-com burst.
We had no money to buy new software and hardware and we were paying 1
USD per mailbox to Critical Path for their ISOCOR platform. Tried
sendmail, qmail and postfix. As someone who lives C programming, fell
in love with DJB's code. Yes it is difficult but very carefully
written. Inspite of this carefully written code, it just failed to
perform. The silly qmail syndrome was a disaster. We lost few customer
the first week, but the management was behind me. Probably didn't
sleep for the whole week but managed to tweak the code to make it
qmail work for me. The biggest problem was the queue. I have enough
examples which tell me that qmail needs to be treated like some holy
grail and prevented from modifications. It is better to make mistakes
and learn on the way rather than living in the fear of not modifying
it and learn nothing.

> 1. Performance
>
> I never have had a performance issue with *qmail. Even when, I would setup
> another (high end) server with load balancing. It doesn't make any sense to
> me to save a nanosecond (or less) by adding complexity to the code. The
> readability of the sources is much more important than performance. Not to
> forget that the 'djblibs' are important for *qmail's performance.

Simplicity and readability goes a long way in getting new programmers
understand it. DJB was thorough with the design. In almost all cases,
you will not require to modify. But I have had enough situations where
the stock qmail or netqmail have not been able to handle, especially
when you don't have money to invest in good servers, fast disks and
large memory. In 2000, my team and me had to support 2.2 million users
on just one Sun Solaris Enterprise 3500 box, which incidentally also
ran a badly written, CPU sucking, webmail code. truss used to be
favourite friend those days. Hardware is much better and much cheaper.
Since 2006, I haven't had a situation where I had to bother about
qmail performance. No one does and it really does not matter to most,
whether they run postfix, sendmail. Since sendmail gets installed by
just typing yum/dnf/apt-get, no one really bothers about qmail. The
truth is that it is orphaned.


> Sent with eQmail-1.10-beta1

Nice signature.

-- 
Regards Manvendra - http://www.indimail.org
GPG Pub Key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C