On Fri, 10 Sep 2010 17:33:22 -0700 Doug Barton <do...@freebsd.org> 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 <r...@ddteam.net> _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"