Re: DHCP server in base
David DEMELIER said: > I agree that for some people it will be completely useless, but if we > can disable it in src.conf everyone will be happy. Since FreeBSD is > great for a router it's really fast to make a full working server > without installing anything else. What is the problem of installing something else? You are probably ignoring that many people are complaining about the presence of sendmail, bind, perl etc. in the base system from ages, indeed X and perl have been removed, and it is clear that the consensus is to make the base smaller not bigger. And frankly i have *very* hard time to think that a DHCP server in the base has any utility. why not maxima for example? I am interested in formal computation, you are interested in routers, another one likes images and would want gimp, and so on. -- Michel TALON ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
2010/9/25 Marcin Cieslak : >>> M. Warner Losh wrote: > >>: 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. >> >> Yea. I agree too. Just because BIND was EOLd in 6 isn't a great >> argument against dhcp server. Most of the code is there anyway, and >> it isn't evolving as fast as BIND. >> >> It would be very convenient to have this particular thing in the base, >> and we shouldn't be too dogmatic about never having any new 3rd party >> things in the base. After all, we just added more compression >> utilities to the base, and nobody said a peep. This is analogous: we >> have good opportunity to integrate into the system, and users benefit >> from that integration. > > As a road-warrior consultant I really value having things like > bootpd, tftpd, bootparamd and similar software always there. > Many times I wished dhcpd was there, too. > > Another typical use - FreeBSD makes a good small network router out > of the box (PPP, NAT, ipfw, WLAN AP, DNS are there, dhcpd - missing). > > I am not sure about the whole "modularization" goal - I think > the relatively monolythic nature is one of the FreeBSD's merits. > > For example, it's good to have NFSv4, Kerberos and required > userland daemons packaged in the base. I don't want to have > those done separately in a modular way (although Heimdal > we have is older then what their current trunk is). > We got stuck on connecting Linux boxes via NFSv4 to Solaris > and BSD because one of the userland modules in Linux was terribly > out of date and authenticating the user w/Kerberos was not possible. > > As we build a more complex networking landscape with VIMAGE and > friends I think that the benefits of better integration of dhcpd > in the base system (rc.d, rc.conf...) may outweigh its costs > (maintenance, bloat, etc.). > > //Marcin > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > I agree that for some people it will be completely useless, but if we can disable it in src.conf everyone will be happy. Since FreeBSD is great for a router it's really fast to make a full working server without installing anything else. I agree for the 70% part of dhcp which is already present. In any case, src.conf(5) is still working and usable, isn't it? Kind regards, -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
On 25 September 2010 21:10, Darren Pilgrim wrote: > M. Warner Losh wrote: > >> It would be very convenient to have this particular thing in the base, and >> we shouldn't be too dogmatic about never having any new 3rd >> party things in the base. >> > > Please no, don't add optional servers to the base. I already don't like > sendmail, bind, ntpd and inetd in the base. These are *optional* > software--not required for the normal operation of the OS. They aren't > even enabled by default except sendmail. Adding sendmail_enable="NONE" > to /etc/rc.conf is one of the first things I do on all new systems. I > only barely tolerate openssl in the base because it's needed for > openssh; however, I'd rather both of those be in ports as well. > > There's also the issue of updating: > > It's very annoying to have to update the OS just to fix a BIND or > OpenSSL vulnerability and, let's be honest, we'll likely never see the > last of those. Rebooting a production server is non-trivial. By-hand > partial installworlds on live systems are a disturbing prospect. If it > was a port, just update the port. Its far easier justifying updating a > port than modifying the OS on a production server. The Ports System > makes updating a port so fast and painless I can do many of the > non-user-facing ones without an announced downtime. > > It's trivial installing ports and utterly so installing packages. I'd > love to see us use the awesomeness that is the Ports System to manage > these things. > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > have a look at man src.conf and named_program ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
>> M. Warner Losh wrote: >: 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. > > Yea. I agree too. Just because BIND was EOLd in 6 isn't a great > argument against dhcp server. Most of the code is there anyway, and > it isn't evolving as fast as BIND. > > It would be very convenient to have this particular thing in the base, > and we shouldn't be too dogmatic about never having any new 3rd party > things in the base. After all, we just added more compression > utilities to the base, and nobody said a peep. This is analogous: we > have good opportunity to integrate into the system, and users benefit > from that integration. As a road-warrior consultant I really value having things like bootpd, tftpd, bootparamd and similar software always there. Many times I wished dhcpd was there, too. Another typical use - FreeBSD makes a good small network router out of the box (PPP, NAT, ipfw, WLAN AP, DNS are there, dhcpd - missing). I am not sure about the whole "modularization" goal - I think the relatively monolythic nature is one of the FreeBSD's merits. For example, it's good to have NFSv4, Kerberos and required userland daemons packaged in the base. I don't want to have those done separately in a modular way (although Heimdal we have is older then what their current trunk is). We got stuck on connecting Linux boxes via NFSv4 to Solaris and BSD because one of the userland modules in Linux was terribly out of date and authenticating the user w/Kerberos was not possible. As we build a more complex networking landscape with VIMAGE and friends I think that the benefits of better integration of dhcpd in the base system (rc.d, rc.conf...) may outweigh its costs (maintenance, bloat, etc.). //Marcin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
M. Warner Losh wrote: It would be very convenient to have this particular thing in the base, and we shouldn't be too dogmatic about never having any new 3rd party things in the base. Please no, don't add optional servers to the base. I already don't like sendmail, bind, ntpd and inetd in the base. These are *optional* software--not required for the normal operation of the OS. They aren't even enabled by default except sendmail. Adding sendmail_enable="NONE" to /etc/rc.conf is one of the first things I do on all new systems. I only barely tolerate openssl in the base because it's needed for openssh; however, I'd rather both of those be in ports as well. There's also the issue of updating: It's very annoying to have to update the OS just to fix a BIND or OpenSSL vulnerability and, let's be honest, we'll likely never see the last of those. Rebooting a production server is non-trivial. By-hand partial installworlds on live systems are a disturbing prospect. If it was a port, just update the port. Its far easier justifying updating a port than modifying the OS on a production server. The Ports System makes updating a port so fast and painless I can do many of the non-user-facing ones without an announced downtime. It's trivial installing ports and utterly so installing packages. I'd love to see us use the awesomeness that is the Ports System to manage these things. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
In message: <4c91100c.5060...@freebsd.org> Doug Barton writes: : > Most of the code is there anyway, and it isn't evolving as fast as : > BIND. : : That is actually a more rational argument, even if I don't agree with : it. FWIW, part of the reason that I don't agree with it is that at : some point, hopefully in the near future, we will want to include the : DHCPv6 client in the mix somewhere; and when we do the code base is : not going to be as stable as we have enjoyed so far with the v4 : dhclient. True, but that still won't change the dynamic that adding a dhcp server is easy give we have most of one already in the tree. Adding v6 support likely will mean a certain amount of code churn, I'll grant you that. But the code/api churn that's happening is within a single program, making it much easier to MFC as necessary to keep up. : > This is analogous: we : > have good opportunity to integrate into the system, and users benefit : > from that integration. : : Given your perspective of wanting more of a complete system in the : base I can certainly see how you would be supportive of this : change. My intent was to make the argument in a general way that this : is the wrong direction to go, and that users would benefit *more* from : a robust modularized system. The fact that the v4 DHCPd might : accidentally be a good candidate for including in the base today : doesn't mean that doing so is the right strategy for the long term. I take a more nuanced view: we have to evaluate each proposed addition to the system on its merits. One of these criteria is long term viability, but others include how useful is it to the users; how much demand will there be; will including it make the project look good?; will not including it make the project look bad?; etc We'd all like to see a more modular base, but until that nut is cracked, we have a balancing act to perform. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
On 9/15/2010 7:25 AM, M. Warner Losh wrote: Yea. I agree too. Just because BIND was EOLd in 6 isn't a great argument against dhcp server. That rather clearly was not the only element of my argument, and not only is it disingenuous for you to indicate that it was, I don't appreciate you doing so. Most of the code is there anyway, and it isn't evolving as fast as BIND. That is actually a more rational argument, even if I don't agree with it. FWIW, part of the reason that I don't agree with it is that at some point, hopefully in the near future, we will want to include the DHCPv6 client in the mix somewhere; and when we do the code base is not going to be as stable as we have enjoyed so far with the v4 dhclient. It would be very convenient to have this particular thing in the base, and we shouldn't be too dogmatic about never having any new 3rd party things in the base. After all, we just added more compression utilities to the base, and nobody said a peep. I actually thought that change was rather silly, but it was clear that there was so much critical mass in favor of it that there was no point in stating a dissenting opinion. As part of the project's leadership you should be careful not to mistake silence for agreement, or worse, support. This is analogous: we have good opportunity to integrate into the system, and users benefit from that integration. Given your perspective of wanting more of a complete system in the base I can certainly see how you would be supportive of this change. My intent was to make the argument in a general way that this is the wrong direction to go, and that users would benefit *more* from a robust modularized system. The fact that the v4 DHCPd might accidentally be a good candidate for including in the base today doesn't mean that doing so is the right strategy for the long term. 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/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
In message: David DEMELIER writes: : 2010/9/11 Doug Barton : : > 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. : > : : 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. Yea. I agree too. Just because BIND was EOLd in 6 isn't a great argument against dhcp server. Most of the code is there anyway, and it isn't evolving as fast as BIND. It would be very convenient to have this particular thing in the base, and we shouldn't be too dogmatic about never having any new 3rd party things in the base. After all, we just added more compression utilities to the base, and nobody said a peep. This is analogous: we have good opportunity to integrate into the system, and users benefit from that integration. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
2010/9/14 Kevin Oberman : >> Date: Tue, 14 Sep 2010 19:13:58 +0200 >> From: David DEMELIER >> Sender: owner-freebsd-curr...@freebsd.org >> >> 2010/9/14 Marian Hettwer : >> > On Tue, 14 Sep 2010 07:11:28 +0200, David DEMELIER >> > wrote: >> >> 2010/9/13 Gordon Tetlow : >> >>> On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER >> >>> >> >>> wrote: >> >> 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. >> >>> >> >>> Perl is not in the base system anymore. It's in the ports system. >> >>> Gordon >> >> >> >> Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect ! >> > >> > Uh. Perl was moved to ports somewhere in 2002 or 2003, IIRC. >> > Nothing to do with following -current ;-) >> > >> > ./Marian >> > >> >> Oh then I'm confused, why the ports still rewrite links in /usr/bin then ? > > This was a way to avoid breaking the huge number of perl scripts that > had: #!/usr/bin/perl as the first line. If perl simply moved to > /usr/local/bin, this would have broken a LOT of stuff people were doing, > so it was decided to put a link in /usr/bin. The port now has an option > to control this, but it is still there by default: > USE_PERL "Rewritelinks in /usr/bin" on > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: ober...@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > Well I see, thanks ! -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
> Date: Tue, 14 Sep 2010 19:13:58 +0200 > From: David DEMELIER > Sender: owner-freebsd-curr...@freebsd.org > > 2010/9/14 Marian Hettwer : > > On Tue, 14 Sep 2010 07:11:28 +0200, David DEMELIER > > wrote: > >> 2010/9/13 Gordon Tetlow : > >>> On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER > >>> > >>> wrote: > > 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. > >>> > >>> Perl is not in the base system anymore. It's in the ports system. > >>> Gordon > >> > >> Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect ! > > > > Uh. Perl was moved to ports somewhere in 2002 or 2003, IIRC. > > Nothing to do with following -current ;-) > > > > ./Marian > > > > Oh then I'm confused, why the ports still rewrite links in /usr/bin then ? This was a way to avoid breaking the huge number of perl scripts that had: #!/usr/bin/perl as the first line. If perl simply moved to /usr/local/bin, this would have broken a LOT of stuff people were doing, so it was decided to put a link in /usr/bin. The port now has an option to control this, but it is still there by default: USE_PERL "Rewritelinks in /usr/bin" on -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
2010/9/14 Marian Hettwer : > On Tue, 14 Sep 2010 07:11:28 +0200, David DEMELIER > wrote: >> 2010/9/13 Gordon Tetlow : >>> On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER >>> wrote: 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. >>> >>> Perl is not in the base system anymore. It's in the ports system. >>> Gordon >> >> Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect ! > > Uh. Perl was moved to ports somewhere in 2002 or 2003, IIRC. > Nothing to do with following -current ;-) > > ./Marian > Oh then I'm confused, why the ports still rewrite links in /usr/bin then ? -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
On Tue, 14 Sep 2010 07:11:28 +0200, David DEMELIER wrote: > 2010/9/13 Gordon Tetlow : >> On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER >> wrote: >>> >>> 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. >> >> Perl is not in the base system anymore. It's in the ports system. >> Gordon > > Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect ! Uh. Perl was moved to ports somewhere in 2002 or 2003, IIRC. Nothing to do with following -current ;-) ./Marian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
2010/9/13 Gordon Tetlow : > On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER > wrote: >> >> 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. > > Perl is not in the base system anymore. It's in the ports system. > Gordon Oh sorry I didn't saw that ! (I'm not following -current yet). Perfect ! -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
On Mon, Sep 13, 2010 at 12:53 PM, David DEMELIER wrote: > 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. Perl is not in the base system anymore. It's in the ports system. Gordon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
2010/9/11 Doug Barton : > 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. > 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 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/ > > -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
On Fri, Sep 10, 2010 at 10:33:11PM -0700, Kevin Oberman wrote: > > Date: Fri, 10 Sep 2010 17:33:22 -0700 > > From: Doug Barton > > Sender: owner-freebsd-curr...@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. > > It is not. I routinely use hostapd for access for my iPod. I use > static addressing and don't run dhcpd. With IPv6 you can additionally use stateles autoconfiguration. The requirement for autoconfiguration with DHCP is a problem of IPv4, which won't have a long future for mainstream purspose anymore. Nevertheless there must be a decision about base and not-base and this point will always be questionable to some. I'm also not very strict about bind - it is handy to have dig available, but at the same time it is handy to have whois available, but the whois in base isn't good enough anymore for most cases. A DHCP client however can be required for initial network configuration to retrieve further packages. dig and co can be handy to debug initial network problems, but there are other tools in base for those problems. But to repeat a point which was already made: Someone who can configure a DHCP server really shouldn't have problems to install a package - installing packages or ports is so basic for an operationg system that this is likely one of the first things to learn. Additionally there are ready made systems based on FreeBSD for special purpose, which probably come with the required tools. > > > 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. DHCP servers don't have to live on routers and there are many reasons to have them installed somewhere else. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
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
Re: DHCP server in base
> Date: Fri, 10 Sep 2010 17:33:22 -0700 > From: Doug Barton > Sender: owner-freebsd-curr...@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. It is not. I routinely use hostapd for access for my iPod. I use static addressing and don't run dhcpd. > > 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. Again, I tend to not make much use of DHCP except when traveling. If I am on a "known" network at work or home, I static address everything (including the iPod and my laptop). I don't need (or run) dhcpd for my use. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
On 09/10/2010 19:14, jhell wrote: > On 09/10/2010 14:36, Doug Barton wrote: >> On 9/10/2010 9:54 AM, David DEMELIER wrote: >>> 2010/9/10 Matthew Jacob: I think not. You are given the opportunity to install prebuilt packages at install time, and with a modest amount of effort can install prebuilt packages afterwards. IMO, such as it is, there should be *less* in the base system than there currently is and more in ports. > >> I agree with Matt on this one, although that shouldn't be a surprise >> since I'm on record saying it often. :) > >>> In this case there are some parts in base/ that could live in >>> ports/ instead of the base directory such as hostapd(8), maybe >>> nobody want to make a usable wireless access point? > >> Unfortunately arguing to include something new in the base because >> something else that you don't agree with is already there is not a >> valid method. The bar is a lot higher for adding things than keeping >> things (for better or worse). > >>> And what about bind too? > >> As I've said many times, I'm ready to have it out when there is >> consensus to do so. The usual discussion goes like this: > >> 1. Get BIND out of the base! 2. If we remove it, the command line >> tools (dig, host, nslookup) go with it. 3. Oh, well, we like those, >> so keep them, but get rid of the rest! 4. BIND is library based, so >> 90% of the work to make the command line tools is building the libs, >> after which building the server and its accessories is trivial work. >> 5. Oh, well, then make knobs to disable the server! 6. That's already >> done. 7. Oh, well, never mind then *mumble mumble* > >> However, all that is likely to change at some point in the future >> (as in, years from now) when BIND 10 becomes the only and/or most >> viable option since it requires a lot of stuff that we are unlikely >> to ever import into the base (like boost, python, etc.). So there is >> hope for you anti-BIND folks yet! :) > > >> Doug > > > This is where I say: I believe it would be the correct route to move > toward a base package system for things like BIND DHCP... the common > stuff that people would like to see in base but not really a > conceptional sound idea. > > My theory behind this goes like this: Make a base package for > bind-server, bind-utils, bind-tools or whatever you want to call them > with the --package-root defined as /. Do this for ports/lang etc... type > of stuff and ship them with the install CD/DVD's. If the user wants the > base port then there is no harm done and they can trivially add it. This > would leave room for other base system options to include too without > having to permanently move things in and out of base because supporting > them in-tree does not make sense or other reasons. > > Specifically I like this type of idea due to not needing to have a > compiler (GCC) installed at all times. It could simply be added and > removed from the base system by package or installed from ports and > allow the end user to choose what they want when they want it. Stuff > like GCC, BIND, DHCP Servers & other languages for this make sense. Why > Not ? > > > Regards, > > PS: I'll coin this idea (base-board-ports) > > .02 > This is also a conversation for another thread. So please do not let it distract you. -- jhell,v ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/10/2010 14:36, Doug Barton wrote: > On 9/10/2010 9:54 AM, David DEMELIER wrote: >> 2010/9/10 Matthew Jacob: >>> I think not. You are given the opportunity to install prebuilt >>> packages at install time, and with a modest amount of effort can >>> install prebuilt packages afterwards. >>> >>> IMO, such as it is, there should be *less* in the base system >>> than there currently is and more in ports. > > I agree with Matt on this one, although that shouldn't be a surprise > since I'm on record saying it often. :) > >> In this case there are some parts in base/ that could live in >> ports/ instead of the base directory such as hostapd(8), maybe >> nobody want to make a usable wireless access point? > > Unfortunately arguing to include something new in the base because > something else that you don't agree with is already there is not a > valid method. The bar is a lot higher for adding things than keeping > things (for better or worse). > >> And what about bind too? > > As I've said many times, I'm ready to have it out when there is > consensus to do so. The usual discussion goes like this: > > 1. Get BIND out of the base! 2. If we remove it, the command line > tools (dig, host, nslookup) go with it. 3. Oh, well, we like those, > so keep them, but get rid of the rest! 4. BIND is library based, so > 90% of the work to make the command line tools is building the libs, > after which building the server and its accessories is trivial work. > 5. Oh, well, then make knobs to disable the server! 6. That's already > done. 7. Oh, well, never mind then *mumble mumble* > > However, all that is likely to change at some point in the future > (as in, years from now) when BIND 10 becomes the only and/or most > viable option since it requires a lot of stuff that we are unlikely > to ever import into the base (like boost, python, etc.). So there is > hope for you anti-BIND folks yet! :) > > > Doug > This is where I say: I believe it would be the correct route to move toward a base package system for things like BIND DHCP... the common stuff that people would like to see in base but not really a conceptional sound idea. My theory behind this goes like this: Make a base package for bind-server, bind-utils, bind-tools or whatever you want to call them with the --package-root defined as /. Do this for ports/lang etc... type of stuff and ship them with the install CD/DVD's. If the user wants the base port then there is no harm done and they can trivially add it. This would leave room for other base system options to include too without having to permanently move things in and out of base because supporting them in-tree does not make sense or other reasons. Specifically I like this type of idea due to not needing to have a compiler (GCC) installed at all times. It could simply be added and removed from the base system by package or installed from ports and allow the end user to choose what they want when they want it. Stuff like GCC, BIND, DHCP Servers & other languages for this make sense. Why Not ? Regards, PS: I'll coin this idea (base-board-ports) .02 - -- jhell,v -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMirvXAAoJEJBXh4mJ2FR+SocH/3pK3s8L9bOb12a6IhhrKSdI mJZeFSyMdx3n4olIkd1VhYA2O6Qsl6hUBASitpbiJ3/9Vz/BAcCW2JE+Ub0rDwZT SG7vk0aaCtjFEBk5xdLM52iDKIGs5uNaKxYQMot0KX4pi/Obm7Pf8AGmQpc8RnSd PBbUX5T0kzbStPE59tQA9gW2UcTxKtx2up+Pzns8mYvUEb+dgEuwPo2rE10aZKuK lnfoZ2LclmQg1KmvzZATrRUxFjHdJQqD4PgPFGEAAWVDlzAFnwQhBufYtyT71lqZ 0T+XW5WQUo6WjjtweyV6uhfPeJUuk+DqkmDGw8oJIRfqYOm3yetSKiOoAgmJ9Qo= =brrR -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
On Fri, 10 Sep 2010 21:06:45 +0200 Julien Laffaye wrote: > On Fri, Sep 10, 2010 at 8:36 PM, Doug Barton wrote: > > As I've said many times, I'm ready to have it out when there is consensus to > > do so. The usual discussion goes like this: > > > > 1. Get BIND out of the base! > > 2. If we remove it, the command line tools (dig, host, nslookup) go with it. > > DragonflyBSD chose to remove BIND and to use drill as a replacement [1]. > Don't know if it meet our requirements, though. > > [1]: http://leaf.dragonflybsd.org/mailarchive/submit/2010-03/msg3.html > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Hi, another argument about hostapd :) if have access point we must have way to assign IP for AP clients. Last spring I made firmware based on FreeBSD for router with only 4MB NOR flash (D-Link DIR-320). 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. So: 1. We already have code for libdhcp in base. 2. We already use isc-dhcp as dhcpclient. 3. We already build small-size embedded routers firmware with DHCP server. 4. We have hostap and other router/AP functionality. So why not include dhcpd in base now? -- Aleksandr Rybalko ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
On Fri, Sep 10, 2010 at 8:36 PM, Doug Barton wrote: > As I've said many times, I'm ready to have it out when there is consensus to > do so. The usual discussion goes like this: > > 1. Get BIND out of the base! > 2. If we remove it, the command line tools (dig, host, nslookup) go with it. DragonflyBSD chose to remove BIND and to use drill as a replacement [1]. Don't know if it meet our requirements, though. [1]: http://leaf.dragonflybsd.org/mailarchive/submit/2010-03/msg3.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
On Fri, Sep 10, 2010 at 11:36 AM, Doug Barton wrote: > On 9/10/2010 9:54 AM, David DEMELIER wrote: >> And what about bind too? > > As I've said many times, I'm ready to have it out when there is consensus to > do so. The usual discussion goes like this: > > 1. Get BIND out of the base! > 2. If we remove it, the command line tools (dig, host, nslookup) go with it. > 3. Oh, well, we like those, so keep them, but get rid of the rest! > 4. BIND is library based, so 90% of the work to make the command line tools > is building the libs, after which building the server and its accessories is > trivial work. > 5. Oh, well, then make knobs to disable the server! > 6. That's already done. > 7. Oh, well, never mind then *mumble mumble* Possibly off-topic for this particular thread, but the above reminded me of what DragonflyBSD just went through, as they removed BIND from their base install: importing a smaller codeset that provides the same functionality as the BIND tools[1]. However, that may or may not be a net gain, as then you need someone to maintain those non-BIND tools. But, if one looks at the Perl situation when it was removed from base, couldn't one remove BIND, but have the package listed as mandatory install, the way Perl was for awhile (or maybe still is)? This is also something that DragonflyBSD does, using pkgsrc packages for things they want installed by default, but that they don't want to maintain as part of their source tree. Of course, then you have to train everyone to use /usr/local/etc/named instead of /etc/named. :) (But, it's that what major version updates and .0 releases are for?) [1] http://leaf.dragonflybsd.org/mailarchive/submit/2010-03/msg3.html -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
On 9/10/2010 9:54 AM, David DEMELIER wrote: 2010/9/10 Matthew Jacob: I think not. You are given the opportunity to install prebuilt packages at install time, and with a modest amount of effort can install prebuilt packages afterwards. IMO, such as it is, there should be *less* in the base system than there currently is and more in ports. I agree with Matt on this one, although that shouldn't be a surprise since I'm on record saying it often. :) In this case there are some parts in base/ that could live in ports/ instead of the base directory such as hostapd(8), maybe nobody want to make a usable wireless access point? Unfortunately arguing to include something new in the base because something else that you don't agree with is already there is not a valid method. The bar is a lot higher for adding things than keeping things (for better or worse). And what about bind too? As I've said many times, I'm ready to have it out when there is consensus to do so. The usual discussion goes like this: 1. Get BIND out of the base! 2. If we remove it, the command line tools (dig, host, nslookup) go with it. 3. Oh, well, we like those, so keep them, but get rid of the rest! 4. BIND is library based, so 90% of the work to make the command line tools is building the libs, after which building the server and its accessories is trivial work. 5. Oh, well, then make knobs to disable the server! 6. That's already done. 7. Oh, well, never mind then *mumble mumble* However, all that is likely to change at some point in the future (as in, years from now) when BIND 10 becomes the only and/or most viable option since it requires a lot of stuff that we are unlikely to ever import into the base (like boost, python, etc.). So there is hope for you anti-BIND folks yet! :) 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/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
2010/9/10 Matthew Jacob : > I think not. You are given the opportunity to install prebuilt packages at > install time, and with a modest amount of effort can install prebuilt > packages afterwards. > > IMO, such as it is, there should be *less* in the base system than there > currently is and more in ports. > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > In this case there are some parts in base/ that could live in ports/ instead of the base directory such as hostapd(8), maybe nobody want to make a usable wireless access point? And what about bind too? A lot of user do not needs it, by the way there is already src.conf(5) to enable or disable modules, then a WITHOUT_DHCPD would be useful. Cheers. -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
On Fri, Sep 10, 2010 at 05:29:40PM +0200, Alex Dupre wrote: > David DEMELIER ha scritto: > > I was surprised to see that there is no DHCP server in base, obviously > > it's not difficult to fetch the net/isc-dhcp31-server package but for > > people that would like to setup a new server on FreeBSD quickly they > > will take some time to learn how packages framework works or ports and > > it can be annoying. > As someone who changed from FreeBSD to CentOS, due to a job change, let me say that one of the things I greatly prefer about FreeBSD is that they *don't* make very many assumptions about what the user needs, whereas far too many Linux distributions do the opposite, not only throwing in too much, but often making it difficult to work around what they've decided you need. :) So, I would respectfully disagree. It's easy enough to add a dhcp server if desired, and this way, you don't annoy all the people who DON'T want it. Sincerely, -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Willow: Why couldn't he be possessed by a puppy, or some ducks? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
I think not. You are given the opportunity to install prebuilt packages at install time, and with a modest amount of effort can install prebuilt packages afterwards. IMO, such as it is, there should be *less* in the base system than there currently is and more in ports. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DHCP server in base
David DEMELIER ha scritto: > I was surprised to see that there is no DHCP server in base, obviously > it's not difficult to fetch the net/isc-dhcp31-server package but for > people that would like to setup a new server on FreeBSD quickly they > will take some time to learn how packages framework works or ports and > it can be annoying. If you (people) don't know how to use ports/packages probably you shouldn't use FreeBSD. And I hardly think that installing a port requires more knowledge than correctly configuring a DHCP server. Then, why 3.1 and not 4.1? Why not bundling also apache? etc., etc. -- Alex Dupre ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
