Re: phk malloc, was (Re: ptmalloc2)

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

com>
In-Reply-To: <20050223060503.GA18114@xxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 36
Message-ID: <421c30eb$0$716$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 218.253.82.16
X-Trace: 1109143788 crater_reader.dragonflybsd.org 716 218.253.82.16
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:7772

Dan Melomedman wrote:

> Bill Hacker wrote:
> 
>>I still thing fixing the application is preferable.
> 
> 
> What's there to fix if it's not the application's fault?

*SNIP*

We should call a halt to this.

http://directory.fsf.org/email/spam/MessageWall.html

Has the e-mail address of the developer and maintainer with whom you 
should be having this discussion.
I see no complaints here from that source about kernel problems.

The addressess of the FreeBSD port maintainer and others who have 
contributed patches to fix what I class as serious flaws are listed in 
the Makefile in the ports tree.

The features it touts have largely been bypassed by MTA's and their 
common 'sputniks', which may be why we have heard little of it.  All of 
those, BTW, DO have connection-limit and other load-management settings. 
  MessageWall should have also.

It relies on "firestring, firedns, *daemontools (with 'svscan' 
running)*".  That last entry shouts 'unstable' in a loud voice.

I see nothing that justifies further waste of kernel developers time.

Wrong venue, that's all.

Bill Hacker