bug-inetutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: inetd and whois


From: Jeff Bailey
Subject: Re: inetd and whois
Date: Fri, 2 Aug 2002 10:22:48 -0700
User-agent: Mutt/1.3.28i

On Fri, Aug 02, 2002 at 06:50:49PM +0200, Marco d'Itri wrote:

> (Looks like I have been unsubscribed from this mailing list because 90%
> of the traffic is made of trivially recognizable Korean spam which is
> bounced by my mail servers. Can you add a few patterns to the mailman
> configuration?)

Spam filtering is scheduled to go in today.  I haven't heard if the
folks working on it are on track or not, sorry.

>  >> BTW, the debian whois package comes with a mkpasswd command I wrote,
>  >> can you help finding a home for it in inetutils or in another GNU
>  >> package?

>  >What does it do?

> It does crypt a password using crypt(3).

Lemme look around to see if I can find a good package for it.  I may
ask the shellutils folks if they'll take it.

>  >> My opinion as a developer is that debian is not even going to
>  >> consider replacing anything with inetutils until its code will
>  >> be better than the other alternatives (and still be compatible
>  >> with them).  It's not like there are no free implementations of
>  >> network daemons.

>  >Sure, but netkit doesn't run on BSD or the Hurd.  Inetutils already

> You may guess how many debian users actually care... A huge number
> of packages does not work with hurd, I assume hurd users someday
> will fix them and/or the kernel.

Mm.  It's amazing how few Debian developers care about quality and
standards, the current DPL among them.  All we can do is keep trying.

>  >runs on all of these.  I'm hoping that Inetutils will have the
>  >required features within a year.

> I'm not going to wait a year. I need a good inetd in debian *now*.

Well, you've already said that you were going to port another
daemon. =)

You're welcome to hack the code into the current code base of our
inetd, but your changes may get lost during the rewrite.  Our roadmap
definitely includes purging all non-FSF copyrwritten code from our
code base.  When I (or someone else) rewrites inetd, we *cannot* refer
to the original code.

>  >The point is that between mailutils and inetutils, we have a dozen
>  >programs that need to share this.  I want to hand off to a function
>  >call that returns me file handles to work with.  I shouldn't have to
>  >worry about how I got there.

> If a programs is started by inetd you get a working fd on stdin,
> that's all. A generic function for self-spawning daemon is a good
> idea, but it's not really related to what is needed to have e.g. a
> multithreaded daemon.

Well, multithreading is a special case.  The others aren't, though.

>  >I haven't and I can't if I want to be able to code this.  Is there
>  >a public API reference?  I don't object to working from that.  If
>  >there

> There are the BSD man pages.

Cool.  I'll try to remember that when I'm thinking about it later.

Tks,
Jeff Bailey

-- 
I reincarnated for this?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]