From owner-freebsd-current@FreeBSD.ORG Wed Sep 15 18:27:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FB8C106564A for ; Wed, 15 Sep 2010 18:27:27 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 49BCD8FC16 for ; Wed, 15 Sep 2010 18:27:27 +0000 (UTC) Received: (qmail 13798 invoked by uid 399); 15 Sep 2010 18:27:26 -0000 Received: from localhost (HELO ?192.168.0.142?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 15 Sep 2010 18:27:26 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4C91100C.5060502@FreeBSD.org> Date: Wed, 15 Sep 2010 11:27:24 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: "M. Warner Losh" References: <20100910234830.87641e07.ray@ddteam.net> <4C8ACE52.8060000@FreeBSD.org> <20100915.082513.802140508206832836.imp@bsdimp.com> In-Reply-To: <20100915.082513.802140508206832836.imp@bsdimp.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: DHCP server in base X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 18:27:27 -0000 On 9/15/2010 7:25 AM, M. Warner Losh wrote: > Yea. I agree too. Just because BIND was EOLd in 6 isn't a great > argument against dhcp server. That rather clearly was not the only element of my argument, and not only is it disingenuous for you to indicate that it was, I don't appreciate you doing so. > Most of the code is there anyway, and it isn't evolving as fast as BIND. That is actually a more rational argument, even if I don't agree with it. FWIW, part of the reason that I don't agree with it is that at some point, hopefully in the near future, we will want to include the DHCPv6 client in the mix somewhere; and when we do the code base is not going to be as stable as we have enjoyed so far with the v4 dhclient. > It would be very convenient to have this particular thing in the base, > and we shouldn't be too dogmatic about never having any new 3rd party > things in the base. After all, we just added more compression > utilities to the base, and nobody said a peep. I actually thought that change was rather silly, but it was clear that there was so much critical mass in favor of it that there was no point in stating a dissenting opinion. As part of the project's leadership you should be careful not to mistake silence for agreement, or worse, support. > This is analogous: we > have good opportunity to integrate into the system, and users benefit > from that integration. Given your perspective of wanting more of a complete system in the base I can certainly see how you would be supportive of this change. My intent was to make the argument in a general way that this is the wrong direction to go, and that users would benefit *more* from a robust modularized system. The fact that the v4 DHCPd might accidentally be a good candidate for including in the base today doesn't mean that doing so is the right strategy for the long term. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/