Re: DHCP server in base

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/