From owner-freebsd-current@FreeBSD.ORG Sat Sep 11 13:06:34 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 CB9D310656B1; Sat, 11 Sep 2010 13:06:34 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3A0E68FC17; Sat, 11 Sep 2010 13:06:33 +0000 (UTC) Received: by fxm4 with SMTP id 4so2734882fxm.13 for ; Sat, 11 Sep 2010 06:06:33 -0700 (PDT) Received: by 10.223.121.147 with SMTP id h19mr1421811far.76.1284210392829; Sat, 11 Sep 2010 06:06:32 -0700 (PDT) Received: from rnote.ddteam.net (218-139-132-95.pool.ukrtel.net [95.132.139.218]) by mx.google.com with ESMTPS id a7sm1870321faa.21.2010.09.11.06.06.30 (version=SSLv3 cipher=RC4-MD5); Sat, 11 Sep 2010 06:06:31 -0700 (PDT) Date: Sat, 11 Sep 2010 16:06:02 +0300 From: Aleksandr Rybalko To: Doug Barton Message-Id: <20100911160602.23deab03.ray@ddteam.net> In-Reply-To: <4C8ACE52.8060000@FreeBSD.org> References: <4C8A5CA0.1050700@feral.com> <4C8A7ACB.9070408@FreeBSD.org> <20100910234830.87641e07.ray@ddteam.net> <4C8ACE52.8060000@FreeBSD.org> X-Mailer: Sylpheed 3.0.3 (GTK+ 2.20.1; i386-portbld-freebsd8.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: David DEMELIER , Julien Laffaye , Matthew Jacob , 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: Sat, 11 Sep 2010 13:06:34 -0000 On Fri, 10 Sep 2010 17:33:22 -0700 Doug Barton wrote: > On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote: > > > > Hi, > > > > another argument about hostapd :) if have access point we must have > > way to assign IP for AP clients. > > To start with, your assumption is wrong. DHCPd is not *actually* a > requirement, although I admit that practically it is. > > > Last spring I made firmware based on FreeBSD for router with only 4MB > > NOR flash (D-Link DIR-320). > > In this category (micro-miniaturization) you're already in the > "significant customization needed" area, which means that general > arguments about "the base" don't apply. > > > Since this device is router I must be > > able to serve DHCP. And current implementation of dhcpclient, that we > > have, is same isc-dhcp, and I replace system dhcpclient with ports > > one+dhcpd but with small patch that put basic dhcp utils onto > > libdhcp.so. > > Your argument is creative and well thought out, but I personally don't > find it persuasive. Counter arguments that come immediately to mind are: > 1. The DHCP server is not going to benefit any but a small minority of > FreeBSD users. > 2. The software is already available in the ports tree, and adding a > port/package of it really is not an overwhelming burden. > > More generally, the main reason I want to keep more stuff out of the > base, and remove some of the stuff that's in there now, is that it makes > maintenance difficult across FreeBSD branches. We have a general policy > that if we have a major version N of something in a release branch that > we don't upgrade that major version without a really good reason to > avoid POLA surprises for our users. Once again using BIND as an example, > this has led to a really old and past-EOL version of BIND in FreeBSD 6 > which I've only gotten away with because anyone doing serious DNS work > nowadays has to upgrade to at least 9.6 anyway. But it's an ugly > situation, and I don't want to repeat it. > > The problems get worse and/or more complex with the more 3rd party stuff > you start including in the base. In part because of the product > lifecycle issues that are similar to BIND's, but also due to the > possibility of licensing issues (such as with gcc and/or other GPL > software) and other more esoteric factors. > > Even with home-grown stuff like our pkg_* tools we have problems because > when we want to introduce new features (or deprecate old ones) there is > currently a _minimum_ 3-year cycle we have to follow in order to make > sure that the new feature is/is not available on all supported versions > of FreeBSD. That's the main motivation behind my continuing to repeat > the suggestion to move those tools specifically into the ports tree so > that we can better support innovation in our ports/packages system. > > In my view what we've needed to do for a long time now is to seriously > strip down the notion of what "the base" should be to those items that > are needed to work together for a specific API/ABI/AKI release, and move > everything else into the ports tree. (Obviously there would be some > exemptions made for really basic/vital stuff like ls, etc.) We can do > this in a way that finds a middle ground between the linux model where > literally everything is a package and the traditional BSD model of > providing a "complete system," which is hardly ever true since I've > never been involved with any FreeBSD system administration where there > were absolutely no ports/packages installed at all. > > Such a system could also be streamlined by creating a ports virtual > category (something like "system") the packages for which could be > included in the install media as long as we are judicious about what > goes in there. Things like wpa_supplicant, dhclient, DNS tools, etc. > could all be in that category, and all we'd have to do to make that work > is to very slightly expand the list of questions that sysinstall already > asks. > > So this is a much longer version of my previous response which hopefully > gives you more background about why it's a bad idea to add *any* more > 3rd party stuff to the base. > > > 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/ > Hi, I fully agree with a small exception: Base dhclient -rwxr-xr-x 1 ray wheel 109296 Sep 11 15:53 dhclient Modified isc-dhcp -rwxr-xr-x 1 ray wheel 65316 Jun 4 12:33 dhclient -rwxr-xr-x 1 ray wheel 74768 Jun 4 12:33 dhcpd -rwxr-xr-x 1 ray wheel 12624 Jun 4 12:33 dhcrelay -rwxr-xr-x 1 ray wheel 128752 Jun 4 12:33 libdhcp.so 3 tools basically use same code (I move this code in libdhcp) Now in base already most of this code (Thought this is 70-80%%), why not pick up the remaining 20-30%% that add two useful tools. Maybe better way is writing BSD licensed client/server/relay? Thanks -- Aleksandr Rybalko