Date: Fri, 10 Sep 2010 17:33:22 -0700 From: Doug Barton <dougb@FreeBSD.org> To: Aleksandr Rybalko <ray@ddteam.net> Cc: David DEMELIER <demelier.david@gmail.com>, Julien Laffaye <kimelto@gmail.com>, Matthew Jacob <mj@feral.com>, freebsd-current@freebsd.org Subject: Re: DHCP server in base Message-ID: <4C8ACE52.8060000@FreeBSD.org> In-Reply-To: <20100910234830.87641e07.ray@ddteam.net> References: <AANLkTinK05bS1cojWo70exQuegus8A2=CZQb76kTEh%2BY@mail.gmail.com> <4C8A5CA0.1050700@feral.com> <AANLkTi=VJ%2BVaOOjm5KHFkReYZ0sXT3L7DfcrsA2LPt66@mail.gmail.com> <4C8A7ACB.9070408@FreeBSD.org> <AANLkTimZ46yk7UPtfJ_7kNYGQeqZCPuOiwLwwCLvAkV_@mail.gmail.com> <20100910234830.87641e07.ray@ddteam.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C8ACE52.8060000>