Date: Mon, 13 Sep 2010 21:53:40 +0200 From: David DEMELIER <demelier.david@gmail.com> To: Doug Barton <dougb@freebsd.org> Cc: Aleksandr Rybalko <ray@ddteam.net>, Julien Laffaye <kimelto@gmail.com>, Matthew Jacob <mj@feral.com>, freebsd-current@freebsd.org Subject: Re: DHCP server in base Message-ID: <AANLkTinkJ182=GFTdWW_0OAT6rfoRJPBxnzMyukCeYnR@mail.gmail.com> In-Reply-To: <4C8ACE52.8060000@FreeBSD.org> 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> <4C8ACE52.8060000@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2010/9/11 Doug Barton <dougb@freebsd.org>: > 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 "significa= nt > 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 fi= nd > 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 t= hat > 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 le= d > 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 w= ant > to repeat it. > I agree but like Aleksandr said, almost 70% of dhcp code is already in base so adding 1Mb of dhcpd code wouldn't be too much. I like the idea to keep some parts in the ports tree and move out from the base. Perl is a great example, I don't really understand why it's in the base, then the port need to rewrite the links into the base hierarchy and I think this is bad. > 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 iss= ues > 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 esoter= ic > 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 sur= e > 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 w= e > 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 st= rip > down the notion of what "the base" should be to those items that are need= ed > 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 find= s 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 categ= ory > (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. Thing= s > 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 > > -- > > =C2=A0 =C2=A0 =C2=A0 =C2=A0... and that's just a little bit of history re= peating. > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0-- Propellerheads > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Improve the effectiveness of your Internet pre= sence with > =C2=A0 =C2=A0 =C2=A0 =C2=A0a domain name makeover! =C2=A0 =C2=A0http://Su= persetSolutions.com/ > > --=20 Demelier David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinkJ182=GFTdWW_0OAT6rfoRJPBxnzMyukCeYnR>